From vleeschh@sh.bel.alcatel.be Wed, 05 Jan 2000 17:58:00 +0100 Date: Wed, 05 Jan 2000 17:58:00 +0100 From: Hans De Vleeschouwer A0 VR233 58223 vleeschh@sh.bel.alcatel.be Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr Hi, I am trying to work my way through the the ISIS MIB defintion. In doing so, I have a question wrt the field isisManAreaAddr in the mib table IsisManAreaAddrEntryTable: Does this field contain only the area address, or does it also include the actual systemid (i.e. the full NET)? >From the description field, I would assume that only the area id is included, however this seems to be contradicted by looking at its type defintion (being OSINSAddress). Any help is kindly appreciated. Kind regards, hans. From jparker@nexabit.com Wed, 5 Jan 2000 13:11:27 -0500 Date: Wed, 5 Jan 2000 13:11:27 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr > Hi, > > I am trying to work my way through the the ISIS MIB defintion. > > In doing so, I have a question wrt the field isisManAreaAddr > in the mib > table IsisManAreaAddrEntryTable: > > Does this field contain only the area address, or does it also include > the actual systemid (i.e. the full NET)? > > From the description field, I would assume that only the area id is > included, however this seems to be contradicted by looking at its type > defintion (being OSINSAddress). > > Any help is kindly appreciated. > > Kind regards, > hans. Hans - It is only the area portion. I could add another type parallel to the OSINSAddress, but this is the orginal form, and it holds exactly what is needed. - jeff parker isisManAreaAddr OBJECT-TYPE SYNTAX OSINSAddress MAX-ACCESS read-only STATUS current DESCRIPTION "A manually configured area address for this system. This object follows the index behaviour." ::= { isisManAreaAddrEntry 2 } From jparker@nexabit.com Fri, 7 Jan 2000 09:42:15 -0500 Date: Fri, 7 Jan 2000 09:42:15 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr > Hi Jeff, > > Thanks for your reply. > > I am really going through the MIB field by field now. ... > I am not quite sure whether I can contact you with those directly, or > wether I should keep on posting them to the newsgroup? Hans - If you think it isn't of general interest, you might send it only to me. I would rather see traffic to the list, for the selfish reason that I will need at some point to make the case that there has been public comment on the draft. It may also serve to keep me honest. Thus I'm going to copy the list on this reply. > In the mean time I came upon with another question related to the > field isisSysMaxAreaAddresses in the isisSysTable. > > The MIB indicates that the value of this field ranges between > 0 and 254. To be honest, this value is 3. It is 3 in all existing implementations, and it is a show stopper if two implementations don't agree. My ToDo list (see below) has the line isisSysMaxAreaAddresses should be 1..3, not 0..254 You could argue that it should be 3..3 instead. My current ToDo list includes the following items: I do intend to rev the draft this millennium. - jeff parker isisL2SummAddrTable isisL2SummAddrOperState change to AdminState The table name should change to IsisSummAddr instead of IsisL2SummAddr Cisco supports summarization at level-1 also and we have implemented an extended OperState to add this capability Remove isisCircManL2Only - replaced by isisCircLevel CircOperstate should be read-only Only isisCircISISL2HelloMultiplier - should be 2, or one, or none. isisSysMaxAreaAddresses should be 1..3, not 0..254 What is the story with IS(2) vs L1 and L2 below? isisISAdjNeighSysType OBJECT-TYPE SYNTAX INTEGER { unknown(1), intermediateSystem(3), l1IntermediateSystem(4), l2IntermediateSystem(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the neighboring system." REFERENCE "{ISIS.aoi neighbourSystemType (80)}" ::= { isisISAdjEntry 6 } Don't use IP addresses as index - summary table and IP reach table Split off optional parameters Overload bit Compliance - grouping Add boolean to mark L2 to L1 leaking Add Auth Type for MD5 Auth key will need to be a table (Rx values) Clarify UpTime From jparker@nexabit.com Fri, 7 Jan 2000 12:30:23 -0500 Date: Fri, 7 Jan 2000 12:30:23 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr > > To be honest, [isisSysMaxAreaAddresses] is 3. > > It is 3 in all existing implementations, and it is > > a show stopper if two implementations don't agree. > > ... > Just for the record, in IOS, since about a year, you can configure > isisSysMaxAreaAddresses 3..254. You're lucky, IOS does not implement > an ISIS MIB (yet). But I implemented it because of pressure that > some ADM vendors "could do isisSysMaxAreaAddresses up to 8". Also > note that ADMs usually only implement CLNS routing, not IP routing. > For CLNS routing multiple isisSysMaxAreaAddresses is a little more > usefull. Still bad network design, IMHO. Oh, and I don't think any > of our customers use it. ;-) > > Henk. I think Henk has just demonstrated the importance of keeping such conversations on the list. Thanks, Henk! - jeff From Mkontoff@Kontoff.com Fri, 07 Jan 2000 13:47:26 -0500 Date: Fri, 07 Jan 2000 13:47:26 -0500 From: Matthew Kontoff Mkontoff@Kontoff.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr Jeff Parker wrote: > > > > To be honest, [isisSysMaxAreaAddresses] is 3. > > > It is 3 in all existing implementations, and it is > > > a show stopper if two implementations don't agree. > > > > ... > > Just for the record, in IOS, since about a year, you can configure > > isisSysMaxAreaAddresses 3..254. You're lucky, IOS does not implement > > an ISIS MIB (yet). But I implemented it because of pressure that > > some ADM vendors "could do isisSysMaxAreaAddresses up to 8". Also > > note that ADMs usually only implement CLNS routing, not IP routing. > > For CLNS routing multiple isisSysMaxAreaAddresses is a little more > > usefull. Still bad network design, IMHO. Oh, and I don't think any > > of our customers use it. ;-) The Avici TSR supports 1..255 area addresses. Matt From rsaluja@nortelnetworks.com Fri, 07 Jan 2000 14:02:09 -0500 Date: Fri, 07 Jan 2000 14:02:09 -0500 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr Why can't this be 0 ? Do you need at least one manual area address for L2-only router also? To me, it seems that isisSysMaxAreaAddresses can be 0..X. Thanks, Rajesh Matthew Kontoff wrote: > Jeff Parker wrote: > > > > > > To be honest, [isisSysMaxAreaAddresses] is 3. > > > > It is 3 in all existing implementations, and it is > > > > a show stopper if two implementations don't agree. > > > > > > ... > > > Just for the record, in IOS, since about a year, you can configure > > > isisSysMaxAreaAddresses 3..254. You're lucky, IOS does not implement > > > an ISIS MIB (yet). But I implemented it because of pressure that > > > some ADM vendors "could do isisSysMaxAreaAddresses up to 8". Also > > > note that ADMs usually only implement CLNS routing, not IP routing. > > > For CLNS routing multiple isisSysMaxAreaAddresses is a little more > > > usefull. Still bad network design, IMHO. Oh, and I don't think any > > > of our customers use it. ;-) > > The Avici TSR supports 1..255 area addresses. > > Matt > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- From jparker@nexabit.com Fri, 7 Jan 2000 15:20:30 -0500 Date: Fri, 7 Jan 2000 15:20:30 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr What is at stake is the maximum -allowed- (isisSysMaxAreaAddresses) not the number of entries in use (the size of isisManAreaAddrTable.) While a size of 0, 1, 2, or 3 are conceivable for this table, I hope we can agree that we wouldn't want a router that didn't allow the user to include 3 Manual Areas, if the user is so foolish as to want that. I did notice the following MIB variable, which suggests I was hasty in calling this a show stopper (see isisSysMaxAreaCheck) The conclusion I will draw from this is that existing practice allows the variable be 3..255. - jeff parker isisSysMaxAreaCheck OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "When on, enables checking of maximum area addresses per IS version of ISO10589." DEFVAL { 1 } ::= { isisSysEntry 36 } [Messages edited] > Why can't this be 0 ? Do you need at least one manual area address for > L2-only router also? To me, it seems that > isisSysMaxAreaAddresses can be 0..X. > > Rajesh > > > > > > To be honest, [isisSysMaxAreaAddresses] is 3. > > > > > It is 3 in all existing implementations, and it is > > > > > a show stopper if two implementations don't agree. > > > > > > > > > > Jeff Parker > > > > > > > > Just for the record, in IOS, since about a year, you > > > > can configure isisSysMaxAreaAddresses 3..254. > > > > > > > > Henk Smit > > > > The Avici TSR supports 1..255 area addresses. > > > > Matt Kontoff From Radia.Perlman@East.Sun.COM Fri, 7 Jan 2000 15:42:39 -0500 (EST) Date: Fri, 7 Jan 2000 15:42:39 -0500 (EST) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr > > To be honest, [isisSysMaxAreaAddresses] is 3. > > It is 3 in all existing implementations, and it is > > a show stopper if two implementations don't agree. > > Having this be a parameter is, in my opinion, really silly. It's one of the things that the ISO committee added, along with ID size, that seems like unnecessary flexibility, and as Henk pointed out, everyone in the area has to have the same values or it won't work. The reason for area address, if I recall, is so that you can detect accidentally merging two areas, so they have different names. In CLNP it also told level 1 routers what prefixes should be routed via level 1 (look at the bottom 6 ...er ID_length... bytes) or sent to a level 2 router. The reason it's nice to allow more than one area address is to be able to merge or split up areas while the net's running. To merge A and B, add B as an allowable address to A, and A to B, and then when everyone agrees on both names, then one by one turn off one of the addresses. There's really no reason to need 3 -- 2 suffices but 3 seemed like a good idea at the time, maybe so you could simultaneously merge 3 areas, or perhaps it allowed you to be lazy about removing an area address for awhile, but certainly there's no reason to need 107 area addresses! It would be nice to leave it fixed at 3 and remove it from the MIB, I'd think. Radia From jjl@one.com Fri, 07 Jan 2000 16:39:49 -0500 Date: Fri, 07 Jan 2000 16:39:49 -0500 From: Jeff Learman jjl@one.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr Rajesh, Some implementations may permit it to be provisioned to zero, but only because 0 in the PDU actually means "use the standard default of 3". At least one area address is absolutely required to do any CLNP routing at all, which is what IS-IS was originally designed for. A level 2 router is, according to the IS-IS spec "also a level 1 router in its own area", although there may be some implementations that skirt this issue. Practically speaking, though, there isn't any advantage to setting the value below three -- since it has to be the same for all ISs in the area, it's a bad idea to change it from the default of 3 unless you really need to (or *feel* you need to). Jeff At 02:02 PM 1/7/00 -0500, Rajesh Saluja wrote: >Why can't this be 0 ? Do you need at least one manual area address for >L2-only router also? To me, it seems that >isisSysMaxAreaAddresses can be 0..X. > >Thanks, >Rajesh > > >Matthew Kontoff wrote: > >> Jeff Parker wrote: >> > >> > > > To be honest, [isisSysMaxAreaAddresses] is 3. >> > > > It is 3 in all existing implementations, and it is >> > > > a show stopper if two implementations don't agree. >> > > > >> > ... >> > > Just for the record, in IOS, since about a year, you can configure >> > > isisSysMaxAreaAddresses 3..254. You're lucky, IOS does not implement >> > > an ISIS MIB (yet). But I implemented it because of pressure that >> > > some ADM vendors "could do isisSysMaxAreaAddresses up to 8". Also >> > > note that ADMs usually only implement CLNS routing, not IP routing. >> > > For CLNS routing multiple isisSysMaxAreaAddresses is a little more >> > > usefull. Still bad network design, IMHO. Oh, and I don't think any >> > > of our customers use it. ;-) >> >> The Avici TSR supports 1..255 area addresses. >> >> Matt >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg > >-- > >------------------------------------------------------------- >Rajesh Saluja >Nortel Networks Inc 600 Technology Park Billerica, MA 01821 >Ph: (978) 288-7791 Fax: (978) 670-8760 >-------------------------------------------------------------- > > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From jharper@cisco.com Fri, 07 Jan 2000 21:45:40 +0000 Date: Fri, 07 Jan 2000 21:45:40 +0000 From: John Harper jharper@cisco.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr And in fact, it was more or less deliberate perversity on our part at the time to make it this way. We (those of us who worked on the original design at DEC and subsequently took it into ISO) thought the idea of having this as a parameter was really stupid (as Radia says), and we certainly weren't going to waste any of our neurones figuring out how to make misconfiguration recover gracefully, as we generally tried to do in the parts of the protocol that we cared about. Why anyone would see it as a feature to be able to set this to 8 boggles my mind. "I really like this Ferrari, but Caterpillar make vehicles with 96 wheels." "OK signor, in V550.1 we'll add the 96 wheel feature". John At 15:42 07/01/00 -0500, Radia Perlman - Boston Center for Networking wrote: >> > To be honest, [isisSysMaxAreaAddresses] is 3. >> > It is 3 in all existing implementations, and it is >> > a show stopper if two implementations don't agree. >> > > >Having this be a parameter is, in my opinion, really silly. It's >one of the things that the ISO committee added, along with ID size, >that seems like unnecessary flexibility, and as Henk pointed out, >everyone in the area has to have the same values or it won't work. > >The reason for area address, if I recall, is so that you can detect >accidentally merging two areas, so they have different names. In CLNP >it also told level 1 routers what prefixes should be routed via >level 1 (look at the bottom 6 ...er ID_length... bytes) or sent to >a level 2 router. > >The reason it's nice to allow more than one area address is to be able >to merge or split up areas while the net's running. To merge A and B, >add B as an allowable address to A, and A to B, and then when everyone >agrees on both names, then one by one turn off one of the addresses. >There's really no reason to need 3 -- 2 suffices but 3 seemed >like a good idea at the time, maybe so you could simultaneously merge >3 areas, or perhaps it allowed you to be lazy about removing an area >address for awhile, but certainly there's no reason to >need 107 area addresses! > >It would be nice to leave it fixed at 3 and remove it from the MIB, I'd >think. > >Radia > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > From mshand@cisco.com Sat, 08 Jan 2000 10:41:49 +0000 Date: Sat, 08 Jan 2000 10:41:49 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr At 15:42 07/01/2000 -0500, Radia Perlman - Boston Center for Networking wrote: >The reason it's nice to allow more than one area address is to be able >to merge or split up areas while the net's running. To merge A and B, >add B as an allowable address to A, and A to B, and then when everyone >agrees on both names, then one by one turn off one of the addresses. >There's really no reason to need 3 -- 2 suffices but 3 seemed >like a good idea at the time, maybe so you could simultaneously merge >3 areas, or perhaps it allowed you to be lazy about removing an area >address for awhile, but certainly there's no reason to >need 107 area addresses! It was to do with DECnet Phase IV compatibility Radia. Typically an area would have two area addresses, a Phaseiv compatible one, and a real OSI one. So that makes two. Now if you want to merge/split the OSI area you need another one. I think that was the argument anyway. Mike ps. and yes I think a value other than 3 is silly too. From jparker@nexabit.com Sun, 9 Jan 2000 13:35:52 -0500 Date: Sun, 9 Jan 2000 13:35:52 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr While I don't want to claim I understand exactly what Cisco is trying to do, and while I haven't seen any documentation of what Avici is trying to do, I suspect the issue is supporting multiple L1 domains on a single router, not supporting multiple areas in a single domain. That is, I suspect that each of the L1 domains has a single area address: perhaps 2 when needed, and it may wish to implement upto 3. I don't think anyone is talking about recognizing 254 different Areas in the same domain. I would rather capture this as different SysInstances, each running with a different area address, which can then summarize the collection of routes learned into a common L2. I will try to clarify the language surrounding isisSysMaxAreaAddresses, to make clear that this is the Maximum Area Addresses in one Domain. A name change may help that effort. - jeff parker > At 15:42 07/01/2000 -0500, Radia Perlman - Boston Center for > Networking wrote: > >The reason it's nice to allow more than one area address is > to be able > >to merge or split up areas while the net's running. To merge A and B, > >add B as an allowable address to A, and A to B, and then > when everyone > >agrees on both names, then one by one turn off one of the addresses. > >There's really no reason to need 3 -- 2 suffices but 3 seemed > >like a good idea at the time, maybe so you could simultaneously merge > >3 areas, or perhaps it allowed you to be lazy about removing an area > >address for awhile, but certainly there's no reason to > >need 107 area addresses! > > It was to do with DECnet Phase IV compatibility Radia. > Typically an area > would have two area addresses, a Phaseiv compatible one, and > a real OSI > one. So that makes two. Now if you want to merge/split the > OSI area you > need another one. I think that was the argument anyway. > > Mike > > ps. and yes I think a value other than 3 is silly too. From mshand@cisco.com Mon, 10 Jan 2000 08:28:53 +0000 Date: Mon, 10 Jan 2000 08:28:53 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr At 13:35 09/01/2000 -0500, Jeff Parker wrote: >While I don't want to claim I understand exactly what Cisco is >trying to do, and while I haven't seen any documentation of >what Avici is trying to do, I suspect the issue is supporting >multiple L1 domains on a single router, not supporting multiple >areas in a single domain. The two issues are pretty much orthogonal. The former is useful; the latter is not. Mike From vleeschh@sh.bel.alcatel.be Mon, 10 Jan 2000 12:02:44 +0100 Date: Mon, 10 Jan 2000 12:02:44 +0100 From: Hans De Vleeschouwer A0 VR233 58223 vleeschh@sh.bel.alcatel.be Subject: [Isis-wg] Another question wrt to the isisSysTable hi, I have followed the discussion related to the isisSysTable field isisSysMaxAreaAddresses with great interest. For now, I think I will stick to the solution where: 1. the value can range between 1 and 3 2. the default value = 3 This will imply that a request to change the field isisSysOperState to 'on' will be rejected if no entry exists in the isisManAddrTable for this system instance. Now I have a different question related to the field isisSysAuthAreaType. I already understand from Jeff Parker that this field will be extended to allow also MD5 as authentication method. However, I still have the following questions: 1. The description talks about 'protecting L1 LSPs' . However, If I look at the RFC1195, it seems that authentication can apply to all types of messages, not only to LSP PDU. e.g. authentication can be applied to L1 Hello PDUs. Is there any reason to authenticate only the LSP PDU? 2. The value of the field is set to read-write. Would it make sense to state that this object follows the 'replaceOnlyWhileDisabled behavior' ? Kind regards, Hans De Vleeschouwer (alcatel Belgium). From jparker@nexabit.com Mon, 10 Jan 2000 09:49:55 -0500 Date: Mon, 10 Jan 2000 09:49:55 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Another question wrt to the isisSysTable > I have followed the discussion related to the isisSysTable field > isisSysMaxAreaAddresses with great interest. > > For now, I think I will stick to the solution where: > 1. the value can range between 1 and 3 > 2. the default value = 3 > > This will imply that a request to change the field isisSysOperState to > 'on' will be rejected if no entry exists in the isisManAddrTable for > this system instance. > > Now I have a different question related to the field > isisSysAuthAreaType. > I already understand from Jeff Parker that this field will be extended > to allow also MD5 as authentication method. > > However, I still have the following questions: > 1. The description talks about 'protecting L1 LSPs' . > However, If I look > at the RFC1195, it seems that authentication can apply to all types of > messages, not only to LSP PDU. e.g. authentication can be > applied to L1 Hello PDUs. There are four Authentication types: isisSysAuthAreaType - level 1 pkts isisSysAuthDomainType - level 2 pkts isisCircL1PasswordType- level 1 hellos isisCircL2PasswordType- level 2 hellos > Is there any reason to authenticate only the LSP PDU? The dominant implementation only protects the LSPs with the Area and Dommain values. > 2. The value of the field is set to read-write. Would it > make sense to > state that this object follows the 'replaceOnlyWhileDisabled > behavior' ? I need to review this with my SNMP gurus - I don't want to allow these to be set via SNMP for obvious security reasons. > > Kind regards, > Hans De Vleeschouwer (alcatel Belgium). From zinin@amt.ru Wed, 12 Jan 2000 12:21:25 +0300 Date: Wed, 12 Jan 2000 12:21:25 +0300 From: Alex Zinin zinin@amt.ru Subject: [Isis-wg] New ID: draft-ietf-ospf-refresh-guide-00.txt Hello, all A new I-D that can be interesting for the OSPF and IS-IS WGs has been submitted to the IETF directories : "Guidelines for Efficient LSA Refreshment in OSPF" http://www.ietf.org/internet-drafts/draft-ietf-ospf-refresh-guide-00.txt The abstract section from the I-D follows: OSPF, an IGP widely deployed in IP networks today, requires each LSA to be refreshed by the originating router every 30 minutes. This method increases the protocol's robustness and solves potential problems that may be caused by software bugs, as well as some properties of the protocol itself. Though OSPF expects each LSA to be refreshed independently, ABRs and ASBRs tend to originate Type 3/4/5 LSAs within a short period of time, thus causing periodical network resource exhaustion by LSA refreshments. This document discusses the techniques that can be used to remedy this problem and provide smooth protocol operation. It must be noted that discussed methods can be applied to other link-state routing protocols, such as IS-IS. I would like to encourage everyone to send their comments, corrections and questions. Please use the address of the OSPF WG list (OSPF@DISCUSS.MICROSOFT.COM) for postings. It is ok to send the notes to me directly. ALSO, anyone feeling [s]he can contribute something to the document is welcomed to co-author. Best regards, Alex. From tangcm@future.futsoft.com Wed, 12 Jan 2000 18:37:59 +0530 Date: Wed, 12 Jan 2000 18:37:59 +0530 From: Jorge tangcm@future.futsoft.com Subject: [Isis-wg] ask a question . Hi, everyone I am a new member of IS-IS Group. Now i am engaged in the work of implementation for IS-IS over IPv4. i am a newcomer for IS-IS procotol,My dout is that going through all of IS-IS document,i cann't find the content for how the IS-IS over IPv4 protocol supporting the X.25 ,Frame-Relay ,multi-link access network.who can give me some advice for it, i will very appreciated.you know ,i am eager to get those answer.Thanks in advance. HuaWei Development Facility of CHINA Future Software Private Limited 480-481,Mount Road,Nandanam, Chennai-600 -35.Inida From zinin@amt.ru Wed, 12 Jan 2000 19:15:56 +0300 Date: Wed, 12 Jan 2000 19:15:56 +0300 From: Alex Zinin zinin@amt.ru Subject: [Isis-wg] ask a question . Other people will add some input here if my answer is not complete. One way of dealing with NBMA media is assigning the VCs to logical point-to-point or multipoint interfaces. IS-IS is then enabled on the logical rather then physical interfaces, but transmission of a packet over a logical interface results in sending the packet through the physical one. Sending an IP packet over a p-t-p interface is simple, since the layer-2 details are either not necessary (in case of physical links) or predetermined (in case of logical links). Having split the VCs you basically represent an NBMA cloud as a set of p-t-p links. Another way (also used for multipoint logical interfaces) is treating the NBMA cloud as a broadcast media. This requires providing (manually or dynamically as in the case of FR) the information on which VCs should multicast packets be sent over. So, the router replicates the IP packets and sends the copies over each involved VCs. This, of course, implies that you have your VCs fully meshed. Regards, Alex. Wednesday, January 12, 2000, 4:07:59 PM, Jorge wrote: J> Hi, everyone J> I am a new member of IS-IS Group. Now i am engaged in the work of implementation for IS-IS over IPv4. i am a newcomer for IS-IS procotol,My dout is that going through all of IS-IS J> document,i cann't find the content for how the IS-IS over IPv4 protocol supporting the X.25 ,Frame-Relay ,multi-link access network.who can give me some advice for it, i will very appreciated.you J> know ,i am eager to get those answer.Thanks in advance. J> HuaWei Development Facility of CHINA J> Future Software Private Limited J> 480-481,Mount Road,Nandanam, J> Chennai-600 -35.Inida J> _______________________________________________ J> Isis-wg mailing list - Isis-wg@external.juniper.net J> http://external.juniper.net/mailman/listinfo/isis-wg From jjl@one.com Wed, 12 Jan 2000 11:32:57 -0500 Date: Wed, 12 Jan 2000 11:32:57 -0500 From: Jeff Learman jjl@one.com Subject: [Isis-wg] ask a question . At 07:15 PM 1/12/00 +0300, Alex Zinin wrote: >Other people will add some input here >if my answer is not complete. > >One way of dealing with NBMA media >is assigning the VCs to logical point-to-point >or multipoint interfaces. IS-IS is then >enabled on the logical rather then physical >interfaces, but transmission of a packet >over a logical interface results in sending >the packet through the physical one. >Sending an IP packet over a p-t-p interface >is simple, since the layer-2 details are >either not necessary (in case of physical links) >or predetermined (in case of logical links). >Having split the VCs you basically represent >an NBMA cloud as a set of p-t-p links. > >Another way (also used for multipoint logical >interfaces) is treating the NBMA cloud as a >broadcast media. This requires providing (manually >or dynamically as in the case of FR) the information >on which VCs should multicast packets be sent over. >So, the router replicates the IP packets and >sends the copies over each involved VCs. >This, of course, implies that you have your VCs >fully meshed. This should be done with great care (or not at all). In general, it's important to send routing protocol traffic the same way data would be sent, as much as possible. Otherwise, you run the risk of thinking there is a data connection where there is none, or of incomplete distribution of routing information. In particular, pay careful attention to IS-IS's transitivity requirement for broadcast networks -- that is, if A can hear B and B can hear C, then A must be able to hear C. This rule would be easy to violate in a misprovisioned NBMA network, and would probably lead to serious connectivity problems. Regareds, Jeff >Regards, >Alex. > >Wednesday, January 12, 2000, 4:07:59 PM, Jorge wrote: > >J> Hi, everyone >J> I am a new member of IS-IS Group. Now i am engaged in the work of implementation for IS-IS over IPv4. i am a newcomer for IS-IS procotol,My dout is that going through all of IS-IS >J> document,i cann't find the content for how the IS-IS over IPv4 protocol supporting the X.25 ,Frame-Relay ,multi-link access network.who can give me some advice for it, i will very appreciated.you >J> know ,i am eager to get those answer.Thanks in advance. > >J> HuaWei Development Facility of CHINA >J> Future Software Private Limited >J> 480-481,Mount Road,Nandanam, >J> Chennai-600 -35.Inida > > >J> _______________________________________________ >J> Isis-wg mailing list - Isis-wg@external.juniper.net >J> http://external.juniper.net/mailman/listinfo/isis-wg > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From navaneethk@future.futsoft.com Thu, 13 Jan 2000 12:00:23 -0800 Date: Thu, 13 Jan 2000 12:00:23 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] ISH PDU.. Hi all.. In the context of ISIS over IP , I have a doubt as to how the ISH PDUs will be handled and by whom... ISO 10589 1992 mentions that as a exception, ISH PDUs will have to be handled on PPP links when they first come up.. ISO 10589 1998 mentions that the ISIS shall cause ES-IS (9542 protocol machine) to send the ISH PDUs on PPP links.. So Who handles ISH PDU? ES-IS or IS-IS. In a pure IP implementation of ISIS we are not to take care of of ES-IS..In this case who sends the ISH PDU... If it is responsibilty of ES-IS, then why the standard talks about IS sendinh ISH in ISIS document.. Please clarify.. Navaneetha Krishnan.N Senior Software Engineer, HDF, Future Software Pvt Ltd, 480 - 481, Anna Salai, Nandanam, Chennai - 600 035 India. Phone : +91-44-4330550 Ext.412 Resi: 91 044 4338421 (After 10 P.M , Before 8 A.M) From navaneethk@future.futsoft.com Thu, 13 Jan 2000 12:01:02 -0800 Date: Thu, 13 Jan 2000 12:01:02 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] ISH PDU.. Hi all.. In the context of ISIS over IP , I have a doubt as to how the ISH PDUs will be handled and by whom... ISO 10589 1992 mentions that as a exception, ISH PDUs will have to be handled on PPP links when they first come up.. ISO 10589 1998 mentions that the ISIS shall cause ES-IS (9542 protocol machine) to send the ISH PDUs on PPP links.. So Who handles ISH PDU? ES-IS or IS-IS. In a pure IP implementation of ISIS we are not to take care of of ES-IS..In this case who sends the ISH PDU... If it is responsibilty of ES-IS, then why the standard talks about IS sendinh ISH in ISIS document.. Please clarify.. Navaneeth. From kim@telia.net Thu, 13 Jan 2000 23:26:38 +0100 Date: Thu, 13 Jan 2000 23:26:38 +0100 From: Michael Kim kim@telia.net Subject: [Isis-wg] BCP for building Integrated IS-IS Network Hi! I have som question about design issue of the Integrated IS-IS network. Network is 200-300 nodes. Should this network be buildt with multiple level-1 IS-IS area and 1 level-2 IS-IS area or should this be buildt with just big one level-1-2 IS-IS area. I prefer to build network with the first alternative because in the first alternative will keep the database small on the routers. It will take few ms to recalculate SPF. I got recommendation from some vendor that network with this size it will be the best to build with just one big level-1-2 area. Reason is that there will be just one database so it will take less time to recalculate SPF. In the first case there will be some routers talking both level-1 and level-2 so there will be 2 database on those router and for those routers it will take longer time to recalculate SPF. But I think this is wrong becase in second alternative all the router is talking level-1 and level-2 so all of the router will have one level-1 and one level-2 database with bigger LSDB. It will increase recalculation time. Do I think right? Is there any BCP document other recommendation document for build IS-IS network? Thank You in advances /michael From hsmit@cisco.com Thu, 13 Jan 2000 16:46:24 -0800 (PST) Date: Thu, 13 Jan 2000 16:46:24 -0800 (PST) From: hsmit@cisco.com hsmit@cisco.com Subject: [Isis-wg] BCP for building Integrated IS-IS Network > Hi! > I have som question about design issue of the Integrated IS-IS network. > Network is 200-300 nodes. > > Should this network be buildt with multiple level-1 IS-IS area and 1 > level-2 IS-IS area or should this be buildt with just big one level-1-2 > IS-IS area. This all depends on the strength of the IS-IS implementation of your vendor. And on the type of routers that you are using. I know at least one vendor where you can build areas with a 1000+ routers, if you buy their high end boxes. > I prefer to build network with the first alternative because in the > first alternative will keep the database small on the routers. It will > take few ms to recalculate SPF. Yes, the SPFs will be cheaper. But you run two of them. Also the mathemetical part of the SPF is usually not that expensive. Route installation (and FIB updates) is typically more expensive. Also when you use a lot of inter-area routes (L1->L2), it doesn't matter much if you deal with complexity of inter-area routes, or the complexity of SPF and intra-area routes. All this is just IMHO, and from experience with one implementation. The benefits of using multiple areas are: 1) a little more protection against link flaps 2) ability to extend your network easier. once your network grows so much that you finally really need multipkle areas, you have already layed them out 3) you can do summarization and filtering between area/level boundaries Drawbacks: 1) added configuration and troubleshooting complexity 2) if you do BGP, the fact that L1 areas are stub areas can give you troubles. (Giving MED to customers, doing shortest-exit-routing, etc). BTW, in some implementations L1 areas are more like NSSA. Also you can now do route-leaking with the old TLVs, or with the newer TLVs. See the recent drafts. > I got recommendation from some vendor that network with this size it > will be the best to build with just one big level-1-2 area. Reason is > that there will be just one database so it will take less time to > recalculate SPF. In the first case there will be some routers talking > both level-1 and level-2 so there will be 2 database on those router and > for those routers it will take longer time to recalculate SPF. I would say the main reason to run 200-300 routers in one area is simplicity. Why bother with multiple areas if you can get away with just one. > But I > think this is wrong becase in second alternative all the router is > talking level-1 and level-2 so all of the router will have one level-1 > and one level-2 database with bigger LSDB. It will increase > recalculation time. > > > Do I think right? I think the duration of SPF computation is not really relevant to the design of your network. > Is there any BCP document other recommendation document for build IS-IS > network? Don't think so. > Thank You in advances Hope this helps, Henk. > /michael > > > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From danny@qwest.net Thu, 13 Jan 2000 19:33:20 -0700 Date: Thu, 13 Jan 2000 19:33:20 -0700 From: Danny McPherson danny@qwest.net Subject: [Isis-wg] BCP for building Integrated IS-IS Network I agree with Henk's comments. We run a single area L2-only domain with a couple hundred routers, other places I've worked had 350+ in a single domain. The primary reasons for not introducing hierarchy are those Henk mentioned: o Inability to derive accurate BGP MED values o L1 routers defaulting to closest L2 router can result in sub-optimal routing. o Troubleshooting is a bit more complex The ability to route leak does make a multi-level IS-IS network more appealing, though it's certainly not worth the complexity trade-offs at this point, or anywhere in the foreseeable future. I didn't see Henk mention it, but it would perhaps also seem that while a multi-level network is a bit more protected against potential of instabilities introduced by link oscillation, a single level network should converge slightly faster, though the gain is probably negligible. As for the SPF runtimes, they don't seem at all concerning in our network today. We use two different vendor implementations and SPF runtimes seem to be ~200 microseconds per node. We don't have any NBMA stuff or psuedonodes though, so the size of the LSDB is probably pretty small in comparison to other networks. -danny From rja@corp.home.net Fri, 14 Jan 2000 11:08:52 -0500 Date: Fri, 14 Jan 2000 11:08:52 -0500 From: Ran Atkinson rja@corp.home.net Subject: [Isis-wg] BCP for building Integrated IS-IS Network IMHO, the analyses in recent emails (e.g. Henk's) would be useful to document in a short Informational RFC. Ran rja@corp.home.net From emmanuel.dauvergne@cnet.francetelecom.fr Fri, 14 Jan 2000 17:27:42 +0100 Date: Fri, 14 Jan 2000 17:27:42 +0100 From: DAUVERGNE Emmanuel CNET/DAC/ISS emmanuel.dauvergne@cnet.francetelecom.fr Subject: [Isis-wg] BCP for building Integrated IS-IS Network I'm not an MPLS expert, but I'm also thinking about the following drawback (in multi-level) : o Complexity in MPLS environnement : Inability to setup an LSP between two PE located in different L1-areas (stub areas). As Henk mentionned for MED calculation, this issue is solved with route-leaking concept. Manu > ---------- > De : Danny McPherson[SMTP:danny@qwest.net] > Répondre à : danny@ice.ip.qwest.net > Date : vendredi 14 janvier 2000 03:33 > A : hsmit@cisco.com > Cc : kim@telia.net; isis-wg@juniper.net > Objet : Re: [Isis-wg] BCP for building Integrated IS-IS Network > > > I agree with Henk's comments. > > We run a single area L2-only domain with a couple hundred routers, other > places I've worked had 350+ in a single domain. The primary reasons for > not > introducing hierarchy are those Henk mentioned: > > o Inability to derive accurate BGP MED values > o L1 routers defaulting to closest L2 router can result in sub-optimal > routing. > o Troubleshooting is a bit more complex > > The ability to route leak does make a multi-level IS-IS network more > appealing, though it's certainly not worth the complexity trade-offs at > this > point, or anywhere in the foreseeable future. > > I didn't see Henk mention it, but it would perhaps also seem that while a > multi-level network is a bit more protected against potential of > instabilities > introduced by link oscillation, a single level network should converge > slightly faster, though the gain is probably negligible. > > As for the SPF runtimes, they don't seem at all concerning in our network > today. We use two different vendor implementations and SPF runtimes seem > to > be ~200 microseconds per node. We don't have any NBMA stuff or > psuedonodes > though, so the size of the LSDB is probably pretty small in comparison to > other networks. > > -danny > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From tangcm@future.futsoft.com Mon, 17 Jan 2000 10:01:12 +0530 Date: Mon, 17 Jan 2000 10:01:12 +0530 From: Jorge tangcm@future.futsoft.com Subject: [Isis-wg] Problem for Support Frame Relay . This is a multi-part message in MIME format. ------=_NextPart_000_004E_01BF60D1.C8E8E200 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGkgLA0KICAgIE5vdyBpIG1ldCBzb21lIHByb2JsZW0gYWJvdXQgSVMtSVMgb24gSVB2NC5XZSB3 YW50IHRvICBpbXBsZW1lbnQgdGhlIElTLUlTIHRvIHN1cHBvcnQgdGhlIEZyYW1lIFJlbGF5ICxi dXQgaSB3YW50IHRvICBrbm93IGhvdyBpIGNhbiBpbXBsZW1lbnQgaXQgLkp1c3QgYXMgc29tZW9u ZSBzYWlkIGluIHByaW8gbWFpbHMgLHRvIHJlZ2FyZCB0aGUgRnJhbWUgUmVsYXkgYXMgbXVsdGlw bGUgUFBQIGxpbmtzICxpIHRoaW5rICx0aGlzIG1ldGhvZCBjYW4gYmUgZml0YWJsZSBmb3IgUFZD LCBidXQgaG93IHRvIGRlYWwgd2l0aCBTVkMsaSBkb24ndCBrbm93IHdoZXRoZXIgaXMgbWVhbnMg d2UgZG9uJ3QgbmVlZCB0byBjYXJlIGFib3V0IFNWQyAscGxlYXNlICBnaXZlIHNvbWUgYWR2aWNl IGZvciBtZS4gIFRoYW5rcyBhIGxvdCENCg== ------=_NextPart_000_004E_01BF60D1.C8E8E200 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yMDE0LjIxMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT3LzszlIHNpemU9Mj5oaSAsPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOUgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNw OyBOb3cgaSBtZXQgc29tZSBwcm9ibGVtIGFib3V0IElTLUlTIA0Kb24gSVB2NC5XZSB3YW50IHRv ICBpbXBsZW1lbnQmbmJzcDt0aGUgSVMtSVMgdG8gc3VwcG9ydCB0aGUgRnJhbWUgUmVsYXkgLGJ1 dCBpIA0Kd2FudCB0byZuYnNwOyBrbm93IGhvdyBpIGNhbiBpbXBsZW1lbnQgaXQgLkp1c3QgYXMg c29tZW9uZSZuYnNwO3NhaWQgaW4gcHJpbyANCm1haWxzICx0byByZWdhcmQgdGhlIEZyYW1lIFJl bGF5IGFzIG11bHRpcGxlIFBQUCBsaW5rcyANCixpJm5ic3A7dGhpbmsmbmJzcDssdGhpcyZuYnNw O21ldGhvZCZuYnNwO2NhbiZuYnNwO2JlIGZpdGFibGUgDQpmb3ImbmJzcDtQVkMsJm5ic3A7YnV0 IGhvdyZuYnNwO3RvIGRlYWwgd2l0aCZuYnNwO1NWQyxpIA0KZG9uJ3QmbmJzcDtrbm93Jm5ic3A7 d2hldGhlciZuYnNwO2lzIG1lYW5zJm5ic3A7d2UgZG9uJ3QgbmVlZCZuYnNwO3RvIGNhcmUgDQph Ym91dCZuYnNwO1NWQyZuYnNwOyxwbGVhc2UmbmJzcDsgZ2l2ZSZuYnNwO3NvbWUmbmJzcDthZHZp Y2UgZm9yIG1lLiZuYnNwOyANClRoYW5rcyBhIGxvdCE8L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRN TD4NCg== ------=_NextPart_000_004E_01BF60D1.C8E8E200-- From jjl@one.com Mon, 17 Jan 2000 11:01:03 -0500 Date: Mon, 17 Jan 2000 11:01:03 -0500 From: Jeff Learman jjl@one.com Subject: [Isis-wg] Problem for Support Frame Relay . It's not important whether the links are PVCs or SVCs, it's just important that they're "statically assigned". In other words, they have to be opened at startup time and in general, kept open the whole time. If you need to have the links open and close on an as-needed basis, then you can't use IS-IS to exchange routing information over them. It's OK if you want to shut down a link; just keep in mind that it won't be opened automatically if it is needed for data traffic. If the Frame Relay links are to end systems, then it isn't a problem. I'ts only a problem if the links are between routers, and you need to exchange IS-IS routing information between them. The reason is that IS-IS relies on the fact that all routers in an area (or for level 2, all L2 routers in the domain) must agree on the topology. In order for this to work, they need to be in constant communication. Therefore, "dynamically assigned" links, those that come up and go down on an as-needed basis, aren't appropriate for links between routers (simply because they're always needed.)=20 Regards, Jeff At 10:01 AM 1/17/00 +0530, Jorge wrote:=20 >>>> =CB=CE=CC=E5hi , Now i met some problem about IS-IS on IPv4.We want to implement the IS-IS to support the Frame Relay ,but i want to know how i can implement it .Just as someone said in prio mails ,to regard the Frame Relay as multiple PPP links ,i think ,this method can be fitable for PVC, but how to deal with SVC,i don't know whether is means we don't need to care about SVC ,please give some advice for me. Thanks a lot! <<<<<<<< ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From zinin@amt.ru Mon, 17 Jan 2000 19:27:25 +0300 Date: Mon, 17 Jan 2000 19:27:25 +0300 From: Alex Zinin zinin@amt.ru Subject: Re[2]: [Isis-wg] Problem for Support Frame Relay . Hmmm...I wouldn't say so. One can easily run IS-IS (or any other dynamic routing proto) over on-demand circuits provided that the idle timer doesn't close the VC before the next Hello PDU is sent over it. This is, actually, how these things are done in a number of implementations. As for Jorge's question---when SVCs are used, just make sure the SVC is open before sending anything along it. If it is not---generate a request for the circuit manager asking it to open the VC. This is assumed to be done in the IP-to-Layer2 part of the code, not in IS-IS. Just like with PVSs, mapping statements for SVCs are marked to be used for broadcast/multicast propagation. HTH Alex. Monday, January 17, 2000, 7:01:03 PM, Jeff Learman wrote: > It's not important whether the links are PVCs or SVCs, it's > just important that they're "statically assigned". In other > words, they have to be opened at startup time and in general, > kept open the whole time. If you need to have the links open > and close on an as-needed basis, then you can't use IS-IS > to exchange routing information over them. It's OK if you > want to shut down a link; just keep in mind that it won't be > opened automatically if it is needed for data traffic. > If the Frame Relay links are to end systems, then it isn't a > problem. I'ts only a problem if the links are between routers, > and you need to exchange IS-IS routing information between them. > The reason is that IS-IS relies on the fact that all routers > in an area (or for level 2, all L2 routers in the domain) must > agree on the topology. In order for this to work, they need to > be in constant communication. Therefore, "dynamically assigned" > links, those that come up and go down on an as-needed basis, > aren't appropriate for links between routers (simply because > they're always needed.) > Regards, > Jeff > At 10:01 AM 1/17/00 +0530, Jorge wrote: >>>>> > ËÎÌåhi , > Now i met some problem about IS-IS on IPv4.We want to implement the > IS-IS to support the Frame Relay ,but i want to know how i can implement > it .Just as someone said in prio mails ,to regard the Frame Relay as > multiple PPP links ,i think ,this method can be fitable for PVC, but how > to deal with SVC,i don't know whether is means we don't need to care > about SVC ,please give some advice for me. Thanks a lot! > > <<<<<<<< > ____________________________________________________________________ > Jeff Learman Internet: jjl@one.com > Engineering Manager Voice: (734)-975-7323 > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > 2725 South Industrial Pkwy, Suite 100 > Ann Arbor, MI 48104 USA > ____________________________________________________________________ > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From zinin@amt.ru Mon, 17 Jan 2000 19:54:53 +0300 Date: Mon, 17 Jan 2000 19:54:53 +0300 From: Alex Zinin zinin@amt.ru Subject: Re[2]: [Isis-wg] Problem for Support Frame Relay . Monday, January 17, 2000, 7:43:07 PM, Tony Przygienda wrote: > again, first a problem statement would be nice to make sure > we're all tackling the same problem. Well, I think Jorge's initial messages are quite clear on that---running IS-IS over NBMA media. ...and whichever issues related :) > 2nd, Alex, you're oversimpliofying here ;-) Tony, I'm not. I'm just correcting the statement that on-demand VCs cannot be used with IS-IS. > Just "running" > the protocol that way leads to extensive thrashing of up&downs > of the circuit Quoting myself: "...provided that the idle timer doesn't close the VC before the next Hello PDU is sent over it." Note "doesn't" above. I think you misunderstood me a bit. I'm not proposing to open a VC for every packet and close it afterwards, I'm saying one doesn't need to emulate PVCs using SVCs. > [and therefore billing, if you don't get billed for your > FR or ATM service, you may as well always leave the circuit up ;-)], > a usable solution needs more thought like in OSPF > (don't age bits, smart adjacency stay-up and couple of more details) Agree. Alex. From prz@siara.com Mon, 17 Jan 2000 11:43:07 -0500 Date: Mon, 17 Jan 2000 11:43:07 -0500 From: Tony Przygienda prz@siara.com Subject: [Isis-wg] Problem for Support Frame Relay . Alex Zinin wrote: > Hmmm...I wouldn't say so. > One can easily run IS-IS (or any other dynamic routing > proto) over on-demand circuits provided that the idle > timer doesn't close the VC before the next Hello PDU > is sent over it. > > This is, actually, how these things are done in a number > of implementations. > > As for Jorge's question---when SVCs are used, just make > sure the SVC is open before sending anything along it. > If it is not---generate a request for the circuit manager > asking it to open the VC. This is assumed to be done > in the IP-to-Layer2 part of the code, not in IS-IS. > Just like with PVSs, mapping statements for SVCs are > marked to be used for broadcast/multicast propagation. again, first a problem statement would be nice to make sure we're all tackling the same problem. 2nd, Alex, you're oversimpliofying here ;-) Just "running" the protocol that way leads to extensive thrashing of up&downs of the circuit [and therefore billing, if you don't get billed for your FR or ATM service, you may as well always leave the circuit up ;-)], a usable solution needs more thought like in OSPF (don't age bits, smart adjacency stay-up and couple of more details) thasnk -tony > HTH > > Alex. > > Monday, January 17, 2000, 7:01:03 PM, Jeff Learman wrote: > > It's not important whether the links are PVCs or SVCs, it's > > just important that they're "statically assigned". In other > > words, they have to be opened at startup time and in general, > > kept open the whole time. If you need to have the links open > > and close on an as-needed basis, then you can't use IS-IS > > to exchange routing information over them. It's OK if you > > want to shut down a link; just keep in mind that it won't be > > opened automatically if it is needed for data traffic. > > > If the Frame Relay links are to end systems, then it isn't a > > problem. I'ts only a problem if the links are between routers, > > and you need to exchange IS-IS routing information between them. > > > The reason is that IS-IS relies on the fact that all routers > > in an area (or for level 2, all L2 routers in the domain) must > > agree on the topology. In order for this to work, they need to > > be in constant communication. Therefore, "dynamically assigned" > > links, those that come up and go down on an as-needed basis, > > aren't appropriate for links between routers (simply because > > they're always needed.) > > > Regards, > > Jeff > > > At 10:01 AM 1/17/00 +0530, Jorge wrote: > > >>>>> > > > ËÎÌåhi , > > > Now i met some problem about IS-IS on IPv4.We want to implement the > > IS-IS to support the Frame Relay ,but i want to know how i can implement > > it .Just as someone said in prio mails ,to regard the Frame Relay as > > multiple PPP links ,i think ,this method can be fitable for PVC, but how > > to deal with SVC,i don't know whether is means we don't need to care > > about SVC ,please give some advice for me. Thanks a lot! From prz@siara.com Fri, 14 Jan 2000 17:07:18 -0500 Date: Fri, 14 Jan 2000 17:07:18 -0500 From: Tony Przygienda prz@siara.com Subject: [Isis-wg] BCP for building Integrated IS-IS Network DAUVERGNE Emmanuel CNET/DAC/ISS wrote: 1. Ran's comment on the issues being worth written down is good but I assume I cannot interpret that as equal to volunteering to do it ;-) ?? > I'm not an MPLS expert, but I'm also thinking about the following drawback > (in multi-level) : > > o Complexity in MPLS environnement : Inability to setup an LSP between two > PE located in different L1-areas (stub areas). 2. there is some current thinking by the usual suspects how to solve the problem. I expect some kind of solution to gel. thanks -- tony From prz@siara.com Sun, 16 Jan 2000 23:52:41 -0500 Date: Sun, 16 Jan 2000 23:52:41 -0500 From: Tony Przygienda prz@siara.com Subject: [Isis-wg] Problem for Support Frame Relay . Jorge wrote: > hi , Now i met some problem about IS-IS on IPv4.We want to implement the IS-IS to support the Frame Relay ,but i want to know how i can implement it .Just as someone said in > prio mails ,to regard the Frame Relay as multiple PPP links ,i think ,this method can be fitable for PVC, but how to deal with SVC,i don't know whether is means we don't need to > care about SVC ,please give some advice for me. Thanks a lot! seems that the issue is being rised of whether we need support for ISIS in terms of P2M as OSPF has (and not of ISIS over IPv4 as the confusing topic and text suggests). It is a non-trivial (and not the most elegant and intuitive) extension to the protocol and probably only worth doing if customer demand exists. I think I pinged once on this list whether the potential customers have interest in P2M for ISIS with 0 answers. So I'd consider the issue not worth tackling for the moment since if there is nobody to deploy it, why put the effort in ? Just run SVCs and FR in P2P mode. However, if someone out there is implementing something proprietary to support P2M, it's probably much better that a draft shows up, rather than struggle with proprietary, incompatible (and probably buggy due to lack of review by knowledgable parties) later. thanks -- tony From prz@siara.com Mon, 17 Jan 2000 11:26:07 -0500 Date: Mon, 17 Jan 2000 11:26:07 -0500 From: Tony Przygienda prz@siara.com Subject: [Isis-wg] Problem for Support Frame Relay . Jeff Learman wrote: > It's not important whether the links are PVCs or SVCs, it's > just important that they're "statically assigned". In other > words, they have to be opened at startup time and in general, > kept open the whole time. If you need to have the links open > and close on an as-needed basis, then you can't use IS-IS > to exchange routing information over them. It's OK if you > want to shut down a link; just keep in mind that it won't be > opened automatically if it is needed for data traffic. > > If the Frame Relay links are to end systems, then it isn't a > problem. I'ts only a problem if the links are between routers, > and you need to exchange IS-IS routing information between them. > > The reason is that IS-IS relies on the fact that all routers > in an area (or for level 2, all L2 routers in the domain) must > agree on the topology. In order for this to work, they need to > be in constant communication. Therefore, "dynamically assigned" > links, those that come up and go down on an as-needed basis, > aren't appropriate for links between routers (simply because > they're always needed.) I'm not clear which problem this thread is pursuiting. Are we talking about the problem of partial meshes (P2M mode) or are we talking about the problem of dynamic FR circuits (SVCs) coming up ? Both problems have solutions (P2M mode or dial-up link extensions that allow the circuit to be shut down but adjacency maintained) but this whole "ISIS and FR" needs a short problem definition before solutions are being tossed around, I'd say. More important even, is anyone from the customers on this list interested in running ISIS over FR ? htankas -=-tony From nrsoma@pluris.com Mon, 17 Jan 2000 10:49:02 -0800 Date: Mon, 17 Jan 2000 10:49:02 -0800 From: Nageswara Rao Soma nrsoma@pluris.com Subject: [Isis-wg] Passive interface Hi, Somewhere I read that only routing updates are not sent over passive interfaces. However, neighbors' updates are received and processed over passive interfaces without affecting adjacencies. Could someone please explain me little more about this? Advance thanks for any help. Soma. PS: Forgive me if have not sent to correct mailing list address. From dkatz@juniper.net Mon, 17 Jan 2000 11:32:37 -0800 (PST) Date: Mon, 17 Jan 2000 11:32:37 -0800 (PST) From: Dave Katz dkatz@juniper.net Subject: [Isis-wg] Passive interface Passive interfaces are a figment of implementation, rather than of specmanship. For LS protocols, the implementations with which I'm familiar will advertise passive interfaces as internal routes, but don't attempt to do any protocol handling at all (since it doesn't make a whole lot of sense and wouldn't work anyhow). For periodic DV protocols (i.e., RIP and IGRP), passive usually means that you're receiving the updates (since they're being blindly sent) but not sending anything back. This is the classic RIP-as-a- router-discovery-protocol mode. From: Nageswara Rao Soma Hi, Somewhere I read that only routing updates are not sent over passive interfaces. However, neighbors' updates are received and processed over passive interfaces without affecting adjacencies. From zinin@amt.ru Tue, 18 Jan 2000 14:27:31 +0300 Date: Tue, 18 Jan 2000 14:27:31 +0300 From: Alex Zinin zinin@amt.ru Subject: Re[2]: [Isis-wg] Problem for Support Frame Relay . Tuesday, January 18, 2000, 12:14:54 AM, Tony Przygienda wrote: >> >> Tony, I'm not. I'm just correcting the statement >> that on-demand VCs cannot be used with IS-IS. > this part you don't, right. But after that you're saying it's easy and doesn't > need anything, that's at least slightly oversimplifying. You can run it that > way but you'll stop pretty soon after the montly bills come. If you don't > beleive me, try an ISDN link with OSPF active ;-) Tony, I'm a Russian, not stupid :) Just, please, don't read between the lines. When I say "x != y", I don't mean "(log(x) > sin(z))&&(exp(z) < log10(y))" Similarly, when I say "IS-IS *can* be easily run over SVCs" in contrast to "SVCs cannot be used with IS-IS", it doesn't mean "Guys, come on! Don't care about your money!"... I agree, however, that P2M and on-demand circuits are two different problems. This thread is more about the second issue, I believe. Sorry for BW wastage. Alex. From selvarajr@future.futsoft.com Mon, 24 Jan 2000 21:42:11 +0530 Date: Mon, 24 Jan 2000 21:42:11 +0530 From: SelvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubts in MIB and SNDF Hi, I'm implementing Integrated ISIS protocol which is very new for me . I've the following doubts. 1. In the MIB draft, draft-ietf-isis-wg-mib-02.txt , for Integrated ISIS It has been stated that , isisSystem table contains information specific to a single instance of ISIS protocol running on a router. Does this means more than one Integrated ISIS runs on a single machine ? If yes, what is the purpose of having more than one instance in a single machine and where does it apply. 2. In ISO 10589 1998, in SNDF for PPP , it has been mentioned setting circuit ID Status after receiving IIH PDU ( section 8.2.5.2( c ) ) . What is the significance of this circiut ID status? Also there is no such MIB object. Please , clarify me. Thanx in advance Selva From hsmit@cisco.com Fri, 28 Jan 2000 20:06:51 +0100 (MET) Date: Fri, 28 Jan 2000 20:06:51 +0100 (MET) From: Henk Smit hsmit@cisco.com Subject: [Isis-wg] Concerns about ISIS in IP encapsulation During the IETF ISIS WG meeting in Oslo we had a bit of a discussion about the proposal for ISIS in IP encapsulation. (See draft-ietf-isis-wg-over-ip-01.txt for details). At that meeting, I have voiced my concerns about the proposal. I had prepared an email to send to this list long time ago. But there was never a compeling reason to bring up the subject again. Let me try to recap some of the discussion. Benefits of ISIS in IP encapsulation. A) ISIS-in-IP improves the efficiency of ATM when using ISIS as IP IGP. My opinion: - This true. But had I hope my proposal was a more simple and easier solution for this problem. (See draft-hsmit-isis-ip-aal5mux-00.txt). Last summer I have emailed two of our largest ISIS+ATM customers that I had the code ready, but they didn't seem much interested. Now I wonder how bad ISPs really want to improve the efficiency of the ISIS+ATM combo. B) ISIS-in-IP prevents the need of defining OSI/ISIS encapses every time a new layer2 technology is emerging. - This is true. But it is very likely that native OSI/ISIS encapsulations will be defined for new layer2 technologies anyway. E.g. CLNS itself is not dead yet. CLNS is not relevant in the Internet, and probably not in Enterprise networks. But RBOCs are using CLNS for their management networks for their Sonet/SDH infrastructure. So native OSI/ISIS/CLNS will be around for a while, so there will be new encapsulations for OSI/ISIS/CLNS defined. C) ISIS-in-IP improves portability of gated. - Personally I don't care much about this. While people might not expect this from a cisco employee, I do like open source software. But I think that new technology should not be based on what is easy to implement in one particular operating system (even if it is Unix). Also the fact remains that all current ISIS implementation run native over layer2, so if gated or any other ISIS implementation wants any acceptance in the real world, it still needs to implement ISIS-in-layer2 encapsulation. D) ISIS-in-IP might improve the acceptance of ISIS in circles of IP bigots. - IMHO people who don't like ISIS won't suddenly like it because they can now encapsulate ISIS in IP. Now the drawbacks: 1) Why add a second method of encapsulation ? ISIS-over-IP doesn't solve a real problem. If the efficiency of ISIS+ATM is really an issue for some customers, this could be solved by using the first byte in the IP header as NLPID. Maybe we can get away without a more complex solution. If we solve this problem just for ATM (actually just for "aal5mux ip"), then if ATM becomes less popular in a couple of years (at least in highspeed networks), we can forget about this hack. If we do ISIS-over-IP we will be stuck with it forever. See IPX. 2) It adds more complexity to the protocol. One of the reasons some people like ISIS over OSPF is the fact that ISIS is simpler in some areas. We are now adding all kinds of features and extensions. If we add too many, ISIS will be worse than OSPF in this respect. Personally I would hate to see that happen. 3) It adds more complexity to the configuration. The less configuration choices there are, the easier ISIS will be to deploy. Look at a similar case: IPX. It has four encapsulations. There are no benefits to that, just added confusion. 4) IP fragmentation. I think that people will not move whole networks at the same time. They will run hybrid networks with ISIS-over-layer2 and ISIS-over-IP. That in itself will add complexity. I am sure customers won't configure smaller LSP buffer sizes on all their routers. At least not until their network really breaks. So I am afraid that LSP will be fragmented at the IP layer. Note, if a router has more than 1492 bytes of info to advertise into ISIS, that router must fragment its LSP. It will probably create a first LSP of size 1492, and at least one small LSP. That first LSP of size 1492 will be fragmented at the IP layer on links that have an MTU of 1500 and run ISIS-over-IP. So a router that redistributes more than 100 IP routes or so will have at least one LSP of size 1492. Right now lots of ISIS networks I know run in a single flat area. But if they ever do true L1L2, the L1L2 routers will advertise lots of interarea routes. So most likely the L1L2 routers will all create LSP fragments of size 1492. As you all know, link-state protocols have two areas of concern regarding scalability. One is route computation, and the other is flooding. I think fragmentation at the IP layer will make ISIS flooding less scalable. I was told by one of editors of 10589 that preventing fragmentation during the flooding was the main reason why ISIS fragments only at the originating router. BTW, I am not so much concerned about fragmentation, but more about reassambly. 5) Consistency towards other standards bodies. The ISIS-over-IP draft recommends that routers use an LSPBufferSize of 1480 (or rather 1472) bytes. In the Sonet/SDH/Telco world the Sonet Interoperability Forum (SIF) works on ISIS too. They want to run ISIS over the DCC. The DCC channel is a part of the bandwidth of a Sonet/SDH ring. The Bellcore spec for DCC says that the DCC must use LAPD encaps, and that the *maximum* MTU is 512 bytes. So you can't run ISIS over the DCC, because some routers might send LSPs of size larger than 512 bytes. Those LSPs can not be flooded over the DCC. So the SIF wanted to add some cruft to 10589 that changes the LSPBufferSize from 1492 to 512 bytes. I am heavily opposed to that. But if the ISIS WG in the IETF recommends to lower the LSPBufferSize from 1492 to 1480, why not lower it to 512 ? We will not be able to defend ourselves to changes like the proposal from the SIF. To be honest, I don't know about the latest status on the SIF proposal. It actually might have been withdrawn. 6) Security. ISIS-over-layer2 is actually a feature. ISIS packets are not routable. It makes sure that nobody but your direct physical neighbors can inject routing packets into your IGP. Suppose a network uses ISIS-over-IP. That means I can send ISIS packets from my PC at home to any router in that network. It is easy to fake source IP addresses. So I can inject LSPs into this network, or do other nasty things, like break adjacencies, etc. So now this network needs to use ISIS authentication. Probably strong authentication, like HMAC/MD5 (not cleartext passwords). But still if that is done, I can send a 1000 LSPs/second to those routers. And they need to check the authentication, which might use lots of CPU power. Or I can send IP fragments, which will use buffers. All kinds of nasty denial of service attacks come to mind. I guess these attacks could be applicable to OSPF today, so the OSPF people might already have a solution which we can use. But I would like to point out that ISIS-over-layer2 is a feature. 7) What about IPv6 ? If we ever get around to define TLVs to do IPv6 routing in ISIS, which encapsulation would it use ? A nice thing about ISIS is that ISIS packets are not encapsulated in CLNS, and not in IP. Now if we add ISIS-over-IPv4, we might end up in a situation where we will have to define an ISIS-over-IPv6 encapsulation too. What if routing for other layer3 protocols gets defined ? Will we add an encapsulation for that layer3 too ? 8) Why not encapsulate in CLNS as well ? 10589 defines virtual links for area repair. Those virtual links use CLNS encapsulation to get packets across the L2 backbone. Extra complexity for little gain. (The gain would be that networks with a broken design seem a little less broken). That added complexity was one of the reasons why I have discourge my employer from implementing virtual links and area partition repair. Once we implement virtual links for area partition repair, we probably will have to support area partitioning for IP as well. The result will be that if gated and others want to stay compatible with current features, they might have to implement a full CLNS stack, just to be able to deal with area partition repair. Just ISIS-over-layer2 encapsulation will not be enough anymore. Some comments on my concerns. - Curtis Villamizer said that networks don't run their IGP over 10 Mbps ethernet anymore. ISPs use POS, ATM, FDDI, Fast Ethernet and Gigabit Ethernet. Those layer2 technology all can have MTUs of 1512 or higher. 10 Mbps ethernet is only used at the edges towards the hosts. I guess that is correct. So fragmentation migh occur less often then I fear. After all, the large NBMA meshes are mostly over ATM today, which has a larger MTU. However, enterprise networks might run ISIS over 10 Mbps Ethernet. And some router implementations use standard MTUs of 1500 on their serial (PPP, HDLC, frame-relay) interfaces. To use larger MTUs over FE and Gig-ethernet we need the new encapsulation, which might cause other problems (like on bridges). So I am not fully convinced yet that fragmentation won't be a problem. Thank you for your attention, Henk. From pst@juniper.net Fri, 28 Jan 2000 15:02:33 -0800 Date: Fri, 28 Jan 2000 15:02:33 -0800 From: Paul Traina pst@juniper.net Subject: [Isis-wg] Concerns about ISIS in IP encapsulation Allow me to reiterate my support (and Dave's) from Oslo. I really like Henk's proposal (draft-hsmit-isis-ip-aal5mux-00.txt), and Dave has pointed out that this is well within the expected behavior for OSI protocols. With Henk's proposal as a tool for solving the MUX encaps issues of ATM and similar encapsulations that are incapable of carrying a ptype, I do not see any great need for IS-IS to be reimplemented to use IP as a transport layer. Your IGPs may as well be multi-protocol. The world is already a happy place. Paul From wrath@cs.umbc.edu Fri, 28 Jan 2000 18:15:00 -0500 (EST) Date: Fri, 28 Jan 2000 18:15:00 -0500 (EST) From: Vijay Gill wrath@cs.umbc.edu Subject: [Isis-wg] Concerns about ISIS in IP encapsulation On Fri, 28 Jan 2000, Henk Smit wrote: > Benefits of ISIS in IP encapsulation. > A) ISIS-in-IP improves the efficiency of ATM when using ISIS as IP IGP. > > My opinion: > - This true. But had I hope my proposal was a more simple and easier > solution for this problem. (See draft-hsmit-isis-ip-aal5mux-00.txt). > Last summer I have emailed two of our largest ISIS+ATM customers > that I had the code ready, but they didn't seem much interested. > Now I wonder how bad ISPs really want to improve the efficiency > of the ISIS+ATM combo. I'll speak to this point briefly. As the promising local ISP I work for transitions from IP over ATM to Packet over SONET, the effort to deploy the above proposals doesn't give us a good enough return. Two years ago, yes; today, the benefits are not that glaringly obvious given the transitioning already in place. /vijay From danny@qwest.net Fri, 28 Jan 2000 16:19:44 -0700 Date: Fri, 28 Jan 2000 16:19:44 -0700 From: Danny McPherson danny@qwest.net Subject: [Isis-wg] Concerns about ISIS in IP encapsulation To chime is as "an operator", I agree. I don't see any significant advantages with deploying it in my network, other than the job security that comes along introducing new complexities into a system. Am I missing something? -danny > Allow me to reiterate my support (and Dave's) from Oslo. I really like > Henk's proposal (draft-hsmit-isis-ip-aal5mux-00.txt), and Dave has pointed > out that this is well within the expected behavior for OSI protocols. > > With Henk's proposal as a tool for solving the MUX encaps issues of ATM and > similar encapsulations that are incapable of carrying a ptype, I do not see > any great need for IS-IS to be reimplemented to use IP as a transport layer. > Your IGPs may as well be multi-protocol. The world is already a happy > place. From danny@qwest.net Fri, 28 Jan 2000 16:19:43 -0700 Date: Fri, 28 Jan 2000 16:19:43 -0700 From: Danny McPherson danny@qwest.net Subject: [Isis-wg] Concerns about ISIS in IP encapsulation To chime is as "an operator", I agree. I don't see any significant advantages with deploying it in my network, other than the job security that comes along introducing new complexities into a system. Am I missing something? -danny > Allow me to reiterate my support (and Dave's) from Oslo. I really like > Henk's proposal (draft-hsmit-isis-ip-aal5mux-00.txt), and Dave has pointed > out that this is well within the expected behavior for OSI protocols. > > With Henk's proposal as a tool for solving the MUX encaps issues of ATM and > similar encapsulations that are incapable of carrying a ptype, I do not see > any great need for IS-IS to be reimplemented to use IP as a transport layer. > Your IGPs may as well be multi-protocol. The world is already a happy > place. From chopps@merit.edu 29 Jan 2000 15:04:51 -0500 Date: 29 Jan 2000 15:04:51 -0500 From: Christian E. Hopps chopps@merit.edu Subject: [Isis-wg] Concerns about ISIS in IP encapsulation Henk Smit writes: > C) ISIS-in-IP improves portability of gated. This of course was my fault, and was not the intent of what I was trying to say. People who were at the meeting will recall that I was asked to give an example of system that might not have OSI available. I too quickly fired off, ``well e.g., someone using gated on unix''. I unfortunetly mentioned an implementation and so it seemed like a at least a few people ``latched'' that and didn't actually take the statement in context. GateD has support for OSI/CLNS. So this is not a GateD issue. As you point out: if your going to do an IS-IS, right now, you have to support CLNS encapsulation. > - Personally I don't care much about this. While people might not > expect this from a cisco employee, I do like open source software. > But I think that new technology should not be based on what is > easy to implement in one particular operating system (even if > it is Unix). > Also the fact remains that all current ISIS implementation run > native over layer2, so if gated or any other ISIS implementation > wants any acceptance in the real world, it still needs to implement > ISIS-in-layer2 encapsulation. A huge amount of networking research occurs on Unix systems. To toss Unix out as unimportant to the internet or routing protocols seems unwise to me. Some Unix vendors even have OSI support e.g., NetBSD, BSDI and I think Digital/Compaq. The BSD stacks, at least, are aging, poorly, mostly through lack of use. I think the only point I'd like to make WRT to this discussion is that: CLNS is dead to most of the world. Maybe IS-IS will continue to drag the dead horse along with it, and maybe IS-IS will continue to be a mostly unknown or unpopular routing protocol for most people. I think this would be sad. Why should such a nice protocol be restricted to only the elite in routing? Thanks, Chris. P.S. I found many of Henk's comments worthwhile and well though out, specifically with regards to issues facing us today. Other than what I've said above I choose not to disagree with any of them. From lester-ginsberg@vertel.com Mon, 31 Jan 2000 11:09:34 -0800 Date: Mon, 31 Jan 2000 11:09:34 -0800 From: Lester Ginsberg lester-ginsberg@vertel.com Subject: [Isis-wg] Concerns about ISIS in IP encapsulation > > 5) Consistency towards other standards bodies. > The ISIS-over-IP draft recommends that routers use an LSPBufferSize > of 1480 (or rather 1472) bytes. In the Sonet/SDH/Telco world > the Sonet Interoperability Forum (SIF) works on ISIS too. > They want to run ISIS over the DCC. The DCC channel is a part of > the bandwidth of a Sonet/SDH ring. The Bellcore spec for DCC > says that the DCC must use LAPD encaps, and that the *maximum* > MTU is 512 bytes. So you can't run ISIS over the DCC, because > some routers might send LSPs of size larger than 512 bytes. > Those LSPs can not be flooded over the DCC. > So the SIF wanted to add some cruft to 10589 that changes the > LSPBufferSize from 1492 to 512 bytes. I am heavily opposed to > that. But if the ISIS WG in the IETF recommends to lower the > LSPBufferSize from 1492 to 1480, why not lower it to 512 ? > We will not be able to defend ourselves to changes like the > proposal from the SIF. > To be honest, I don't know about the latest status on the SIF > proposal. It actually might have been withdrawn. > To clarify the position presented by SIF - SIF never proposed changing the LSPBufferSize. The current spec allows values of 512-1492, though most folks prefer to use 1492 whenever possible - which, as Henk points out is not possible over the SONET DCC. What SIF did propose is to define TLVs to allow the detection of inconsistent provisioning throughout the area/domain. So at least someone would have a clue when a system generated a 1492 LSP and it couldn't be forwarded over a DCC link. A complete discussion of the SIF proposal can be found on the (renamed) NSIF web site: www.atis.org go to NSIF - then documents - then 1998 - then find SIF-AR-9802-031 (R7) or ftp from ftp.juniper.net:/pub/isis/lspsize.PDF The proposal is still viable - if the work on the 10589 second edition draft ever resumes (there is still hope, I think) - then this proposal will be part of the discussion. Les From tangcm@future.futsoft.com Tue, 1 Feb 2000 15:31:15 +0530 Date: Tue, 1 Feb 2000 15:31:15 +0530 From: Jorge tangcm@future.futsoft.com Subject: [Isis-wg] for a IS-IS conflict . This is a multi-part message in MIME format. ------=_NextPart_000_0061_01BF6CC9.606AC6E0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGksDQogICAgIE5vdyBpIGZpbmQgYSBjb25mbGljdCBmb3IgSVMtSVMgUERVIGF1dGhlbnRpY2F0 aW9uIENvZGUgIHZhbHVlIGRlZmluZWQgLkluIElTTyAxMDU4OSAsMTk5OC4gd2hpY2ggaW5pZGNh dGUgdGhpcyBjb2RlIHZhbHVlIHNob3VsZCBiZSAxMCwgYnV0IGluIFJGQyAxMTk1ICx3aGljaCBk ZWZpbmUgdGhpcyB2YWx1ZSB0byBiZSAxMzMgLnNvIHdoYXQgaXMgb24gZWFydGggdGhlIGNvcnJl Y3QgdmFsdWUgID8gb3IgIG1heWJlIG15IHVuZGVyc3RhbmRpbmcgaXMgbm90IGNvcnJlY3QgPyBQ bHMgZ2l2ZSBtZSBhZHZpY2UgLg0KICAgICAgIFRoYW5rcyAsYW55d2F5ICENCg== ------=_NextPart_000_0061_01BF6CC9.606AC6E0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yMDE0LjIxMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT3LzszlIHNpemU9Mj5oaSw8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9y87M5SBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE5vdyBpIGZpbmQgDQphJm5ic3A7Y29uZmxpY3QmbmJzcDtmb3IgSVMtSVMmbmJzcDtQ RFUgDQphdXRoZW50aWNhdGlvbiZuYnNwO0NvZGUmbmJzcDsmbmJzcDt2YWx1ZSZuYnNwO2RlZmlu ZWQgLkluIElTTyAxMDU4OSAsMTk5OC4gDQp3aGljaCZuYnNwO2luaWRjYXRlJm5ic3A7dGhpcyZu YnNwO2NvZGUmbmJzcDt2YWx1ZSBzaG91bGQgYmUmbmJzcDsxMCwgYnV0IA0KaW4mbmJzcDtSRkMg MTE5NSZuYnNwOyx3aGljaCZuYnNwO2RlZmluZSB0aGlzIHZhbHVlJm5ic3A7dG8gYmUmbmJzcDsx MzMgLnNvIHdoYXQgDQppcyBvbiBlYXJ0aCB0aGUgY29ycmVjdCB2YWx1ZSZuYnNwOyA/IG9yJm5i c3A7IG1heWJlIG15IHVuZGVyc3RhbmRpbmcgaXMgbm90IA0KY29ycmVjdCA/IFBscyBnaXZlIG1l IGFkdmljZSAuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOUgc2l6ZT0yPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MgLGFueXdheSANCiE8L0ZPTlQ+ PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0061_01BF6CC9.606AC6E0-- From mshand@cisco.com Tue, 01 Feb 2000 11:27:39 +0000 Date: Tue, 01 Feb 2000 11:27:39 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] for a IS-IS conflict . At 15:31 01/02/2000 +0530, Jorge wrote: >hi, > Now i find a conflict for IS-IS PDU authentication Code value > defined .In ISO 10589 ,1998. which inidcate this code value should be 10, > but in RFC 1195 ,which define this value to be 133 .so what is on earth > the correct value ? or maybe my understanding is not correct ? Pls give > me advice . > Thanks ,anyway ! I'm pretty sure 10 is the one that is used. RFC 1195 was written when 10589 was only at DIS stage, and there were various technical changes between DIS and IS. One of those was the introduction of the authentication TLV using 10 (i.e. the next unused TLV code point). This was identical in functionality to that which had been put in RFC 1195. So I think the 133 one is now unused. There was a draft (authored by Ross Callon and Chris Gunner) put out some time later (around 1994 I think) which withdrew the 133 value (and incidentally made some improvements to the L1 L2 propagation mechanisms), but by that time the IETF had lost interest in IS-IS and so it never got progressed. Mike From lester-ginsberg@vertel.com Tue, 1 Feb 2000 07:07:17 -0800 (PST) Date: Tue, 1 Feb 2000 07:07:17 -0800 (PST) From: Lester Ginsberg lester-ginsberg@vertel.com Subject: [Isis-wg] for a IS-IS conflict . Since several people over the last few weeks - not just Jorge - have referenced the 1998 Second Edition Draft of ISO 10589 as if it were a standard I feel it is time to reiterate the following: The 1998 Second Edition Draft is NOT an approved standard. It is a draft with lots of problems. It was posted to this group as a means of getting reviewed. It should NOT be used as a reference for validating protocol implementations. Hopefully, someday, there will be a new Second Edition Draft which resolves these problems - until then stick with the 1992 edition. Les > At 15:31 01/02/2000 +0530, Jorge wrote: > >hi, > > Now i find a conflict for IS-IS PDU authentication Code value > > defined .In ISO 10589 ,1998. which inidcate this code value should be 10, > > but in RFC 1195 ,which define this value to be 133 .so what is on earth > > the correct value ? or maybe my understanding is not correct ? Pls give > > me advice . > > Thanks ,anyway ! > From mshand@cisco.com Tue, 01 Feb 2000 15:30:17 +0000 Date: Tue, 01 Feb 2000 15:30:17 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] for a IS-IS conflict . At 07:07 01/02/2000 -0800, Lester Ginsberg wrote: >Since several people over the last few weeks - not just Jorge - have >referenced the 1998 Second Edition Draft of ISO 10589 as if it were a >standard I feel it is time to reiterate the following: > >The 1998 Second Edition Draft is NOT an approved standard. It is a >draft with lots of problems. It was posted to this group as a means of >getting reviewed. It should NOT be used as a reference for validating >protocol implementations. Hopefully, someday, there will be a new >Second Edition Draft which resolves these problems - until then stick >with the 1992 edition. Absolutely. The so called second edition is plain WRONG in a number of critical places. However, the authentication code value in question appears equally in the 1992 version. But I guess this raises an interesting question about how one is supposed to decide whether to believe ISO/IEC 10589:1992 or RFC 1195 when they conflict. Mike > Les > > > > > At 15:31 01/02/2000 +0530, Jorge wrote: > > >hi, > > > Now i find a conflict for IS-IS PDU authentication Code value > > > defined .In ISO 10589 ,1998. which inidcate this code value should > be 10, > > > but in RFC 1195 ,which define this value to be 133 .so what is on earth > > > the correct value ? or maybe my understanding is not correct ? Pls > give > > > me advice . > > > Thanks ,anyway ! > > From lester-ginsberg@vertel.com Tue, 1 Feb 2000 07:48:24 -0800 (PST) Date: Tue, 1 Feb 2000 07:48:24 -0800 (PST) From: Lester Ginsberg lester-ginsberg@vertel.com Subject: [Isis-wg] for a IS-IS conflict . Mike Shand writes: > > But I guess this raises an interesting question about how one is supposed > to decide whether to believe ISO/IEC 10589:1992 or RFC 1195 when they conflict. > This is an example of the potential benefits of an "Integrated Specification" i.e. a version that combines 10589:1992, defect reports, RFC 1195, traffic engineering extensions into a single document or aligned collection of documents. This notion is part of a proposed agenda within ISO SC6/WG7 and which has received some informal verbal support from both ISO and IETF officialdom. Obviously such an effort requires participation from both communities. I hope in the coming months that this agenda "sees the light of day" and that when contemplating such an agenda that Mike's question/point is considered. Les From rja@corp.home.net Tue, 01 Feb 2000 13:39:40 -0500 Date: Tue, 01 Feb 2000 13:39:40 -0500 From: Ran Atkinson rja@corp.home.net Subject: [Isis-wg] for a IS-IS conflict . My (possibly incorrect) understanding is that IAB/IESG has sent a formal liaison to ISO requesting that ISO ISIS WG be re-activated. I'm less clear on whether ISO sent a formal reply. Ran rja@corp.home.net From tli@miata.procket.com Tue, 1 Feb 2000 15:32:19 -0800 Date: Tue, 1 Feb 2000 15:32:19 -0800 From: Tony Li tli@miata.procket.com Subject: [Isis-wg] for a IS-IS conflict . | My (possibly incorrect) understanding is that IAB/IESG has sent a | formal liaison to ISO requesting that ISO ISIS WG be re-activated. I'm | less clear on whether ISO sent a formal reply. My understanding is that we (IETF) asked for a liaison to TC6, which was granted. However, the lack of interest in the ISO makes the communication rather one-sided. Tony From tli@miata.procket.com Tue, 1 Feb 2000 15:34:19 -0800 Date: Tue, 1 Feb 2000 15:34:19 -0800 From: Tony Li tli@miata.procket.com Subject: [Isis-wg] for a IS-IS conflict . | But I guess this raises an interesting question about how one is supposed | to decide whether to believe ISO/IEC 10589:1992 or RFC 1195 when they conflict. Well, one thing that WE can do is to issue updates that supersede RFC 1195. For example, on the TLV number, we can edict that we use code point 10 now. Tony From navaneethk@future.futsoft.com Wed, 2 Feb 2000 09:35:47 -0800 Date: Wed, 2 Feb 2000 09:35:47 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] CLV encoding for Integrated ISIS... Hi... Keeping aside the conflicting codes for th CLV encoding for authentication in ISO 10589 and RFC 1195, What about the other CLVs? Are the codes given in RFC 1195, being used in implementations? Do we have any documents wihich give us a list of codes to be used for the variable length fields to be encoded using CLV? Any help in this regard is most welcome. -Thanx Navaneeth. From tli@procket.com Wed, 2 Feb 2000 13:35:22 -0800 Date: Wed, 2 Feb 2000 13:35:22 -0800 From: Tony Li tli@procket.com Subject: [Isis-wg] CLV encoding for Integrated ISIS... | Keeping aside the conflicting codes for th CLV encoding for | authentication in ISO 10589 and RFC 1195, What about the other CLVs? Are | the codes given in RFC 1195, being used in implementations? Do we have | any documents wihich give us a list of codes to be used for the variable | length fields to be encoded using CLV? Yes, the other codes specified in RFC 1195 are in use. Note that I don't think any of them has been ratified by ISO, but they've not objected either. ISO 10589 and RFC 1195 are the current definitive sources for TLV code points. Tony From navaneethk@future.futsoft.com Thu, 3 Feb 2000 10:44:42 -0800 Date: Thu, 3 Feb 2000 10:44:42 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Clarification With respect to ISIS MIB Hi, I have few doubts on the MIB for IS-IS. 1. Some tables have got objects, Operstate and ExistState. For Ex, isisSysTable has IsisSysOperState and isisSysExistState. What is the significance of these two objects and how do they differ. Is ExistState equivalent to AdminStatus?, "Setting it off make the Router forget all current states". Does it mean clearing all the databases of IS-IS and making the Protocol down. Please clarify. 2. I am not clear about the correlation between the objects and isisSysNextCircIndex and isisCircIndex. 3. isisCircTable has an object "isisManAdjNeighNSAP" . What is the purpose of this object. Where it is used? 4. Could you explain the object "isisIPRouteForw" in isisIPDestTable. 5. What do the circuit types StaticIn and StaticOut stand for in isisCirctype? 6. What are the MeshGroup entires used for? How do we use this? Thanks Regards -vani ------ Navaneeth. From jparker@nexabit.com Thu, 3 Feb 2000 09:50:15 -0500 Date: Thu, 3 Feb 2000 09:50:15 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] RE: Clarification With respect to ISIS MIB > Hi, > > > I have few doubts on the MIB for IS-IS. > > 1. Some tables have got objects, Operstate and ExistState. > For Ex, isisSysTable has > IsisSysOperState and isisSysExistState. What is the > significance of these two objects > and how do they differ. Is ExistState equivalent to > AdminStatus?, "Setting it off make the > Router forget all current states". Does it mean clearing all > the databases of IS-IS and making the > Protocol down. Please clarify. There are three types of things in mib speak Does this object exist? (Exist state) Do I want this object active? (Admin State) Is this object operating? (Oper State) We are currently using OperState in many spots where we should be using AdminState, but that is another story. ExistState is used to help clarify the steps in creating a new item. If Isis had a SystemAdminState, and you set it to Down, you would hope that configuration, such as system id, would be remembered when SystemAdminState was reset to Up. However, seting isisSysExistState to isisSysExistState_destroy should clear setting such as isisSysID. > 2. I am not clear about the correlation between the > objects and isisSysNextCircIndex and isisCircIndex. I is useful to have a circuit Index that is unique within the instance of Isis. The variable isisSysNextCircIndex is a system wide variable that can be used with an SNMP convention called TestAndIncr to provide the "next" value. It works like the roll of numbers you see at the bakery: you tear off the next number, and you will be the only person in the shop with that number. > 3. isisCircTable has an object "isisManAdjNeighNSAP" . > What is the purpose of this object. > Where it is used? If you wish to have a configured adjacency, rather than one created by the exchange of hello messages, this variable holds the SystemId of the other side which you would otherwise discover in the hello packets. > 4. Could you explain the object "isisIPRouteForw" in > isisIPDestTable. This looks like a "next hop" description. > 5. What do the circuit types StaticIn and StaticOut stand for > in isisCirctype? These look like simplex (one way) circuits. > 6. What are the MeshGroup entires used for? How do we use this? There is a draft describing their use... draft-balay-katz-parker-mesh-00.txt > Thanks > Regards > -vani > > ------ > Navaneeth. From prz@siara.com Thu, 03 Feb 2000 15:33:04 -0500 Date: Thu, 03 Feb 2000 15:33:04 -0500 From: Tony Przygienda prz@siara.com Subject: [Isis-wg] comments on Did some more carefull reading and here comments: * please use either "octets" or "bytes" consistently, confusing to have both strawn across the draft (or is there some subtle difference I'm missing ?) * 4 bytes of metric information 1 byte of control information, consisting of 1 bit of up/down information 1 bit indicating the existence of sub-TLVs 6 bits of prefix length you may need to spell out which bits are what, is up/down least or most significant bit ? * sub-TLV format is not given, since all the sub-tlvs have fixed length is the length field contained in sub-tlv format or not, so e.g. for sub-tlv 3 is it byte 1 3 byte 2-5 4 bytes ad-group or byte 1 3 byte 2 4 (length) byte 3-6 4 bytes ad-group ? First is denser, 2nd is extensible (sub-sub-TLVs ?) and consistent with today's TLV encoding. Please spell out which is used in the draft From navaneethk@future.futsoft.com Mon, 7 Feb 2000 10:15:49 -0800 Date: Mon, 7 Feb 2000 10:15:49 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Draft needed... Hi... Can any of you tell me where the draft , < draft-balay-katz-parker-mesh-00.txt> can be found.. Thanx Navaneeth. From balay@torrentnet.com Mon, 07 Feb 2000 10:46:37 -0500 Date: Mon, 07 Feb 2000 10:46:37 -0500 From: Rajesh Balay balay@torrentnet.com Subject: [Isis-wg] Draft needed... Its available at the IETF drafts directory : http://search.ietf.org/internet-drafts/draft-balay-katz-parker-mesh-00.txt -rajesh navaneeth K wrote: > Hi... > Can any of you tell me where the draft , < draft-balay-katz-parker-mesh-00.txt> > can be found.. > Thanx > Navaneeth. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From satish@pluris.com Mon, 7 Feb 2000 14:32:52 -0800 Date: Mon, 7 Feb 2000 14:32:52 -0800 From: Satish Dattatri satish@pluris.com Subject: [Isis-wg] Qn on Pt-Pt IIH Hi, I have a question on pt-pt iih processing: While processing a pt-pt iih does the max area in the packet need to match always? according to [8.2.5.2 (a)] In case of Lan IIH we see if the max area check is enabled or not before discarding the packet. Or is there a error in the version 2 draft here. thanks, satish From lester-ginsberg@vertel.com Mon, 7 Feb 2000 14:57:12 -0800 (PST) Date: Mon, 7 Feb 2000 14:57:12 -0800 (PST) From: Lester Ginsberg lester-ginsberg@vertel.com Subject: [Isis-wg] Qn on Pt-Pt IIH The text in 8.2.5.2(a) in 1998 draft appears identical to the text in 8.2.4.2(a) 1992 spec. And both clearly state text which is identical to the LAN IIH case (8.4.2.2(b) - 1992): "...unless the IS only implements a value of three... in which case this check may be omitted." So I am rather confused as to why you think LAN/P2P are different in this regard. And, once again, I repeat to one and all - please do NOT use the 1998 draft as a reference for protocol implementations. It is not an approved standard, it has lots of problems. Until a newer revision is available - 1992 is what to live by. (Sorry for the repetition of this warning - but it seems necessary.) Les Satish Dattatri writes: > Hi, > I have a question on pt-pt iih processing: > > While processing a pt-pt iih does the max area > in the packet need to match always? according to > [8.2.5.2 (a)] > > In case of Lan IIH we see if the max area check > is enabled or not before discarding the packet. > > Or is there a error in the version 2 draft here. > > thanks, > satish > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From nrsoma@pluris.com Mon, 7 Feb 2000 15:11:37 -0800 Date: Mon, 7 Feb 2000 15:11:37 -0800 From: Nageswara Rao Soma nrsoma@pluris.com Subject: [Isis-wg] Qn on Pt-Pt IIH > -----Original Message----- > From: Satish Dattatri [mailto:satish@pluris.com] > Sent: Monday, February 07, 2000 02:33 PM > To: 'isis-wg@external.juniper.net' > Subject: [Isis-wg] Qn on Pt-Pt IIH > > > Hi, > I have a question on pt-pt iih processing: > > While processing a pt-pt iih does the max area > in the packet need to match always? according to > [8.2.5.2 (a)] Value of isisSysMaxAreaCheck may have the same impact on point-to-point IIH processing as it does for LAN IIH. > In case of Lan IIH we see if the max area check > is enabled or not before discarding the packet. I did not find any difference between processing of LAN IIH and PtPt IIH in this context. Correct me, if I am wrong. > Or is there a error in the version 2 draft here. > > thanks, > satish > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From satish@pluris.com Mon, 7 Feb 2000 15:13:33 -0800 Date: Mon, 7 Feb 2000 15:13:33 -0800 From: Satish Dattatri satish@pluris.com Subject: [Isis-wg] Qn on Pt-Pt IIH That is what I had in mind, both should be processed the same. sorry I overlooked, satish -----Original Message----- From: Lester Ginsberg [mailto:lester-ginsberg@vertel.com] Sent: Monday, February 07, 2000 2:57 PM To: Satish Dattatri Cc: 'isis-wg@external.juniper.net' Subject: [Isis-wg] Qn on Pt-Pt IIH The text in 8.2.5.2(a) in 1998 draft appears identical to the text in 8.2.4.2(a) 1992 spec. And both clearly state text which is identical to the LAN IIH case (8.4.2.2(b) - 1992): "...unless the IS only implements a value of three... in which case this check may be omitted." So I am rather confused as to why you think LAN/P2P are different in this regard. And, once again, I repeat to one and all - please do NOT use the 1998 draft as a reference for protocol implementations. It is not an approved standard, it has lots of problems. Until a newer revision is available - 1992 is what to live by. (Sorry for the repetition of this warning - but it seems necessary.) Les Satish Dattatri writes: > Hi, > I have a question on pt-pt iih processing: > > While processing a pt-pt iih does the max area > in the packet need to match always? according to > [8.2.5.2 (a)] > > In case of Lan IIH we see if the max area check > is enabled or not before discarding the packet. > > Or is there a error in the version 2 draft here. > > thanks, > satish > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From navaneethk@future.futsoft.com Tue, 8 Feb 2000 10:58:34 -0800 Date: Tue, 8 Feb 2000 10:58:34 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Draft needed... Hi... Can any of you tell me where the draft , < draft-balay-katz-parker-mesh-00.txt> can be found.. The given link http://search.ietf.org/internet-drafts/draft-balay-katz-parker-mesh-00.txt points to broken link... The draft is not accessible from here.. Any other Links?? Thanx Navaneeth. From navaneethk@future.futsoft.com Tue, 8 Feb 2000 19:26:44 -0800 Date: Tue, 8 Feb 2000 19:26:44 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] (no subject) Hi... Anybody out there knows any router that supports ISIS over NBMA/X.25/FR ?? Thanx Navaneeth.. From satish@pluris.com Tue, 8 Feb 2000 17:15:24 -0800 Date: Tue, 8 Feb 2000 17:15:24 -0800 From: Satish Dattatri satish@pluris.com Subject: [Isis-wg] MeshGroup in MIB HI, There seems to be a typo in the mib regarding meshgroups. In the object isisCircMeshGroup description: "... If isisCircMeshGroupEnable is false, this value is ignored." ^^^^^^ The fasle should be inactive. thanks, satish From CMartin@mercury.balink.com Tue, 8 Feb 2000 23:43:31 -0500 Date: Tue, 8 Feb 2000 23:43:31 -0500 From: Martin, Christian CMartin@mercury.balink.com Subject: [Isis-wg] Draft needed... Looks as if it has been repaired... Internet Engineering Task Force R.Balay INTERNET DRAFT D.Katz J.Parker Mon Jun 14 1999 IS-IS Mesh Groups 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents <-snip-> /chris > -----Original Message----- > From: navaneeth K [mailto:navaneethk@future.futsoft.com] > Sent: Tuesday, February 08, 2000 1:59 PM > To: 'isis-wg@external.juniper.net' > Subject: [Isis-wg] Draft needed... > > > Hi... > Can any of you tell me where the draft , < > draft-balay-katz-parker-mesh-00.txt> > can be found.. > The given link > http://search.ietf.org/internet-drafts/draft-balay-katz-parker > -mesh-00.txt points to broken link... > The draft is not accessible from here.. Any other Links?? > Thanx > Navaneeth. > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From satish@pluris.com Thu, 10 Feb 2000 11:05:27 -0800 Date: Thu, 10 Feb 2000 11:05:27 -0800 From: Satish Dattatri satish@pluris.com Subject: [Isis-wg] ISO 10589 : 1992 Edition Hi, Does anyone have a digital copy of 1992 spec? OR do one have to buy a printed version only. Thanks, satish From jparker@nexabit.com Thu, 10 Feb 2000 14:16:02 -0500 Date: Thu, 10 Feb 2000 14:16:02 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] ISO 10589 : 1992 Edition > Hi, > Does anyone have a digital copy of > 1992 spec? OR do one have to buy a > printed version only. > > Thanks, > satish Satish - Check RFC 1142, a reprinting of 10589. There are Text and postscript versions. The text version is a poor imitation. http://www.ietf.org/rfc/rfc1142.txt http://www.ietf.org/rfc/rfc1142.ps - jeff parker From dclemmen@cosinecom.com Thu, 10 Feb 2000 14:52:37 -0500 Date: Thu, 10 Feb 2000 14:52:37 -0500 From: dclemmen dclemmen@cosinecom.com Subject: [Isis-wg] ISO 10589 : 1992 Edition Jeff Parker wrote: > > > Hi, > > Does anyone have a digital copy of > > 1992 spec? OR do one have to buy a > > printed version only. > > > > Thanks, > > satish > > Satish - > Check RFC 1142, a reprinting of 10589. > There are Text and postscript versions. > The text version is a poor imitation. > > http://www.ietf.org/rfc/rfc1142.txt > http://www.ietf.org/rfc/rfc1142.ps > > - jeff parker RFC1142 claims to be the 1990 version of the document, I think. Satish is looking for the 1992 version. From mshand@cisco.com Fri, 11 Feb 2000 08:14:09 +0000 Date: Fri, 11 Feb 2000 08:14:09 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] ISO 10589 : 1992 Edition At 14:52 10/02/2000 -0500, dclemmen wrote: >Jeff Parker wrote: > > > > > Hi, > > > Does anyone have a digital copy of > > > 1992 spec? OR do one have to buy a > > > printed version only. > > > > > > Thanks, > > > satish > > > > Satish - > > Check RFC 1142, a reprinting of 10589. > > There are Text and postscript versions. > > The text version is a poor imitation. > > > > http://www.ietf.org/rfc/rfc1142.txt > > http://www.ietf.org/rfc/rfc1142.ps > > > > - jeff parker > >RFC1142 claims to be the 1990 version of the document, I think. >Satish is looking for the 1992 version. Yes. RFC1142 is a copy of the DP version of 10589. For those unfamiliar with ISO terminology (in those days), there were 3 stages; DP, DIS and IS. DP was the first stage of submission, and numerous changes were made between then and publication of the final standard. I wouldn't try to work off RFC1142 (nor, as has oft been repeated, would I try to work off the so called version 2 of 10589 which is plain WRONG). The best course is to get hold of a copy of the original version 1 (ISO/IEC 10589:1992) AND the various technical corrigenda. These mostly correct trivial errors, but there are some (for example the operation of partition repair; should anyone be foolhardy enough to implement it) which correct very serious bugs. I don't know what the current rules are, but as far as I am aware ISO standards still cannot be made publicly available. >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From lester-ginsberg@vertel.com Fri, 11 Feb 2000 21:04:19 -0800 Date: Fri, 11 Feb 2000 21:04:19 -0800 From: Lester Ginsberg lester-ginsberg@vertel.com Subject: [Isis-wg] ISO 10589 : 1992 Edition ISO standards can be purchased from your national organization - in the US that is ANSI (www.ansi.org). Both 1992 spec and the three published Technical Corrigenda should be available. Les > > Yes. RFC1142 is a copy of the DP version of 10589. For those unfamiliar > with ISO terminology (in those days), there were 3 stages; DP, DIS and IS. > DP was the first stage of submission, and numerous changes were made > between then and publication of the final standard. I wouldn't try to work > off RFC1142 (nor, as has oft been repeated, would I try to work off the so > called version 2 of 10589 which is plain WRONG). The best course is to get > hold of a copy of the original version 1 (ISO/IEC 10589:1992) AND the > various technical corrigenda. These mostly correct trivial errors, but > there are some (for example the operation of partition repair; should > anyone be foolhardy enough to implement it) which correct very serious bugs. > > I don't know what the current rules are, but as far as I am aware ISO > standards still cannot be made publicly available. > From vleeschh@sh.bel.alcatel.be Mon, 14 Feb 2000 11:53:11 +0100 Date: Mon, 14 Feb 2000 11:53:11 +0100 From: Hans De Vleeschouwer WX29 58223 vleeschh@sh.bel.alcatel.be Subject: [Isis-wg] Changing the system id while running hi, I was wondering if it is possible to change the ISIS system id while the router is up and running, or whether it is needed to first turn off the protocol. Does anybody have some expierence with this? kind regards, Hans De Vleeschouwer Alcatel Belgium From mshand@cisco.com Mon, 14 Feb 2000 11:32:52 +0000 Date: Mon, 14 Feb 2000 11:32:52 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Changing the system id while running At 11:53 14/02/2000 +0100, Hans De Vleeschouwer WX29 58223 wrote: >hi, > >I was wondering if it is possible to change the ISIS system id while the >router is up and running, or whether it is needed to first turn off the >protocol. Well notionally a router with a different system ID is a different router, so it would be necessary to drop the adjacencies to the old systemID, let the old LSPs die (or purge them) and then form new adjacencies and generate new LSPs. This is equivalent to turning off the protocol. I suppose it is conceivable that one could implement something which did all this in response to changing the system ID, without requiring a separate command to turn the protocol off and back on again, but architecturally it would still be turning off and turning back on the protocol. One could envisage a router having multiple system IDs each with their own set of LSPs, but this starts to get very complicated. Can I ask why you would want to do this? >Does anybody have some expierence with this? > >kind regards, > Hans De Vleeschouwer > Alcatel Belgium > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From dclemmen@cosinecom.com Wed, 16 Feb 2000 17:32:41 -0500 Date: Wed, 16 Feb 2000 17:32:41 -0500 From: dclemmen dclemmen@cosinecom.com Subject: [Isis-wg] Conformance testing tools? Does anyone know of any conformance testing tools or services for IS-IS implementations? From Chris.Flores@broadwing.com Wed, 16 Feb 2000 16:47:35 -0600 Date: Wed, 16 Feb 2000 16:47:35 -0600 From: Chris.Flores@broadwing.com Chris.Flores@broadwing.com Subject: [Isis-wg] Conformance testing tools? The Qosnetics QA Robot- now owned by Agilent technologies. See http://www.qosnetics.com/home.htm I have personally used this test device and would recommend taking a look at the product features. The IS-IS protocol test suite is fairly new. I hope this helps. Thanks. Chris -----Original Message----- From: dclemmen [mailto:dclemmen@cosinecom.com] Sent: Wednesday, February 16, 2000 4:33 PM To: Isis-wg@external.juniper.net Subject: [Isis-wg] Conformance testing tools? Does anyone know of any conformance testing tools or services for IS-IS implementations? _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From dclemmen@cosinecom.com Fri, 18 Feb 2000 15:34:30 -0500 Date: Fri, 18 Feb 2000 15:34:30 -0500 From: dclemmen dclemmen@cosinecom.com Subject: [Isis-wg] e-mail address for Tony Li? I tried to send e-mail to Tony Li, the author of draft-ietf-isis-hmac-00.txt at the address listed in the document. The listed address is: tli@juniper.net It bounced. Tony, are you out there? From wrath@cs.umbc.edu Fri, 18 Feb 2000 15:57:21 -0500 (EST) Date: Fri, 18 Feb 2000 15:57:21 -0500 (EST) From: Vijay Gill wrath@cs.umbc.edu Subject: [Isis-wg] e-mail address for Tony Li? On Fri, 18 Feb 2000, dclemmen wrote: > I tried to send e-mail to Tony Li, the author of > draft-ietf-isis-hmac-00.txt > at the address listed in the document. > The listed address is: > tli@juniper.net > It bounced. > > Tony, are you out there? > I believe the better method is to try tli@procket.com Dr. Li has moved on. /vijay From Chris.Flores@broadwing.com Fri, 18 Feb 2000 16:05:44 -0600 Date: Fri, 18 Feb 2000 16:05:44 -0600 From: Chris.Flores@broadwing.com Chris.Flores@broadwing.com Subject: [Isis-wg] e-mail address for Tony Li? Toni Li is not at Juniper - he has co-founded procket networks. See www.procket.net Thanks. Chris -----Original Message----- From: dclemmen [mailto:dclemmen@cosinecom.com] Sent: Friday, February 18, 2000 2:35 PM To: isis-wg@external.juniper.net Subject: [Isis-wg] e-mail address for Tony Li? I tried to send e-mail to Tony Li, the author of draft-ietf-isis-hmac-00.txt at the address listed in the document. The listed address is: tli@juniper.net It bounced. Tony, are you out there? _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From navaneethk@future.futsoft.com Wed, 23 Feb 2000 09:40:00 -0800 Date: Wed, 23 Feb 2000 09:40:00 -0800 From: navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Clarification on Terminology... Hi all.. I need to have a clarification on the usage of SystemID, NSAP address and SNPA address and the NET ... What exactly do each of these stand for an how are they related? How are these different when in a OSI environment, IP environment and when in a Dual Environment? It would be better if we could get some examples of each type of address in each of the environments.. Thanx & Regards Navaneeth. From mshand@cisco.com Wed, 08 Mar 2000 09:12:03 +0000 Date: Wed, 08 Mar 2000 09:12:03 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-wg-mesh-group-00.txt At 10:32 02/03/2000 -0500, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the IS-IS for IP Internets Working Group of >the IETF. > > Title : IS-IS Mesh Groups > Author(s) : R. Balay, D. Katz, J. Parker > Filename : draft-ietf-isis-wg-mesh-group-00.txt > Pages : 9 > Date : 01-Mar-00 Just a few comments. In the modified 7.3.15.1. e.1.ii) there is no mention of what to do if the incoming circuit is 'meshblocked'. I assume this is do nothing, since if things are correctly configured you wouldn't receive an LSP over such a circuit, but the spec should be clear on this point. It could do with an example of how one is supposed to deploy it. It might be helpful to say that a very good way of shooting yourself in the foot is to define some links as meshSet and some links as meshBlocked in the same 'mesh'. One could argue that use of CSNPs gets you out of the hole, but maybe that is even worse because although you get the LSPs delivered eventually you introduce a considerable propagation delay. Oh and I think there's a typo. In the sentence leading up to the changes to section 7.3.15.3 clause b) (bottom of page 4) it says "...links with a mesh group meshEnabled or meshBlocked." presumably this should read "... links with a meshEnabled value of meshSet or meshBlocked" Mike From mshand@cisco.com Wed, 08 Mar 2000 09:30:55 +0000 Date: Wed, 08 Mar 2000 09:30:55 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-wg-mesh-group-00.txt At 09:12 08/03/2000 +0000, Mike Shand wrote: >In the modified 7.3.15.1. e.1.ii) there is no mention of what to do if the >incoming circuit is 'meshblocked'. I assume this is do nothing, since if >things are correctly configured you wouldn't receive an LSP over such a >circuit, but the spec should be clear on this point. Hmmm. Thinking about this some more, its not so obvious. If you received a CSNP over a meshBlocked circuit, and you had a newer LSP you would send it out over the meshBlocked circuit (since the draft makes no changes to section 7.3.15.2 c). Hence it would be entirely reasonable to receive an LSP over a circuit marked meshBlocked, even in a correctly configured network. So presumably one would want to accept that LSP and treat it as for meshSet? Mike From jparker@nexabit.com Wed, 8 Mar 2000 10:28:20 -0500 Date: Wed, 8 Mar 2000 10:28:20 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-wg-mesh-group-00.txt > At 10:32 02/03/2000 -0500, Internet-Drafts@ietf.org wrote: > > > > Title : IS-IS Mesh Groups > > Author(s) : R. Balay, D. Katz, J. Parker > > Filename : draft-ietf-isis-wg-mesh-group-00.txt > > Pages : 9 > > Date : 01-Mar-00 > > Just a few comments. Mike - Thanks for your careful reading. > In the modified 7.3.15.1. e.1.ii) there is no mention of what > to do if the incoming circuit is 'meshblocked'. I assume this > is do nothing, since if things are correctly configured you > wouldn't receive an LSP over such a circuit, but the spec > should be clear on this point. I would imagine that this would be a legal configuration, and that some might find a use for one way links like this. > It could do with an example of how one is supposed to deploy it. I suppose documenting them is one step on the slippery slope to advocating them. Perhaps I can find some weasel words and add an example: maybe a 6-way complete mesh constrained to have a couple of alternative flooding paths between each pair. > It might be helpful to say that a very good way of shooting > yourself in the foot is to define some links as meshSet and > some links as meshBlocked in the same 'mesh'. One could argue > that use of CSNPs gets you out of the hole, but maybe that is > even worse because although you get the LSPs delivered > eventually you introduce a considerable propagation delay. > > Oh and I think there's a typo. In the sentence leading up to > the changes to > section 7.3.15.3 clause b) (bottom of page 4) it says > > "...links with a mesh group meshEnabled or meshBlocked." > > presumably this should read > "... links with a meshEnabled value of meshSet or meshBlocked" > > Mike Thanks - will make that edit. - jeff parker - jdparker@lucent.com From jparker@nexabit.com Wed, 8 Mar 2000 10:57:54 -0500 Date: Wed, 8 Mar 2000 10:57:54 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-wg-mesh-group-00.txt > >In the modified 7.3.15.1. e.1.ii) there is no mention of > >what to do if the incoming circuit is 'meshblocked'. > > Hmmm. Thinking about this some more, its not so obvious. If > you received a CSNP over a meshBlocked circuit, and you had > a newer LSP you would send it out over the meshBlocked circuit > (since the draft makes no changes to section 7.3.15.2 c). > Hence it would be entirely reasonable to receive an LSP over > a circuit marked meshBlocked, even in a correctly configured > network. So presumably one would want to accept that LSP and > treat it as for meshSet? > > Mike Sorry, missed this when replying to previous. Is there a reason to discard any valid LSP? We do solicit them when we detect a missing LSP listed in a CSNP. We could check to see if this one arrived "on it's own" or if we asked for it, but this seems excessive. I see Mesh Groups as a way to cut back on transmissions. Once the network has taken the trouble to deliver an LSP, taking the time to check to see if the LSP is new, and keeping it if it is, seems conservative. - jdparker@lucent.com - Lucent INS From selvarajr@future.futsoft.com Sun, 12 Mar 2000 13:02:59 +0530 Date: Sun, 12 Mar 2000 13:02:59 +0530 From: SelvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubt regarding DR election ------ =_NextPart_000_01BF8C23.4D49F620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Regarding DR election 10589 : 92 section 8.4.5 (e) states that DR election process can start whenever an IIH PDU is received or transmitted as described in 8.4.4. I find this little bit vague. To my understanding I find it is better to start the DR election whenever 1. A new IIH PDU with higher priority than the existing DR been received. 2. The priority of any existing neighbour been increased higher than the existing DR 3. Initially after waiting for twice the Hello interval when circuit comes UP The third point is mentioned clearly . But the remaining cases are vague if I go through the STD. Will it happen to conduct DR election during transmission of IIH at any time. Some clarification with points of cases will be helpful. Thanx Selva ------ =_NextPart_000_01BF8C23.4D49F620 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IgMHAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAqAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAbgAAAAAAAAC1O8LALHcQGqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUf kqBkiAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAASVNJUy1XRwBTTVRQAGlzaXMtd2dAZXh0ZXJu YWwuanVuaXBlci5uZXQAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAHQAAAGlzaXMtd2dA ZXh0ZXJuYWwuanVuaXBlci5uZXQAAAAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAACgAAACdJU0lT LVdHJwAAAAIBCzABAAAAIgAAAFNNVFA6SVNJUy1XR0BFWFRFUk5BTC5KVU5JUEVSLk5FVAAAAAMA ADkAAAAACwBAOgEAAAAeAPZfAQAAAAgAAABJU0lTLVdHAAIB918BAAAALAAAAL8AAAC1O8LALHcQ GqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUfkqBkiAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAA BAAAAAAAAALsVAEEgAEAHAAAAERvdWJ0IHJlZ2FyZGluZyBEUiBlbGVjdGlvbgD6CQEFgAMADgAA ANAHAwAMAA0AAgA7AAAAMAEBIIADAA4AAADQBwMADAAMAB4AKAAAADgBAQmAAQAhAAAARjYzQTAx RTIwNkY4RDMxMUE4NTgwMDIwMzUxRjkyQTAA6AYBA5AGANAKAAAgAAAACwACAAEAAAALACMAAAAA AAMAJgAAAAAACwApAAAAAAADADYAAAAAAEAAOQBgoj4x9Yu/AR4AcAABAAAAHAAAAERvdWJ0IHJl Z2FyZGluZyBEUiBlbGVjdGlvbgACAXEAAQAAABYAAAABv4v1MS3iATsW+AYR06hYACA1H5KgAAAe AB4MAQAAAAUAAABTTVRQAAAAAB4AHwwBAAAAHQAAAHNlbHZhcmFqckBmdXR1cmUuZnV0c29mdC5j b20AAAAAAwAGEMz20FMDAAcQXQIAAB4ACBABAAAAZQAAAEhJLFJFR0FSRElOR0RSRUxFQ1RJT04x MDU4OTo5MlNFQ1RJT044NDUoRSlTVEFURVNUSEFURFJFTEVDVElPTlBST0NFU1NDQU5TVEFSVFdI RU5FVkVSQU5JSUhQRFVJU1JFQ0UAAAAAAgEJEAEAAACuBwAAqgcAADgRAABMWkZ1nCKJTgMACgBy Y3BnMTI1cjIMYGMxAzABBwtgbpEOEDAzMw8WZmUPkk8B9wKkA2MCAGNoCsBzhGV0AtFwcnEyAACS Kgqhbm8SUCAwAdCFAdA2D6AwNTA0FCHzAdAUEDR9B20CgwBQA9T7Ef8TC2IT4RRQE7IY9BTQrwcT AoACkQjmOwlvMBrf+mUOMDUcCh0hHN8d6Rv0/x4SHH8gTyANH48dvxwPEGD8Mjgl2ibxJq8nuRv0 J+K/Jk8qHyndKV8njytUOQ5QHy6kMAEoIzAAAoJzdHlqbAeQaAngdAAAA/BkGGN0bAqxAGBkanVz MXAFEGdoBUIWMgwBY4cJwDJAAzBzbmV4FzAvB7AFsADAAnNzAFBzYpYyFFAxYGET8FxrCeC+cAuQ MjgIYDJwC4BlMaD+djfgAUAy2wwwM6QoADaAmwSgC4BnJ/E0JmJhFxB+ZAIgNOA0hjHQMtA6ESD+ MTEzDlA13zbvN/MAUTh8/wCgM646/zwGMSQPwD0PPh+/N/MOUDhvQM9B3zwzMwKCPRMQYzWgSKEy 0DwwdGmJOBAgRAEQYXVsBUAKUArAYQnAYXBoII5GAiE1ZCVAZmktD5BeOAFAN7BNMzI4Ygsgcs8J UE6SFqBOknc0JUEXAP5wAdBKcjL/R59IpkzQS5AbBRACMC1MMANhOiBUQm9T8FN1YmoFkHRBU/BE YXRlOjVkNv9M/04PTx9QLjHAPCMOIUihbzk2DlBRr1K+UjgBFwEg7kg8EQSQNWQ3Va9Wv1fPv0ih N49ZPw+QZDAI0GIKsPx0OEb6D1RD0Fs/XEZkwPNdUAtQeS9MQFgwCxFdxf5zNWQoAF6/X89g31A/ UU/fZt9n6lQSU7RU6TkyL21FHWRzOW2fbq9z4ERvY/51B4ACMAXQTAAaAxMQYjA/MXABkTGgAAB3 YndUZW0/C1FVAHIwAdAv8FWANDP/AFB3YgCQeMF35WJzagBigm5uFsBp8WKCanu2AhBs/QkAd3vF MXAKwAGQUwB9Nf0KsGMKYHs0C4ABAAIwAeFnYnNVADTAXCcToIBRMO4uAoJ7RHZgYl2BgFE8gf1p gjNEMWIwgoJ8MHdlDMFNgoEggPJ3cW5hB4Agv4Ihd2J5IQ+QeaABwDgwAP13CG9dcTRBFyB3uIa2 hQ/7hmsFoHV/cWoANaAaEHIS730AclBrUQGAblRwAGAJ8P9KoHZAAgE1IFnSiFCMUTGAknAegFx2 CJB3a38x/2YAjcIE8AdAEGEBQA4AayL3PAKPJQIQbwVCFyES8nimoCBDOlxcU0BvS+HebUwwAxAH kJHQTQ3gA2Dkc28BgCBPASAN4IhQWlyThkUAwAMQLkhwdN+CMBcQclA0YWIyeAFAjCG+bjHQGvCV JEs0gzAgEvPzAIAFkGx2P2FEkA5wNSD/l7J9ophCfzQBwZexFuAPcM8AAESQDNABkCAudwSXxv8O UJhiS3AysJjfme+a/w/A30SQBYGcn52vnr9sZgBEkO5snF+hH6IlKZssJUCf/+Ok36IUYiAoApGl /5fz/1WQo6+ob6l/qo+YIF6Qq9L/mK+tP65PmywoAKvfsV+yb/+zf5ggcgCwX7Xvtv+4BAr5DwMw ci9tXzRRe0hpLBsKhV1QZwsRPEJEUiDrYmG90GkCICA8cBQgheA2IFPwMAAglTLBwjguxDQuUyAo ZSnCsH3R/QeRdBbgBUDBShdwdkAHkM8EII6wA6B9kyB3MdA0oEVdcSADkUlJSEuQRPRVIAQAIBrw fqBK4TRg9wWxvpAAcW1KwFUANGBIQP4gAQAE8oGgNGC9YcNCw2D9xzAgaZB/QMRBx8FiMAJAyTGg IGJKwCB2S9AKUMPKwFQQIG15IIpgaNL/AZB/QDxCyuXMIcfBgaB4kf/IkczQxiTEUEsBwVnGhwqF /6IDgCILCjO8y2AW0ABgAEH8ZGLUI2nxdkDUMABAPHD+LgyCvLUDMYJqvaiDLZeEzwrhtNCYIAbg ZHkMQJgR/4qTl7EEoJBgpVKnn39SgoKPoa+E8TWhvkp7QSA0oP8H4MdGA/DEUDvwvrHG4Rdw/8HA BRAxgMRCA6DP0jSwhSLvwRSBoAnwx+cu0W/Sf9OP/dSfMtW/1s/X39jv2f/bD/fcH90v3j1Uz+Hg x5NAxwH/zQDh5zSgvrEG4Ahw4pQLgP8FADwQSFHgRuFfwTHjj+Sf++Wv5r8z59/o7+n/6w/sH+/t L+4/70/ePUkBIErQB0D/Z/DHAIuwxuFoUErBPFGMkf/EQBZwfqDPw13QfOHKMc8Bz8xQl2DGgsXQ aXJ2UMwh84pAFRJVUAqF+wa9r97Ez/ZV8ULLUWhxcG9TYcey/3ZywcHIUYMwPBBrUASQysD+QmIQ z8Ma8JSROgLF0RNwf86w9pATgMxTx7DyIMrgZzfM0OAgkxB180DPw1NUekTKwFeUsJdgzCEW4HD/ jYD1QczQikB/QJiAxIwS8P9TUTxgyLXFsMHC8hHHQsRx3/JCStCEsON29lVTCEENQf/2kBAQkvBU 8NCT4BIMI86wf/IRDxTgABHBgaA78QnwZu9LYON28UDI0HjRVhZ8CS/33kxHAvhANFRAYmDMUIDw CRyGfQAgcAAAAwAQEAAAAAADABEQAAAAAAMAgBD/////QAAHMCDEha3wi78BQAAIMCDEha3wi78B CwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQ hQAAAAAAAAMABYAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADzFQAAAwAHgAggBgAAAAAAwAAAAAAA AEYAAAAAAYUAAAAAAAAeAAiACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAUAAAA4LjA0AAAA AAsACYAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAKgAggBgAAAAAAwAAAAAAAAEYAAAAA EYUAAAAAAAADAAuACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4ADIAIIAYAAAAAAMAAAAAA AABGAAAAADaFAAABAAAAAQAAAAAAAAAeAA2ACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEA AAAAAAAAHgAOgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAB4APQABAAAAAQAA AAAAAAADAA00/TcAAP6c ------ =_NextPart_000_01BF8C23.4D49F620-- From mshand@cisco.com Sun, 12 Mar 2000 22:13:48 +0000 Date: Sun, 12 Mar 2000 22:13:48 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Doubt regarding DR election Well, since the standard specifies only externally visible behaviour it makes no difference. If you 'run' the DR election in a case where there is no change it is exactly equivalent to not running it. Whether you actually 'run' it or not is an implementation detail. You could regard some of your cases as actually running the election and then aborting it when you discover that the PDU is not a higher priority. etc. etc. Mike At 13:02 12/03/2000 +0530, SelvarajR wrote: >Hi, >Regarding DR election 10589 : 92 section 8.4.5 (e) states that DR election >process can start whenever an IIH PDU is received or transmitted as >described in 8.4.4. I find this little bit vague. To my understanding I >find it is better to start the DR election whenever >1. A new IIH PDU with higher priority than the existing DR been received. >2. The priority of any existing neighbour been increased higher than the >existing DR >3. Initially after waiting for twice the Hello interval when circuit comes >UP > >The third point is mentioned clearly . But the remaining cases are vague if >I go through the STD. Will it happen to conduct DR election during >transmission of IIH at any time. > >Some clarification with points of cases will be helpful. >Thanx > > >Selva From Henrik.J.Villfor@telia.se Fri, 17 Mar 2000 13:35:27 +0100 Date: Fri, 17 Mar 2000 13:35:27 +0100 From: =?ISO-8859-1?Q?Henrik_Villf=F6r?= Henrik.J.Villfor@telia.se Subject: [Isis-wg] BGP in L1 routers Hi. Reading I am a bit surprised to find the following. " When a router learns multiple possible paths to external destinations via BGP, it will select only one of those routes to be installed in the forwarding table. One of the factors in the BGP route selection is the IGP cost to the BGP next hop address. Many ISP networks depend on this technique, which is known as "shortest exit routing". If a L1 router does not know the exact IGP metric to all BGP speakers in other L1 areas, it cannot do effective shortest exit routing. " What confuses me is that I was under the very strong impression that destinations could not be installed from BGP unless a route to the BGP next hop existed in the RIB and FIB and that a default route (as would be what is available in an L1 router for an external route) would not do. I would much appreciate if one of you wise people would spare the time to enlighten me. Thank's in advance, Henrik Villfor Telia Research From danny@tcb.net Fri, 17 Mar 2000 10:43:28 -0700 Date: Fri, 17 Mar 2000 10:43:28 -0700 From: Danny McPherson danny@tcb.net Subject: [Isis-wg] BGP in L1 routers Extracted from RFC 1771, Section 9.1.2: [...] If the NEXT_HOP attribute of a BGP route depicts an address to which the local BGP speaker doesn't have a route in its Loc-RIB, the BGP route SHOULD be excluded from the Phase 2 decision function. [...] The local speaker MUST determine the immediate next hop to the address depicted by the NEXT_HOP attribute of the selected route by performing a lookup in the IGP and selecting one of the possible paths in the IGP. This immediate next hop MUST be used when installing the selected route in the Loc-RIB. I see no reason why "one of the possible paths in the IGP" could not be the "default" route, so long as the immediate next hop address can be determined. -danny > " When a router learns multiple possible paths to external destinations > via BGP, it will select only one of those routes to be installed in > the forwarding table. One of the factors in the BGP route selection > is the IGP cost to the BGP next hop address. Many ISP networks > depend on this technique, which is known as "shortest exit routing". > If a L1 router does not know the exact IGP metric to all BGP speakers > in other L1 areas, it cannot do effective shortest exit routing. " > > What confuses me is that I was under the very strong impression that > destinations could not be installed from BGP unless a route to the BGP next > hop existed in the RIB and FIB and that a default route (as would be what is > available in an L1 router for an external route) would not do. From vleeschh@sh.bel.alcatel.be Tue, 21 Mar 2000 11:12:05 +0100 Date: Tue, 21 Mar 2000 11:12:05 +0100 From: Hans De Vleeschouwer WX29 58223 vleeschh@sh.bel.alcatel.be Subject: [Isis-wg] question related to isisSystemTable --------------35B21A56A6ED8AD8BC1FBE0D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have a question related to the isisSysTable On one hand we see that the table contains a row-status. This seems to indicate that the operator can create and delete rows. The question we have is: why are the objects not read-create in stead of read-write. Since non of the objects are read-create a row can in fact not be created by the operator (see RFC 2578). In our implementation we would allow only 1 instance of the protocol. Does it still make sense in this case, to allow the operator to create and delete this row, or would it make more sense to have always one row, and use the isisSysOperState to turn on/off the protocol. Any help is kindly appreciated. Kind regards, Hans De Vleeschouwer Alcatel --------------35B21A56A6ED8AD8BC1FBE0D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

I have  a question related to the isisSysTable

On one hand we see that the table contains a row-status. This seems to indicate that the operator can create and delete rows.


The question we have is: why are the objects not read-create in stead of read-write. Since non of the objects are read-create a row can in fact not be created by the operator (see RFC 2578).

In our implementation we would allow only 1 instance of the protocol.  Does it still make sense in this case, to allow the operator to create and delete this row,  or would it make more sense to have always one row, and use the isisSysOperState to turn on/off the protocol.
 

Any help is kindly appreciated.
 

Kind regards,
    Hans De Vleeschouwer
    Alcatel --------------35B21A56A6ED8AD8BC1FBE0D-- From navaneethk@future.futsoft.com Tue, 21 Mar 2000 17:58:03 +0530 Date: Tue, 21 Mar 2000 17:58:03 +0530 From: Navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Clarification on ISIS configuration Hi all.. My doubt is with regard to the configuration of Summary Addresses in ISIS . i. Can summary addresses be configured for both Level 1 and Level 2? If so , how do we use the Level 1 summary addresses? In advertising the summary addresses , do we take it from the Level 1 LSPs or from the routes calculated by Level 1 Decision process? ii. In the configuration of the summary address , there are two parts the address mask and the prefix mask. How are these used and what values do these take? Can anyone explain these with an illustration? Any help in this regard is most welcome. Thanks and Regards Navaneeth. From rsaluja@nortelnetworks.com Tue, 21 Mar 2000 08:33:37 -0500 Date: Tue, 21 Mar 2000 08:33:37 -0500 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] Clarification on ISIS configuration Navaneeth K wrote: > > Hi all.. > > My doubt is with regard to the configuration of Summary Addresses in ISIS . > > i. Can summary addresses be configured for both Level 1 and Level 2? Only for Level2 as far as RFC is concerned. Summarization is done while advertising L1 routes into L2 domain. > If so , how do we use the Level 1 summary addresses? In advertising the summary addresses , > do we take it from the Level 1 LSPs or from the routes calculated by Level 1 Decision process? from the routes calculated by Level 1 decision process. > ii. In the configuration of the summary address , there are two parts the address mask and the prefix mask. > How are these used and what values do these take? Can anyone explain these with an illustration? If you have 192.9.3.0/24 and 192.9.2.0/24 networks allocated to your L1 domain, you could configure 192.9.2.0/23 as summary address which will basically aggregate both while advertising to L2 domain. Regards, Rajesh From henk@procket.com Tue, 21 Mar 2000 19:11:57 +0100 (CET) Date: Tue, 21 Mar 2000 19:11:57 +0100 (CET) From: henk@procket.com henk@procket.com Subject: [Isis-wg] Clarification on ISIS configuration Hello Navaneeth, hello all, > My doubt is with regard to the configuration of Summary Addresses in ISIS . > > i. Can summary addresses be configured for both Level 1 and Level 2? Yes, they can now. RFC1195 only specifies L1->L2 leaking, and only specifies redistribution into L2. This has changed with the new draft draft-ietf-isis-domain-wide-02.txt. > If so , how do we use the Level 1 summary addresses? With the new draft about route-leaking, there are now two descriptions of how routes can be summarized into L1. 1) is via L2->L1 route-leaking, and 2) via redistribution from outside the IGP into ISIS. > In advertising the summary addresses , do we take it from the Level > 1 LSPs or from the routes calculated by Level 1 Decision process? From routes calculated. The rule of thumb for routing protocols is that you only advertise routes that you use yourself. So if a prefix is in the LSPDB, but for some reason you didn't install it in the RIB, then you will not advertise it. Nor use it when calculating summary addresses. Hope this helps, Henk. From vanik@future.futsoft.com Wed, 22 Mar 2000 11:50:37 +0530 Date: Wed, 22 Mar 2000 11:50:37 +0530 From: vanisri .k vanik@future.futsoft.com Subject: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsps Hi, I have doubts regarding the following. Please clarify me. 1. IS-IS allows multiple IP addresses assigned to an physical interface. What is the significant of it and where it is applied? 2. L2 Router advertises in its level 2 LSPs all the IP addresses reachable in their area. Summary address can be configured, otherwise all the level 1 Addresses obtained from the level 1 LSPs has to be advertised. My doubt is can we get the addresses from the "level 1 Forwarding Data base" instead of "level1 LSPs". RFC says (Sec 3.2 of 1195) these are determined from level 1 LSPs. Should the l2 router collects all l1 reachable addresses and the cost to reach them from level 1 LS data base, if summary address is not configured. Thanks -vani From jparker@nexabit.com Wed, 22 Mar 2000 09:34:40 -0500 Date: Wed, 22 Mar 2000 09:34:40 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsp s > Hi, > > I have doubts regarding the following. Please > clarify me. > > 1. > IS-IS allows multiple IP addresses assigned to > an physical interface. What is the significant of it > and where it is applied? IP allows multiple IP addresses assigned the the same interface. This can be used to allow a router to participate in multiple networks. ISIS just relays the information. > 2. > L2 Router advertises in its level 2 LSPs all the IP addresses > reachable in their area. Summary address can be configured, > otherwise all the level 1 Addresses obtained from the level 1 > LSPs has to be advertised. An optimization lets you reduce the network load by checking to see if the L1 route is comming from an L1/L2 router, which can be trusted to put it into L2 for you. > My doubt is can we get the addresses from the "level 1 > Forwarding Data base" > instead of "level1 LSPs". > RFC says (Sec 3.2 of 1195) these are determined from > level 1 LSPs. Should the l2 router collects all l1 reachable > addresses and the cost to reach them from level 1 LS data base, > if summary address is not configured. > > Thanks > -vani There are a number of issues in your question: I'm not sure which you are asking about. - jeff parker - Lucent INS From rsaluja@nortelnetworks.com Wed, 22 Mar 2000 09:37:43 -0500 Date: Wed, 22 Mar 2000 09:37:43 -0500 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsps "vanisri .k" wrote: > Hi, > > I have doubts regarding the following. Please > clarify me. > > 1. > IS-IS allows multiple IP addresses assigned to > an physical interface. What is the significant of it > and where it is applied? You can support multinetting on one physical interface. > > > 2. > L2 Router advertises in its level 2 LSPs all the IP addresses > reachable in their area. Summary address can be configured, > otherwise all the level 1 Addresses obtained from the level 1 > LSPs has to be advertised. > My doubt is can we get the addresses from the "level 1 Forwarding Data base" > instead of "level1 LSPs". > RFC says (Sec 3.2 of 1195) these are determined from > level 1 LSPs. Should the l2 router collects all l1 reachable > addresses and the cost to reach them from level 1 LS data base, > if summary address is not configured. Spec says "address obtained from level1 LSP". It is an implementation choice whether you want to extract this information from L1 LSPs or forwarding database or some other data structure. Regards, Rajesh From vanik@future.futsoft.com Thu, 23 Mar 2000 11:42:44 +0530 Date: Thu, 23 Mar 2000 11:42:44 +0530 From: vanisri .k vanik@future.futsoft.com Subject: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsp s Hi Jeff, My comments are inlined. > Hi, > > I have doubts regarding the following. Please > clarify me. > > 1. > IS-IS allows multiple IP addresses assigned to > an physical interface. What is the significant of it > and where it is applied? IP allows multiple IP addresses assigned the same interface. This can be used to allow a router to participate in multiple networks. ISIS just relays the information. [vanisri .k] Then how IS-IS should handle, when advertising reachable information about the nbr,having multiple IP addresses.? There will be multiple IP addresses (Reachable information) to that neighbor .? I am not much clear how IS-IS handles and relays the multiple IP addresses information. Could you please explain. > 2. > L2 Router advertises in its level 2 LSPs all the IP addresses > reachable in their area. Summary address can be configured, > otherwise all the level 1 Addresses obtained from the level 1 > LSPs has to be advertised. An optimization lets you reduce the network load by checking to see if the L1 route is comming from an L1/L2 router, which can be trusted to put it into L2 for you. > RFC says (Sec 3.2 of 1195) these are determined from > level 1 LSPs. Should the l2 router collects all l1 reachable > addresses and the cost to reach them from level 1 LS data base, > if summary address is not configured. > > Thanks > -vani There are a number of issues in your question: I'm not sure which you are asking about. [vanisri .k] My question was clarfied by Rajesh. My actual question was , How do the L1L2 Router collects the level 1 reachablity information, before it advertises in its level2 LSPs to other areas, from its level1 LSPs or Level 1 Forwarding Data base. ? Rajesh says, It is implementaion specific. - jeff parker - Lucent INS Thanks -vani From mshand@cisco.com Thu, 23 Mar 2000 12:00:29 +0000 Date: Thu, 23 Mar 2000 12:00:29 +0000 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsps At 09:37 22/03/2000 -0500, Rajesh Saluja wrote: >Spec says "address obtained from level1 LSP". It is an implementation choice >whether you want to extract this information from L1 LSPs or forwarding >database or some other data structure. But its important that what you extract is the REACHABLE addresses, not just any old addresses that happen to be skulking around in some unconnected L1 LSP. So in that sense you should get them from the RIB/FIB not from the raw LSP database. Mike From jparker@nexabit.com Thu, 23 Mar 2000 15:14:08 -0500 Date: Thu, 23 Mar 2000 15:14:08 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsp s > > 1. > > IS-IS allows multiple IP addresses assigned to > > an physical interface. What is the significant of it > > and where it is applied? > > IP allows multiple IP addresses assigned the same > interface. This can be used to allow a router to > participate in multiple networks. ISIS just relays > the information. > [vanisri .k] Then how IS-IS should handle, when advertising > reachable information about the nbr,having multiple IP addresses.? > There will be multiple IP addresses (Reachable information) > to that neighbor .? > I am not much clear how IS-IS handles and relays the multiple > IP addresses information. > Could you please explain. These IP Addresses could appear in two places: In the hello pkt sent out that port In the LSPs sent by that router If you have multiple IP addresses on a port, you could advertise one, both, or none in your L1 LSP and in your hellos. I think this is an implementation issue: but the principle of least surprise would probably suggest that you include both in Hellos and in LSPs. - jparker From satish@pluris.com Thu, 23 Mar 2000 12:30:43 -0800 Date: Thu, 23 Mar 2000 12:30:43 -0800 From: Satish Dattatri satish@pluris.com Subject: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsp s Hi Jeff, Take a configuration of R1 and R2 in a area. Let R1 have 2 interfaces R1I1 and R1I2. R1 and R2 are connected via R1I2. Now, if R1I1 has multiple IP addresses, The only way R2 will know is by the LSP of R1 [ assume only isis is running;-) ] Then, where is the option of none of the IP reachability info in L1 LSP holds out? Well, there may be other cases where with a router sending none of the IP info still may have connectivity. But that does not mean protocol can have the option of not sending local reachability. Please let me know if I am missing something here. thanks, satish These IP Addresses could appear in two places: In the hello pkt sent out that port In the LSPs sent by that router If you have multiple IP addresses on a port, you could advertise one, both, or none in your L1 LSP and in your hellos. I think this is an implementation issue: but the principle of least surprise would probably suggest that you include both in Hellos and in LSPs. - jparker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From jparker@nexabit.com Thu, 23 Mar 2000 15:52:14 -0500 Date: Thu, 23 Mar 2000 15:52:14 -0500 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsp s Satish - I will not try to defend the option "none", though I admit that I raised it earlier. There is a place for unnumbered interfaces, but that is another discussion. I am just trying to suggest that there is a great deal of leyway for implementations. There may be a reason to have a second IP address, and there may be a reason not to mention that address to the ISIS protocol. R2 will not know about it: that may be what the user wants. We do not want to be in the business of telling you how your users use the protocol. - jeff parker - I'm not sure if these opinions are mine, - much less those of Lucent Technologies. > Hi Jeff, > Take a configuration of R1 and R2 > in a area. Let R1 have 2 interfaces > R1I1 and R1I2. R1 and R2 are connected > via R1I2. > Now, if R1I1 has multiple IP addresses, > The only way R2 will know is by the LSP > of R1 [ assume only isis is running;-) ] > > Then, where is the option of none of the IP > reachability info in L1 LSP holds out? > > Well, there may be other cases where with a > router sending none of the IP info still may > have connectivity. But that does not mean > protocol can have the option of not sending > local reachability. > > Please let me know if I am missing something here. > thanks, > satish > > > These IP Addresses could appear in two places: > In the hello pkt sent out that port > In the LSPs sent by that router > > If you have multiple IP addresses on a port, you could > advertise one, both, or none in your L1 LSP and in your > hellos. I think this is an implementation issue: but > the principle of least surprise would probably suggest > that you include both in Hellos and in LSPs. > > - jparker > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From naiming@siara.com Thu, 23 Mar 2000 13:04:25 -0800 Date: Thu, 23 Mar 2000 13:04:25 -0800 From: Naiming Shen naiming@siara.com Subject: [Isis-wg] Reg. multiple IP addr and Advt of L1 Addr in L2 Lsp s ]Hi Jeff, ]Take a configuration of R1 and R2 ]in a area. Let R1 have 2 interfaces ]R1I1 and R1I2. R1 and R2 are connected ]via R1I2. ]Now, if R1I1 has multiple IP addresses, ]The only way R2 will know is by the LSP ]of R1 [ assume only isis is running;-) ] ] ]Then, where is the option of none of the IP ]reachability info in L1 LSP holds out? ] depends on if there is a need for R2 to know the IP address on R1I1. some IP addresses should be stay local only. so this is an implementation and configuration issue. even if R1I1 has isis configured on the interface, you don't have to stuff all the IP addresses on the LSPs, you have a choice say only put "primary" address there, or put all the addresses there, or even use some kind of filtering to selectively stuff part of the addresses there. An example is if you have a 10/x address on the interface as a secondary IP address, you may choose not to advertise it into your isis LSP. you can also use redistribution to selectively bring in your connected IP addresses using some kind of policy. ]Well, there may be other cases where with a ]router sending none of the IP info still may ]have connectivity. But that does not mean ]protocol can have the option of not sending ]local reachability. ] ]Please let me know if I am missing something here. ]thanks, ]satish ] ] ]These IP Addresses could appear in two places: ] In the hello pkt sent out that port ] In the LSPs sent by that router ] ]If you have multiple IP addresses on a port, you could ]advertise one, both, or none in your L1 LSP and in your ]hellos. I think this is an implementation issue: but ]the principle of least surprise would probably suggest ]that you include both in Hellos and in LSPs. ] ]- jparker ] ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg ] ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming From mbartell@cisco.com Fri, 24 Mar 2000 00:56:20 -0600 Date: Fri, 24 Mar 2000 00:56:20 -0600 From: Micah Bartell mbartell@cisco.com Subject: [Isis-wg] ISIS TE Draft Do we have a new revision of the draft-ietf-isis-traffic? Revision 02 has expired. This Internet-Draft has expired and is no longer available. Unrevised documents placed in the Internet-Drafts directories have a maximum life of six months. After that time, they must be updated, or they will be deleted. This document was deleted on March 20, 2000. /mpb -- Micah Bartell, CCIE #5069 mbartell@cisco.com Network Consulting Engineer, NSA Phone: 972.364.8829 Cisco Systems, Inc Fax: 972.364.8829 -- The Network Works, No Excuses From dwfedyk@nortelnetworks.com Fri, 24 Mar 2000 11:31:51 -0500 Date: Fri, 24 Mar 2000 11:31:51 -0500 From: Don Fedyk dwfedyk@nortelnetworks.com Subject: [Isis-wg] ISIS TE Draft This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF95AE.76AE75BA Content-Type: text/plain; charset="iso-8859-1" This is a good point. I will mention it at the Routing Area meeting. We are proposing extensions to this draft and OSPF. Neither WG is meeting at Adelaide though. Regards, Don > -----Original Message----- > From: Micah Bartell [mailto:mbartell@cisco.com] > Sent: Friday, March 24, 2000 1:56 AM > To: isis-wg@external.juniper.net > Subject: [Isis-wg] ISIS TE Draft > > > Do we have a new revision of the draft-ietf-isis-traffic? > > Revision 02 has expired. > > This Internet-Draft has expired and is no longer available. > Unrevised documents placed in the Internet-Drafts directories > have a maximum life of six months. After that time, they must > be updated, or they will be deleted. This document was > deleted on March 20, 2000. > > > /mpb > > > -- > Micah Bartell, CCIE #5069 mbartell@cisco.com > Network Consulting Engineer, NSA Phone: 972.364.8829 > Cisco Systems, Inc Fax: 972.364.8829 > -- > The Network Works, No Excuses > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > ------_=_NextPart_001_01BF95AE.76AE75BA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] ISIS TE Draft

This is a good point. I will mention it at the = Routing
Area meeting. We are proposing extensions to this = draft and
OSPF. Neither WG is meeting at Adelaide = though.

Regards,
Don

> -----Original Message-----
> From: Micah Bartell [mailto:mbartell@cisco.com]=
> Sent: Friday, March 24, 2000 1:56 AM
> To: isis-wg@external.juniper.net
> Subject: [Isis-wg] ISIS TE Draft
>
>
> Do we have a new revision of the = draft-ietf-isis-traffic?
>
> Revision 02 has expired.
>
> This Internet-Draft has expired and is no = longer available.
> Unrevised documents placed in the = Internet-Drafts directories
> have a maximum life of six months. After that = time, they must
> be updated, or they will be deleted. This = document was
> deleted on March 20, 2000.
>
>
> /mpb
>
>
> --
> Micah Bartell, CCIE = #5069     =         =         mbartell@cisco.com
> Network Consulting Engineer, = NSA      =         Phone: 972.364.8829
> Cisco Systems, Inc    =         =         =         Fax: 972.364.8829
> --
> The Network Works, No Excuses
>
> = _______________________________________________
> Isis-wg mailing list  -  = Isis-wg@external.juniper.net
> http://external.juniper.net/mailman/listinfo/isis-wg
>

------_=_NextPart_001_01BF95AE.76AE75BA-- From henk@procket.com Sun, 26 Mar 2000 19:59:50 +0200 (CEST) Date: Sun, 26 Mar 2000 19:59:50 +0200 (CEST) From: Henk Smit henk@procket.com Subject: [Isis-wg] ISIS TE Draft > Do we have a new revision of the draft-ietf-isis-traffic? No. However, I will have a look at it in the near future, and get a new version out. Might take a few weeks, though. If anyone has any comments or remarks, please let me know. Henk. > Revision 02 has expired. > > This Internet-Draft has expired and is no longer available. Unrevised documents placed in the Internet-Drafts directories have a maximum life of six months. After that time, they must be updated, or they will be deleted. This document was deleted on March 20, 2000. > > > /mpb > > > -- > Micah Bartell, CCIE #5069 mbartell@cisco.com > Network Consulting Engineer, NSA Phone: 972.364.8829 > Cisco Systems, Inc Fax: 972.364.8829 > -- > The Network Works, No Excuses > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From selvarajr@future.futsoft.com Wed, 5 Apr 2000 12:10:39 +0530 Date: Wed, 5 Apr 2000 12:10:39 +0530 From: SelvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubt regarding PtPtCircId ------ =_NextPart_000_01BF9EF7.F66220C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Please, could any of you tell the use of PtPtCircId in Integrated ISIS MIB. This object is mentioned in the circuit Table. The standard has mentioned some negotiation process for that. But I find it is no where used in the Protocol. SELVA ------ =_NextPart_000_01BF9EF7.F66220C0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IikGAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAqAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAbgAAAAAAAAC1O8LALHcQGqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUf kqBkiAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAASVNJUy1XRwBTTVRQAGlzaXMtd2dAZXh0ZXJu YWwuanVuaXBlci5uZXQAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAHQAAAGlzaXMtd2dA ZXh0ZXJuYWwuanVuaXBlci5uZXQAAAAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAACgAAACdJU0lT LVdHJwAAAAIBCzABAAAAIgAAAFNNVFA6SVNJUy1XR0BFWFRFUk5BTC5KVU5JUEVSLk5FVAAAAAMA ADkAAAAACwBAOgEAAAAeAPZfAQAAAAgAAABJU0lTLVdHAAIB918BAAAALAAAAL8AAAC1O8LALHcQ GqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUfkqBkiAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAA BAAAAAAAAALsVAEEgAEAGwAAAERvdWJ0IHJlZ2FyZGluZyBQdFB0Q2lyY0lkAKcJAQWAAwAOAAAA 0AcEAAUADAAKACcAAwAgAQEggAMADgAAANAHBAAFAAwAAwAsAAMAHgEBCYABACEAAAAxOTY5OTI3 ODQxMEFENDExQTg1ODAwMjAzNTFGOTJBMADGBgEDkAYAYAQAACAAAAALAAIAAQAAAAsAIwAAAAAA AwAmAAAAAAALACkAAAAAAAMANgAAAAAAQAA5AMCCbNvJnr8BHgBwAAEAAAAbAAAARG91YnQgcmVn YXJkaW5nIFB0UHRDaXJjSWQAAAIBcQABAAAAFgAAAAG/nsnbY3iSaR8KQRHUqFgAIDUfkqAAAB4A HgwBAAAABQAAAFNNVFAAAAAAHgAfDAEAAAAdAAAAc2VsdmFyYWpyQGZ1dHVyZS5mdXRzb2Z0LmNv bQAAAAADAAYQNa9yjgMABxDCAAAAHgAIEAEAAABlAAAASElQTEVBU0UsQ09VTERBTllPRllPVVRF TExUSEVVU0VPRlBUUFRDSVJDSURJTklOVEVHUkFURURJU0lTTUlCVEhJU09CSkVDVElTTUVOVElP TkVESU5USEVDSVJDVUlUVEFCTAAAAAACAQkQAQAAAD8BAAA7AQAAgwEAAExaRnXoe3gMAwAKAHJj cGcxMjUWMgD4C2BuDhAwMzOdAfcgAqQD4wIAY2gKwGBzZXQwIAcTAoB9OQqBdWMAUAsDC7UgSA5p CuMKhAqAUGxlYQkRMCwgBaB1bGQggQBweSBvZiB5CGAQIHRlbAMgdGhlTCB1ETAVQlB0FsBDMGly Y0kU8AuAICBqSQIwZQnAYRXAFPBJBlMYYAXQSUIuIFTmaAQAFUBiagWQBUAZIXsHgAIwaQIgGDEX cRYSY2kXEXVpBUBUAaAUQC6XE3QZABYwcwGQbmQLEXYgEQAZ2nMDcBYwGlBnTm8aIBgQGjEgcANg Y38HkAQgAhAFwBYQGBAY4EJ6dQVASR9wC4AXURmjbnhvIHcWIAlwFkIad1A9A2B0HyAG8BvVE3pT RVhMVkETdBHxACUgAAMAEBAAAAAAAwAREAAAAAADAIAQ/////0AABzDgrjbkyJ6/AUAACDDgrjbk yJ6/AQsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYA AAAAEIUAAAAAAAADAAWACCAGAAAAAADAAAAAAAAARgAAAABShQAA8xUAAAMAB4AIIAYAAAAAAMAA AAAAAABGAAAAAAGFAAAAAAAAHgAIgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAFAAAAOC4w NAAAAAALAAmACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMACoAIIAYAAAAAAMAAAAAAAABG AAAAABGFAAAAAAAAAwALgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAAyACCAGAAAAAADA AAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgANgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEA AAABAAAAAAAAAB4ADoAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAAeAD0AAQAA AAEAAAAAAAAAAwANNP03AAC+yw== ------ =_NextPart_000_01BF9EF7.F66220C0-- From mshand@cisco.com Wed, 05 Apr 2000 09:11:21 +0100 Date: Wed, 05 Apr 2000 09:11:21 +0100 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Doubt regarding PtPtCircId At 12:10 05/04/2000 +0530, SelvarajR wrote: >Hi > >Please, could any of you tell the use of PtPtCircId in Integrated ISIS >MIB. This object is mentioned in the circuit Table. >The standard has mentioned some negotiation process for that. But I find >it is no where used in the Protocol. 8.2.4.2 sub-clause (d) (if the circuit ID changes drop the adjacency). You are right that this is not ever SENT in the protocol. The local circuit ID is used for that. But the existing value is checked against the newly computed value (based on the value of the other nodes's local circuit ID carried in the protocol. Mike >SELVA From selvarajr@future.futsoft.com Wed, 5 Apr 2000 14:31:02 +0530 Date: Wed, 5 Apr 2000 14:31:02 +0530 From: SelvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubt regarding PtPtCircId ------ =_NextPart_000_01BF9F0B.93ECF5A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit But that section is totally left out in the 10589 1998 draft. This I'm mentioning just to consider while taking corrective action in the draft. Thanks SELVA -----Original Message----- From: Mike Shand [SMTP:mshand@cisco.com] Sent: Wednesday, April 05, 2000 1:41 PM To: SelvarajR; 'ISIS-WG' Subject: Re: [Isis-wg] Doubt regarding PtPtCircId At 12:10 05/04/2000 +0530, SelvarajR wrote: >Hi > >Please, could any of you tell the use of PtPtCircId in Integrated ISIS >MIB. This object is mentioned in the circuit Table. >The standard has mentioned some negotiation process for that. But I find >it is no where used in the Protocol. 8.2.4.2 sub-clause (d) (if the circuit ID changes drop the adjacency). You are right that this is not ever SENT in the protocol. The local circuit ID is used for that. But the existing value is checked against the newly computed value (based on the value of the other nodes's local circuit ID carried in the protocol. Mike >SELVA _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg ------ =_NextPart_000_01BF9F0B.93ECF5A0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IgYJAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAIAMAAAIAAAARAAAAAwAAMAMAAAAL AA8OAQAAAAIB/w8BAAAAOQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAABAE1pa2UgU2hhbmQAU01U UABtc2hhbmRAY2lzY28uY29tAAAAAB4AAjABAAAABQAAAFNNVFAAAAAAHgADMAEAAAARAAAAbXNo YW5kQGNpc2NvLmNvbQAAAAADABUMAQAAAAMA/g8GAAAAHgABMAEAAAANAAAAJ01pa2UgU2hhbmQn AAAAAAIBCzABAAAAFgAAAFNNVFA6TVNIQU5EQENJU0NPLkNPTQAAAAMAADkAAAAACwBAOgAAAAAD AHE6AAAAAB4A9l8BAAAACwAAAE1pa2UgU2hhbmQAAAIB918BAAAAOQAAAAAAAACBKx+kvqMQGZ1u AN0BD1QCAAABAE1pa2UgU2hhbmQAU01UUABtc2hhbmRAY2lzY28uY29tAAAAAAMA/V8BAAAAAwD/ XwAAAAACAfYPAQAAAAQAAAAAAAADEAAAAAMAADAEAAAACwAPDgAAAAACAf8PAQAAAG4AAAAAAAAA tTvCwCx3EBqhvAgAKypWwhUAAAAT3mZrXmHTEahYACA1H5KgZIgAAAAAAACBKx+kvqMQGZ1uAN0B D1QCAAAAAElTSVMtV0cAU01UUABpc2lzLXdnQGV4dGVybmFsLmp1bmlwZXIubmV0AAAAHgACMAEA AAAFAAAAU01UUAAAAAAeAAMwAQAAAB0AAABpc2lzLXdnQGV4dGVybmFsLmp1bmlwZXIubmV0AAAA AAMAFQwCAAAAAwD+DwYAAAAeAAEwAQAAAAoAAAAnSVNJUy1XRycAAAACAQswAQAAACIAAABTTVRQ OklTSVMtV0dARVhURVJOQUwuSlVOSVBFUi5ORVQAAAADAAA5AAAAAAsAQDoBAAAAHgD2XwEAAAAI AAAASVNJUy1XRwACAfdfAQAAACwAAAC/AAAAtTvCwCx3EBqhvAgAKypWwhUAAAAT3mZrXmHTEahY ACA1H5KgZIgAAAMA/V8BAAAAAwD/XwAAAAACAfYPAQAAAAQAAAAAAAAEQZcBBIABACkAAABSRTog W0lzaXMtd2ddIERvdWJ0IHJlZ2FyZGluZyBQdFB0Q2lyY0lkABMOAQWAAwAOAAAA0AcEAAUADgAf AAIAAwASAQEggAMADgAAANAHBAAFAA4AGAAfAAMAKAEBCYABACEAAAAyNjY5OTI3ODQxMEFENDEx QTg1ODAwMjAzNTFGOTJBMADEBgEDkAYAtAcAACIAAAALAAIAAQAAAAsAIwAAAAAAAwAmAAAAAAAL ACkAAAAAAAMALgAAAAAAAwA2AAAAAABAADkAgPwTeN2evwEeAHAAAQAAACkAAABSRTogW0lzaXMt d2ddIERvdWJ0IHJlZ2FyZGluZyBQdFB0Q2lyY0lkAAAAAAIBcQABAAAAFgAAAAG/nt132niSaSgK QRHUqFgAIDUfkqAAAB4AHgwBAAAABQAAAFNNVFAAAAAAHgAfDAEAAAAdAAAAc2VsdmFyYWpyQGZ1 dHVyZS5mdXRzb2Z0LmNvbQAAAAADAAYQrBTkowMABxBhAwAAHgAIEAEAAABlAAAAQlVUVEhBVFNF Q1RJT05JU1RPVEFMTFlMRUZUT1VUSU5USEUxMDU4OTE5OThEUkFGVFRISVNJTU1FTlRJT05JTkdK VVNUVE9DT05TSURFUldISUxFVEFLSU5HQ09SUkVDVElWRQAAAAACAQkQAQAAADsEAAA3BAAAgwYA AExaRnW9CosOAwAKAHJjcGcxMjV2MgD0AfcgAqQD4wIAY4JoCsBzZXQwIAcThwKDAFAPtnBycTIQ tmZ9CoAIyCA7CW8OMDWzAoAKgXVjAFALA2MAQUULYG4OEDAzMwumIHRCdQVAdBBABUAQcGO0dGkC ICAEABdQbwGQoGxseSBsAXEgCGAnBUALgBdRZSAWUDU4AjkZ0Dk5OCBkckJhAYAuIFRoGDFJeCdt IAeAAjAX8QuAZ5AganVzF0FvIAWgcwCBBIEgdxsQGOAXUGHeaxwCBaEJcBfRdhnAAND/F+QZhBqU CqIKhAqAGwAAcAZrBCEgKVNFTFZBwyAaCvRsaTM2AUAV0B8BQBIAGHAXwRFEMTYg6i0lEk8FEGcL gAdABdDhB5BzYWdlJRMgFiQkByPxCxMkJmktMTQ04wFAI3AxODABQAzQKLOoYiBGA2E6DINiEKAo TWlrGcBTIOFkIABbU01UUDptc1krMkBjBAAFoC4FoG2+XSAVKeAGYAIwKkdXCYDCbgeQZGF5LBCw EgA/AxEZ8C7gAdApQBnQOjSQMSBQTSz3VG8qRwkGYGx2CsBhalI7ECAnSVMyYC1XR2InLPh1YmoX wSpHUhRlOitwSQCQcy130GddIEQIYGIFQAlwJmcLERwCUHQ2UENp+HJjSQsxJt8n6CN0C7ZtICNB BUAOIDoWUC9RLygwNC8voysZ8DMwPy7gMacdQCQiKkAgIz5I1wCgPLQ8pVAY4GEQcC7gOQWgdWwr YABwGMBvZvwgeQhgF1AxsAMgGaIcUP8ZwD8xNlgZYhtAAjA1wBqgDyRAK2AyYiE1Pk1JQv0a5W8z kxgiG5VCERl1LFDpNrB1aQVAVAGgGOAgBb4+GwAZwBxgK0ELESAQQN1EKnMDcBnALoBnGHAHMOsX 4yQRYyYBIAIQBcAXYvsa4BciSUnQC4ArYDylRaF9GDFuHKAdUASQQBNEx1APJCFJgAbwIAs4LjIu zjROsBegM4AtYwtgQDI4KGQpT8AGkEULSUSfHLAg4SZABCAakG9wGZMYYWRqANAJ8GN5Kb0gC1k/ cQrAGcAlcWgXRe8XYBgxS9MFQGUeoAXAIgD8TlQZZiQSTZMa8RnACQD+YyXBRVYgFFERGDFMk0ns +RmiZXgEABfgHBEx0ApB/xgiEDAFkCrwPtE10AuAHGK7GbEugHcYsSAULLFwFzDzQhFbRChiPkEr YBgBGaJ/W0Q/MRmiGHBMQUvxAQBz/icEIFesURFdZgrACIFEx/9WxyJeCoBBcGV1KtJkXyBl9j4i DyAUX2lPal9rKliF/zTUG4ALcCNwHBEjcBxhJQB7QXE01EBasCRABKAHQC7rHEADAHAEkC4ugCRw ICQPFdI+sEdgAkBwOi8v226vb7EvbRIDgS9tkguA/QIQLwQANOMjwz6wOYUSwQIAdSAAAwAQEAAA AAADABEQAAAAAB4AQhABAAAALwAAADw0LjIuMi4yMDAwMDQwNTA5MDgxNC4wMGFhZTYxMEBqYXdz LmNpc2NvLmNvbT4AAAMAgBD/////QAAHMGCYBI/cnr8BQAAIMGCYBI/cnr8BCwAAgAggBgAAAAAA wAAAAAAAAEYAAAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMABYAI IAYAAAAAAMAAAAAAAABGAAAAAFKFAADzFQAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAA AAAeAAiACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAUAAAA4LjA0AAAAAAsACYAIIAYAAAAA AMAAAAAAAABGAAAAAA6FAAAAAAAAAwAKgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADAAuA CCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4ADIAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAAB AAAAAQAAAAAAAAAeAA2ACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAOgAgg BgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAB4APQABAAAABQAAAFJFOiAAAAAAAwAN NP03AABe0g== ------ =_NextPart_000_01BF9F0B.93ECF5A0-- From mshand@cisco.com Wed, 05 Apr 2000 10:15:51 +0100 Date: Wed, 05 Apr 2000 10:15:51 +0100 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Doubt regarding PtPtCircId At 14:31 05/04/2000 +0530, SelvarajR wrote: >But that section is totally left out in the 10589 1998 draft. This I'm >mentioning just to consider while taking corrective action in the draft. Which just goes to show that you should not believe ANYTHING you read in the so called 1998 draft. I think the strategy being adopted is to ignore the 1998 draft, but start with the original 1992 standard, and apply all the defect reports etc. to that. Mike From rvaradar@fore.com Thu, 6 Apr 2000 17:39:06 -0400 (EDT) Date: Thu, 6 Apr 2000 17:39:06 -0400 (EDT) From: Rajesh Varadarajan rvaradar@fore.com Subject: [Isis-wg] Doubt regarding PtPtCircId This misunderstanding of using one draft vs the other has happened *multiple* times in the mailing list. It would be useful to have a pointer to the ISO document that is to be used for reference at the IETF web site or at a place which is *freely* accessible. This will for hopefully avoid this type of misunderstanding so that people know what version of the standard to implement to. For ISO liasons or WG chairs - Would ISO would make it available for use for the IETF community for *free* :) along with the defect reports that are relevant for ISIS. thanks, rajesh On Wed, 5 Apr 2000, Mike Shand wrote: > At 14:31 05/04/2000 +0530, SelvarajR wrote: > >But that section is totally left out in the 10589 1998 draft. This I'm > >mentioning just to consider while taking corrective action in the draft. > > Which just goes to show that you should not believe ANYTHING you read in > the so called 1998 draft. > > I think the strategy being adopted is to ignore the 1998 draft, but start > with the original 1992 standard, and apply all the defect reports etc. to > that. > > > Mike > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From selvarajr@future.futsoft.com Fri, 7 Apr 2000 18:00:11 +0530 Date: Fri, 7 Apr 2000 18:00:11 +0530 From: SelvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubt reg system type usage in Integ. ISIS ------ =_NextPart_000_01BFA0BB.21070560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi The Integ,ISIS MIB draft has specified three values for system type( L1(1) or L2(2) or L1AndL2 (3) ) in the system table But the Hello PDU transmission is based on whether system Type is L1 (1) ,or L2 (3) and manualCircL2Only( TRUE/FALSE) Here, if the system type is L1AndL2 ( 3 ) then no Hello be sent. The system type object in the MIB shall be defined to take only two values, L1 (1) or L2 (2). No L1AndL2 ( 3 ). I hope the MIB Draft is still Valid.. How can we handle this anomaly? SELVA ------ =_NextPart_000_01BFA0BB.21070560 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhAMAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAqAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAbgAAAAAAAAC1O8LALHcQGqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUf kqBkiAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAASVNJUy1XRwBTTVRQAGlzaXMtd2dAZXh0ZXJu YWwuanVuaXBlci5uZXQAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAHQAAAGlzaXMtd2dA ZXh0ZXJuYWwuanVuaXBlci5uZXQAAAAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAACgAAACdJU0lT LVdHJwAAAAIBCzABAAAAIgAAAFNNVFA6SVNJUy1XR0BFWFRFUk5BTC5KVU5JUEVSLk5FVAAAAAMA ADkAAAAACwBAOgEAAAAeAPZfAQAAAAgAAABJU0lTLVdHAAIB918BAAAALAAAAL8AAAC1O8LALHcQ GqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUfkqBkiAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAA BAAAAAAAAALsVAEEgAEAKwAAAERvdWJ0IHJlZyBzeXN0ZW0gdHlwZSB1c2FnZSBpbiBJbnRlZy4g SVNJUwDMDgEFgAMADgAAANAHBAAHABIAAAALAAUABAEBIIADAA4AAADQBwQABwARACwAJQAFAEkB AQmAAQAhAAAARUJGMzRBOUQ3QzBDRDQxMUE4NTgwMDIwMzUxRjkyQTAAHAcBA5AGACAFAAAgAAAA CwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAEAAOQDAC30EjaC/AR4AcAAB AAAAKwAAAERvdWJ0IHJlZyBzeXN0ZW0gdHlwZSB1c2FnZSBpbiBJbnRlZy4gSVNJUwAAAgFxAAEA AAAWAAAAAb+gjQR1nUrz7Qx8EdSoWAAgNR+SoAAAHgAeDAEAAAAFAAAAU01UUAAAAAAeAB8MAQAA AB0AAABzZWx2YXJhanJAZnV0dXJlLmZ1dHNvZnQuY29tAAAAAAMABhC3lZrsAwAHEIgBAAAeAAgQ AQAAAGUAAABISVRIRUlOVEVHLElTSVNNSUJEUkFGVEhBU1NQRUNJRklFRFRIUkVFVkFMVUVTRk9S U1lTVEVNVFlQRShMMSgxKU9STDIoMilPUkwxQU5ETDIoMykpSU5USEVTWVNURU1UQUJMAAAAAAIB CRABAAAA7QEAAOkBAAC8AgAATFpGdWkT1GIDAAoAcmNwZzEyNRYyAPgLYG4OEDAzM50B9yACpAPj AgBjaArAYHNldDAgBxMCgH05CoF1YwBQCwMLtSBIDwCgCrEKhAqAVGhlIIJJAjBlZyxJUxTAgQXQ SUIgZHJhAYDmIBEABCBzcAWQBpAIkJBkIHRoCdEgdgdAjwpQBCACEAXAc3lzFIAKbRaAeRYAKCBM MRAoMSkgBbFMMihCMhi0MUFuZBkAIPwoMxiwGLALgBaBFEAXpskBoGxlE2RCdQVAGqIISGVsCQAg UERV1xaAFWAAgG0EAWkCIBpg3QQgYhXAFmEdwXcUMBqh/ReHVBghHeITZBhwGgAYoX4sBbAgJRn0 AHAWcAOBdSEHQENpcmMZAE9uBGx5GFBUUlVFL8BGQUxTRSkTahyAdQlwLBpgZhqbH7UZlyDOMxpB GqEDoCBuHMAchGZiGsEJ8HQuE24lmm+8YmoFkAVAGnUVEnMRAH8coChCAQELgBZiHMABkGv3KnEj ARaAdxzAFvQlACCF9xjTGgAZMC4HsBzAJosoy9pJFaBvH8ErNkQVYx3xFxfAAxADIFYHQGlkLqko y0hvB+BjA5F3FED/EQAZwBuAFoEd8QBwA3EjEI4/E2oTaiPQTFZBE2QFEfEAOLAAAAADABAQAAAA AAMAERAAAAAAAwCAEP////9AAAcwQDud14qgvwFAAAgwQDud14qgvwELAACACCAGAAAAAADAAAAA AAAARgAAAAADhQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAFgAggBgAA AAAAwAAAAAAAAEYAAAAAUoUAAPMVAAADAAeACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAB4A CIAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABQAAADguMDQAAAAACwAJgAggBgAAAAAAwAAA AAAAAEYAAAAADoUAAAAAAAADAAqACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAC4AIIAYA AAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgAMgAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAAB AAAAAAAAAB4ADYAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeAA6ACCAGAAAA AADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAAHgA9AAEAAAABAAAAAAAAAAMADTT9NwAASgs= ------ =_NextPart_000_01BFA0BB.21070560-- From jparker@nexabit.com Fri, 7 Apr 2000 10:01:42 -0400 Date: Fri, 7 Apr 2000 10:01:42 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] RE: Doubt reg system type usage in Integ. ISIS > Hi > > The Integ,ISIS MIB draft has specified three values for > system type( L1(1) or L2(2) or L1AndL2 (3) ) in the system table > But the Hello PDU transmission is based on whether system Type is > L1 (1) ,or > L2 (3) and manualCircL2Only( TRUE/FALSE) > > Here, if the system type is L1AndL2 ( 3 ) then no Hello be sent. > > The system type object in the MIB shall be defined to take > only two values, L1 (1) or L2 (2). No L1AndL2 ( 3 ). > > I hope the MIB Draft is still Valid.. > > How can we handle this anomaly? > > SELVA Selva - As you know, L2 in line 7 above means L1AndL2. The current MIB work reflects many changes that have been deployed since the original version of 10589 was written. This is one place where existing practice and the document conflict. When implementing a system, you may decide if you wish to implement the a system that supports system type of L2 only. If not, you need not vary your implementation of the Hello Transmission. If you would like to support L2 only systemType, you will need to change the algorithm in the Hello PDU transmission in the obvious fashion. - jeff parker From selvarajr@future.futsoft.com Fri, 7 Apr 2000 20:38:14 +0530 Date: Fri, 7 Apr 2000 20:38:14 +0530 From: SelvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] RE: Doubt reg system type usage in Integ. ISIS ------ =_NextPart_000_01BFA0D1.34EFC100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jeff, Thank U Thers is one mistake in my last mail. The line number 7 should have been "L2 (2) and manualCircL2Only( TRUE/FALSE)" I'm sorry. That what I like to convey is, setting 3 to system type object in system table will case problem during Hello transmission. OK , anyhow I accept ur suggestion that the implementation should decide over the algorithm. SELVA -----Original Message----- From: Jeff Parker [SMTP:jparker@nexabit.com] Sent: Friday, April 07, 2000 7:32 PM To: selvarajr@kailash.future.futsoft.com; 'ISIS-WG' Subject: RE: Doubt reg system type usage in Integ. ISIS > Hi > > The Integ,ISIS MIB draft has specified three values for > system type( L1(1) or L2(2) or L1AndL2 (3) ) in the system table > But the Hello PDU transmission is based on whether system Type is > L1 (1) ,or > L2 (3) and manualCircL2Only( TRUE/FALSE) > > Here, if the system type is L1AndL2 ( 3 ) then no Hello be sent. > > The system type object in the MIB shall be defined to take > only two values, L1 (1) or L2 (2). No L1AndL2 ( 3 ). > > I hope the MIB Draft is still Valid.. > > How can we handle this anomaly? > > SELVA Selva - As you know, L2 in line 7 above means L1AndL2. The current MIB work reflects many changes that have been deployed since the original version of 10589 was written. This is one place where existing practice and the document conflict. When implementing a system, you may decide if you wish to implement the a system that supports system type of L2 only. If not, you need not vary your implementation of the Hello Transmission. If you would like to support L2 only systemType, you will need to change the algorithm in the Hello PDU transmission in the obvious fashion. - jeff parker ------ =_NextPart_000_01BFA0D1.34EFC100 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhIPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYALAMAAAIAAAARAAAAAwAAMAMAAAAL AA8OAQAAAAIB/w8BAAAAPQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAABAEplZmYgUGFya2VyAFNN VFAAanBhcmtlckBuZXhhYml0LmNvbQAAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAFAAA AGpwYXJrZXJAbmV4YWJpdC5jb20AAwAVDAEAAAADAP4PBgAAAB4AATABAAAADgAAACdKZWZmIFBh cmtlcicAAAACAQswAQAAABkAAABTTVRQOkpQQVJLRVJATkVYQUJJVC5DT00AAAAAAwAAOQAAAAAL AEA6AAAAAAMAcToAAAAAHgD2XwEAAAAMAAAASmVmZiBQYXJrZXIAAgH3XwEAAAA9AAAAAAAAAIEr H6S+oxAZnW4A3QEPVAIAAAEASmVmZiBQYXJrZXIAU01UUABqcGFya2VyQG5leGFiaXQuY29tAAAA AAMA/V8BAAAAAwD/XwAAAAACAfYPAQAAAAQAAAAAAAADEAAAAAMAADAEAAAACwAPDgAAAAACAf8P AQAAAG4AAAAAAAAAtTvCwCx3EBqhvAgAKypWwhUAAAAT3mZrXmHTEahYACA1H5KgZIgAAAAAAACB Kx+kvqMQGZ1uAN0BD1QCAAAAAElTSVMtV0cAU01UUABpc2lzLXdnQGV4dGVybmFsLmp1bmlwZXIu bmV0AAAAHgACMAEAAAAFAAAAU01UUAAAAAAeAAMwAQAAAB0AAABpc2lzLXdnQGV4dGVybmFsLmp1 bmlwZXIubmV0AAAAAAMAFQwCAAAAAwD+DwYAAAAeAAEwAQAAAAoAAAAnSVNJUy1XRycAAAACAQsw AQAAACIAAABTTVRQOklTSVMtV0dARVhURVJOQUwuSlVOSVBFUi5ORVQAAAADAAA5AAAAAAsAQDoB AAAAHgD2XwEAAAAIAAAASVNJUy1XRwACAfdfAQAAACwAAAC/AAAAtTvCwCx3EBqhvAgAKypWwhUA AAAT3mZrXmHTEahYACA1H5KgZIgAAAMA/V8BAAAAAwD/XwAAAAACAfYPAQAAAAQAAAAAAAAE2Z0B BIABAC8AAABSRTogRG91YnQgcmVnIHN5c3RlbSB0eXBlIHVzYWdlIGluIEludGVnLiBJU0lTAL0P AQWAAwAOAAAA0AcEAAcAFAAmAA4ABQAvAQEggAMADgAAANAHBAAHABQACQAbAAUAHwEBCYABACEA AABGMEYzNEE5RDdDMENENDExQTg1ODAwMjAzNTFGOTJBMAALBwEDkAYAOAkAACIAAAALAAIAAQAA AAsAIwAAAAAAAwAmAAAAAAALACkAAAAAAAMALgAAAAAAAwA2AAAAAABAADkAYKTTGKOgvwEeAHAA AQAAAC8AAABSRTogRG91YnQgcmVnIHN5c3RlbSB0eXBlIHVzYWdlIGluIEludGVnLiBJU0lTAAAC AXEAAQAAABYAAAABv6CjGKqdSvP0DHwR1KhYACA1H5KgAAAeAB4MAQAAAAUAAABTTVRQAAAAAB4A HwwBAAAAHQAAAHNlbHZhcmFqckBmdXR1cmUuZnV0c29mdC5jb20AAAAAAwAGEFIcAf0DAAcQRQUA AB4ACBABAAAAZQAAAEhJSkVGRixUSEFOS1VUSEVSU0lTT05FTUlTVEFLRUlOTVlMQVNUTUFJTFRI RUxJTkVOVU1CRVI3U0hPVUxESEFWRUJFRU4iTDIoMilBTkRNQU5VQUxDSVJDTDJPTkxZKFRSVUUA AAAAAgEJEAEAAACqBQAApgUAADUJAABMWkZ1gZfW2gMACgByY3BnMTI1djIA9AH3IAKkA+MCAGOC aArAc2V0MCAHE4cCgwBQD7ZwcnEyELZmfQqACMggOwlvDjA1swKACoF1YwBQCwNjAEFFC2BuDhAw MzMLpiDQSGkgSgERLAqiCoSFCoBUEEBuayBVF6wXBJAEIAQAIAIgZSBtOwQAAZBrGkALgBpQeSCP C2AagBpQC3BsLiAZkc4gGzALgBpAbnUG0ASQJCA3HCBzaAhgbGT6IBBAdhpAHMAJ8ArjCoAWIhXB EKBMEjAoMikuIABwHYADgXUHQENpBHJjHwBPbmx5KAEb4FJVRS9GQUwYU0UpHqAXs0knbVMdIAWw cnkb0mEFQHeNIrJJHDEasXRvIAWgbm4dwBsgBAAsHSAQgHSRC4BnIDMjonN5GoAiZSIQdHlwGkBv Yr5qBZAFQBrhJWYBoGwaQPUD8GwDIGMbUBpAEgAmIJsnYCIQZAhxJOFIZSeweSPAdHIAcRphAJAC IC6xF6pPSyAkcABweR1A5wfgI0AA0GNlBTEIcB0g+HVnZweQJMACICOgIrL7LUAawW0LUCWgCfAB kCzz+x01BYFpAQAaEB3ABcAtktUHQGcFsGktQG0qSzE/4gohUExWQTGfCpAV0ucXtwswHEAzNgFA HsEKoA8DYCWQJmARRDE2IC31NsJPBRBnC4AHQAXQB5D8c2EswDbDF6Y11DWhCxPBNdZpLTE0NAFA HEA4MTgwAUAM0DpjYiBqRgNhOgyDYhCgF1IgDlAKwBqwBcBbU01UWFA6agqxPQFAGjB4ywGgMIAu BaBtXRelO5CfBmACMDv3O7AvYGF5JHDmQRIAAxEwNyRwAdA68Ekc8DozEjBQTT7nVCZvO/cQcGx2 CsBhag0+AGsboRtQaC5mdXp0CHBlRHIiMAGAPpI7ECAnSVNF0C1XRxonPuh1JjM791JFOvQgRAhg YgVACXAk8CVq9nU30hrSSQIwSJAb0EXS3zhvOXo1JAu2F7M+FxFNZjdNZhvyShMsRdIF0ElC3yig KZABgB2RBCBzJfAvUO86MAmALTEJ0SBDkApBBCAfAhAK1E2iJWkgsEwxKD4xH1AFsR8AHzJUMjFB +x+AHwIzH1AfUBrhLZImyh1NZkJEkC2DKSRQRFX7KXsZ4mIn8R2ALREi8BCA+xmhJVZUJeIZ8U1m U9AfIP1UASwFsFunVVQffyCOTg7/KSAJcCRwBpBV+1s1VPclAf9dkC2RA6AcgCPAKSQcwCSB/wIw KkVObCVvJnMtkk/yHTD/B0ADIGRRAQEcUVFRKWEaou9NZgIgIJAjoHcjwFHUJHDvXCVUMx8iG9BO I8Bii2TP7yNAHUAl8Wd2RFBDGfEs4a0nsVYHQC9gLm0/SCuh7yfgWhEaQBhxZCdhLUAZ8fcAcANx IJA/ZN4yvwZgQ4FfNrAXpQGRELAEIHkIYCD6a2PAd2rxEjAa4RxDHQD3AaAvoRpQZQYiVPUb0B41 +3YJG/JjCHAJcAIwT+NqYPs88EhxZidgJmAEIAOBGyD/EDEWMAeRLUMdohekHfMBANkLUG95UUEA kG4sEC2DXzBhN0QvsVkjRTAgFlA17Dg5IuBQoXcwcWZAKjD/eZYYYBnxGfULUX9xWjEJcP4gPjAa cSTSEgAA0CTAf3HzXbItkmRvewAuIhekI+HvfDAN4D6AHCBXY3It1yTS/3XQZhQkcHbiAMAbIC81 YSH3F6R24gPxaCOiLdcv5GYH8yKyLJBwcAkRULFmIxek3yXUPLAfAWoCeYFJPLBjwP50iRQaMFFB j9FRwSJgdtLfBcAt3BekgPFXyFQpmo+D/4qzHVMjZo01F6SPBWYFWyL/iRQnk5BjI7J9Ay/sF6RV 1e9YD1kVVeQmIHYqEEmAUjDnREGUNBeqLSAmQDyhPbQLF6QSwQCgQAAAAwAQEAAAAAADABEQAAAA AB4AQhABAAAAPQAAADxCQUM5Q0NGMDRGRUVEMzExQkQxRDAwMDYyOTUwQUJCMTIxOEQwMEBiYW5k aXRvLm5leGFiaXQuY29tPgAAAAADAIAQ/////0AABzAgwBUTn6C/AUAACDAgwBUTn6C/AQsAAIAI IAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAA AAADAAWACCAGAAAAAADAAAAAAAAARgAAAABShQAA8xUAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAA AAGFAAAAAAAAHgAIgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAFAAAAOC4wNAAAAAALAAmA CCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMACoAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAA AAAAAwALgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAAyACCAGAAAAAADAAAAAAAAARgAA AAA2hQAAAQAAAAEAAAAAAAAAHgANgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAA AB4ADoAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAAeAD0AAQAAAAUAAABSRTog AAAAAAMADTT9NwAABHA= ------ =_NextPart_000_01BFA0D1.34EFC100-- From navaneethk@future.futsoft.com Thu, 20 Apr 2000 13:14:49 +0530 Date: Thu, 20 Apr 2000 13:14:49 +0530 From: Navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Clarification.. Hi.. In the case of processing of the LSPs in integrated ISIS , used for IP forwarding, How are the interface addresses (4 octet Values without mask) in the TLVs used in route tabel calculation. Can any of you help out on how these i/f addresses are used? Thanx Navaneeth. From prkumar@nortelnetworks.com Thu, 20 Apr 2000 09:08:03 -0400 Date: Thu, 20 Apr 2000 09:08:03 -0400 From: Prashant Kumar prkumar@nortelnetworks.com Subject: [Isis-wg] Clarification.. Hello Navaneeth, For route calculation IP Internal reachability, IP external reachability and IS reachability TLVs are used. Please refer the SPF calculation section(Dijkstra) C.1 in RFC1195. Hope this helps you. Regards, Prashant. Navaneeth K wrote: > > Hi.. > > In the case of processing of the LSPs in integrated ISIS , used for IP forwarding, > How are the interface addresses (4 octet Values without mask) in the TLVs used in route tabel calculation. > Can any of you help out on how these i/f addresses are used? > > Thanx > Navaneeth. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- Prashant Kumar Nortel Networks Telephone : 978-288-7947(o) Billerica, MA 01821 ESN : 288-7947 From navaneethk@future.futsoft.com Thu, 20 Apr 2000 20:56:46 +0530 Date: Thu, 20 Apr 2000 20:56:46 +0530 From: Navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Clarification on ISIS SPF algorithm Hi, This doubt is regarding the SPF algorithm mentioned in RFC 1195 The section 8 under STEP 0: Says: " Now add systems to which the local router does not have adjacencies, but which are mentioned in neighbouring pseudonode LSPs.The adjacency for such systems is set to that of the Designated router" What does it exactly mean? When is possible that a router does not have adjacency to a system mentioned in a neighbour's pseudonode LSP? Please clarify. Thanx and regards Navaneeth. From henk@Procket.com Thu, 20 Apr 2000 10:21:25 -0700 (PDT) Date: Thu, 20 Apr 2000 10:21:25 -0700 (PDT) From: Henk Smit henk@Procket.com Subject: [Isis-wg] Clarification.. > In the case of processing of the LSPs in integrated ISIS , used for > IP forwarding, How are the interface addresses (4 octet Values > without mask) in the TLVs used in route tabel calculation. Can any > of you help out on how these i/f addresses are used? They are not used for calculating the topology. The interface IP addresses are only used to determine the IP address of the first next-hop on the path to each destination. When you build a routing table, most implementations have entries there that look like: destination IP prefix, mask, outgoing interface, next-hop IP address For p2p interfaces you don't really need the next-hop IP address, the interface should be enough info. But for LANs it is much more convenient (though in theory the MAC address of the next-hop should be enough). Hope this helps, Henk. From henk@Procket.com Thu, 20 Apr 2000 10:24:50 -0700 (PDT) Date: Thu, 20 Apr 2000 10:24:50 -0700 (PDT) From: Henk Smit henk@Procket.com Subject: [Isis-wg] Clarification on ISIS SPF algorithm Under buggy conditions on a LAN. Should never happen though. Another example might be when you configure your routers to model a Frame-relay, ATM or X25 cloud as a LAN. On those NBMA WAN technologies it is more likely that when some links fail, the resulting topology might be a partial mesh. Note that even if you do the trick that you quote, routing is still broken. IMHO on NBMA networks you need to configure all VCs as p2p links. Hope this helps, Henk. > Hi, > > This doubt is regarding the SPF algorithm mentioned in RFC 1195 > > The section 8 under STEP 0: > > Says: > > " Now add systems to which the local router does not have adjacencies, but > which are mentioned in neighbouring pseudonode LSPs.The adjacency for such > systems is set to that of the Designated router" > > What does it exactly mean? When is possible that a router does not have > adjacency to a system mentioned in a neighbour's pseudonode LSP? > > Please clarify. > > Thanx and regards > Navaneeth. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From henk@Procket.com Thu, 20 Apr 2000 10:37:50 -0700 (PDT) Date: Thu, 20 Apr 2000 10:37:50 -0700 (PDT) From: Henk Smit henk@Procket.com Subject: [Isis-wg] Clarification.. > Thanks for the reponse. > I still have one doubt.. Can we use these addresses advetised in LSP TLV's > for next hop addresses.Since these addresses have no specific mapping to > the IP reachability information. > Please correct me if I'm wrong. Ai, sorry, I was to quick in my reply. The IP interface address TLV (TLV #132) I was talking about are the IP interface address TLVs used in *hellos*. Not in LSPs. In LSPs there is the same TLV (TLV #132). But those have no practical use. And you are not supposed to use them in your routing calculations. The easiest thing is to just ignore them during your SPF computation. Sorry about the confusion, Henk. > Thanx > Navaneeth > > -----Original Message----- > From: Henk Smit [SMTP:henk@procket.com] > Sent: Thursday, April 20, 2000 10:51 PM > To: navaneethk@kailash.future.futsoft.com > Cc: 'isis-wg@external.juniper.net' > Subject: Re: [Isis-wg] Clarification.. > > > > In the case of processing of the LSPs in integrated ISIS , used for > > IP forwarding, How are the interface addresses (4 octet Values > > without mask) in the TLVs used in route tabel calculation. Can any > > of you help out on how these i/f addresses are used? > > They are not used for calculating the topology. > The interface IP addresses are only used to determine the IP address > of the first next-hop on the path to each destination. When you > build a routing table, most implementations have entries there that > look like: > destination IP prefix, mask, outgoing interface, next-hop IP address > > For p2p interfaces you don't really need the next-hop IP address, the > interface should be enough info. But for LANs it is much more convenient > (though in theory the MAC address of the next-hop should be enough). > > Hope this helps, > > Henk. > From navaneethk@future.futsoft.com Fri, 21 Apr 2000 14:50:53 +0530 Date: Fri, 21 Apr 2000 14:50:53 +0530 From: Navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Clarification on ISIS SPF algorithm Hi Henk, Thanks for your reply. I just want to confirm this. LAN nbrs will be loaded to TENT from Adjacency table as well as from the pseudonode LSP. In the second loading, since the Nbr is already present it wont be loaded (normal LAN scenario) Eventhough this is done as a pre-caution, it is unnecessary operation most of the time. Thanks Navaneeth Under buggy conditions on a LAN. Should never happen though. Another example might be when you configure your routers to model a Frame-relay, ATM or X25 cloud as a LAN. On those NBMA WAN technologies it is more likely that when some links fail, the resulting topology might be a partial mesh. Note that even if you do the trick that you quote, routing is still broken. IMHO on NBMA networks you need to configure all VCs as p2p links. Hope this helps, Henk. > Hi, > > This doubt is regarding the SPF algorithm mentioned in RFC 1195 > > The section 8 under STEP 0: > > Says: > > " Now add systems to which the local router does not have adjacencies, but > which are mentioned in neighbouring pseudonode LSPs.The adjacency for such > systems is set to that of the Designated router" > > What does it exactly mean? When is possible that a router does not have > adjacency to a system mentioned in a neighbour's pseudonode LSP? > > Please clarify. > > Thanx and regards > Navaneeth. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From henk@Procket.com Fri, 21 Apr 2000 10:45:32 -0700 (PDT) Date: Fri, 21 Apr 2000 10:45:32 -0700 (PDT) From: Henk Smit henk@Procket.com Subject: [Isis-wg] Clarification on ISIS SPF algorithm That is an implementation decision. The one implementation I am familiar with only looks at the content of the LSPs during SPF, and tries to find the relevant adjacencies in the adjacency database later. Henk. > I just want to confirm this. > LAN nbrs will be loaded to TENT from Adjacency table as well > as from the pseudonode LSP. In the second loading, since the Nbr is > already present it wont be loaded (normal LAN scenario) > Eventhough this is done as a pre-caution, it is unnecessary > operation most of the time. > > Thanks > Navaneeth From mshand@cisco.com Tue, 25 Apr 2000 08:18:32 +0100 Date: Tue, 25 Apr 2000 08:18:32 +0100 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Clarification on ISIS SPF algorithm At 10:24 20/04/2000 -0700, Henk Smit wrote: > Under buggy conditions on a LAN. Should never happen though. Strictly its not just buggy conditions, but it can happen for some period of time when a new router comes up etc. It might well acquire the adjacency to the DR and hence discover that certain other nodes are reachable via its pseudonode, before it has acquired the adjacencies to the nodes themselves. All this is doing is saying that if the pseudonode claims reachability, but you don't have an adjacency(yet), then you can always get packets to the node in question by forwarding them to the DR (since that MUST have an adjacency to the node, otherwise it wouldn't appear in its pseudonode LSP. This was more of an issue with OSI, where the endsystem adjacencies could take a few minutes to be acquired in some cases (typically you run with quite long ESH timers to keep the traffic down from potentially thousands of Endsystems, and the soliciting mechanisms don't work for all implementations.) So, bottom line is that it doesn't happen very often, and even if it does it doesn't happen for very long, but it does avoid the problem of not having an adjacency, and gets things working a little bit quicker. Mike From emmanuel.dauvergne@rd.francetelecom.fr Wed, 26 Apr 2000 08:54:55 +0200 Date: Wed, 26 Apr 2000 08:54:55 +0200 From: DAUVERGNE Emmanuel FTRD/DAC/ISS emmanuel.dauvergne@rd.francetelecom.fr Subject: [Isis-wg] ID status ? Hi, Just a refresh regarding 2 IDs : Is the ISIS WG still concerned with OMP works? (The last ID I read was draft-ietf-isis-omp-01, and it disapeared from the IETF server) Is there any update of draft-ietf-isis-traffic-01.txt? Did this work moved to the TEWG? Regardless of subTLV specifications, what is the status of the "wider metric" concept which was introduced in that ID? Thanks Manu (by the way, I sent this email last week, but I guess it got lost because my address changed. I fixed it, but sorry if you received it twice) From henk@procket.com Wed, 26 Apr 2000 09:51:47 +0200 (CEST) Date: Wed, 26 Apr 2000 09:51:47 +0200 (CEST) From: Henk Smit henk@procket.com Subject: [Isis-wg] ID status ? > Just a refresh regarding 2 IDs : > > Is there any update of draft-ietf-isis-traffic-01.txt? Did this work moved > to the TEWG? I am one of the two authors. There have been no significant changes to the document, so basically we could just re-submit the draft with little work. But because I changed jobs I have little time to work on the draft. > Regardless of subTLV specifications, what is the status of the "wider > metric" concept which was introduced in that ID? What do you mean by "status of the wider metric concept" ? draft-ietf-isis-traffic-01.txt gives you new TLVs to advertise links and IP prefixes, and those new TLVs have more bits for metrics. I know of at least two inter-operable implementations that are use in ISP backbones today. Hope this helps, Henk. From emmanuel.dauvergne@rd.francetelecom.fr Wed, 26 Apr 2000 12:05:06 +0200 Date: Wed, 26 Apr 2000 12:05:06 +0200 From: DAUVERGNE Emmanuel FTRD/DAC/ISS emmanuel.dauvergne@rd.francetelecom.fr Subject: [Isis-wg] ID status ? Thanks for your replies. My comments below... -----Message d'origine----- De: Henk Smit [mailto:henk@procket.com] Date: mercredi 26 avril 2000 09:52 À: emmanuel.dauvergne@rd.francetelecom.fr Cc: isis-wg@external.juniper.net Objet: Re: [Isis-wg] ID status ? > Just a refresh regarding 2 IDs : > > Is there any update of draft-ietf-isis-traffic-01.txt? Did this work moved > to the TEWG? I am one of the two authors. There have been no significant changes to the document, so basically we could just re-submit the draft with little work. But because I changed jobs I have little time to work on the draft. I'm not trying to urge you, it was just a question ;-) > Regardless of subTLV specifications, what is the status of the "wider > metric" concept which was introduced in that ID? What do you mean by "status of the wider metric concept" ? My question was not clear, sorry for that, let me detail (and correct me if I'm wrong)... Actually, I was first concerned with the up/down bit encoding : - in draft-ietf-domain-wide-02, it is suggested to encode it in the classical TLVs (128 and 130) on the high-order bit reserved of the default metric. (And the 4-byte metrics field remain a structured field). rather than, - in draft-ietf-isis-traffic-01, it is suggested to encode it in the extended TLVs, where it is encoded in the control information field. (And the 4-byte metric is a flat field) I was confused about this difference : why not using the same high-order bit in the 4-byte metric? (which would leave 31-bit for the metric value) I was also confused about the extended IS reachibility TLV which default-metric is "only" 3-byte long (and not 4-byte long). Thanks for your time Manu draft-ietf-isis-traffic-01.txt gives you new TLVs to advertise links and IP prefixes, and those new TLVs have more bits for metrics. I know of at least two inter-operable implementations that are use in ISP backbones today. Hope this helps, Henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From henk@procket.com Wed, 26 Apr 2000 13:24:00 +0200 (CEST) Date: Wed, 26 Apr 2000 13:24:00 +0200 (CEST) From: Henk Smit henk@procket.com Subject: [Isis-wg] ID status ? > Actually, I was first concerned with the up/down bit encoding : - in > draft-ietf-domain-wide-02, it is suggested to encode it in the > classical TLVs (128 and 130) on the high-order bit reserved of the > default metric. (And the 4-byte metrics field remain a structured > field). The reason for this is that some customers wanted to have L2->L1 route-leaking in the older TLVs, and preferably in a way where you only need to upgrade the L1L2 routers. With this hack of using the reserved bit in existing TLVs 128 and 130, older implementations will just ignore the up/down bit. > rather than, - in draft-ietf-isis-traffic-01, it is suggested to > encode it in the extended TLVs, where it is encoded in the control > information field. (And the 4-byte metric is a flat field) This is a cleaner way. The up/down bit has nothing to do with the metrics. So why make it part of it. We have two unused bits in the prefix-lenght field, so we could save a byte for each IP prefix by using one of these two unused bits as the up/down bit. For the other bit we found another use: indicator whether there are sub-TLVs present. > I was confused about this difference : why not using the same > high-order bit in the 4-byte metric? (which would leave 31-bit for > the metric value) Because metric and up/down bit have nothing to do with each other. And why make the metric wider, and then start nibbling bits off of it again. Yes, we could have done it that way, but we didn't. Also note that draft-ietf-isis-traffic-01.txt is older than draft-ietf-domain-wide-02.txt. And draft-ietf-isis-traffic-01.txt is in use in the Internet today, while I don't know of any ISPs (or enterprise networks) that use draft-ietf-domain-wide-02.txt today. > I was also confused about the extended IS reachibility TLV which > default-metric is "only" 3-byte long (and not 4-byte long). That was my idea. One of the problems with the TLVs in 10589 and rfc1195 is that the metrics between areas (or rather between L1 and L2) are not very useful. Link metrics are 1-63, which creates some limitations for people designing networks. But the overall result is a little less bad, as the path inside an area or inside the L2 backbone can be up to 1023. However, if your L1 path has a cost over 63, that cost can not be advertised, it has to be rounded down to 63. The problem is the fact that the added cost of the links can be way bigger than what you can advertise in a TLV 128 or 130. We wanted to prevent that from happening. So the link cost can be 2^24 at most, while the advertised total path cost can be 2^32. That way you can have 256 links with the worst cost in your network, and still maintain the path cost when advertising between L1 and L2. And the risk of overflowing a ulong of 4 bytes in your implementation is reduced as well. Hope this helps, henk. > Thanks for your time > Manu > > > > draft-ietf-isis-traffic-01.txt gives you new TLVs to advertise links > and IP prefixes, and those new TLVs have more bits for metrics. I know > of at least two inter-operable implementations that are use in ISP > backbones today. > > Hope this helps, > > Henk. > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From emmanuel.dauvergne@rd.francetelecom.fr Wed, 26 Apr 2000 18:51:44 +0200 Date: Wed, 26 Apr 2000 18:51:44 +0200 From: DAUVERGNE Emmanuel FTRD/DAC/ISS emmanuel.dauvergne@rd.francetelecom.fr Subject: [Isis-wg] ID status ? Ok, thanks a lot for this explanation. Fine for me! Manu -----Message d'origine----- De: Henk Smit [mailto:henk@procket.com] Date: mercredi 26 avril 2000 13:24 À: emmanuel.dauvergne@rd.francetelecom.fr Cc: isis-wg@external.juniper.net Objet: Re: [Isis-wg] ID status ? > Actually, I was first concerned with the up/down bit encoding : - in > draft-ietf-domain-wide-02, it is suggested to encode it in the > classical TLVs (128 and 130) on the high-order bit reserved of the > default metric. (And the 4-byte metrics field remain a structured > field). The reason for this is that some customers wanted to have L2->L1 route-leaking in the older TLVs, and preferably in a way where you only need to upgrade the L1L2 routers. With this hack of using the reserved bit in existing TLVs 128 and 130, older implementations will just ignore the up/down bit. > rather than, - in draft-ietf-isis-traffic-01, it is suggested to > encode it in the extended TLVs, where it is encoded in the control > information field. (And the 4-byte metric is a flat field) This is a cleaner way. The up/down bit has nothing to do with the metrics. So why make it part of it. We have two unused bits in the prefix-lenght field, so we could save a byte for each IP prefix by using one of these two unused bits as the up/down bit. For the other bit we found another use: indicator whether there are sub-TLVs present. > I was confused about this difference : why not using the same > high-order bit in the 4-byte metric? (which would leave 31-bit for > the metric value) Because metric and up/down bit have nothing to do with each other. And why make the metric wider, and then start nibbling bits off of it again. Yes, we could have done it that way, but we didn't. Also note that draft-ietf-isis-traffic-01.txt is older than draft-ietf-domain-wide-02.txt. And draft-ietf-isis-traffic-01.txt is in use in the Internet today, while I don't know of any ISPs (or enterprise networks) that use draft-ietf-domain-wide-02.txt today. > I was also confused about the extended IS reachibility TLV which > default-metric is "only" 3-byte long (and not 4-byte long). That was my idea. One of the problems with the TLVs in 10589 and rfc1195 is that the metrics between areas (or rather between L1 and L2) are not very useful. Link metrics are 1-63, which creates some limitations for people designing networks. But the overall result is a little less bad, as the path inside an area or inside the L2 backbone can be up to 1023. However, if your L1 path has a cost over 63, that cost can not be advertised, it has to be rounded down to 63. The problem is the fact that the added cost of the links can be way bigger than what you can advertise in a TLV 128 or 130. We wanted to prevent that from happening. So the link cost can be 2^24 at most, while the advertised total path cost can be 2^32. That way you can have 256 links with the worst cost in your network, and still maintain the path cost when advertising between L1 and L2. And the risk of overflowing a ulong of 4 bytes in your implementation is reduced as well. Hope this helps, henk. > Thanks for your time > Manu > > > > draft-ietf-isis-traffic-01.txt gives you new TLVs to advertise links > and IP prefixes, and those new TLVs have more bits for metrics. I know > of at least two inter-operable implementations that are use in ISP > backbones today. > > Hope this helps, > > Henk. > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From vanik@future.futsoft.com Wed, 3 May 2000 10:53:51 +0530 Date: Wed, 3 May 2000 10:53:51 +0530 From: Vani Sree K vanik@future.futsoft.com Subject: [Isis-wg] Incremental SPF Hi, Is there any document or guide that explains about incremental SPF. Can anyone provide the pointer to it, if any. Thanks Regards -vani From shenjun@ns.chinanet.cn.net Tue, 9 May 2000 10:12:17 +0800 Date: Tue, 9 May 2000 10:12:17 +0800 From: shenjun shenjun@ns.chinanet.cn.net Subject: [Isis-wg] undescribe undescribe From shenjun@ns.chinanet.cn.net Tue, 9 May 2000 10:23:06 +0800 Date: Tue, 9 May 2000 10:23:06 +0800 From: shenjun shenjun@ns.chinanet.cn.net Subject: [Isis-wg] (no subject) undescribe From shenjun@ns.chinanet.cn.net Tue, 9 May 2000 10:29:38 +0800 Date: Tue, 9 May 2000 10:29:38 +0800 From: shenjun shenjun@ns.chinanet.cn.net Subject: [Isis-wg] (no subject) unsubscribe> From dwm@caida.org Sun, 14 May 2000 04:06:39 -0400 Date: Sun, 14 May 2000 04:06:39 -0400 From: Daniel McRobb dwm@caida.org Subject: [Isis-wg] draft-ietf-isis-wg-mib-02 I'm new to the list, so please forgive me if this issue has come up before (I dind't find it in a cursory search of the archives)... Is there any interest in making isisISAdjUpTime semantics similar to bgpPeerFsmEstablishedTime from BGP4-MIB, making it the number of seconds the adjacency has been 'up' if the current state is 'up', and seconds passed since the adjacency was last 'up' if the current state is not 'up'? I personally prefer these semantics (even if we define notifications for adjacency changes). Daniel ~~~~~~ From navaneethk@future.futsoft.com Thu, 18 May 2000 17:12:18 +0530 Date: Thu, 18 May 2000 17:12:18 +0530 From: Navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Clarification on Dual ISIS Hi, The doubt is regarding a Dual environment where integrated ISIS is deployed. In this scenario, i. Is it possible for a system reachable through a circuit to have both IP and OSI addresses simultaneously? ii. In Dual routers, normally are both the IP and OSI addresses valid at the same time? According to RFC 1195, A dual router must be capable of routing both IP and OSI packets. Are there Any address considerations in this regard? Thanx Navaneeth. From henk@Procket.com Thu, 18 May 2000 14:14:41 +0200 (MEST) Date: Thu, 18 May 2000 14:14:41 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] Clarification on Dual ISIS > Hi, > The doubt is regarding a Dual environment where integrated ISIS is > deployed. > In this scenario, > i. Is it possible for a system reachable through a circuit to have both > IP and OSI addresses simultaneously? Yes. Note, IP addresses are interface specific. E.g. each interface typically has one IP address. OSI addresses (NSAPs) are box specific. E.g. typically each router or each hosts has a single OSI address. > ii. In Dual routers, normally are both the IP and OSI addresses valid at > the same time? That is the definition of a Dual router. An ISIS-CLNS router has and OSI address (an NSAP), forwards CLNS packets, and does not forward IP packets. An ISIS-IP router has an IP addresses, forwards IP packets, and does not forward CLNS packets. Typically an ISIS-IP router still has an NSAP configured, because it needs a systemID and an area-address. A Dual router has all of that combined. IP addresses, an NSAP, and it does forward IP and CLNS packets. > According to RFC 1195, A dual router must be capable of routing both IP > and OSI packets. Are there Any address considerations in this regard? Not that I can think of. IP and OSI address space are independant. But don't forget that typically the NSAP is used to derive the systemID and the area-address. Hope this helps, Henk. From jparker@nexabit.com Thu, 18 May 2000 09:49:14 -0400 Date: Thu, 18 May 2000 09:49:14 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Clarification on Dual ISIS > Note, IP addresses are interface specific. E.g. each > interface typically has one IP address. OSI addresses and the new TLV for Router ID that provides a unique IP address for a box. - jeff parker - Nexabit From ben.abarbanel@ipoptical.com Thu, 18 May 2000 09:35:50 -0700 Date: Thu, 18 May 2000 09:35:50 -0700 From: ben abarbanel ben.abarbanel@ipoptical.com Subject: [Isis-wg] Clarification on Dual ISIS Does anybody know where I can purchase a reliable implementation of ISIS with dual mode. Thanks, Ben ----- Original Message ----- From: Henk Smit To: Cc: Sent: Thursday, May 18, 2000 5:14 AM Subject: Re: [Isis-wg] Clarification on Dual ISIS > > > Hi, > > The doubt is regarding a Dual environment where integrated ISIS is > > deployed. > > In this scenario, > > i. Is it possible for a system reachable through a circuit to have both > > IP and OSI addresses simultaneously? > > Yes. > Note, IP addresses are interface specific. E.g. each interface typically > has one IP address. OSI addresses (NSAPs) are box specific. E.g. typically > each router or each hosts has a single OSI address. > > > ii. In Dual routers, normally are both the IP and OSI addresses valid at > > the same time? > > That is the definition of a Dual router. > An ISIS-CLNS router has and OSI address (an NSAP), forwards CLNS packets, > and does not forward IP packets. > An ISIS-IP router has an IP addresses, forwards IP packets, and does not > forward CLNS packets. Typically an ISIS-IP router still has an NSAP > configured, because it needs a systemID and an area-address. > > A Dual router has all of that combined. IP addresses, an NSAP, and it > does forward IP and CLNS packets. > > > According to RFC 1195, A dual router must be capable of routing both IP > > and OSI packets. Are there Any address considerations in this regard? > > Not that I can think of. IP and OSI address space are independant. > But don't forget that typically the NSAP is used to derive the systemID > and the area-address. > > Hope this helps, > > Henk. > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From jparker@nexabit.com Thu, 18 May 2000 11:56:53 -0400 Date: Thu, 18 May 2000 11:56:53 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Clarification on Dual ISIS > -----Original Message----- > From: ben abarbanel [mailto:ben.abarbanel@ipoptical.com] > Sent: Thursday, May 18, 2000 12:36 PM > To: Henk Smit; navaneethk@future.futsoft.com > Cc: isis-wg@juniper.net > Subject: Re: [Isis-wg] Clarification on Dual ISIS > > > Does anybody know where I can purchase a reliable > implementation of ISIS > with dual mode. > > Thanks, > Ben Ben - Are you looking to route both OSI and IP, or are you asking for dual mode because you want to route IP? - jeff parker - Nexabit Networks - Lucent Technologies From emmanuel.dauvergne@rd.francetelecom.fr Thu, 18 May 2000 19:09:02 +0200 Date: Thu, 18 May 2000 19:09:02 +0200 From: DAUVERGNE Emmanuel FTRD/DAC/ISS emmanuel.dauvergne@rd.francetelecom.fr Subject: [Isis-wg] Behavior upon new adjacency Hello, A few questions regarding the Update Process and the Decision Process upon new adjacency event. 1. Update Process : Upon an LSP generation (either a periodic regeneration or an event driven generation), ISO10589 indicates that the LSP(s) shall be sent on every circuit with an IS adjacency of the appropriate level, by setting the SRMFlag on each circuits. In the case of an new adjacency (event driven generation), is there any restriction regarding the circuit corresponding to this new adjacency which has triggered the generation of the LSP? According to the spec, the LSP shall be sent on that circuit as well, but is it recommended to wait for a certain time before sending routing information through that new adjacency? In that same case what chronological order should be respected between the sending of LSP and CSNP (p2p link)? 2. Decision Process : ISO10589 indicates that any topological change (notified by the update process) can trigger an SPF calculation. Is a new adjacency considered as a topological change? Shouldn't the local router wait for the LSP of the new adjacent router before triggering the SPF calculation? Thanks for your time Manu From prz@net4u.ch Thu, 18 May 2000 19:31:14 +0200 (MEST) Date: Thu, 18 May 2000 19:31:14 +0200 (MEST) From: Tony Przygienda prz@net4u.ch Subject: [Isis-wg] last calls ... After simmering for a while and enough experience following drafts are going last call: 1. draft-ietf-isis-wg-255adj-02.txt 2. draft-ietf-isis-domain-wide-02.txt 3. draft-ietf-isis-wg-mesh-group-00.txt 4. draft-kaplan-isis-ext-eth-01.txt Authors of 4. pls comment whether you want to pursuit informational, experimental or standards track. 1-3 are informational. Last call ends June 3rd thanks -- tony From ben.abarbanel@ipoptical.com Thu, 18 May 2000 13:15:55 -0700 Date: Thu, 18 May 2000 13:15:55 -0700 From: ben abarbanel ben.abarbanel@ipoptical.com Subject: [Isis-wg] Clarification on Dual ISIS Looking for dual mode to route IP. Regards, Ben ----- Original Message ----- From: Jeff Parker To: ben abarbanel Cc: Sent: Thursday, May 18, 2000 8:56 AM Subject: RE: [Isis-wg] Clarification on Dual ISIS > > -----Original Message----- > > From: ben abarbanel [mailto:ben.abarbanel@ipoptical.com] > > Sent: Thursday, May 18, 2000 12:36 PM > > To: Henk Smit; navaneethk@future.futsoft.com > > Cc: isis-wg@juniper.net > > Subject: Re: [Isis-wg] Clarification on Dual ISIS > > > > > > Does anybody know where I can purchase a reliable > > implementation of ISIS > > with dual mode. > > > > Thanks, > > Ben > > Ben - > Are you looking to route both OSI and IP, > or are you asking for dual mode because you > want to route IP? > > - jeff parker > - Nexabit Networks > - Lucent Technologies > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From jparker@nexabit.com Thu, 18 May 2000 14:24:10 -0400 Date: Thu, 18 May 2000 14:24:10 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Clarification on Dual ISIS > > > Does anybody know where I can purchase a reliable > > > implementation of ISIS > > > with dual mode. > > > > > > Thanks, > > > Ben Ben - If you intend to route IP, then the usual suspects (ourselves included) ship a version of ISIS. I'm not sure that this is the venue to discuss reliability of implementations rather than protocols. I'm not sure how much recent work there has been on routing both OSI and IP using IS-IS. - jeff parker - Nexabit Networks - Lucent Technologies From prz@siara.com Mon, 17 Jan 2000 16:14:54 -0500 Date: Mon, 17 Jan 2000 16:14:54 -0500 From: Tony Przygienda prz@siara.com Subject: [Isis-wg] Problem for Support Frame Relay . Alex Zinin wrote: > Monday, January 17, 2000, 7:43:07 PM, Tony Przygienda wrote: > > again, first a problem statement would be nice to make sure > > we're all tackling the same problem. > > Well, I think Jorge's initial messages are quite > clear on that---running IS-IS over NBMA media. > ...and whichever issues related :) again, it may be the partial mesh problem (the protocol needs to understand the topology correctly) or the "running over dial-up links" problem. > > 2nd, Alex, you're oversimpliofying here ;-) > > Tony, I'm not. I'm just correcting the statement > that on-demand VCs cannot be used with IS-IS. this part you don't, right. But after that you're saying it's easy and doesn't need anything, that's at least slightly oversimplifying. You can run it that way but you'll stop pretty soon after the montly bills come. If you don't beleive me, try an ISDN link with OSPF active ;-) > > Just "running" > > the protocol that way leads to extensive thrashing of up&downs > > of the circuit > > Quoting myself: > > "...provided that the idle timer doesn't close > the VC before the next Hello PDU is sent over it." then de-facto you _never_ close the circuit wyhen the protocol is running and if you're paying usage, that's expensive stuff, either charged per data unit or per time unit (2nd is worse normally). If that's the soluiton people are happy with (but weren't in OSPF) then de facto, no work needs tio be done in layer 3 and Alex's right. From tli@Procket.com Thu, 18 May 2000 11:25:20 -0700 Date: Thu, 18 May 2000 11:25:20 -0700 From: Tony Li tli@Procket.com Subject: [Isis-wg] Clarification on Dual ISIS | Looking for dual mode to route IP. There is at least one implementation in the world that routes IP but not CLNP. This can't strictly be called dual mode. Tony From Internet-Drafts@ietf.org Wed, 12 Apr 2000 07:11:20 -0400 Date: Wed, 12 Apr 2000 07:11:20 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-hmac-01.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Cryptographic Authentication Author(s) : T. Li, R. Atkinson Filename : draft-ietf-isis-hmac-01.txt Pages : 11 Date : 11-Apr-00 This document specifies an algorithm-independent cryptographic authentication mechanism for use with the IS-IS routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-hmac-01.txt 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-isis-hmac-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-ietf-isis-hmac-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. --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: <20000411095848.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-hmac-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-hmac-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000411095848.I-D@ietf.org> --OtherAccess-- --NextPart-- From prz@redback.com Wed, 17 May 2000 15:16:16 -0700 (PDT) Date: Wed, 17 May 2000 15:16:16 -0700 (PDT) From: prz@redback.com prz@redback.com Subject: [Isis-wg] (no subject) going last call for informational: 1. draft-ietf-isis-wg-255adj-02.txt 2. draft-ietf-isis-domain-wide-02.txt 3. draft-ietf-isis-wg-mesh-group-00.txt Last calls end June 2nd thanks -- tony From root@prz-laptop.redback.com Wed, 17 May 2000 16:12:48 -0700 (PDT) Date: Wed, 17 May 2000 16:12:48 -0700 (PDT) From: Charlie Root root@prz-laptop.redback.com Subject: [Isis-wg] Last call started for 3 drafts going last call for informational: 1. draft-ietf-isis-wg-255adj-02.txt 2. draft-ietf-isis-domain-wide-02.txt 3. draft-ietf-isis-wg-mesh-group-00.txt Last calls end June 2nd thanks -- tony From ethkkg@etxb.ericsson.se Thu, 18 May 2000 10:20:20 +0200 Date: Thu, 18 May 2000 10:20:20 +0200 From: Gabor Korossy (ETH) ethkkg@etxb.ericsson.se Subject: [Isis-wg] RE: MPLS and IS-IS Hi, if I may repeat, could anyone help me please, find the draft "IS-IS extensions for Traffic Engineering," draft-ietf-isis-traffic-01.txt If so many ISPs run IS-IS with MPLS TE extensions shouldn't it become an IETF standard? Maybe one of the MPLS, TE and IS-IS working groups doesn´t feel ashamed to adopt this child? regards - Gabor >> -----Original Message----- >> From: Chris.Flores@broadwing.com [mailto:Chris.Flores@broadwing.com] >> Sent: Wednesday, May 17, 2000 8:48 PM >> To: mpls@UU.NET >> Subject: FW: MPLS and IS-IS >> >> >> >> David - >> >> Most large ISPs in the US use ISIS: >> >> UUnet, C&W, Sprintlink, Qwest, Verio, Digex, Frontier, Broadwing. >> >> It also seems like more and more european ISPs are starting >> to use ISIS: >> EUnet, Ebone, Hermes, TeleDanMark, Renater (FT), Telia, Tele2, etc. >> >> Chris >> >> -----Original Message----- >> From: David Wang [mailto:david.wang@metro-optix.com] >> Sent: Wednesday, May 17, 2000 12:36 PM >> To: 'HANSEN CHAN'; mpls@UU.NET >> Subject: RE: MPLS and IS-IS >> >> >> Hi all, >> >> IS-IS is defined to work with CLNP not for IP originally. >> Until today a lot >> of SONET and telecommunication equipment vendors still use >> IS-IS to route >> CLNP packets through the SONET Data communication >> channel(DCC) to carry >> management information and there is a great pressure to >> change this to OSPF >> and IP. I also know that UUNET runs IS-IS on their network. >> I never heard >> any other networks run IS-IS. Seems I am wrong. My questions are. >> >> 1. You guys are talking about using IS-IS in a IP networks >> not in CLNP >> networks. The IS-IS has been modified according to RFC 1195 >> (Use of OSI >> IS-IS for Routing in TCP/IP and Dual Environments) or some >> other standard. >> Is this correct? >> >> 2. Besides UUNET, which ISPs run IS-IS protocol? Can you >> name a few? or >> what percentage of networks run IS-IS instead of OSPF? >> >> Thanks >> David >> >> >> -----Original Message----- >> From: HANSEN CHAN [mailto:hchan@newbridge.com] >> Sent: Tuesday, May 16, 2000 7:22 AM >> To: mpls@UU.NET >> Subject: MPLS and IS-IS >> >> >> Hi all, >> >> I have been hearing IS-IS is a better protocol to be used >> than OSPF in a >> MPLS >> network for TE application. Is that a fair statement? What >> are the technical >> reasons? >> >> Appreciate if someone can shed some light on this subject. >> >> Thanks, >> Hansen >> >> From emmanuel.dauvergne@rd.francetelecom.fr Fri, 21 Apr 2000 11:45:42 +0200 Date: Fri, 21 Apr 2000 11:45:42 +0200 From: DAUVERGNE Emmanuel FTRD/DAC/ISS emmanuel.dauvergne@rd.francetelecom.fr Subject: [Isis-wg] ID status ? Hi, Just a refresh regarding 2 IDs : Is the ISIS WG still concerned with OMP works? (The last ID I read was draft-ietf-isis-omp-01) Is there any update of draft-ietf-isis-traffic-01.txt? Did this work moved to the TEWG? Regardless of subTLV specifications, what is the status of the "wider metric" concept which was introduced in that ID? Thanks Manu From navaneethk@future.futsoft.com Wed, 3 May 2000 15:08:35 +0530 Date: Wed, 3 May 2000 15:08:35 +0530 From: Navaneeth K navaneethk@future.futsoft.com Subject: [Isis-wg] Clarification on ISIS MIB Hi... My doubt is with regard to the ISIS MIB.. In the IpRA table, There is a field for the IpRASNPA address.. This is mentioned as to be used as the NextHop for reaching the Reachable address.. But in case of IP , How can the NExtHop address be got.. Since the SNPA address is equivalent to the MAC address, what address can be considered as the nexthop address? Please Clarify. Thanx Navaneeth. From prz@siara.com Wed, 26 Apr 2000 01:22:10 -0700 Date: Wed, 26 Apr 2000 01:22:10 -0700 From: Tony Przygienda prz@siara.com Subject: [Isis-wg] ID status ? DAUVERGNE Emmanuel FTRD/DAC/ISS wrote: > Hi, > > Just a refresh regarding 2 IDs : > > Is the ISIS WG still concerned with OMP works? (The last ID I read was > draft-ietf-isis-omp-01, and it disapeared from the IETF server) expired a while ago. > Is there any update of draft-ietf-isis-traffic-01.txt? Did this work moved > to the TEWG? > Regardless of subTLV specifications, what is the status of the "wider > metric" concept which was introduced in that ID? Henk promised a new version in 2--3 weeks (and it was 2--3 weeks ago ;-) thanks -- tony > > > Thanks > Manu > From Internet-Drafts@ietf.org Thu, 11 May 2000 06:57:18 -0400 Date: Thu, 11 May 2000 06:57:18 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-kaplan-isis-ext-eth-01.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Extended Ethernet Frame Size Support Author(s) : M. O'Dell, J. Kaplan, J. Hayes, T. Schroeder, P. Singh, D. Morrell, J. Hsu Filename : draft-kaplan-isis-ext-eth-01.txt Pages : 4 Date : 10-May-00 This document presents an extension to current Ethernet Frame standards to support payloads greater than 1500 Bytes for Ethernet_II and 802.3 frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-isis-ext-eth-01.txt 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-kaplan-isis-ext-eth-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-kaplan-isis-ext-eth-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. --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: <20000510111709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kaplan-isis-ext-eth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-kaplan-isis-ext-eth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000510111709.I-D@ietf.org> --OtherAccess-- --NextPart-- From jkaplan@UU.NET Wed, 10 May 2000 09:13:35 -0400 (EDT) Date: Wed, 10 May 2000 09:13:35 -0400 (EDT) From: Jed Kaplan jkaplan@UU.NET Subject: [Isis-wg] Extended Ethernet Frame Size Support This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-684387517-957964415=:12311 Content-Type: TEXT/PLAIN; charset=US-ASCII A revised ISIS draft (draft-kaplan-isis-ext-eth-01.txt) by O'Dell, Kaplan, Hayes, Schroeder, Singh, and Hsu entitled: "Extended Ethernet Frame Size Support" has been submitted to the IETF. The is a resubmission of the draft, draft-kaplan-isis-ext-eth-00.txt, that expired in November, 1999. The sole change to the draft was an update of authorship. The draft abstract is: This document presents an extension to the current Ethernet Frame standards to support payloads greater than 1500 Bytes for Ethernet_II and 802.3 frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. Jed kaplan jkaplan@uu.net ---559023410-684387517-957964415=:12311 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="draft-kaplan-isis-ext-eth-01.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="draft-kaplan-isis-ext-eth-01.txt" TmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBNaWtlIE8nRGVsbA0KSW50ZXJuZXQgRHJhZnQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKZWQgS2FwbGFu DQpFeHBpcmF0aW9uIERhdGU6IE5vdmVtYmVyIDE5OTkJCQkJVVVORVQgVGVj aG5vbG9naWVzLCBJbmMuDQoNCgkJCQkJCQlKb2huIEhheWVzDQoJCQkJCQkJ VGVkIFNjaHJvZWRlcg0KCQkJCQkJCUFsdGVvbiBXZWJTeXN0ZW1zLCBJbmMu DQoJCQkJCQkJDQoJCQkJCQkJUC5KLiBTaW5naA0KCQkJCQkJCVBhY2tldCBF bmdpbmVzLCBJbmMuDQoNCgkJCQkJCQlEYWVtb24gTW9ycmVsbA0KCQkJCQkJ CUp1bmlwZXIgTmV0d29ya3MsIEluYy4NCg0KCQkJCQkJCUplbm5pZmVyIEhz dQ0KCQkJCQkJDQoNCg0KCSAgICAgICAgICBFeHRlbmRlZCBFdGhlcm5ldCBG cmFtZSBTaXplIFN1cHBvcnQgDQoNCgkJICAgIGRyYWZ0LWthcGxhbi1pc2lz LWV4dC1ldGgtMDAudHh0DQoNCg0KMS4gU3RhdHVzIG9mIHRoaXMgTWVtbw0K DQoJVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMg aW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIA0KCWFsbCBwcm92aXNpb25zIG9m IFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4NCg0KCUludGVybmV0LURyYWZ0cyBh cmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVy aW5nDQoJVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3 b3JraW5nIGdyb3Vwcy4gTm90ZSB0aGF0DQoJb3RoZXIgZ3JvdXBzIG1heSBh bHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQt DQoJRHJhZnRzLg0KDQoJSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1 bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzIA0KCWFu ZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBv dGhlciBkb2N1bWVudHMgYXQgYW55DQoJdGltZS4gSXQgaXMgaW5hcHByb3By aWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KCW1h dGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGlu IHByb2dyZXNzLiINCg0KCVRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQt RHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCglodHRwOi8vd3d3LmlldGYu b3JnL2lldGYvbGlkLWFic3RyYWN0cy50eHQNCg0KCVRoZSBsaXN0IG9mIElu dGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNz ZWQgYXQNCglodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQoNCg0K Mi4gQWJzdHJhY3QNCg0KCVRoaXMgZG9jdW1lbnQgcHJlc2VudHMgYW4gZXh0 ZW5zaW9uIHRvIGN1cnJlbnQgRXRoZXJuZXQgRnJhbWUgDQoJc3RhbmRhcmRz IHRvIHN1cHBvcnQgcGF5bG9hZHMgZ3JlYXRlciB0aGFuIDE1MDAgQnl0ZXMg Zm9yIEV0aGVybmV0X0lJDQoJYW5kIDgwMi4zIGZyYW1lcy4gVGhpcyBpcyB1 c2VmdWwgZm9yIEdpZ2FiaXQgRXRoZXJuZXQgdGVjaG5vbG9neSwgDQogICAg ICAgIHByb3ZpZGluZyBhIG1lYW5zIHRvIGNhcnJ5IGxhcmdlIE1UVSBwYWNr ZXRzIHdpdGhvdXQgZnJhZ21lbnRhdGlvbiANCiAgICAgICAgb3ZlciBhIGhp Z2gtc3BlZWQgYnJvYWRjYXN0IG5ldHdvcmsuDQoNCjMuIE92ZXJ2aWV3DQoN CglUaGVyZSBhcmUgdHdvIGZ1bmRhbWVudGFsIGZyYW1lIHR5cGVzIGRlZmlu ZWQgZm9yIEV0aGVybmV0Og0KCUV0aGVybmV0IElJIFtFVEhdIFtSRkM4OTRd IGFuZCA4MDIuMyBbSUVFRTgwMi4zXS4gODAyLjMgaGVhZGVycw0KCW1heSBi ZSBmb2xsb3dlZCBieSBhIExvZ2ljYWwgTGluayBDb250cm9sIGhlYWRlciwN Cgk4MDIuMiBbSUVFRTgwMi4yXS4gQm90aCB0eXBlcyBvZiBlbmNhcHN1bGF0 aW9ucyBjYW4gY28tZXhpc3Qgb24NCgl0aGUgc2FtZSBtZWRpYSBhdCB0aGUg c2FtZSB0aW1lLiBFbmNvZGluZ3MgZm9yIEV0aGVybmV0IElJIGFuZCA4MDIu Mw0KCWZyYW1lcyBldm9sdmVkIHN1Y2ggdGhhdCwgYXMgbG9uZyBhcyBwYXls b2FkcyB3ZXJlIGxlc3MgdGhhbiAxNTAwDQoJYnl0ZXMsIEV0aGVybmV0IElJ IGZyYW1lcyBjb3VsZCBhbHdheXMgYmUgZGlzdGluZ3Vpc2hlZCBmcm9tDQoJ SUVFRSA4MDIuMyBmcmFtZXMuDQoNCglIb3dldmVyLCB3aGVuIHRoZSBwYXls b2FkIGlzIGdyZWF0ZXIgdGhhbiAxNTAwIGJ5dGVzIGZyYW1lcyBtYXkgDQog ICAgICAgIG5vdCBiZSB1bmlxdWVseSBkaXN0aW5ndWlzaGFibGUgYXMgY29u Zm9ybWluZyB0byBFdGhlcm5ldCBJSSBvciANCiAgICAgICAgODAyLjMgZm9y bWF0cy4gVGhpcyBkb2N1bWVudCBleHRlbmRzIHRoZSBFdGhlcm5ldCBmcmFt ZSBmb3JtYXQgDQoJdG8gYWxsb3cgRXRoZXJuZXRfSUkgb3IgODAyLjMgZnJh bWUgcGF5bG9hZHMgbGFyZ2VyIHRoYW4gMTUwMCBieXRlcyANCiAgICAgICAg dG8gYmUgdW5pcXVlbHkgZGlzdGluZ3Vpc2hlZC4NCg0KNC4gRXRoZXJuZXQg RnJhbWUgRm9ybWF0cw0KDQoJQS4gRXRoZXJuZXQgSUkNCgkJDQoJCSstLS0t Ky0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLSsNCgkJfCBEQSB8IFNBIHwgVHlw ZSB8IERhdGEgfCBGQ1MgfA0KCQkrLS0tLSstLS0tKy0tLS0tLSstLS0tLS0r LS0tLS0rDQoJICANCgkJREEgICAgICBEZXN0aW5hdGlvbiBNQUMgQWRkcmVz cyAoNiBieXRlcykNCgkJU0EgICAgICBTb3VyY2UgTUFDIEFkZHJlc3MgICAg ICAoNiBieXRlcykNCgkJVHlwZSAgICBQcm90b2NvbCBUeXBlICAgICAgICAg ICAoMiBieXRlcykNCgkJRGF0YSAgICBQcm90b2NvbCBEYXRhICAgICAgICAg ICAoNDYgLSAxNTAwIGJ5dGVzKQ0KCQlGQ1MgICAgIEZyYW1lIENoZWNrc3Vt ICAgICAgICAgICg0IGJ5dGVzKQ0KDQoJQi4gSUVFRSA4MDIuMyBhbmQgZGVy aXZhdGl2ZXMNCg0KCQkrLS0tLSstLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0r DQoJCXwgREEgfCBTQSB8IExlbiAgfCBEYXRhIHwgRkNTIHwNCgkJKy0tLS0r LS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tKw0KDQoJCURBICAgICAgRGVzdGlu YXRpb24gTUFDIEFkZHJlc3MgKDYgYnl0ZXMpDQoJCVNBICAgICAgU291cmNl IE1BQyBBZGRyZXNzICAgICAgKDYgYnl0ZXMpDQoJCUxlbiAgICAgTGVuZ3Ro IG9mIERhdGEgZmllbGQgICAgKDIgYnl0ZXMpDQoJCURhdGEgICAgUHJvdG9j b2wgRGF0YSAgICAgICAgICAgKDQ2IC0gMTUwMCBieXRlcykNCgkJRkNTICAg ICBGcmFtZSBDaGVja3N1bSAgICAgICAgICAoNCBieXRlcykNCgkgIA0KCVRo ZSBkZXJpdmF0aXZlcyBpbmNsdWRlIExMQyAoODAyLjIpIGFuZCBTTkFQIHdo aWNoIHByZWZpeCB0aGUNCglkYXRhIGZpZWxkIHdpdGggYW4gTExDIGhlYWRl ci4gIEluIHRoZXNlIGluc3RhbmNlcyB0aGUgTGVuIGZpZWxkDQoJdGhlbiBj b3JyZXNwb25kcyB0byB0aGUgY29tYmluZWQgc2l6ZSBvZiBib3RoIHRoZSBk YXRhIHBvcnRpb24NCglvZiB0aGUgZnJhbWUgYW5kIHRoZSBMTEMgaGVhZGVy Lg0KCQ0KCU9uIHJlY2VwdGlvbiwgdGhlIHR3byBmb3JtYXRzIGFyZSBkaWZm ZXJlbnRpYXRlZCBiYXNlZCBvbiB0aGUNCgltYWduaXR1ZGUgb2YgdGhlIFR5 cGUvTGVuZ3RoIGZpZWxkLCBhcyBmb2xsb3dzOg0KDQoJPiAxNTAwIGJ5dGVz OiAgIHZhbHVlIGNvcnJlc3BvbmRzIHRvIGEgdHlwZSBmaWVsZC4gIFRoZSBm cmFtZSBpcyBhbg0KCQkJRXRoZXJuZXQgSUkgZnJhbWUsIHdpdGggdHlwZSB2 YWx1ZXMgc3RhcnRpbmcNCgkJCWF0IDE1MzYgKDYwMCBoZXgpLg0KDQoJPD0g MTUwMCBieXRlczogIHZhbHVlIGNvcnJlc3BvbmRzIHRvIGEgbGVuZ3RoIGZp ZWxkLiAgVGhlIGZyYW1lIGlzDQoJCQlhbiBJRUVFIDgwMi4zIGZvcm1hdCAo b3IgZGVyaXZhdGl2ZSkgd2l0aCBhIG1heGltdW0NCgkJCWRhdGEgbGVuZ3Ro IG9mIDE1MDAgYnl0ZXMuDQoNCjUuIFByb2JsZW0gd2l0aCBMYXJnZSA4MDIu MyBGcmFtZXMgaW4gdGhlIHByZXNlbmNlIG9mIEV0aGVybmV0X0lJIEZyYW1l cw0KDQoJU29tZSBwcm90b2NvbHMgY29tbW9ubHkgdXNlZCBpbiB0aGUgSW50 ZXJuZXQsIHN1Y2ggYXMgRVNJUw0KCWFuZCBJU0lTIHdoaWNoIGFyZSBjYXJy aWVkIGFzIENMTlMgcGFja2V0cywgaGF2ZSBubyByZXNlcnZlZA0KICAgICAg ICBFdGhlcnR5cGUuICBTdWNoIHBhY2tldHMgY2FuIG9ubHkgdXNlIHRoZSBJ RUVFIDgwMi4zLzgwMi4yIGVuY29kaW5nLCANCiAgICAgICAgYW5kIHNvIGFy ZSBsaW1pdGVkIGluIGxlbmd0aCB0byAxNTAwIGJ5dGVzLg0KDQogCUV0aGVy bmV0X0lJIGZyYW1lcyBoYXZlIG5vIGxlbmd0aCBmaWVsZC4gUHJvdG9jb2xz IGVuY2Fwc3VsYXRlZCBpbiANCglFdGhlcm5ldCBJSSBmcmFtZXMsIHN1Y2gg YXMgSVAsIGFyZSBub3QgbGltaXRlZCBpbiBsZW5ndGggdG8gMTUwMCANCiAg ICAgICAgYnl0ZXMgYnkgZnJhbWluZy4NCg0KNi4gUHJvcG9zZWQgRXRoZXJu ZXQgRnJhbWUgRXh0ZW5zaW9uDQoNCglMYXJnZSA4MDIuMyBhbmQgRXRoZXJu ZXRfSUkgZnJhbWVzIGNhbiBiZSBzdXBwb3J0ZWQgYnkgdGhlIGZvbGxvd2lu ZzoNCgkNCgkrICBEZWZpbmUgYW4gRXRoZXJ0eXBlIGZvciA4MDIuMywgMHg4 ODcwLCBhbmQgZW5jb2RlIGxhcmdlIGZyYW1lcw0KCSAgICh3aGVyZSB0aGUg ZGF0YSBmaWVsZCBpcyBncmVhdGVyIHRoYW4gMTUwMCBieXRlcyksDQoJICAg ZXhjbHVzaXZlIG9mIHRoZSBEZXN0aW5hdGlvbiBNQUMgYWRkcmVzcywgU291 cmNlIE1BQyBhZGRyZXNzLA0KICAgICAgICAgICBhbmQgRGF0YSBsZW5ndGgg ZmllbGRzLCB3aXRoaW4gRXRoZXJuZXQgSUkuDQoNCgkgICBMYXJnZSA4MDIu My84MDIuMiBmcmFtZXMgd291bGQgaGF2ZSB0aGUgZm9sbG93aW5nIGZpZWxk czoNCiANCgkJKy0tLS0rLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0t LS0rLS0tLS0tKy0tLS0tKw0KCQl8IERBIHwgU0EgfCBUeXBlIHwgRFNBUCB8 IFNTQVAgfCBDdHJsIHwgRGF0YSB8IEZDUyB8DQoJCSstLS0tKy0tLS0rLS0t LS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLSsNCgkJCQkg ID09PSA4MDIuMiBIZWFkZXIgPT09DQoNCgkJREEgICAgICBEZXN0aW5hdGlv biBNQUMgQWRkcmVzcyAgICAgICAgICAgICAgICAgKDYgYnl0ZXMpDQoJCVNB ICAgICAgU291cmNlIE1BQyBBZGRyZXNzICAgICAgICAgICAgICAgICAgICAg ICg2IGJ5dGVzKQ0KCQlUeXBlICAgIDB4ODg3MCAoRXRoZXJ0eXBlKSAgICAg ICAgICAgICAgICAgICAgICAoMiBieXRlcykNCgkJRFNBUCAgICA4MDIuMiBE ZXN0aW5hdGlvbiBTZXJ2aWNlIEFjY2VzcyBQb2ludCAgKDEgYnl0ZSkNCgkJ U1NBUCAgICA4MDIuMiBTb3VyY2UgU2VydmljZSBBY2Nlc3MgUG9pbnQgICAg ICAgKDEgYnl0ZSkNCgkJQ3RybCAgICA4MDIuMiBDb250cm9sIEZpZWxkICAg ICAgICAgICAgICAgICAgICAgKDEgYnl0ZSkNCgkJRGF0YSAgICBQcm90b2Nv bCBEYXRhICAgICAgICAgICAgICAgICAgICAgICAgICAgKCA+IDQ2IGJ5dGVz KQ0KCQlGQ1MgICAgIEZyYW1lIENoZWNrc3VtICAgICAgICAgICAgICAgICAg ICAgICAgICAoNCBieXRlcykNCgkgIA0KCSsgIEFsbG93IEV0aGVybmV0IElJ IGZyYW1lcyB0byBoYXZlIHBheWxvYWRzIGdyZWF0ZXIgdGhhbiAxNTAwIGJ5 dGVzLg0KDQoJVGhlcmUgaXMgbm8gbG9zcyBvZiBpbmZvcm1hdGlvbiBmcm9t IDgwMi4zLzgwMi4yIGZyYW1lcy4gQWx0aG91Z2ggDQogICAgICAgIHRoZSA4 MDIuMyBsZW5ndGggZmllbGQgaXMgbWlzc2luZywgdGhlIGZyYW1lIGxlbmd0 aCBpcyBrbm93biBieSANCiAgICAgICAgdmlydHVlIG9mIHRoZSBmcmFtZSBi ZWluZyBhY2NlcHRlZCBieSB0aGUgbmV0d29yayBpbnRlcmZhY2UuDQoNCglJ biB0aGlzIG1hbm5lciwgYWxsIEV0aGVybmV0IElJIGZyYW1lcywgaW5jbHVk aW5nIGxhcmdlIDgwMi4zIA0KIAlwYWNrZXRzLCBjYW4gYmUgbG9uZ2VyIHRo YW4gMTUwMCBieXRlcywgeWV0IGFyZSB1bmlxdWVseSBpZGVudGlmaWVkLg0K DQoNCjcuIFJlZmVyZW5jZXMNCg0KW0VUSF0gIlRoZSBFdGhlcm5ldCAtIEEg TG9jYWwgQXJlYSBOZXR3b3JrIiwgdmVyc2lvbiAxLjAsIERpZ2l0YWwNCkVx dWlwbWVudCBDb3Jwb3JhdGlvbiwgU2VwdGVtYmVyIDE5ODAsIGFuZCAiVGhl IEV0aGVybmV0LCBBIExvY2FsDQpBcmVhIE5ldHdvcmsiIERhdGEgTGluayBM YXllciBhbmQgUGh5c2ljYWwgTGF5ZXIgU3BlY2lmaWNhdGlvbnMiLA0KRGln aXRhbCwgSW50ZWwsIGFuZCBYZXJveCwgTm92ZW1iZXIsIDE5ODIuDQoNCltS RkM4OTRdIElFVEYgUkZDIDg5NA0KDQpbSUVFRTgwMi4zXSBJRUVFIFN0ZCA4 MDIuMw0KDQpbSUVFRTgwMl0gSUVFRSBTdGQgODAyDQoNCltJRUVFODAyLjNa XSBJRUVFIFN0ZCA4MDIuM3oNCg0KW0VYVC5GUkFNRV0gIlVzZSBvZiBFeHRl bmRlZCBGcmFtZSBTaXplcyBpbiBFdGhlcm5ldCBOZXR3b3JrcyIsIGRyYWZ0 DQoyLjEsIEFsdGVvbiBOZXR3b3JrcywgSW5jLg0KDQoNCjguIEF1dGhvcidz IEFkZHJlc3Nlcw0KDQpNaWtlIE8nRGVsbA0KVVVORVQgYW4gTUNJIFdvcmxk Q29tIENvbXBhbnkNCjMwNjAgV0lsbGFpbXMgRHJpdmUNCkZhaXJmYXgsIFZh LiAyMjAzMS00NjQ4DQo3MDMtMjA2LTU4OTANCmVtYWlsOiBtb0B1dS5uZXQN Cg0KSmVkIEthcGxhbg0KVVVORVQgYW4gTUNJIFdvcmxkQ29tIENvbXBhbnkN CjMwNjAgV0lsbGFpbXMgRHJpdmUNCkZhaXJmYXgsIFZhLiAyMjAzMS00NjQ4 DQo5MTQtNzAxLTUzMDkNCmVtYWlsOiBqa2FwbGFuQHV1Lm5ldA0KDQpKb2hu IEhheWVzDQpBbHRlb24gV2ViU3lzdGVtcywgSW5jLg0KNTAgR3JlYXQgT2Fr cyBCbHZkLg0KU2FuIEpvc2UsIENBIDk1MTE5DQo0MDgtMzYwLTU1MDcNCmVt YWlsOiBoYXllc0BhbHRlb24uY29tDQoNClRlZCBTY2hyb2VkZXINCkFsdGVv biBXZWJTeXN0ZW1zLCBJbmMuDQo1MCBHcmVhdCBPYWtzIEJsdmQuDQpTYW4g Sm9zZSwgQ0EgOTUxMTkNCjQwOC0zNjAtNTUwMA0KZW1haWw6IHRlZEBhbHRl b24uY29tDQoNClAuSi4gU2luZ2gNClBhY2tldCBFbmdpbmVzLCBJbmMuDQox MTcwNyBFYXN0IFNwcmFndWUgIzEwMQ0KU3Bva2FuZSBXQSAgOTkyMDYNCjUw OS03NzctNzAwMA0KZW1haWw6IHBqc2luZ2hAcGFja2V0ZW5naW5lcy5jb20N Cg0KRGFlbW9uIE1vcnJlbGwNCkp1bmlwZXIgTmV0d29ya3MsIEluYy4NCjEy MzQzLUQgU3VucmlzZSBWYWxsZXkgRHJpdmUNClJlc3RvbiwgVkEgMjAxOTEN CmVtYWlsOiBkbW9ycmVsbEBqdW5pcGVyLm5ldA0KDQpKZW5uaWZlciBIc3UN Cmpoc3VAbXVyLmNvbQ0K ---559023410-684387517-957964415=:12311-- From Internet-Drafts@ietf.org Wed, 19 Apr 2000 06:43:40 -0400 Date: Wed, 19 Apr 2000 06:43:40 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-snp-checksum-01.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Optional Checksums in ISIS Author(s) : A. Przygienda Filename : draft-ietf-isis-wg-snp-checksum-01.txt Pages : 3 Date : 18-Apr-00 This draft describes an optional extension to IS-IS [ISO90, Cal90a, Cal90b], used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. IS-IS originally doesn't provide CSNP adn PSNP checksums, relying on the underlying layers to verify the integrity of information provided. Experience with the protocol shows that this precondition does not always hold and scenarios can be imagined that impact protocol functionality. This document introduces a new optional TLV providing checksums. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-snp-checksum-01.txt 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-isis-wg-snp-checksum-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-ietf-isis-wg-snp-checksum-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. --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: <20000418080618.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-snp-checksum-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-snp-checksum-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000418080618.I-D@ietf.org> --OtherAccess-- --NextPart-- From prz@redback.com Thu, 20 Apr 2000 13:51:32 -0700 Date: Thu, 20 Apr 2000 13:51:32 -0700 From: Tony Przygienda prz@redback.com Subject: [Isis-wg] Clarification.. Henk Smit wrote: > > Thanks for the reponse. > > I still have one doubt.. Can we use these addresses advetised in LSP TLV's > > for next hop addresses.Since these addresses have no specific mapping to > > the IP reachability information. > > Please correct me if I'm wrong. > > Ai, sorry, I was to quick in my reply. > The IP interface address TLV (TLV #132) I was talking about are the IP > interface address TLVs used in *hellos*. Not in LSPs. > > In LSPs there is the same TLV (TLV #132). But those have no practical use. > And you are not supposed to use them in your routing calculations. > The easiest thing is to just ignore them during your SPF computation. You are not supposed to use them in the routing calculations, so far Henk's correct, but some people use them as the management address of the router so basically if they need to connect to the box to manage it, they use this specific address. That way you can advertise a stable loopback independent from the fact whether certain router interfaces are up or not ... One can solve the problem in different ways as well but that's one way ... just my 2c -- tony From Internet-Drafts@ietf.org Thu, 11 May 2000 06:57:18 -0400 Date: Thu, 11 May 2000 06:57:18 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-kaplan-isis-ext-eth-01.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Extended Ethernet Frame Size Support Author(s) : M. O'Dell, J. Kaplan, J. Hayes, T. Schroeder, P. Singh, D. Morrell, J. Hsu Filename : draft-kaplan-isis-ext-eth-01.txt Pages : 4 Date : 10-May-00 This document presents an extension to current Ethernet Frame standards to support payloads greater than 1500 Bytes for Ethernet_II and 802.3 frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-isis-ext-eth-01.txt 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-kaplan-isis-ext-eth-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-kaplan-isis-ext-eth-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. --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: <20000510111709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kaplan-isis-ext-eth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-kaplan-isis-ext-eth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000510111709.I-D@ietf.org> --OtherAccess-- --NextPart-- From Daniel.Proch@marconi.com Thu, 18 May 2000 16:17:08 -0400 Date: Thu, 18 May 2000 16:17:08 -0400 From: Proch, Daniel Daniel.Proch@marconi.com Subject: [Isis-wg] RE: MPLS and IS-IS Gabor, http://202.38.127.18/res/www.ietf.org/internet-drafts/draft-ietf-isis-traffi c-01.txt If that link is broke, I will send it to you. ======================== Daniel Proch Marconi Communications ======================== -----Original Message----- From: Gabor Korossy (ETH) [mailto:ethkkg@etxb.ericsson.se] Sent: Thursday, May 18, 2000 4:20 AM To: mpls@UU.NET; 'isis-wg@juniper.net'; 'te-wg@uu.net' Subject: [Isis-wg] RE: MPLS and IS-IS Hi, if I may repeat, could anyone help me please, find the draft "IS-IS extensions for Traffic Engineering," draft-ietf-isis-traffic-01.txt If so many ISPs run IS-IS with MPLS TE extensions shouldn't it become an IETF standard? Maybe one of the MPLS, TE and IS-IS working groups doesn´t feel ashamed to adopt this child? regards - Gabor >> -----Original Message----- >> From: Chris.Flores@broadwing.com [mailto:Chris.Flores@broadwing.com] >> Sent: Wednesday, May 17, 2000 8:48 PM >> To: mpls@UU.NET >> Subject: FW: MPLS and IS-IS >> >> >> >> David - >> >> Most large ISPs in the US use ISIS: >> >> UUnet, C&W, Sprintlink, Qwest, Verio, Digex, Frontier, Broadwing. >> >> It also seems like more and more european ISPs are starting >> to use ISIS: >> EUnet, Ebone, Hermes, TeleDanMark, Renater (FT), Telia, Tele2, etc. >> >> Chris >> >> -----Original Message----- >> From: David Wang [mailto:david.wang@metro-optix.com] >> Sent: Wednesday, May 17, 2000 12:36 PM >> To: 'HANSEN CHAN'; mpls@UU.NET >> Subject: RE: MPLS and IS-IS >> >> >> Hi all, >> >> IS-IS is defined to work with CLNP not for IP originally. >> Until today a lot >> of SONET and telecommunication equipment vendors still use >> IS-IS to route >> CLNP packets through the SONET Data communication >> channel(DCC) to carry >> management information and there is a great pressure to >> change this to OSPF >> and IP. I also know that UUNET runs IS-IS on their network. >> I never heard >> any other networks run IS-IS. Seems I am wrong. My questions are. >> >> 1. You guys are talking about using IS-IS in a IP networks >> not in CLNP >> networks. The IS-IS has been modified according to RFC 1195 >> (Use of OSI >> IS-IS for Routing in TCP/IP and Dual Environments) or some >> other standard. >> Is this correct? >> >> 2. Besides UUNET, which ISPs run IS-IS protocol? Can you >> name a few? or >> what percentage of networks run IS-IS instead of OSPF? >> >> Thanks >> David >> >> >> -----Original Message----- >> From: HANSEN CHAN [mailto:hchan@newbridge.com] >> Sent: Tuesday, May 16, 2000 7:22 AM >> To: mpls@UU.NET >> Subject: MPLS and IS-IS >> >> >> Hi all, >> >> I have been hearing IS-IS is a better protocol to be used >> than OSPF in a >> MPLS >> network for TE application. Is that a fair statement? What >> are the technical >> reasons? >> >> Appreciate if someone can shed some light on this subject. >> >> Thanks, >> Hansen >> >> _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From Thomas.M.Holland@usa.alcatel.com Thu, 18 May 2000 17:19:22 -0400 Date: Thu, 18 May 2000 17:19:22 -0400 From: Thomas M Holland Thomas.M.Holland@usa.alcatel.com Subject: [Isis-wg] IS-IS mixed domains I have a question about mixing Dual and OSI-only routers in an OSI-only area. Here is the configuration: Dual-1 --- OSI-1 --- OSI-2 --- Dual-2 | | Dual-3 --- Dual-4 --- Dual-5 --- Dual-6 (note: there are supposed to be vertical connections from Dual-1 to Dual-3 and from Dual-2 to Dual-6, in case my artwork gets mangled) Each of these NEs support Integrated ISIS and are all in the same area. By definition, this must be an OSI-only area since two of the NEs are OSI-only. Assume Dual-1 wants to send an IP packet to IP3 which is attached to Dual-2. Dual-1 has received an L1-LSP from Dual-2 with IP3 in its IP reachability entries list. Dual-1 should now have 2 paths to IP3, one through OSI-1 and one through Dual-3. The one through OSI-1 looks like the shorter path, but won't work, because it includes OSI only routers. The standard states that you cannot route IP packets in an OSI-only area. But it doesn't indicate any checks that you must do to prevent doing this. Are you required to check the 'protocol supported' field in each LSP and keep track of what type of area you are in? It seems if the node was required to look at the 'protocol supported' field of each link to determine if the area was OSI-only, that would fix the problem. Either the node would drop the packet itself with an appropriate ICMP error, or perhaps the SPF algorithm would take into account which nodes support IP and which do not. However, the way the standard reads to me (especially sec 1.4 and 3.10), it implies that you just send it out and the packet will get dropped. Is my reading correct? It seems that if you have even one OSI only router in an area, there's not much use in having Dual routers in that area, since IP packets can't be routed. Is there any kind of mechanism for easing the transition from OSI to IP (or vice-versa)? Do you know if anyone is using RFC1195 to route both CLNP and IP? Also, sec 3.8 of the RFC refers to future optional encapsulation mechanisms for forwarding packets through incompatible routers (which might help ease the transition); do you know of any work along these lines? Thanks, Tom Holland Alcatel From henk@Procket.com Fri, 19 May 2000 00:02:40 +0200 (MEST) Date: Fri, 19 May 2000 00:02:40 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] IS-IS mixed domains > > I have a question about mixing Dual and OSI-only routers in an OSI-only area. > > Here is the configuration: > > Dual-1 --- OSI-1 --- OSI-2 --- Dual-2 > | | > Dual-3 --- Dual-4 --- Dual-5 --- Dual-6 > > (note: there are supposed to be vertical connections > from Dual-1 to Dual-3 and from Dual-2 to Dual-6, in > case my artwork gets mangled) The picture is crisp clear. > Each of these NEs support Integrated ISIS and are all in the same area. > By definition, this must be an OSI-only area since two of the NEs are > OSI-only. Don't know where you found that definition. This is what rfc1195 has to say. See paragraph 1.4: Support of Mixed Routing Domains. In a dual routing domain, IP-only, OSI-only, and dual routers may be mixed on a per-area basis. Specifically, each area may itself be defined to be pure IP, pure OSI, or dual. In a dual area within a dual routing domain only dual routers may be used. Both IP and OSI traffic can be routed within a dual area. When I read this, I understand that it states that you may not mix Dual routers and OSI-only routers *inside* one area. In the design you presented in your example, you do mix them. That is forbidden. Your network design will not work. > Assume Dual-1 wants to send an IP packet to IP3 which is attached to Dual-2. > Dual-1 has received an L1-LSP from Dual-2 with IP3 in its IP > reachability entries list. Dual-1 should now have 2 paths to IP3, > one through OSI-1 and one through Dual-3. The one through OSI-1 > looks like the shorter path, but won't work, because it includes OSI > only routers. Correct. > The standard states that you cannot route IP packets in an OSI-only > area. But it doesn't indicate any checks that you must do to > prevent doing this. Are you required to check the 'protocol > supported' field in each LSP and keep track of what type of area you > are in? I would assume it is the responsability of the network adminstrator who install and configures the routers. Note: the protocol supported TLV is inside hello packets. So routers could check that to accept or reject adjacencies with other routers that are differently configured. Note also that this would make migration between modes more difficult. > It seems if the node was required to look at the 'protocol > supported' field of each link Which field ? The description of a link inside an LSP only tells you between which routers the link is, and what the cost is. It does not tell you which protocols are supported over that link. This is TLV #2. If you use the newer TLV #22, then you might want to add a new sub-TLV to describe the protocols supported. Then each router can run an SPF per protocol. IMHO this is not worth the trouble. > to determine if the area was OSI-only, > that would fix the problem. Either the node would drop the packet > itself with an appropriate ICMP error, or perhaps the SPF algorithm > would take into account which nodes support IP and which do > not. You'll need a separate SPF for IP and one for OSI. > However, the way the standard reads to me (especially sec 1.4 > and 3.10), it implies that you just send it out and the packet will > get dropped. Is my reading correct? My reading is that your setup is illegal. Behaviour of routers in illegal configurations in not (always) defined. > It seems that if you have even one OSI only router in an area, there's not > much use in having Dual routers in that area, since IP packets can't > be routed. Correct. That is probably why the requirement is there to make all routers inside an area in the same mode. > Is there any kind of mechanism for easing the transition > from OSI to IP (or vice-versa)? I am not sure what you mean by that question. > Do you know if anyone is using RFC1195 to route both CLNP and IP? Of course. > Also, sec 3.8 of the RFC refers to future optional encapsulation mechanisms > for forwarding packets through incompatible routers (which might help ease > the transition); do you know of any work along these lines? Nothing that I know of. Tunnels are a pain. Hope this helps, Henk. From jjl@one.com Fri, 19 May 2000 15:32:09 -0400 Date: Fri, 19 May 2000 15:32:09 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] IS-IS mixed domains >> I have a question about mixing Dual and OSI-only routers in an OSI-only area. You can mix OSI-only and dual routers in an area, but only OSI routing will be supported in the area. While the dual routers support IP routing capability, you won't get meaningful IP routing in the area. RFC1195 says: In a pure-OSI area within a dual domain, OSI-only and dual routers may be freely mixed. Only OSI traffic can be routed by level 1 routing within a pure OSI area. The protocol does not enforce the requirement. But if you try to break the rules, it just won't work. IP-capable routers may attempt to forward IP packets to OSI-only routers, which will drop them (if it's robust, but NE implementations aren't always as robust as one might wish ;-). As Henk says, the protocol doesn't distinguish between CLNP links and IP links. It just describes links, and a link is assumed to be capable of any protocol supported by the router that's running SPF. The strange upshot of this is that there are some mixed networks (some dual, some CLNP-only) where IP actually works, but only because all best paths between dual routers are via dual routers. I would strongly recommend against building a network like this on purpose, except in very special cases. Note that the fault tolerance assesment is much more complicated. For example, in your picture: >> >> Here is the configuration: >> >> Dual-1 --- OSI-1 --- OSI-2 --- Dual-2 >> | | >> Dual-3 --- Dual-4 --- Dual-5 --- Dual-6 >> If Dual-1 is trying to send IP traffic to Dual 2, it will forward it via OSI-1, which will just drop it. Assuming all link costs are equal, Dual-3 will be able to exchange IP traffic with Dual-6, but only if none of the links between them are down. >> Each of these NEs support Integrated ISIS and are all in the same area. >> By definition, this must be an OSI-only area since two of the NEs are >> OSI-only. Correct. >> Assume Dual-1 wants to send an IP packet to IP3 which is attached to Dual-2. >> Dual-1 has received an L1-LSP from Dual-2 with IP3 in its IP >> reachability entries list. Dual-1 should now have 2 paths to IP3, >> one through OSI-1 and one through Dual-3. The one through OSI-1 >> looks like the shorter path, but won't work, because it includes OSI >> only routers. > > Correct. > >> The standard states that you cannot route IP packets in an OSI-only >> area. But it doesn't indicate any checks that you must do to >> prevent doing this. Are you required to check the 'protocol >> supported' field in each LSP and keep track of what type of area you >> are in? > > I would assume it is the responsability of the network adminstrator > who install and configures the routers. > Note: the protocol supported TLV is inside hello packets. So routers could > check that to accept or reject adjacencies with other routers that > are differently configured. Note also that this would make migration > between modes more difficult. > >> It seems if the node was required to look at the 'protocol >> supported' field of each link to determine if the area was OSI-only, >> that would fix the problem. Either the node would drop the packet >> itself with an appropriate ICMP error, or perhaps the SPF algorithm >> would take into account which nodes support IP and which do >> not. As Henk says, there is no information for each link. There is, however, a Protocols Supported TLV in each LSP, identifying the protocols supported by the router, according to RFC 1195: The "Protocols Supported" field identifies the protocols which are supported by each router. This field must be included in all IS-IS Hello packets and all LSPs with LSP number 0 transmitted by IP- capable routers. But this information is not consulted when running SPF (or at any other time, so some implementations might even omit them from LSPs, and there would be no side effects except when trying to debug routing problems by looking in a router's LSDB). >> However, the way the standard reads to me (especially sec 1.4 >> and 3.10), it implies that you just send it out and the packet will >> get dropped. Is my reading correct? > > My reading is that your setup is illegal. Behaviour of routers in > illegal configurations in not (always) defined. I disagree that the setup is illegal (using dual routers in an OSI-only area). I do agree that trying to route IP traffic in this area is illegal. This is only a semantic nit I am picking ;-) and I agree with Henk's assessment that the behavior is a "don't care case" in the spec. >> It seems that if you have even one OSI only router in an area, there's not >> much use in having Dual routers in that area, since IP packets can't >> be routed. The only reason would be for transition purposes. >> Is there any kind of mechanism for easing the transition >> from OSI to IP (or vice-versa)? Introduce dual routers, but use only CLNP, until all routers are dual- capable. Then it is a dual area, and you can start using IP. >> Also, sec 3.8 of the RFC refers to future optional encapsulation mechanisms >> for forwarding packets through incompatible routers (which might help ease >> the transition); do you know of any work along these lines? Unfortunately, RFC 1195 makes this difficult if not impossible to do, because of ignoring the Protocols Supported TLV when running SPF. This makes tunneling impossible without creating some new special kind of link that would need to be understood by all dual routers in the area as being an IP-only link. This need to upgrade all dual routers in the area makes such an enhancement impractical. Regards, Jeff ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From prz@net4u.ch Sat, 20 May 2000 22:47:39 +0200 (MEST) Date: Sat, 20 May 2000 22:47:39 +0200 (MEST) From: Tony Przygienda prz@net4u.ch Subject: [Isis-wg] Last call for draft-kaplan-isis-ext-eth-01.txt Last call for draft-kaplan-isis-ext-eth-01.txt to go informational. Last call ends June 5th thanks -- tony From Thomas.M.Holland@usa.alcatel.com Wed, 24 May 2000 08:56:07 -0400 Date: Wed, 24 May 2000 08:56:07 -0400 From: Thomas M Holland Thomas.M.Holland@usa.alcatel.com Subject: [Isis-wg] IDRPI field Does anyone know if the Inter-Domain Routing Protocol Information field (TLV 131) is used very much out in the field? Are there other values for the Inter-Domain Information Type than (0, 1, and 2) in use? I did not see any reference to them in IANA. For Type 1 (i.e., local) are there standard or common formats in use? Thanks, Tom Holland Alcatel From henk@Procket.com Wed, 24 May 2000 15:53:46 +0200 (MEST) Date: Wed, 24 May 2000 15:53:46 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] IDRPI field I have never seen it in any LSPs. I don't know of any vendor that has implemented this. In fact, I'm not even sure I know that TVL 131 is supposed to do. ;-) Henk. > Does anyone know if the Inter-Domain Routing > Protocol Information field (TLV 131) is used > very much out in the field? > > Are there other values for the Inter-Domain > Information Type than (0, 1, and 2) in use? > I did not see any reference to them in IANA. > > For Type 1 (i.e., local) are there standard > or common formats in use? > > Thanks, > > Tom Holland > Alcatel > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From Internet-Drafts@ietf.org Wed, 24 May 2000 06:35:13 -0400 Date: Wed, 24 May 2000 06:35:13 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-3way-02.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Three-Way Handshake for IS-IS Point-to-Point Adjacencies Author(s) : D. Katz, R. Saluja Filename : draft-ietf-isis-3way-02.txt Pages : 7 Date : 23-May-00 The IS-IS routing protocol (ISO 10589) does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines an backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension. Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router. This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-3way-02.txt 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-isis-3way-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-isis-3way-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: <20000523121610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-3way-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-3way-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000523121610.I-D@ietf.org> --OtherAccess-- --NextPart-- From NZvaig@adtech-inc.com Wed, 24 May 2000 10:09:33 -1000 Date: Wed, 24 May 2000 10:09:33 -1000 From: Nava.Zvaig NZvaig@adtech-inc.com Subject: [Isis-wg] Packet encapsulations This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFC5BB.FA81D192 Content-Type: text/plain; charset="iso-8859-1" I'm looking for the latest encapsulations of IS-IS packets. It seemed that the format detailed in RFC 1195 and RFC 1142 has changed. For example, by searching the web, I found out that the common header doesn't include the ECO and USER ECO fields and has the Maximum Area Addresses field. Is there another source that describes the encapsulations of the Hello, LSP, and SNPs (for IS-IS over IP)? TIA, Nava ------_=_NextPart_001_01BFC5BB.FA81D192 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Packet encapsulations

I'm looking for the latest encapsulations of IS-IS = packets.  It seemed that the format detailed in RFC 1195 and RFC = 1142 has changed.  For example, by searching the web, I found out = that the common header doesn't include the ECO and USER ECO fields and = has the Maximum Area Addresses field.  Is there another source = that describes the encapsulations of the Hello, LSP, and SNPs (for = IS-IS over IP)?

TIA,
Nava

------_=_NextPart_001_01BFC5BB.FA81D192-- From jjl@one.com Wed, 24 May 2000 16:25:54 -0400 Date: Wed, 24 May 2000 16:25:54 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] draft-ietf-isis-3way-02.txt questions The procedures in draft-ietf-isis-3way-02 look great. I have a suggestion: It should be stated that this mechanism is unnecessary when using a reliable link layer service, and that implementing this mechanism relaxes certain requirements stated in ISO 10589 for the operation of IS-IS over point-to-point links. These requirements are: "a) Provision that both source and destination systems complete startup before PDU exchange can occur; b) Detection of remote start-up; c) Provision that no old PDUs be received after start-up is complete; d) Provision that no PDUs transmitted after a particular startup is complete are delivered out of sequence; e) Provision that failure to deliver a specific subnetwork SDU will result in the timely disconnexion of the subnetwork connection in both directions and that this failure will be reported to both systems; and f) Reporting of other subnetwork failures and degrade subnetwork conditions. g) The following events are "very low probability", ..." Clearly, the draft relieves the subnetwork of requirements a, b, e, and f. I don't know whether the mechanism has any impact on requirements c and d. Regards, Jeff ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From mbartell@cisco.com Wed, 24 May 2000 17:37:59 -0500 Date: Wed, 24 May 2000 17:37:59 -0500 From: Micah Bartell mbartell@cisco.com Subject: [Isis-wg] Packet encapsulations With regards to the encapsulations of IS-IS packets, they are encapsulated within the Data Link. They do not run over CLNS or over IP. Does this answer you question? I would also not recommend the use of RFC 1142 as it is not the final draft of ISO 10589. I would instead recommend the obtaining an actual copy of ISO 10589 with the related updates which are packaged together by ANSI. Yes, work is in progress to produce a new edition of ISO 10589 which contains the defect reports integrated into the standard. /mpb At 10:09 AM 5/24/2000 -1000, Nava.Zvaig wrote: >I'm looking for the latest encapsulations of IS-IS packets. It seemed that the format detailed in RFC 1195 and RFC 1142 has changed. For example, by searching the web, I found out that the common header doesn't include the ECO and USER ECO fields and has the Maximum Area Addresses field. Is there another source that describes the encapsulations of the Hello, LSP, and SNPs (for IS-IS over IP)? > >TIA, >Nava -- Micah Bartell, CCIE #5069 mbartell@cisco.com Network Consulting Engineer, NSA Phone: 972.364.8829 Cisco Systems, Inc Fax: 972.364.8829 -- The Network Works, No Excuses From rsaluja@nortelnetworks.com Thu, 25 May 2000 09:36:27 -0400 Date: Thu, 25 May 2000 09:36:27 -0400 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] draft-ietf-isis-3way-02.txt questions Jeff, It is a valid point. Thanks for your suggestion. Regards, Rajesh Jeff Learman wrote: > The procedures in draft-ietf-isis-3way-02 look great. I have a suggestion: > > It should be stated that this mechanism is unnecessary when using a > reliable link layer service, and that implementing this mechanism relaxes > certain requirements stated in ISO 10589 for the operation of IS-IS over > point-to-point links. These requirements are: > > "a) Provision that both source and destination systems complete startup > before PDU exchange can occur; > b) Detection of remote start-up; > c) Provision that no old PDUs be received after start-up is complete; > d) Provision that no PDUs transmitted after a particular startup is > complete are delivered out of sequence; > e) Provision that failure to deliver a specific subnetwork SDU will > result in the timely disconnexion of the subnetwork connection in > both directions and that this failure will be reported to both systems; > and > f) Reporting of other subnetwork failures and degrade subnetwork conditions. > g) The following events are "very low probability", ..." > > Clearly, the draft relieves the subnetwork of requirements a, b, e, and f. > I don't know whether the mechanism has any impact on requirements c and d. > > Regards, > Jeff > > ____________________________________________________________________ > > Jeff Learman Internet: jjl@one.com > Engineering Manager Voice: (734)-975-7323 > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > 2725 South Industrial Pkwy, Suite 100 > Ann Arbor, MI 48104 USA > ____________________________________________________________________ > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- From CMartin@mercury.balink.com Thu, 25 May 2000 17:10:29 -0400 Date: Thu, 25 May 2000 17:10:29 -0400 From: Martin, Christian CMartin@mercury.balink.com Subject: [Isis-wg] IDRPI field Henk, I posed a question regarding this a while back. As you know, RFC1195 indicates that the IDRPI field could be used for adminstrative tagging, a la OSPF admin tags when the type is set to 1, or an External AS LSA (LSA 6) for a type 2. From an operational perspective, this would be useful additional information that could aid in things like redistribution filtering. Given all the TE work being done to extend the protocol, it should be a relatively painless addition to the next rev. Regards, Chris -----Original Message----- From: Henk Smit [mailto:henk@Procket.com] Sent: Wednesday, May 24, 2000 9:54 AM To: Thomas.M.Holland@usa.alcatel.com Cc: isis-wg@external.juniper.net Subject: Re: [Isis-wg] IDRPI field I have never seen it in any LSPs. I don't know of any vendor that has implemented this. In fact, I'm not even sure I know that TVL 131 is supposed to do. ;-) Henk. > Does anyone know if the Inter-Domain Routing > Protocol Information field (TLV 131) is used > very much out in the field? > > Are there other values for the Inter-Domain > Information Type than (0, 1, and 2) in use? > I did not see any reference to them in IANA. > > For Type 1 (i.e., local) are there standard > or common formats in use? > > Thanks, > > Tom Holland > Alcatel > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From vanik@future.futsoft.com Fri, 26 May 2000 10:27:07 +0530 Date: Fri, 26 May 2000 10:27:07 +0530 From: Vani Sree K vanik@future.futsoft.com Subject: [Isis-wg] Doubt on IS-IS Hi, In the Intermediate system Neighbors option of LAN Hello, the code value carries the 6 Octet Mac Address. (10589, 1992) My doubt is whether it is the Mac Address of the interface from which the Hello is sent or System Id of the Intermediate system. (Assuming one of the Mac address is system Id). (In one of the Cisco document of IS-IS, it has been stated that the "SystemID is usually the MAC identifier of an interface on the device. The IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has been heard within the last Hold time..") While creating new adjacencies, the NeigbourSNPA Address is set to the MAC source address of the PDU. It means, the source MAC address is got from the Ethernet header.? Please correct me. Thanks -vani From rsaluja@nortelnetworks.com Fri, 26 May 2000 09:16:30 -0400 Date: Fri, 26 May 2000 09:16:30 -0400 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] Doubt on IS-IS LAN Hello carries the system ID. -Rajesh Vani Sree K wrote: > Hi, > > In the Intermediate system Neighbors option of LAN Hello, the code value > carries the 6 Octet Mac Address. (10589, 1992) > My doubt is whether it is the Mac Address of the interface from which the > Hello is sent or System Id of the Intermediate system. (Assuming one of the > Mac address is system Id). > (In one of the Cisco document of IS-IS, it has been stated that the > "SystemID is usually the MAC identifier of an interface on the device. The > IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has > been heard within the last Hold time..") > > While creating new adjacencies, the NeigbourSNPA Address is set to the MAC > source address of the PDU. > It means, the source MAC address is got from the Ethernet header.? > > Please correct me. > > Thanks > -vani > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- From jjl@one.com Fri, 26 May 2000 11:37:44 -0400 Date: Fri, 26 May 2000 11:37:44 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] Doubt on IS-IS Vani, While it is true that a LAN IIH carries a system ID, the Intermediate System Neighbors option in a LAN IIH carries the MAC address of the neighbor, not the system ID. The MAC address of the neighbor is obtained from the Ethernet header of the IIH received from the neighbor. See ISO 10589:1992 Section 9.5, Intermediate System Neighbours, on page 50. Regards, Jeff Vani Sree K wrote: > Hi, > > In the Intermediate system Neighbors option of LAN Hello, the code value > carries the 6 Octet Mac Address. (10589, 1992) > My doubt is whether it is the Mac Address of the interface from which the > Hello is sent or System Id of the Intermediate system. (Assuming one of the > Mac address is system Id). > (In one of the Cisco document of IS-IS, it has been stated that the > "SystemID is usually the MAC identifier of an interface on the device. The > IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has > been heard within the last Hold time..") > > While creating new adjacencies, the NeigbourSNPA Address is set to the MAC > source address of the PDU. > It means, the source MAC address is got from the Ethernet header.? > > Please correct me. > > Thanks > -vani > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From emmanuel.dauvergne@rd.francetelecom.fr Fri, 26 May 2000 18:11:33 +0200 Date: Fri, 26 May 2000 18:11:33 +0200 From: DAUVERGNE Emmanuel FTRD/DAC/ISS emmanuel.dauvergne@rd.francetelecom.fr Subject: [Isis-wg] Doubt on IS-IS ...and this MAC address (SNPA) is used in the DIS election : (if no priority imposed) choose the highest one. Regards, Manu -----Message d'origine----- De: Jeff Learman [mailto:jjl@one.com] Date: vendredi 26 mai 2000 17:38 À: Vani Sree K Cc: isis-wg@external.juniper.net Objet: Re: [Isis-wg] Doubt on IS-IS Vani, While it is true that a LAN IIH carries a system ID, the Intermediate System Neighbors option in a LAN IIH carries the MAC address of the neighbor, not the system ID. The MAC address of the neighbor is obtained from the Ethernet header of the IIH received from the neighbor. See ISO 10589:1992 Section 9.5, Intermediate System Neighbours, on page 50. Regards, Jeff Vani Sree K wrote: > Hi, > > In the Intermediate system Neighbors option of LAN Hello, the code value > carries the 6 Octet Mac Address. (10589, 1992) > My doubt is whether it is the Mac Address of the interface from which the > Hello is sent or System Id of the Intermediate system. (Assuming one of the > Mac address is system Id). > (In one of the Cisco document of IS-IS, it has been stated that the > "SystemID is usually the MAC identifier of an interface on the device. The > IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has > been heard within the last Hold time..") > > While creating new adjacencies, the NeigbourSNPA Address is set to the MAC > source address of the PDU. > It means, the source MAC address is got from the Ethernet header.? > > Please correct me. > > Thanks > -vani > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From selvarajr@future.futsoft.com Sat, 27 May 2000 10:52:52 +0530 Date: Sat, 27 May 2000 10:52:52 +0530 From: SelvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubt on IS-IS ------ =_NextPart_000_01BFC7C9.B68FE220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Except resolving tie does the SNPA is useful for any other purpose that can't be done using System ID. Also for breaking Tie, if there are two string(or value) that can be compared then that's enough. But those string(or value) necessarily not be the SNPA. In case of Integrated ISIS while the protocol runs over IP , I feel it is little bit inefficient to get the MAC address from the Ethernet header. Pls clarify if wrong. SELVA -----Original Message----- From: DAUVERGNE Emmanuel FTRD/DAC/ISS [SMTP:emmanuel.dauvergne@rd.francetelecom.fr] Sent: Friday, May 26, 2000 9:42 PM To: Vani Sree K Cc: isis-wg@external.juniper.net Subject: RE: [Isis-wg] Doubt on IS-IS ...and this MAC address (SNPA) is used in the DIS election : (if no priority imposed) choose the highest one. Regards, Manu -----Message d'origine----- De: Jeff Learman [mailto:jjl@one.com] Date: vendredi 26 mai 2000 17:38 A: Vani Sree K Cc: isis-wg@external.juniper.net Objet: Re: [Isis-wg] Doubt on IS-IS Vani, While it is true that a LAN IIH carries a system ID, the Intermediate System Neighbors option in a LAN IIH carries the MAC address of the neighbor, not the system ID. The MAC address of the neighbor is obtained from the Ethernet header of the IIH received from the neighbor. See ISO 10589:1992 Section 9.5, Intermediate System Neighbours, on page 50. Regards, Jeff Vani Sree K wrote: > Hi, > > In the Intermediate system Neighbors option of LAN Hello, the code value > carries the 6 Octet Mac Address. (10589, 1992) > My doubt is whether it is the Mac Address of the interface from which the > Hello is sent or System Id of the Intermediate system. (Assuming one of the > Mac address is system Id). > (In one of the Cisco document of IS-IS, it has been stated that the > "SystemID is usually the MAC identifier of an interface on the device. The > IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has > been heard within the last Hold time..") > > While creating new adjacencies, the NeigbourSNPA Address is set to the MAC > source address of the PDU. > It means, the source MAC address is got from the Ethernet header.? > > Please correct me. > > Thanks > -vani > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg ------ =_NextPart_000_01BFC7C9.B68FE220 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IjcFAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAwAMAAAIAAAARAAAAAwAAMAMAAAAL AA8OAQAAAAIB/w8BAAAAZAAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAABAERBVVZFUkdORSBFbW1h bnVlbCBGVFJEL0RBQy9JU1MAU01UUABlbW1hbnVlbC5kYXV2ZXJnbmVAcmQuZnJhbmNldGVsZWNv bS5mcgAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAJwAAAGVtbWFudWVsLmRhdXZlcmduZUBy ZC5mcmFuY2V0ZWxlY29tLmZyAAADABUMAQAAAAMA/g8GAAAAHgABMAEAAAAiAAAAJ0RBVVZFUkdO RSBFbW1hbnVlbCBGVFJEL0RBQy9JU1MnAAAAAgELMAEAAAAsAAAAU01UUDpFTU1BTlVFTC5EQVVW RVJHTkVAUkQuRlJBTkNFVEVMRUNPTS5GUgADAAA5AAAAAAsAQDoAAAAAAwBxOgAAAAAeAPZfAQAA ACAAAABEQVVWRVJHTkUgRW1tYW51ZWwgRlRSRC9EQUMvSVNTAAIB918BAAAAZAAAAAAAAACBKx+k vqMQGZ1uAN0BD1QCAAABAERBVVZFUkdORSBFbW1hbnVlbCBGVFJEL0RBQy9JU1MAU01UUABlbW1h bnVlbC5kYXV2ZXJnbmVAcmQuZnJhbmNldGVsZWNvbS5mcgADAP1fAQAAAAMA/18AAAAAAgH2DwEA AAAEAAAAAAAAAxAAAAADAAAwBAAAAAsADw4AAAAAAgH/DwEAAABuAAAAAAAAALU7wsAsdxAaobwI ACsqVsIVAAAAE95ma15h0xGoWAAgNR+SoGSIAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAABJU0lT LVdHAFNNVFAAaXNpcy13Z0BleHRlcm5hbC5qdW5pcGVyLm5ldAAAAB4AAjABAAAABQAAAFNNVFAA AAAAHgADMAEAAAAdAAAAaXNpcy13Z0BleHRlcm5hbC5qdW5pcGVyLm5ldAAAAAADABUMAgAAAAMA /g8GAAAAHgABMAEAAAAKAAAAJ0lTSVMtV0cnAAAAAgELMAEAAAAiAAAAU01UUDpJU0lTLVdHQEVY VEVSTkFMLkpVTklQRVIuTkVUAAAAAwAAOQAAAAALAEA6AQAAAB4A9l8BAAAACAAAAElTSVMtV0cA AgH3XwEAAAAsAAAAvwAAALU7wsAsdxAaobwIACsqVsIVAAAAE95ma15h0xGoWAAgNR+SoGSIAAAD AP1fAQAAAAMA/18AAAAAAgH2DwEAAAAEAAAAAAAABDXPAQSAAQAdAAAAUkU6IFtJc2lzLXdnXSBE b3VidCBvbiBJUy1JUwDsCAEFgAMADgAAANAHBQAbAAoANAA0AAYAbwEBIIADAA4AAADQBwUAGwAK ACUAAAAGACwBAQmAAQAhAAAAMkFCMEE1QkRCMDMzRDQxMUE4NTgwMDIwMzUxRjkyQTAA9gYBA5AG AGgLAAAiAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAAAAAA QAA5AECeG5ubx78BHgBwAAEAAAAdAAAAUkU6IFtJc2lzLXdnXSBEb3VidCBvbiBJUy1JUwAAAAAC AXEAAQAAABYAAAABv8ebmwq9pbAsM7AR1KhYACA1H5KgAAAeAB4MAQAAAAUAAABTTVRQAAAAAB4A HwwBAAAAHQAAAHNlbHZhcmFqckBmdXR1cmUuZnV0c29mdC5jb20AAAAAAwAGEP8jp7cDAAcQfwgA AB4ACBABAAAAZQAAAEVYQ0VQVFJFU09MVklOR1RJRURPRVNUSEVTTlBBSVNVU0VGVUxGT1JBTllP VEhFUlBVUlBPU0VUSEFUQ0FOVEJFRE9ORVVTSU5HU1lTVEVNSURBTFNPRk9SQlJFQUtJTkdUSUUA AAAAAgEJEAEAAADsBwAA6AcAAJwPAABMWkZ19+scXXcACgEDAfcgAqQD4wIAY4JoCsBzZXQwIAcT DwKDAFADVA9ZQm9vaxEDgk9sZAYAdHlsGmUCgzIC4w9ZVGFoCwNxAoMzDudwcnEyTQ/2fQqACMgg OwlvMsw1NQKACoF1YwBQCwMGYwBBC2BuZzEwM4MU8QvEIEV4Y2UFMRUJcHMG8HYLgGcgdJEIkCBk bweRdGgb4CBTTlBBIAQAIHV5D7BmdQMgAhAFwABweSwgbxxRBcBwCHBwb6sPsBxBYQVAYwBwJwVA emIb4m4b4B0QG4IGsHOAdGVtIElELgqiWQqAQWwbQB1zYglwYUZrG4IHYGUsIBzQZs8cQglwHbAj UXR3IaAgkGsFEBnAKAWxdgdAClAp9x7XH4IFoG0KsQmAHEIDoB0e4icEIAnwCGBnaC7zCuMKgEJ1 BUAcUB6iJA//H+Aa0AQQCsADEB3gJzAfc3ccViEFIRRJA6AfMB6xbz8jACwwIKAJwB8AJjFJU/Et kCB3aAMQKsQVkB4Alm8I4RsQdQYxb3YeMehJUCAiwEkdcAngAyBWaQVAHOFsMHB0LhFi5zByH+AB IGljCJACMBuwjSGgZw/AHENNQUMdsLxkZBshBCADUhxDRR4Sfx/gBUAcYDMwBJArayEUUL8hgB8g C2AGgR3gIvF3A2B/GcA1PxlCAUAAoABABgBFOExWQQxAAtETMXMxnjY4GhThOCkw0DM2AUBXLoIF kAVALTziTwUQZ/8LgAdABdAp4jJwPOMrdjx0DzxBCxM8dAIAaS0xNMY0AUAw0DE4MAFADNBRQINi IEYDYToMg2IBD+BEQVVWRVJHdE5FGqBtA4EKUAMgRpBUUkQvQqBDLy2QgQXwW1NNVFA6ILChQ2Qu ZGF1L3FnH+D6QAsgLgNQAHAa0CCgEsD7JdFGUV0rdUGwBmACMEIXVUHQaUWQeSLATUkQIBwyNiLA AdBBECA5OpI0FcBQTUd3VG9CF5pWAHBpBgAJ0SBLR3ccQ2NCFwQABAAtd2c4QGV4IKAEoAdALmof LyAFIDURNJFHeHViaqM8oUIXUkU6RJBJTdR2XUKQCGBiBUACIC2BLb8tkD6PP5o8BAu2ISMuVdDv AHAmQhzhMvooHJIk8Bzk9xJwC4AcQ0QtsUbSG8BSUf1RMCgi8ScwLnFZQAUQEqD3IRQHcB6SZCTw D3AR4B6zXxvgLfAnYAeQUjJlK2tS8y0QCxFzLCEUSVBDgCt6dzzjPcUb8CdaQT1hPipESmVRMEoB ESBMIiByfQOCWxlTHVEAwAMQLrA68GpqbEBcsiXROMMdUPsP4EdlRC1BUTAvcFYQCXEPTABJkGMy ScQxNzoz4jgrdSdjMFEwS99NEfNNv07PCk9QMUgwB/Bhsb9RX1JtNW5oIl4lIRRXLfMvMHQkEApQ HtRhYiBBTukg0ElIHyFyCIEEIHGw/nMghl4lHFIs4mJgZhEtQf8gZgfAXEEG4A+gHfAFMFlC/1hB cbchFHJWMr4ssRxSH+D/dZQiwCpyHFJy9CvVIPAi0O5UeD95SxzSb20QC3EmMX8DUnOYNE15FnIS CXAa0Gk/L3B+ZHlLIQUGYHQRU08RZwAwNThKIDE5OccVwAZgWSQ5LjUv4XRPP3VXCHBeFlJRCrBg MTUw/1zvXfhh4m6OTBU3QmWBK3roPiBIb3Y+jEYsMXP/73L1dX8ssXHSSDBACQAiwX8cUgWgAQAk lIxGd6pmYE93PLAygUlQYw/wM0QngCjXg6MiwIQCKYxGTR3gHAD/bQIc4S3gD8AeInC1MsKUSPd5 FguAahFmANAb4DOzLeH/D3AcQoxHkSIc0g+wMhEFsb8gdhJwgGaOb0cgV0BBBBD8dW0bgh/SLLBz l5XXlEG3MzabwpyGKSEFjKAoLDG7n3QcQ0MEAAWgG/FjnxD/nAMswVKSIsAwcQ+ABCAfkJ8mgSCQ LUMe45q5ICIgdPsg4BzUdQdAKkEytkjwMgH/BpAIkSyiA5GZaFJRHFIBAL8bcBrQIQV7wY1nBfBO IgD9BCBDOYAwwSCQHDSh13yj/6jBeYczlS3gM9FxsJtkpbH/jEal8zTRCyAt0DBwLfBYVHsLYFyB SAbwJkEHcVXQIv+VxoxGcFQFACIgG8AbkR/g+wfgMzBqmcFGkHKRIsAcUv+PkoayHJOYdpvDMiMy tYxGjxtACHCZ0XxNUERVonf+SQVAB4AAcZFlurUy+hzh7mcqgTO/NMY/jP02YCIg/x6xJcFycDyi tEGM/XvAAHC6a7GXLSSgAwCM/V/GP//HT8gajWdphGMzG4Kt8iLQfi0i0GxVae9PSIygYsZoYQJA cDovL8u/NJEvu2NCA4EvrfILgAIQL2l1/2RmK3rIH9N/1I/Vnyt6ItD/YevYX9j3hSM0kWwg2PJj uv3XJUUZwDGBBnEbkV6RPgFnBcDdTyLQVm+r4dqEKAA3MzQpLTk3NVot30AyOzUi0E9DESjeT08Q A6AHwCPBcsRQ3AqNhQJjJPAi0EZheNqEWd8aNjlAodclMgHANe8GAAhgHFAs0WQdECQRPZH4UGt3 SSFQEDBwG+AZ4Lnkh0FuA6AHEHnjTTAAKCA0OBngNCLQVVP/OaDSL+qP65/sr9Zv7Q/v3//tTywR yb/Kz86PT3bNj/Rv/8+v0L/uL/sv/D/xX/Jv839/9I/1n/av97/4z/nYGJEAAQawAwAQEAAAAAAD ABEQAAAAAB4AQhABAAAAPwAAADw5ODM4OEMwNUQ0NjREMTExQjYxODAwODA1RjE1MDQxNjAxNDhC NDc4QHAtaWJpcy5pc3N5LmNuZXQuZnI+AAADAIAQ/////0AABzDgF9Jjmce/AUAACDDgF9Jjmce/ AQsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAA EIUAAAAAAAADAAWACCAGAAAAAADAAAAAAAAARgAAAABShQAA8xUAAAMAB4AIIAYAAAAAAMAAAAAA AABGAAAAAAGFAAAAAAAAHgAIgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAFAAAAOC4wNAAA AAALAAmACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMACoAIIAYAAAAAAMAAAAAAAABGAAAA ABGFAAAAAAAAAwALgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAAyACCAGAAAAAADAAAAA AAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgANgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAAB AAAAAAAAAB4ADoAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAAeAD0AAQAAAAUA AABSRTogAAAAAAMADTT9NwAARWY= ------ =_NextPart_000_01BFC7C9.B68FE220-- From tangcm@future.futsoft.com Sat, 27 May 2000 11:34:05 +0530 Date: Sat, 27 May 2000 11:34:05 +0530 From: Jorge tangcm@future.futsoft.com Subject: [Isis-wg] Doubt on IS-IS I also agree with most of what Mr/Miss SELVA say . for actually now integrated Is-Is communication with IP layer only through Raw socket API , can somebody tell me how i can get the Ethernet header from raw socket with the condition that i won't encapsulate Is-Is packet with Ethernet header myself ( And also i can't make assumption that another implementation for integrated is-is will encapsulate Is-Is packet with Ethernet header in raw socket ) . ----- Original Message ----- From: SelvarajR To: 'DAUVERGNE Emmanuel FTRD/DAC/ISS' Cc: 'ISIS-WG' Sent: Saturday, May 27, 2000 10:52 AM Subject: RE: [Isis-wg] Doubt on IS-IS > Except resolving tie does the SNPA is useful for any other purpose that > can't be done using System ID. > Also for breaking Tie, if there are two string(or value) that can be > compared then that's enough. > But those string(or value) necessarily not be the SNPA. > > In case of Integrated ISIS while the protocol runs over IP , I feel it is > little bit inefficient to get the MAC address from the Ethernet header. > > > Pls clarify if wrong. > > SELVA > > -----Original Message----- > From: DAUVERGNE Emmanuel FTRD/DAC/ISS > [SMTP:emmanuel.dauvergne@rd.francetelecom.fr] > Sent: Friday, May 26, 2000 9:42 PM > To: Vani Sree K > Cc: isis-wg@external.juniper.net > Subject: RE: [Isis-wg] Doubt on IS-IS > > ...and this MAC address (SNPA) is used in the DIS election : (if no > priority > imposed) choose the highest one. > > Regards, > Manu > > -----Message d'origine----- > De: Jeff Learman [mailto:jjl@one.com] > Date: vendredi 26 mai 2000 17:38 > A: Vani Sree K > Cc: isis-wg@external.juniper.net > Objet: Re: [Isis-wg] Doubt on IS-IS > > > > Vani, > > While it is true that a LAN IIH carries a system ID, > the Intermediate System Neighbors option in a LAN IIH > carries the MAC address of the neighbor, not the system > ID. The MAC address of the neighbor is obtained from > the Ethernet header of the IIH received from the neighbor. > See ISO 10589:1992 Section 9.5, Intermediate System Neighbours, > on page 50. > > Regards, > Jeff > > Vani Sree K wrote: > > > Hi, > > > > In the Intermediate system Neighbors option of LAN Hello, the code value > > carries the 6 Octet Mac Address. (10589, 1992) > > My doubt is whether it is the Mac Address of the interface from which the > > Hello is sent or System Id of the Intermediate system. (Assuming one of > the > > Mac address is system Id). > > (In one of the Cisco document of IS-IS, it has been stated that the > > "SystemID is usually the MAC identifier of an interface on the device. > The > > IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has > > been heard within the last Hold time..") > > > > While creating new adjacencies, the NeigbourSNPA Address is set to the > MAC > > source address of the PDU. > > It means, the source MAC address is got from the Ethernet header.? > > > > Please correct me. > > > > Thanks > > -vani > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > ____________________________________________________________________ > > Jeff Learman Internet: jjl@one.com > Engineering Manager Voice: (734)-975-7323 > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > 2725 South Industrial Pkwy, Suite 100 > Ann Arbor, MI 48104 USA > ____________________________________________________________________ > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From henk@Procket.com Sat, 27 May 2000 12:21:03 +0200 (MEST) Date: Sat, 27 May 2000 12:21:03 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] Doubt on IS-IS > In case of Integrated ISIS while the protocol runs over IP , I feel it is > little bit inefficient to get the MAC address from the Ethernet header. > > Pls clarify if wrong. Yes, this is wrong. There is a relatively new draft proposal to define an IP encapsulation for IS-IS. But integrated ISIS, as defined in rfc1195, uses the same encapsulation as ISIS defined in ISO/IEC DIS 10589. IS-IS packets are encapsulated directly in the data-link layer. No IP headers anywhere ...... Henk. From henk@Procket.com Sat, 27 May 2000 12:23:23 +0200 (MEST) Date: Sat, 27 May 2000 12:23:23 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] Doubt on IS-IS > I also agree with most of what Mr/Miss SELVA say . for actually now > integrated Is-Is communication with IP layer only through Raw socket > API , can somebody tell me how i can get the Ethernet header from raw > socket with the condition that i won't encapsulate Is-Is packet with > Ethernet header myself ( And also i can't make assumption that another > implementation for integrated is-is will encapsulate Is-Is packet with > Ethernet header in raw socket ) . These are all clearly *implementation* questions. The answers depend on the OS you use. Henk. From prz@net4u.ch Sat, 27 May 2000 21:29:56 +0200 (MEST) Date: Sat, 27 May 2000 21:29:56 +0200 (MEST) From: Tony Przygienda prz@net4u.ch Subject: [Isis-wg] Doubt on IS-IS > > I also agree with most of what Mr/Miss SELVA say . for actually now > > integrated Is-Is communication with IP layer only through Raw socket > > API , can somebody tell me how i can get the Ethernet header from raw > > socket with the condition that i won't encapsulate Is-Is packet with > > Ethernet header myself ( And also i can't make assumption that another > > implementation for integrated is-is will encapsulate Is-Is packet with > > Ethernet header in raw socket ) . > > These are all clearly *implementation* questions. > The answers depend on the OS you use. > > Henk. Correct, however nothings' wrong with posting implementation qeustions on this list ;-) Henk was right in the other mail as well, there is the IPv4 encaps draft and one of the reasons for it was the difficulty to get mac header in many environments. Observe however that today's deployment occurs without IPv4 encaps pretty much. If you primarily want to play with ISIS without the realities of the market-place and only care to have it talk to e.g. gated, IPv4 encaps is nice since it let's you forget most of those ethernet header problems which are not easily taken care of on any Unix platform and in fact imply writing your own encaps and lots of toying around wiht things like SOCK_PACKET stuff. -- tony From Internet-Drafts@ietf.org Tue, 30 May 2000 06:34:25 -0400 Date: Tue, 30 May 2000 06:34:25 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-kaplan-isis-ext-eth-02.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Extended Ethernet Frame Size Support Author(s) : M. O'Dell, J. Kaplan, J. Hayes, T. Schroeder, P. Singh, D. Morrell, J. Hsu Filename : draft-kaplan-isis-ext-eth-02.txt Pages : 4 Date : 26-May-00 This document presents an extension to current Ethernet Frame standards to support payloads greater than 1500 Bytes for Ethernet_II and 802.3 frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-isis-ext-eth-02.txt 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-kaplan-isis-ext-eth-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-kaplan-isis-ext-eth-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: <20000526105527.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kaplan-isis-ext-eth-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-kaplan-isis-ext-eth-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000526105527.I-D@ietf.org> --OtherAccess-- --NextPart-- From jjl@one.com Tue, 30 May 2000 14:16:43 -0400 Date: Tue, 30 May 2000 14:16:43 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] draft-ietf-isis-3way-02.txt questions Rajesh, Does the 3-way handshake resolve the problem of a loss of the initial CSNP? I see how the probability is reduced by handling the restart case. But over Frame Relay, for example, the first CSNP could be dropped without a restart. Is this covered by the procedure? If not, a timer could be added forcing a circuit restart if the CSNP is not received within a reasonable time. Also, if the first CSNP is lost, I would expect it to take up to 20 minutes for all systems to regenerate their LSPs, causing them to be flooded throughout the area and correcting the problem (not 18 hours). How did you come up with 18 hours? Thanks, Jeff ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From jjl@one.com Tue, 30 May 2000 14:16:46 -0400 Date: Tue, 30 May 2000 14:16:46 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] Doubt on IS-IS In addition to resolving the tie for Designated IS, the SNPA address in the LAN IIH is used to govern the adjacency transition from "initializing" to "up". You don't transition the adjacency for a neigboring IS to "up" until you see your MAC address in the neighbor's IIH (in the Intermediate System Neighbors option). Note that if your IS has multiple LAN interfaces on the same LAN, you will have multiple adjacencies for each neighbor IS, and each adjacency's state is independently controlled by the presence of its MAC address in the neighbor's IIH. Concerning implementation issues, most UNIX systems, including Solaris and AIX, support DLPI (Data Link Provider Interface), a STREAMS-based interface to the data link layer. This interface provides all necessary link and MAC layer addressing information. At 10:52 AM 5/27/00 +0530, SelvarajR wrote: >Except resolving tie does the SNPA is useful for any other purpose that >can't be done using System ID. >Also for breaking Tie, if there are two string(or value) that can be >compared then that's enough. >But those string(or value) necessarily not be the SNPA. > >In case of Integrated ISIS while the protocol runs over IP , I feel it is >little bit inefficient to get the MAC address from the Ethernet header. > > >Pls clarify if wrong. > >SELVA > >-----Original Message----- >From: DAUVERGNE Emmanuel FTRD/DAC/ISS >[SMTP:emmanuel.dauvergne@rd.francetelecom.fr] >Sent: Friday, May 26, 2000 9:42 PM >To: Vani Sree K >Cc: isis-wg@external.juniper.net >Subject: RE: [Isis-wg] Doubt on IS-IS > >...and this MAC address (SNPA) is used in the DIS election : (if no >priority >imposed) choose the highest one. > >Regards, >Manu > >-----Message d'origine----- >De: Jeff Learman [mailto:jjl@one.com] >Date: vendredi 26 mai 2000 17:38 >A: Vani Sree K >Cc: isis-wg@external.juniper.net >Objet: Re: [Isis-wg] Doubt on IS-IS > > > >Vani, > >While it is true that a LAN IIH carries a system ID, >the Intermediate System Neighbors option in a LAN IIH >carries the MAC address of the neighbor, not the system >ID. The MAC address of the neighbor is obtained from >the Ethernet header of the IIH received from the neighbor. >See ISO 10589:1992 Section 9.5, Intermediate System Neighbours, >on page 50. > >Regards, >Jeff > >Vani Sree K wrote: > >> Hi, >> >> In the Intermediate system Neighbors option of LAN Hello, the code value >> carries the 6 Octet Mac Address. (10589, 1992) >> My doubt is whether it is the Mac Address of the interface from which the >> Hello is sent or System Id of the Intermediate system. (Assuming one of >the >> Mac address is system Id). >> (In one of the Cisco document of IS-IS, it has been stated that the >> "SystemID is usually the MAC identifier of an interface on the device. >The >> IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has >> been heard within the last Hold time..") >> >> While creating new adjacencies, the NeigbourSNPA Address is set to the >MAC >> source address of the PDU. >> It means, the source MAC address is got from the Ethernet header.? >> >> Please correct me. >> >> Thanks >> -vani >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg > >____________________________________________________________________ > > Jeff Learman Internet: jjl@one.com > Engineering Manager Voice: (734)-975-7323 > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > 2725 South Industrial Pkwy, Suite 100 > Ann Arbor, MI 48104 USA >____________________________________________________________________ > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg >Attachment Converted: "c:\eudora\attach\RE [Isis-wg] Doubt on IS-IS" > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From henk@Procket.com Tue, 30 May 2000 20:36:06 +0200 (MEST) Date: Tue, 30 May 2000 20:36:06 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] draft-ietf-isis-3way-02.txt questions > Also, if the first CSNP is lost, I would expect it to take up to It should be noted that in addition to sending a CSNP, you must also set the SRM bit for this interface on all LSPs. If the CSNP from your neighbor does arrive, you can probably unset the SRM bits for lots of LSPs. If the CSNP from your neighbor is dropped, you end up sending all LSPs to your neighbor. That is gonna take more resources than strictly needed, but at least you are sure that the LSPDBs are synced quickly. > 20 minutes for all systems to regenerate their LSPs, causing them > to be flooded throughout the area and correcting the problem > (not 18 hours). How did you come up with 18 hours? The Remaininglifetime in the LSPs is 2 bytes. So in theory you could set the Remaininglifetime of a new LSP to 65535 seconds. If you adhere strictly to 10589, such an LSP should be considered to be corrupted. However, IMHO there is no need to be so restrictive. Some implementations will work fine with Remaininglifetimes larger than 20 minutes. Some implementations will even allow you to configure the router to set the Remaininglifetime higher than 20 minutes on new LSPs. This helps to bring down the "background flooding noise". 65535 seconds is 18.7 hours. Voila .... Henk. From prz@net4u.ch Wed, 31 May 2000 06:03:18 +0200 (MEST) Date: Wed, 31 May 2000 06:03:18 +0200 (MEST) From: Tony Przygienda prz@net4u.ch Subject: [Isis-wg] Agenda for Pittsburgh ... it's time to start to gather the agenda (beside the last calls and new draft versions) for Pittsburgh. Requests for slots pls to me or Tony Li -- tony From henk@Procket.com Fri, 26 May 2000 18:46:27 +0200 (MEST) Date: Fri, 26 May 2000 18:46:27 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] IDRPI field > Henk, > > I posed a question regarding this a while back. As you know, RFC1195 > indicates that the IDRPI field could be used for adminstrative tagging, a la > OSPF admin tags when the type is set to 1, or an External AS LSA (LSA 6) for > a type 2. Because TLV 131 is not well documented, different people can use it for different things. And if their technology gets deployed, the customers run into interoperability problems. > From an operational perspective, this would be useful additional > information that could aid in things like redistribution filtering. I agree it can be useful to have that kind of information available in the protocol. I'm not sure TLV 131 is the right place to do that. E.g. as far as I can see, TLV 131 stands on itself inside an LSP, and is not associated with any IP prefixes. How would you want to associate TLV 131 with particular IP prefixes ? By looking at the ordering of the TLVs inside an LSP ? For the obvious reasons, that doesn't seem a good idea to me. Can you let us know if you have a better idea about how to do that ? BTW, I tried to answer the question whether TLV 131 was deployed in the real world. I did not want to touch the subject of what it could be used for. That is another discussion. > Given all the TE work being done to extend the protocol, it should > be a relatively painless addition to the next rev. Agreed. However, if you look at the traffic-eng draft, you see there is new TLV for IP prefixes, TLV 135. Besides having wider metrics, this new TLV also has the capability to store sub-TLVs associated with an IP prefix. We designed to have these sub-TLVs to store TE info. But also other useful info can be stored there, like redistribution information. Feel free to implement a solution and write a draft about it. Yeah, yeah, yeah, I know I'm supposed to submit the next version of draft-draft-ietf-isis-traffic-0x.txt. :-) RSN ........ Henk. From bboulton@nexabit.com Wed, 31 May 2000 10:22:39 -0400 Date: Wed, 31 May 2000 10:22:39 -0400 From: Bryan Boulton bboulton@nexabit.com Subject: [Isis-wg] IDRPI field > Agreed. > However, if you look at the traffic-eng draft, you see there is new > TLV for IP prefixes, TLV 135. Besides having wider metrics, this > new TLV also has the capability to store sub-TLVs associated with an > IP prefix. We designed to have these sub-TLVs to store TE info. > But also other useful info can be stored there, like redistribution > information. Feel free to implement a solution and write a draft > about it. > Are these sub-TLVs defined anywhere? I notice the traffic-eng draft describes some for the extended IS reachability TLV (22) but not TLV 135. Thanks, -Bryan Boulton -Lucent Technologies From chopps@djinesys.com Fri, 26 May 2000 14:25:01 -0400 Date: Fri, 26 May 2000 14:25:01 -0400 From: Christian E. Hopps chopps@djinesys.com Subject: [Isis-wg] IDRPI field On Wed, May 24, 2000 at 03:53:46PM +0200, Henk Smit wrote: > > I have never seen it in any LSPs. > I don't know of any vendor that has implemented this. > In fact, I'm not even sure I know that TVL 131 is supposed to do. ;-) I'm not sure but I suspect this is somehow related to RC1745. However, RFC1745 uses other bits in the 32 bit ospf tag field that aren't available with the TLV131 type 2 description. If people want to implement RFC1745 I would think the new TE TLV (using a sub-TLV) would be a better way to do it. Chris. From chopps@djinesys.com Fri, 26 May 2000 14:36:29 -0400 Date: Fri, 26 May 2000 14:36:29 -0400 From: Christian E. Hopps chopps@djinesys.com Subject: [Isis-wg] draft-ietf-isis-traffic Is this draft (draft-ietf-isis-traffic) going to be reissued? It appears to have expired. Thanks, Chris. From prz@siara.com Fri, 26 May 2000 23:17:30 -0700 Date: Fri, 26 May 2000 23:17:30 -0700 From: Tony Przygienda prz@siara.com Subject: [Isis-wg] Doubt on IS-IS Jorge wrote: > I also agree with most of what Mr/Miss SELVA say . for actually now integrated Is-Is communication with IP layer only through Raw socket API , can somebody tell me how i can get the Ethernet header from raw socket with the condition that i won't encapsulate Is-Is packet with Ethernet header myself ( And also i can't make assumption that another implementation for integrated is-is will encapsulate Is-Is packet with Ethernet header in raw socket ) . look @ the ISIS over IPv4 draft ... thanks -- tony From henk@Procket.com Wed, 31 May 2000 17:52:26 +0200 (MEST) Date: Wed, 31 May 2000 17:52:26 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] IDRPI field > > However, if you look at the traffic-eng draft, you see there is new > > TLV for IP prefixes, TLV 135. Besides having wider metrics, this > > new TLV also has the capability to store sub-TLVs associated with an > > IP prefix. We designed to have these sub-TLVs to store TE info. > > But also other useful info can be stored there, like redistribution > > information. Feel free to implement a solution and write a draft > > about it. > > > Are these sub-TLVs defined anywhere? I notice the traffic-eng draft > describes some for the extended IS reachability TLV (22) but not > TLV 135. No, none have been described yet. Henk. From rhan@ibnets.com Wed, 31 May 2000 16:14:02 +0000 Date: Wed, 31 May 2000 16:14:02 +0000 From: Rick Han rhan@ibnets.com Subject: [Isis-wg] question on MTU Hi, iso10589 (8.2.3 (c)) says that IIH should be padded (at least for the first one) to the maxsize-1. This is to make sure that allISs in the domain use the same MTU. Does this mean that MTU check is part of HELLO checking before further processing the PDU? My understanding is that there will be no adjacency established if an IS uses different MTU as other ISs are configured. Is this correct? It seems Cisco allows adjacency setup even the two routers configured different MTU, why is that? Thanks Rick -- Rick Han Iron Bridge Networks, Inc. rhan@ibnets.com (781)372-8180 From jjl@one.com Wed, 31 May 2000 16:56:26 -0400 Date: Wed, 31 May 2000 16:56:26 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] question on MTU Remember that ISO 10598 requires point-to-point links to be reliable, so that failure to deliver an IS-IS PDU would cause the link to go down. Note that 8.2.2 does not require the IS to check the size of the received IIH. I think the idea was to make sure that whatever your idea of the MTU size is, that you can transmit a packet of that size without worrying about it being dropped by the link layer. If you're transmitting IIHs that are too large to be received at the other end, your data-link connection will go down and the adjacency will never come up. But this only works if the link is reliable (that is, if the link goes down if it can't deliver a packet). Since Integrated IS-IS is usually used over unreliable links (ones where failure to deliver doesn't cause anything special), the guarantee that you can actually deliver a packet of what you think is the maximum size doesn't work any more. On the other hand, isn't MTU size negotiation handled by LCP/NCP? If IS-IS is run over PPP with MTU size negotiation, this IS-IS guarantee may no longer be important. Regards, Jeff At 04:14 PM 5/31/00 +0000, Rick Han wrote: >Hi, iso10589 (8.2.3 (c)) says that IIH should be padded (at least for the >first one) to the maxsize-1. This is to make sure that allISs in the domain >use the same MTU. Does this mean that MTU check is part of HELLO checking >before further processing the PDU? My understanding is that there will be >no adjacency established if an IS uses different MTU as other ISs are >configured. Is this correct? It seems Cisco allows adjacency setup even the >two routers configured different MTU, why is that? > >Thanks > >Rick >-- >Rick Han >Iron Bridge Networks, Inc. >rhan@ibnets.com >(781)372-8180 > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From jparker@nexabit.com Wed, 31 May 2000 17:10:54 -0400 Date: Wed, 31 May 2000 17:10:54 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] question on MTU > I think the idea was to make sure that whatever your idea of > the MTU size is, that you can transmit a packet of that size > without worrying about it being dropped by the link layer. > If you're transmitting IIHs that are too large to be received > at the other end, your data-link connection will go down and > the adjacency will never come up. But this only works if the > link is reliable (that is, if the link goes down if it can't > deliver a packet). > > Jeff Learman Internet: jjl@one.com You could send padded packets on pt2pt until the adjacency comes up. This makes no assumptions about the reliability of the link layer. - jeff parker - Lucent Technology From jjl@one.com Wed, 31 May 2000 17:29:42 -0400 Date: Wed, 31 May 2000 17:29:42 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] question on MTU Jeff Good point -- that would solve the problem. This could be added to the 3-way handshake RFC. It might be unnecessary, though, when operating over links where the MTU is negotiated end-to-end and IS-IS is using the result of that negotiation. Unfortunately, it wouldn't guarantee that you can receive big packets from the other end, which might not implement the new requirement. To do that, you'd have to check the size of the neighbor's IIH and only accept it if it looks like it's padded to a maximum size, during initialization phase. (But how would you do that? Presence of any padding option over some given size?) As you probably know, the check is important to make sure that any LSP you send over the link will actually make it. It is not necessary that the MTU size be equal in both directions, so it wouldn't necessarily be a good idea to require the received IIH to match your own MTU size. While I suppose it's uncommon to have asymmetrical MTU sizes, it might be useful in certain situations, like ADSL. To add such a check would be to add a new restriction on the use of IS-IS. Regards, Jeff At 05:10 PM 5/31/00 -0400, you wrote: >> I think the idea was to make sure that whatever your idea of >> the MTU size is, that you can transmit a packet of that size >> without worrying about it being dropped by the link layer. >> If you're transmitting IIHs that are too large to be received >> at the other end, your data-link connection will go down and >> the adjacency will never come up. But this only works if the >> link is reliable (that is, if the link goes down if it can't >> deliver a packet). >> >> Jeff Learman Internet: jjl@one.com > >You could send padded packets on pt2pt until the adjacency comes up. >This makes no assumptions about the reliability of the link layer. > >- jeff parker >- Lucent Technology ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From jjl@one.com Wed, 31 May 2000 17:54:24 -0400 Date: Wed, 31 May 2000 17:54:24 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] question on MTU This is a big, bad, nasty problem. This case is NOT handled by the protocol -- you aren't told what to do, and no matter what you do, it's not good. It was discussed in detail at the SONET Interoperability Forum, where we have the unlucky situation that the SONET management channel (normally unused by you IP folks) is specified to use an MTU size of 512 bytes, but the rest of the natural world uses a size of 1500. Fortunately, there is a solution, which can be found in ftp://ftp.atis.org/pub/sif/arch/ar820317.doc I believe that this was submitted to ISO as a defect report or technical corrigendum, but I don't know the current status. Perhaps Les Guinsberg or Tom Rutt could fill us in, if they are listening. Regards, Jeff At 09:52 PM 5/31/00 +0000, Rick Han wrote: >Suppose we have following setup: > router1 (R1) --- router2 (R2)----- router3 (R3) > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and R3 is 2k. If R1 >sends a HELLO padded to 4k and R2 accepts it. What does R2 do to the >following LSPs from R1, if they are in 4k packets? How does R2 propagate >them to R3? I guess that's why the adjacency between R1 and R2 is supposed >to be droped at the first place. But if we accept the neighbor, then what >if R1 sends two LSPs, one in 1.5k and another in 3k? The smaller LSP can go >through to R3 but the bigger one get droped at the link. Now we have >un-synchronized database over the domain. > >Rick > >Jeff Learman wrote: >> >> Jeff >> >> Good point -- that would solve the problem. This could be added >> to the 3-way handshake RFC. It might be unnecessary, though, when >> operating over links where the MTU is negotiated end-to-end >> and IS-IS is using the result of that negotiation. >> >> Unfortunately, it wouldn't guarantee that you can receive big >> packets from the other end, which might not implement the new >> requirement. To do that, you'd have to check the size of the >> neighbor's IIH and only accept it if it looks like it's padded >> to a maximum size, during initialization phase. (But how would >> you do that? Presence of any padding option over some given >> size?) >> >> As you probably know, the check is important to make sure that >> any LSP you send over the link will actually make it. It is not >> necessary that the MTU size be equal in both directions, so >> it wouldn't necessarily be a good idea to require the received >> IIH to match your own MTU size. While I suppose it's uncommon >> to have asymmetrical MTU sizes, it might be useful in certain >> situations, like ADSL. To add such a check would be to add a >> new restriction on the use of IS-IS. >> >> Regards, >> Jeff >> >> At 05:10 PM 5/31/00 -0400, you wrote: >> >> I think the idea was to make sure that whatever your idea of >> >> the MTU size is, that you can transmit a packet of that size >> >> without worrying about it being dropped by the link layer. >> >> If you're transmitting IIHs that are too large to be received >> >> at the other end, your data-link connection will go down and >> >> the adjacency will never come up. But this only works if the >> >> link is reliable (that is, if the link goes down if it can't >> >> deliver a packet). >> >> >> >> Jeff Learman Internet: jjl@one.com >> > >> >You could send padded packets on pt2pt until the adjacency comes up. >> >This makes no assumptions about the reliability of the link layer. >> > >> >- jeff parker >> >- Lucent Technology >> >> ____________________________________________________________________ >> >> Jeff Learman Internet: jjl@one.com >> Engineering Manager Voice: (734)-975-7323 >> ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 >> 2725 South Industrial Pkwy, Suite 100 >> Ann Arbor, MI 48104 USA >> ____________________________________________________________________ >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg > >-- >Rick Han >Iron Bridge Networks, Inc. >rhan@ibnets.com >(781)372-8180 > > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From jparker@nexabit.com Wed, 31 May 2000 18:01:39 -0400 Date: Wed, 31 May 2000 18:01:39 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] question on MTU I think section 8.2.3 of ISO 10589 specifies that you use the appropriate L1 or L2 BufferSize, rather than the interface MTU. - jeff parker - Lucent Technology > > This is a big, bad, nasty problem. This case is NOT handled by > the protocol -- you aren't told what to do, and no matter what you > do, it's not good. It was discussed in detail at the SONET > Interoperability Forum, where we have the unlucky situation that > the SONET management channel (normally unused by you IP folks) > is specified to use an MTU size of 512 bytes, but the rest of > the natural world uses a size of 1500. > > Fortunately, there is a solution, which can be found in > > ftp://ftp.atis.org/pub/sif/arch/ar820317.doc > > I believe that this was submitted to ISO as a defect report or > technical corrigendum, but I don't know the current status. > Perhaps Les Guinsberg or Tom Rutt could fill us in, if they > are listening. > > Regards, > Jeff > > At 09:52 PM 5/31/00 +0000, Rick Han wrote: > >Suppose we have following setup: > > router1 (R1) --- router2 (R2)----- router3 (R3) > > > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and > R3 is 2k. If R1 > >sends a HELLO padded to 4k and R2 accepts it. What does R2 do to the > >following LSPs from R1, if they are in 4k packets? How does > R2 propagate > >them to R3? I guess that's why the adjacency between R1 and > R2 is supposed > >to be droped at the first place. But if we accept the > neighbor, then what > >if R1 sends two LSPs, one in 1.5k and another in 3k? The > smaller LSP can go > >through to R3 but the bigger one get droped at the link. Now we have > >un-synchronized database over the domain. > > > >Rick > > > >Jeff Learman wrote: > >> > >> Jeff > >> > >> Good point -- that would solve the problem. This could be added > >> to the 3-way handshake RFC. It might be unnecessary, though, when > >> operating over links where the MTU is negotiated end-to-end > >> and IS-IS is using the result of that negotiation. > >> > >> Unfortunately, it wouldn't guarantee that you can receive big > >> packets from the other end, which might not implement the new > >> requirement. To do that, you'd have to check the size of the > >> neighbor's IIH and only accept it if it looks like it's padded > >> to a maximum size, during initialization phase. (But how would > >> you do that? Presence of any padding option over some given > >> size?) > >> > >> As you probably know, the check is important to make sure that > >> any LSP you send over the link will actually make it. It is not > >> necessary that the MTU size be equal in both directions, so > >> it wouldn't necessarily be a good idea to require the received > >> IIH to match your own MTU size. While I suppose it's uncommon > >> to have asymmetrical MTU sizes, it might be useful in certain > >> situations, like ADSL. To add such a check would be to add a > >> new restriction on the use of IS-IS. > >> > >> Regards, > >> Jeff > >> > >> At 05:10 PM 5/31/00 -0400, you wrote: > >> >> I think the idea was to make sure that whatever your idea of > >> >> the MTU size is, that you can transmit a packet of that size > >> >> without worrying about it being dropped by the link layer. > >> >> If you're transmitting IIHs that are too large to be received > >> >> at the other end, your data-link connection will go down and > >> >> the adjacency will never come up. But this only works if the > >> >> link is reliable (that is, if the link goes down if it can't > >> >> deliver a packet). > >> >> > >> >> Jeff Learman Internet: > jjl@one.com > >> > > >> >You could send padded packets on pt2pt until the > adjacency comes up. > >> >This makes no assumptions about the reliability of the link layer. > >> > > >> >- jeff parker > >> >- Lucent Technology > >> > >> > ____________________________________________________________________ > >> > >> Jeff Learman Internet: jjl@one.com > >> Engineering Manager Voice: (734)-975-7323 > >> ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > >> 2725 South Industrial Pkwy, Suite 100 > >> Ann Arbor, MI 48104 USA > >> > ____________________________________________________________________ > >> > >> _______________________________________________ > >> Isis-wg mailing list - Isis-wg@external.juniper.net > >> http://external.juniper.net/mailman/listinfo/isis-wg > > > >-- > >Rick Han > >Iron Bridge Networks, Inc. > >rhan@ibnets.com > >(781)372-8180 > > > > > ____________________________________________________________________ > > Jeff Learman Internet: jjl@one.com > Engineering Manager Voice: (734)-975-7323 > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > 2725 South Industrial Pkwy, Suite 100 > Ann Arbor, MI 48104 USA > ____________________________________________________________________ > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From mbartell@cisco.com Wed, 31 May 2000 17:25:35 -0500 Date: Wed, 31 May 2000 17:25:35 -0500 From: Micah Bartell mbartell@cisco.com Subject: [Isis-wg] question on MTU Actually the IIH should be at least maxsize-1 octets. maxsize is the maximum of the three following values: 1. dataLinkBlocksize 2. originatingL1LSPBufferSize 3. originatingL2LSPBufferSize The reason for using maxsize-1 is any padding added needs to be at least 2 octets. So if the PDU length is maxsize-1 you can't add 2 octets, requiring that to be a valid size also. /mpb At 06:01 PM 5/31/2000 -0400, Jeff Parker wrote: >I think section 8.2.3 of ISO 10589 specifies that you use the appropriate >L1 or L2 BufferSize, rather than the interface MTU. > >- jeff parker >- Lucent Technology > > > > This is a big, bad, nasty problem. This case is NOT handled by > > the protocol -- you aren't told what to do, and no matter what you > > do, it's not good. It was discussed in detail at the SONET > > Interoperability Forum, where we have the unlucky situation that > > the SONET management channel (normally unused by you IP folks) > > is specified to use an MTU size of 512 bytes, but the rest of > > the natural world uses a size of 1500. > > > > Fortunately, there is a solution, which can be found in > > > > ftp://ftp.atis.org/pub/sif/arch/ar820317.doc > > > > I believe that this was submitted to ISO as a defect report or > > technical corrigendum, but I don't know the current status. > > Perhaps Les Guinsberg or Tom Rutt could fill us in, if they > > are listening. > > > > Regards, > > Jeff > > > > At 09:52 PM 5/31/00 +0000, Rick Han wrote: > > >Suppose we have following setup: > > > router1 (R1) --- router2 (R2)----- router3 (R3) > > > > > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and > > R3 is 2k. If R1 > > >sends a HELLO padded to 4k and R2 accepts it. What does R2 do to the > > >following LSPs from R1, if they are in 4k packets? How does > > R2 propagate > > >them to R3? I guess that's why the adjacency between R1 and > > R2 is supposed > > >to be droped at the first place. But if we accept the > > neighbor, then what > > >if R1 sends two LSPs, one in 1.5k and another in 3k? The > > smaller LSP can go > > >through to R3 but the bigger one get droped at the link. Now we have > > >un-synchronized database over the domain. > > > > > >Rick > > > > > >Jeff Learman wrote: > > >> > > >> Jeff > > >> > > >> Good point -- that would solve the problem. This could be added > > >> to the 3-way handshake RFC. It might be unnecessary, though, when > > >> operating over links where the MTU is negotiated end-to-end > > >> and IS-IS is using the result of that negotiation. > > >> > > >> Unfortunately, it wouldn't guarantee that you can receive big > > >> packets from the other end, which might not implement the new > > >> requirement. To do that, you'd have to check the size of the > > >> neighbor's IIH and only accept it if it looks like it's padded > > >> to a maximum size, during initialization phase. (But how would > > >> you do that? Presence of any padding option over some given > > >> size?) > > >> > > >> As you probably know, the check is important to make sure that > > >> any LSP you send over the link will actually make it. It is not > > >> necessary that the MTU size be equal in both directions, so > > >> it wouldn't necessarily be a good idea to require the received > > >> IIH to match your own MTU size. While I suppose it's uncommon > > >> to have asymmetrical MTU sizes, it might be useful in certain > > >> situations, like ADSL. To add such a check would be to add a > > >> new restriction on the use of IS-IS. > > >> > > >> Regards, > > >> Jeff > > >> > > >> At 05:10 PM 5/31/00 -0400, you wrote: > > >> >> I think the idea was to make sure that whatever your idea of > > >> >> the MTU size is, that you can transmit a packet of that size > > >> >> without worrying about it being dropped by the link layer. > > >> >> If you're transmitting IIHs that are too large to be received > > >> >> at the other end, your data-link connection will go down and > > >> >> the adjacency will never come up. But this only works if the > > >> >> link is reliable (that is, if the link goes down if it can't > > >> >> deliver a packet). > > >> >> > > >> >> Jeff Learman Internet: > > jjl@one.com > > >> > > > >> >You could send padded packets on pt2pt until the > > adjacency comes up. > > >> >This makes no assumptions about the reliability of the link layer. > > >> > > > >> >- jeff parker > > >> >- Lucent Technology > > >> > > >> > > ____________________________________________________________________ > > >> > > >> Jeff Learman Internet: jjl@one.com > > >> Engineering Manager Voice: (734)-975-7323 > > >> ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > > >> 2725 South Industrial Pkwy, Suite 100 > > >> Ann Arbor, MI 48104 USA > > >> > > ____________________________________________________________________ > > >> > > >> _______________________________________________ > > >> Isis-wg mailing list - Isis-wg@external.juniper.net > > >> http://external.juniper.net/mailman/listinfo/isis-wg > > > > > >-- > > >Rick Han > > >Iron Bridge Networks, Inc. > > >rhan@ibnets.com > > >(781)372-8180 > > > > > > > > ____________________________________________________________________ > > > > Jeff Learman Internet: jjl@one.com > > Engineering Manager Voice: (734)-975-7323 > > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > > 2725 South Industrial Pkwy, Suite 100 > > Ann Arbor, MI 48104 USA > > ____________________________________________________________________ > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg -- Micah Bartell, CCIE #5069 mbartell@cisco.com Network Consulting Engineer, NSA Phone: 972.364.8829 Cisco Systems, Inc Fax: 972.364.8829 -- The Network Works, No Excuses From ginsberg@pluris.com Wed, 31 May 2000 16:04:23 -0700 Date: Wed, 31 May 2000 16:04:23 -0700 From: Les Ginsberg ginsberg@pluris.com Subject: [Isis-wg] question on MTU The problem that Rick refers to is not quite as bad as his example suggests. "originatingLxBufferSize" is limited to values between 512-1492. So long as the MTU of any link over which IS-IS operates is >= 1492 there should never be a problem propagating LSPs due to PDU size issues. This issue, as Jeff remembers all too well, actually occurs only when some of the links used for IS-IS have an MTU smaller than 1492 - as is the case with SONET DCC. The solution referred to below does not eliminate the problem, but it provides the protocol with the tools to detect and report the problem, hopefully before it ever occurs. The proposal is part of the revised agenda the US has submitted to ISO for producing a new draft revision of ISO 10589:1992. Inclusion of this proposal is of course subject to review by the international community - as of this date the revised draft is not yet available and the international review process has not yet begun. Les > -----Original Message----- > From: Jeff Learman [mailto:jjl@one.com] > Sent: Wednesday, May 31, 2000 2:54 PM > To: rhan@ibnets.com > Cc: Jeff Parker; isis-wg@external.juniper.net > Subject: Re: [Isis-wg] question on MTU > > > > This is a big, bad, nasty problem. This case is NOT handled by > the protocol -- you aren't told what to do, and no matter what you > do, it's not good. It was discussed in detail at the SONET > Interoperability Forum, where we have the unlucky situation that > the SONET management channel (normally unused by you IP folks) > is specified to use an MTU size of 512 bytes, but the rest of > the natural world uses a size of 1500. > > Fortunately, there is a solution, which can be found in > > ftp://ftp.atis.org/pub/sif/arch/ar820317.doc > > I believe that this was submitted to ISO as a defect report or > technical corrigendum, but I don't know the current status. > Perhaps Les Guinsberg or Tom Rutt could fill us in, if they > are listening. > > Regards, > Jeff > > At 09:52 PM 5/31/00 +0000, Rick Han wrote: > >Suppose we have following setup: > > router1 (R1) --- router2 (R2)----- router3 (R3) > > > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and > R3 is 2k. If R1 > >sends a HELLO padded to 4k and R2 accepts it. What does R2 do to the > >following LSPs from R1, if they are in 4k packets? How does > R2 propagate > >them to R3? I guess that's why the adjacency between R1 and > R2 is supposed > >to be droped at the first place. But if we accept the > neighbor, then what > >if R1 sends two LSPs, one in 1.5k and another in 3k? The > smaller LSP can go > >through to R3 but the bigger one get droped at the link. Now we have > >un-synchronized database over the domain. > > > >Rick > > > >Jeff Learman wrote: > >> > >> Jeff > >> > >> Good point -- that would solve the problem. This could be added > >> to the 3-way handshake RFC. It might be unnecessary, though, when > >> operating over links where the MTU is negotiated end-to-end > >> and IS-IS is using the result of that negotiation. > >> > >> Unfortunately, it wouldn't guarantee that you can receive big > >> packets from the other end, which might not implement the new > >> requirement. To do that, you'd have to check the size of the > >> neighbor's IIH and only accept it if it looks like it's padded > >> to a maximum size, during initialization phase. (But how would > >> you do that? Presence of any padding option over some given > >> size?) > >> > >> As you probably know, the check is important to make sure that > >> any LSP you send over the link will actually make it. It is not > >> necessary that the MTU size be equal in both directions, so > >> it wouldn't necessarily be a good idea to require the received > >> IIH to match your own MTU size. While I suppose it's uncommon > >> to have asymmetrical MTU sizes, it might be useful in certain > >> situations, like ADSL. To add such a check would be to add a > >> new restriction on the use of IS-IS. > >> > >> Regards, > >> Jeff > >> > >> At 05:10 PM 5/31/00 -0400, you wrote: > >> >> I think the idea was to make sure that whatever your idea of > >> >> the MTU size is, that you can transmit a packet of that size > >> >> without worrying about it being dropped by the link layer. > >> >> If you're transmitting IIHs that are too large to be received > >> >> at the other end, your data-link connection will go down and > >> >> the adjacency will never come up. But this only works if the > >> >> link is reliable (that is, if the link goes down if it can't > >> >> deliver a packet). > >> >> > >> >> Jeff Learman Internet: > jjl@one.com > >> > > >> >You could send padded packets on pt2pt until the > adjacency comes up. > >> >This makes no assumptions about the reliability of the link layer. > >> > > >> >- jeff parker > >> >- Lucent Technology > >> > >> > ____________________________________________________________________ > >> > >> Jeff Learman Internet: jjl@one.com > >> Engineering Manager Voice: (734)-975-7323 > >> ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > >> 2725 South Industrial Pkwy, Suite 100 > >> Ann Arbor, MI 48104 USA > >> > ____________________________________________________________________ > >> > >> _______________________________________________ > >> Isis-wg mailing list - Isis-wg@external.juniper.net > >> http://external.juniper.net/mailman/listinfo/isis-wg > > > >-- > >Rick Han > >Iron Bridge Networks, Inc. > >rhan@ibnets.com > >(781)372-8180 > > > > > ____________________________________________________________________ > > Jeff Learman Internet: jjl@one.com > Engineering Manager Voice: (734)-975-7323 > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > 2725 South Industrial Pkwy, Suite 100 > Ann Arbor, MI 48104 USA > ____________________________________________________________________ > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From dkatz@juniper.net Wed, 31 May 2000 16:21:45 -0700 (PDT) Date: Wed, 31 May 2000 16:21:45 -0700 (PDT) From: Dave Katz dkatz@juniper.net Subject: [Isis-wg] question on MTU LSPs have an architecturally-defined maximum size (1492 if memory serves) because, unlike in OSPF, they are not regenerated hop-by-hop so they must be small enough so that they are guaranteed to be able to cross *any* media in the network. Trying to use variable sizes gets very interesting. NLSP was operationally problematic due to this (try setting the MTU to 1500 and then accidentally using SNAP encapsulation on some links--whee!) The "big, bad, nasty problem" is due to the media of choice in the SONET application having an unfortunately small MTU, and the problem is confined entirely to such media (I think ARCnet is about the only other one; see earlier comment about NLSP). It in particular is *not* any sort of problem when dealing with links having MTUs *larger* than 1492. Even if the link MTU were negotiated, it would *not* have any use in the protocol per se (other than complaining if it were too small). OSPF has a hook added after the original spec came out which won't allow neighbors to become adjacent unless their MTUs agree--this is more important because LSUpdates are built hop-by-hop and so can become MTU-sized if the implementor so desires, but it also leads to regular customer service calls asking "why are my neighbors stuck in EXSTART state." IIH padding was intended to catch badly misconfigured boxes, and to a lesser extent size-dependent errors (though the padded ones were only supposed to be sent on point-to-point links only briefly, and these are the only links that usually ever show any size dependency). IIH padding has, in practice, been largely deprecated because it is essentially useless and creates lots of unnecessary customer service calls to vendors ("Why is my adjacency stuck in Init state?"). Incoming padding should be ignored, period. --Dave X-Sender: jjl@mail.one.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 31 May 2000 17:54:24 -0400 From: Jeff Learman Cc: Jeff Parker , isis-wg@external.juniper.net References: <3.0.1.32.20000531172942.0131f370@mail.one.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net This is a big, bad, nasty problem. This case is NOT handled by the protocol -- you aren't told what to do, and no matter what you do, it's not good. It was discussed in detail at the SONET Interoperability Forum, where we have the unlucky situation that the SONET management channel (normally unused by you IP folks) is specified to use an MTU size of 512 bytes, but the rest of the natural world uses a size of 1500. Fortunately, there is a solution, which can be found in ftp://ftp.atis.org/pub/sif/arch/ar820317.doc I believe that this was submitted to ISO as a defect report or technical corrigendum, but I don't know the current status. Perhaps Les Guinsberg or Tom Rutt could fill us in, if they are listening. Regards, Jeff At 09:52 PM 5/31/00 +0000, Rick Han wrote: >Suppose we have following setup: > router1 (R1) --- router2 (R2)----- router3 (R3) > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and R3 is 2k. If R1 >sends a HELLO padded to 4k and R2 accepts it. What does R2 do to the >following LSPs from R1, if they are in 4k packets? How does R2 propagate >them to R3? I guess that's why the adjacency between R1 and R2 is supposed >to be droped at the first place. But if we accept the neighbor, then what >if R1 sends two LSPs, one in 1.5k and another in 3k? The smaller LSP can go >through to R3 but the bigger one get droped at the link. Now we have >un-synchronized database over the domain. > >Rick > >Jeff Learman wrote: >> >> Jeff >> >> Good point -- that would solve the problem. This could be added >> to the 3-way handshake RFC. It might be unnecessary, though, when >> operating over links where the MTU is negotiated end-to-end >> and IS-IS is using the result of that negotiation. >> >> Unfortunately, it wouldn't guarantee that you can receive big >> packets from the other end, which might not implement the new >> requirement. To do that, you'd have to check the size of the >> neighbor's IIH and only accept it if it looks like it's padded >> to a maximum size, during initialization phase. (But how would >> you do that? Presence of any padding option over some given >> size?) >> >> As you probably know, the check is important to make sure that >> any LSP you send over the link will actually make it. It is not >> necessary that the MTU size be equal in both directions, so >> it wouldn't necessarily be a good idea to require the received >> IIH to match your own MTU size. While I suppose it's uncommon >> to have asymmetrical MTU sizes, it might be useful in certain >> situations, like ADSL. To add such a check would be to add a >> new restriction on the use of IS-IS. >> >> Regards, >> Jeff >> >> At 05:10 PM 5/31/00 -0400, you wrote: >> >> I think the idea was to make sure that whatever your idea of >> >> the MTU size is, that you can transmit a packet of that size >> >> without worrying about it being dropped by the link layer. >> >> If you're transmitting IIHs that are too large to be received >> >> at the other end, your data-link connection will go down and >> >> the adjacency will never come up. But this only works if the >> >> link is reliable (that is, if the link goes down if it can't >> >> deliver a packet). >> >> >> >> Jeff Learman Internet: jjl@one.com >> > >> >You could send padded packets on pt2pt until the adjacency comes up. >> >This makes no assumptions about the reliability of the link layer. >> > >> >- jeff parker >> >- Lucent Technology >> >> ____________________________________________________________________ >> >> Jeff Learman Internet: jjl@one.com >> Engineering Manager Voice: (734)-975-7323 >> ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 >> 2725 South Industrial Pkwy, Suite 100 >> Ann Arbor, MI 48104 USA >> ____________________________________________________________________ >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg > >-- >Rick Han >Iron Bridge Networks, Inc. >rhan@ibnets.com >(781)372-8180 > > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From rsaluja@nortelnetworks.com Wed, 31 May 2000 18:58:16 -0400 Date: Wed, 31 May 2000 18:58:16 -0400 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] question on MTU IIH maximum size and LSP maximum size are two different things. IIH size should be at least equal to the maximum(dataLinkBlocksize (MTU),LSPBuffersize) -1 according to the spec. The LSP packet maximum size has really a global significance in an ISIS area and it should be set consistently by system management. LSP packets have to travel throughout the area. Also note that dataLinkBlocksize should always be greater than or equal to the maximum of the LSPBufferSize. So IMHO IIH size is nothing but dataLinkBlocksize - 1. Regards, Rajesh Micah Bartell wrote: > > Actually the IIH should be at least maxsize-1 octets. maxsize is the maximum of the three following values: > > 1. dataLinkBlocksize > 2. originatingL1LSPBufferSize > 3. originatingL2LSPBufferSize > > The reason for using maxsize-1 is any padding added needs to be at least 2 octets. So if the PDU length is maxsize-1 you can't add 2 octets, requiring that to be a valid size also. > > /mpb > > At 06:01 PM 5/31/2000 -0400, Jeff Parker wrote: > >I think section 8.2.3 of ISO 10589 specifies that you use the appropriate > >L1 or L2 BufferSize, rather than the interface MTU. > > > >- jeff parker > >- Lucent Technology > > > > > > This is a big, bad, nasty problem. This case is NOT handled by > > > the protocol -- you aren't told what to do, and no matter what you > > > do, it's not good. It was discussed in detail at the SONET > > > Interoperability Forum, where we have the unlucky situation that > > > the SONET management channel (normally unused by you IP folks) > > > is specified to use an MTU size of 512 bytes, but the rest of > > > the natural world uses a size of 1500. > > > > > > Fortunately, there is a solution, which can be found in > > > > > > ftp://ftp.atis.org/pub/sif/arch/ar820317.doc > > > > > > I believe that this was submitted to ISO as a defect report or > > > technical corrigendum, but I don't know the current status. > > > Perhaps Les Guinsberg or Tom Rutt could fill us in, if they > > > are listening. > > > > > > Regards, > > > Jeff > > > > > > At 09:52 PM 5/31/00 +0000, Rick Han wrote: > > > >Suppose we have following setup: > > > > router1 (R1) --- router2 (R2)----- router3 (R3) > > > > > > > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and > > > R3 is 2k. If R1 > > > >sends a HELLO padded to 4k and R2 accepts it. What does R2 do to the > > > >following LSPs from R1, if they are in 4k packets? How does > > > R2 propagate > > > >them to R3? I guess that's why the adjacency between R1 and > > > R2 is supposed > > > >to be droped at the first place. But if we accept the > > > neighbor, then what > > > >if R1 sends two LSPs, one in 1.5k and another in 3k? The > > > smaller LSP can go > > > >through to R3 but the bigger one get droped at the link. Now we have > > > >un-synchronized database over the domain. > > > > > > > >Rick > > > > > > > >Jeff Learman wrote: > > > >> > > > >> Jeff > > > >> > > > >> Good point -- that would solve the problem. This could be added > > > >> to the 3-way handshake RFC. It might be unnecessary, though, when > > > >> operating over links where the MTU is negotiated end-to-end > > > >> and IS-IS is using the result of that negotiation. > > > >> > > > >> Unfortunately, it wouldn't guarantee that you can receive big > > > >> packets from the other end, which might not implement the new > > > >> requirement. To do that, you'd have to check the size of the > > > >> neighbor's IIH and only accept it if it looks like it's padded > > > >> to a maximum size, during initialization phase. (But how would > > > >> you do that? Presence of any padding option over some given > > > >> size?) > > > >> > > > >> As you probably know, the check is important to make sure that > > > >> any LSP you send over the link will actually make it. It is not > > > >> necessary that the MTU size be equal in both directions, so > > > >> it wouldn't necessarily be a good idea to require the received > > > >> IIH to match your own MTU size. While I suppose it's uncommon > > > >> to have asymmetrical MTU sizes, it might be useful in certain > > > >> situations, like ADSL. To add such a check would be to add a > > > >> new restriction on the use of IS-IS. > > > >> > > > >> Regards, > > > >> Jeff > > > >> > > > >> At 05:10 PM 5/31/00 -0400, you wrote: > > > >> >> I think the idea was to make sure that whatever your idea of > > > >> >> the MTU size is, that you can transmit a packet of that size > > > >> >> without worrying about it being dropped by the link layer. > > > >> >> If you're transmitting IIHs that are too large to be received > > > >> >> at the other end, your data-link connection will go down and > > > >> >> the adjacency will never come up. But this only works if the > > > >> >> link is reliable (that is, if the link goes down if it can't > > > >> >> deliver a packet). > > > >> >> > > > >> >> Jeff Learman Internet: > > > jjl@one.com > > > >> > > > > >> >You could send padded packets on pt2pt until the > > > adjacency comes up. > > > >> >This makes no assumptions about the reliability of the link layer. > > > >> > > > > >> >- jeff parker > > > >> >- Lucent Technology > > > >> > > > >> > > > ____________________________________________________________________ > > > >> > > > >> Jeff Learman Internet: jjl@one.com > > > >> Engineering Manager Voice: (734)-975-7323 > > > >> ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > > > >> 2725 South Industrial Pkwy, Suite 100 > > > >> Ann Arbor, MI 48104 USA > > > >> > > > ____________________________________________________________________ > > > >> > > > >> _______________________________________________ > > > >> Isis-wg mailing list - Isis-wg@external.juniper.net > > > >> http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > >-- > > > >Rick Han > > > >Iron Bridge Networks, Inc. > > > >rhan@ibnets.com > > > >(781)372-8180 > > > > > > > > > > > ____________________________________________________________________ > > > > > > Jeff Learman Internet: jjl@one.com > > > Engineering Manager Voice: (734)-975-7323 > > > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > > > 2725 South Industrial Pkwy, Suite 100 > > > Ann Arbor, MI 48104 USA > > > ____________________________________________________________________ > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > -- > Micah Bartell, CCIE #5069 mbartell@cisco.com > Network Consulting Engineer, NSA Phone: 972.364.8829 > Cisco Systems, Inc Fax: 972.364.8829 > -- > The Network Works, No Excuses > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From ginsberg@pluris.com Wed, 31 May 2000 17:14:14 -0700 Date: Wed, 31 May 2000 17:14:14 -0700 From: Les Ginsberg ginsberg@pluris.com Subject: [Isis-wg] question on MTU (At the risk of belaboring a point...) dataLinkBlockSize SHOULD always be >= originatingLxBufferSize. The point of sending a padded IIH which is the maximum of the bunch is precisely to detect those misconfigurations where this is not the case. So if dataLinkBlockSize is NOT large enough, the adjacency presumably will never come up. Therefore stating that "So IMHO IIH size is nothing but dataLinkBlocksize - 1." is denying the possibility of a misconfiguration. I believe the original text in ISO 10589 8.2.3c is better, even if it rarely comes into play. Of course, given the global significance of originatingLxLSPBufferSize, this still does not guarantee consistency throughout the area/domain - hence the problem that occurs in SONET environments. Les > -----Original Message----- > From: Rajesh Saluja [mailto:rsaluja@nortelnetworks.com] > Sent: Wednesday, May 31, 2000 3:58 PM > To: Micah Bartell > Cc: Jeff Parker; Jeff Learman; rhan@ibnets.com; > isis-wg@external.juniper.net > Subject: Re: [Isis-wg] question on MTU > > > IIH maximum size and LSP maximum size are two different > things. IIH size > should be at least equal to the maximum(dataLinkBlocksize > (MTU),LSPBuffersize) -1 according to the spec. > The LSP packet maximum size has really a global significance > in an ISIS > area and it should be set consistently by system management. > LSP packets > have to travel throughout the area. > > Also note that dataLinkBlocksize should always be greater > than or equal > to the maximum of the LSPBufferSize. So IMHO IIH size is nothing but > dataLinkBlocksize - 1. > > Regards, > Rajesh > > Micah Bartell wrote: > > > > Actually the IIH should be at least maxsize-1 octets. > maxsize is the maximum of the three following values: > > > > 1. dataLinkBlocksize > > 2. originatingL1LSPBufferSize > > 3. originatingL2LSPBufferSize > > > > The reason for using maxsize-1 is any padding added needs > to be at least 2 octets. So if the PDU length is maxsize-1 > you can't add 2 octets, requiring that to be a valid size also. > > > > /mpb > > > > At 06:01 PM 5/31/2000 -0400, Jeff Parker wrote: > > >I think section 8.2.3 of ISO 10589 specifies that you use > the appropriate > > >L1 or L2 BufferSize, rather than the interface MTU. > > > > > >- jeff parker > > >- Lucent Technology > > > > > > > > This is a big, bad, nasty problem. This case is NOT handled by > > > > the protocol -- you aren't told what to do, and no > matter what you > > > > do, it's not good. It was discussed in detail at the SONET > > > > Interoperability Forum, where we have the unlucky situation that > > > > the SONET management channel (normally unused by you IP folks) > > > > is specified to use an MTU size of 512 bytes, but the rest of > > > > the natural world uses a size of 1500. > > > > > > > > Fortunately, there is a solution, which can be found in > > > > > > > > ftp://ftp.atis.org/pub/sif/arch/ar820317.doc > > > > > > > > I believe that this was submitted to ISO as a defect report or > > > > technical corrigendum, but I don't know the current status. > > > > Perhaps Les Guinsberg or Tom Rutt could fill us in, if they > > > > are listening. > > > > > > > > Regards, > > > > Jeff > > > > > > > > At 09:52 PM 5/31/00 +0000, Rick Han wrote: > > > > >Suppose we have following setup: > > > > > router1 (R1) --- router2 (R2)----- router3 (R3) > > > > > > > > > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and > > > > R3 is 2k. If R1 > > > > >sends a HELLO padded to 4k and R2 accepts it. What > does R2 do to the > > > > >following LSPs from R1, if they are in 4k packets? How does > > > > R2 propagate > > > > >them to R3? I guess that's why the adjacency between R1 and > > > > R2 is supposed > > > > >to be droped at the first place. But if we accept the > > > > neighbor, then what > > > > >if R1 sends two LSPs, one in 1.5k and another in 3k? The > > > > smaller LSP can go > > > > >through to R3 but the bigger one get droped at the > link. Now we have > > > > >un-synchronized database over the domain. > > > > > > > > > >Rick > > > > > > > > > >Jeff Learman wrote: > > > > >> > > > > >> Jeff > > > > >> > > > > >> Good point -- that would solve the problem. This > could be added > > > > >> to the 3-way handshake RFC. It might be > unnecessary, though, when > > > > >> operating over links where the MTU is negotiated end-to-end > > > > >> and IS-IS is using the result of that negotiation. > > > > >> > > > > >> Unfortunately, it wouldn't guarantee that you can receive big > > > > >> packets from the other end, which might not implement the new > > > > >> requirement. To do that, you'd have to check the size of the > > > > >> neighbor's IIH and only accept it if it looks like > it's padded > > > > >> to a maximum size, during initialization phase. > (But how would > > > > >> you do that? Presence of any padding option over some given > > > > >> size?) > > > > >> > > > > >> As you probably know, the check is important to make > sure that > > > > >> any LSP you send over the link will actually make > it. It is not > > > > >> necessary that the MTU size be equal in both directions, so > > > > >> it wouldn't necessarily be a good idea to require > the received > > > > >> IIH to match your own MTU size. While I suppose > it's uncommon > > > > >> to have asymmetrical MTU sizes, it might be useful in certain > > > > >> situations, like ADSL. To add such a check would be to add a > > > > >> new restriction on the use of IS-IS. > > > > >> > > > > >> Regards, > > > > >> Jeff > > > > >> > > > > >> At 05:10 PM 5/31/00 -0400, you wrote: > > > > >> >> I think the idea was to make sure that whatever > your idea of > > > > >> >> the MTU size is, that you can transmit a packet > of that size > > > > >> >> without worrying about it being dropped by the link layer. > > > > >> >> If you're transmitting IIHs that are too large to > be received > > > > >> >> at the other end, your data-link connection will > go down and > > > > >> >> the adjacency will never come up. But this only > works if the > > > > >> >> link is reliable (that is, if the link goes down > if it can't > > > > >> >> deliver a packet). > > > > >> >> > > > > >> >> Jeff Learman Internet: > > > > jjl@one.com > > > > >> > > > > > >> >You could send padded packets on pt2pt until the > > > > adjacency comes up. > > > > >> >This makes no assumptions about the reliability of > the link layer. > > > > >> > > > > > >> >- jeff parker > > > > >> >- Lucent Technology > > > > >> > > > > >> > > > > > ____________________________________________________________________ > > > > >> > > > > >> Jeff Learman Internet: > jjl@one.com > > > > >> Engineering Manager Voice: > (734)-975-7323 > > > > >> ONE (Open Networks Engineering, Inc) Fax: > (734)-975-6940 > > > > >> 2725 South Industrial Pkwy, Suite 100 > > > > >> Ann Arbor, MI 48104 USA > > > > >> > > > > > ____________________________________________________________________ > > > > >> > > > > >> _______________________________________________ > > > > >> Isis-wg mailing list - Isis-wg@external.juniper.net > > > > >> http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > > > >-- > > > > >Rick Han > > > > >Iron Bridge Networks, Inc. > > > > >rhan@ibnets.com > > > > >(781)372-8180 > > > > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > Jeff Learman Internet: > jjl@one.com > > > > Engineering Manager Voice: > (734)-975-7323 > > > > ONE (Open Networks Engineering, Inc) Fax: > (734)-975-6940 > > > > 2725 South Industrial Pkwy, Suite 100 > > > > Ann Arbor, MI 48104 USA > > > > > ____________________________________________________________________ > > > > > > > > _______________________________________________ > > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > > > >_______________________________________________ > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > -- > > Micah Bartell, CCIE #5069 mbartell@cisco.com > > Network Consulting Engineer, NSA Phone: 972.364.8829 > > Cisco Systems, Inc Fax: 972.364.8829 > > -- > > The Network Works, No Excuses > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From ginsberg@pluris.com Wed, 31 May 2000 20:39:27 -0700 Date: Wed, 31 May 2000 20:39:27 -0700 From: Les Ginsberg ginsberg@pluris.com Subject: [Isis-wg] question on MTU I agree - I think it would be a useful addition to the three way handshake RFC - send padded IIHs until the adjacency is in the UP state. I also agree that the receiving side should not check the size of the received IIH. In addition to solving the issue in cases where the "first" IIH was lost, it would eliminate wording in 10589 that has always been a bit confusing. The use of the term "first" IIH PDU was never unambiguous. It really meant the IIH sent as a result of receiving an ISH PDU and if for some strange reason multiple ISH PDUs were received then one was left to wonder how to resolve the designation of an IIH sent in response to receipt of an ISH which was not the "first". Much less ambiguous to say "an IIH should be padded if the adjacency is not in the UP state". Les > -----Original Message----- > From: Jeff Learman [mailto:jjl@one.com] > Sent: Wednesday, May 31, 2000 2:30 PM > To: Jeff Parker > Cc: isis-wg@external.juniper.net > Subject: RE: [Isis-wg] question on MTU > > > > Jeff > > Good point -- that would solve the problem. This could be added > to the 3-way handshake RFC. It might be unnecessary, though, when > operating over links where the MTU is negotiated end-to-end > and IS-IS is using the result of that negotiation. > > Unfortunately, it wouldn't guarantee that you can receive big > packets from the other end, which might not implement the new > requirement. To do that, you'd have to check the size of the > neighbor's IIH and only accept it if it looks like it's padded > to a maximum size, during initialization phase. (But how would > you do that? Presence of any padding option over some given > size?) > > As you probably know, the check is important to make sure that > any LSP you send over the link will actually make it. It is not > necessary that the MTU size be equal in both directions, so > it wouldn't necessarily be a good idea to require the received > IIH to match your own MTU size. While I suppose it's uncommon > to have asymmetrical MTU sizes, it might be useful in certain > situations, like ADSL. To add such a check would be to add a > new restriction on the use of IS-IS. > > Regards, > Jeff > > At 05:10 PM 5/31/00 -0400, you wrote: > >> I think the idea was to make sure that whatever your idea of > >> the MTU size is, that you can transmit a packet of that size > >> without worrying about it being dropped by the link layer. > >> If you're transmitting IIHs that are too large to be received > >> at the other end, your data-link connection will go down and > >> the adjacency will never come up. But this only works if the > >> link is reliable (that is, if the link goes down if it can't > >> deliver a packet). > >> > >> Jeff Learman Internet: jjl@one.com > > > >You could send padded packets on pt2pt until the adjacency > comes up. > >This makes no assumptions about the reliability of the link layer. > > > >- jeff parker > >- Lucent Technology > > ____________________________________________________________________ > > Jeff Learman Internet: jjl@one.com > Engineering Manager Voice: (734)-975-7323 > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > 2725 South Industrial Pkwy, Suite 100 > Ann Arbor, MI 48104 USA > ____________________________________________________________________ > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From rsaluja@nortelnetworks.com Wed, 31 May 2000 23:49:38 -0400 Date: Wed, 31 May 2000 23:49:38 -0400 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] question on MTU Les Ginsberg wrote: > > (At the risk of belaboring a point...) > > dataLinkBlockSize SHOULD always be >= originatingLxBufferSize. The point of > sending a padded IIH which is the maximum of the bunch is precisely to > detect those misconfigurations where this is not the case. So if > dataLinkBlockSize is NOT large enough, the adjacency presumably will never > come up. Therefore stating that > > "So IMHO IIH size is nothing but dataLinkBlocksize - 1." > > is denying the possibility of a misconfiguration. Yes, I should say that if you impose the requirement ( dataLinkBlocksize >= Buffersize ), then IIH size = dataLinkBlocksize - 1. The reason why it is not possible to enforce this requirement in explained in ISO 10589 section 8.2.3c. But I was wondering if this mechanism on P2P link could result in one way adjacency if you do not implement three way handshake mechanism. Consider IS A and IS B connected by P2P link. Suppose P2P link MTU size = X A - Buffersize = Y B - Buffersize = Z ( misconfiguration ) where Y < X < Z A will send padded Hello with size max(X,Y) i.e. X - 1. When B receives, it is going to accept this packet. Right? ( I do not see any check on the padded hello size at the receive end ). So B will make adjacency A UP ( if you do not implement three way handshake ) B will send padded Hello with size max(X,Z) i.e. Z-1 but it can not be delivered becuase DataLinkBlockSize is less. A will never receive Hello packet from B. So you end up with one-way adjacency. ( an example of link failing in one direction ? ) Please correct me if I am missing anything. Thanks, Rajesh From jjl@one.com Thu, 01 Jun 2000 10:10:05 -0400 Date: Thu, 01 Jun 2000 10:10:05 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] question on MTU Rajesh, You are correct -- you can get a persistent one-way adjacency. At the risk of sounding like a broken record, let me note that this wouldn't happen when operating IS-IS as it was designed to operate, over reliable p2p links. Fortunately, thanks to the "robustness check" for two-way connectivity, this isn't a problem unless there are multiple links between systems. In this case, if you were so unlucky as to have the same problem in different directions on two links, you would have a black hole. Of course, the 3-way handshake solves the problem. Thanks to Les, Jeff, and Dave for detecting my mistake about a 4K link not causing the "inconsistent LSP buffer size" problem. I also agree with Micah Bartell -- the IIH should be AT LEAST maxsize - 1. It's better to make it maxsize unless you simply can't because of the size of your IIH ending at maxsize - 1. (That's assuming you think the check is worthwhile at all.) Concerning what Dave Katz says about the unfortunate choice of SONET using a 512-byte MTU size, I completely agree that this was a particularly bad choice by Bellcore. Actually, this is not a media limitation, simply a poor choice of the default for a LAPD parameter. However, the IS-IS spec does not prohibit the use of smaller MTU sizes; it is certainly possible to use a consistently small LSP buffer size in a subdomain. IS-IS is flawed in that it does not properly address what should be done when the LSP buffer size is inconsistent. The good news is that, as Dave and Les point out, it isn't a problem unless you use an MTU size smaller than 1492. And Rajesh is correct that a link-by-link check is not sufficient to guarantee the end-to-end requirement for passing LSPs. The fact that maxsize is limited by LSP buffer size indicates that it's a check for passing LSPs and not a true MTU size check (which is better to do using LCP's MRU configuration option, and has nothing to do with routes anyway). This means that the IIH padding doesn't really serve any purpose, as Dave points out. I still agree with Les and Jeff that, if you're going to send padded IIHs, it's best to continue doing it until the adjacency goes into the UP state. But sending padded IIHs could be made optional if the MTU size is negotiated. And I take back my suggestion about checking the size on received IIHs! Bad idea! Regards, Jeff At 11:49 PM 5/31/00 -0400, Rajesh Saluja wrote: > > >Les Ginsberg wrote: >> >> (At the risk of belaboring a point...) >> >> dataLinkBlockSize SHOULD always be >= originatingLxBufferSize. The point of >> sending a padded IIH which is the maximum of the bunch is precisely to >> detect those misconfigurations where this is not the case. So if >> dataLinkBlockSize is NOT large enough, the adjacency presumably will never >> come up. Therefore stating that >> >> "So IMHO IIH size is nothing but dataLinkBlocksize - 1." >> >> is denying the possibility of a misconfiguration. > >Yes, I should say that if you impose the requirement ( dataLinkBlocksize >>= Buffersize ), then IIH size = dataLinkBlocksize - 1. >The reason why it is not possible to enforce this requirement in >explained in ISO 10589 section 8.2.3c. > >But I was wondering if this mechanism on P2P link could result in one >way adjacency if you do not implement three way handshake mechanism. > >Consider IS A and IS B connected by P2P link. >Suppose P2P link MTU size = X >A - Buffersize = Y >B - Buffersize = Z ( misconfiguration ) >where Y < X < Z > >A will send padded Hello with size max(X,Y) i.e. X - 1. >When B receives, it is going to accept this packet. Right? ( I do not >see any check on the padded hello size at the receive end ). >So B will make adjacency A UP ( if you do not implement three way >handshake ) > >B will send padded Hello with size max(X,Z) i.e. Z-1 but it can not be >delivered becuase DataLinkBlockSize is less. A will never receive Hello >packet from B. >So you end up with one-way adjacency. ( an example of link failing in >one direction ? ) > >Please correct me if I am missing anything. > >Thanks, >Rajesh > > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From selvarajr@future.futsoft.com Fri, 2 Jun 2000 08:00:32 +0530 Date: Fri, 2 Jun 2000 08:00:32 +0530 From: SelvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubt regarding LSP IP Address TLV ------ =_NextPart_000_01BFCC68.A123B440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit LSP includes one or more IP Addresses of the interfaces. (for encapsulation or transmission of n/w Mgmt pkts). I suppose it need not include all the IP addresses of the interfaces. How these IP Address(s) chosen? What may be selection criteria ? SELVA ------ =_NextPart_000_01BFCC68.A123B440 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IiICAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAqAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAbgAAAAAAAAC1O8LALHcQGqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUf kqBkiAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAASVNJUy1XRwBTTVRQAGlzaXMtd2dAZXh0ZXJu YWwuanVuaXBlci5uZXQAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAHQAAAGlzaXMtd2dA ZXh0ZXJuYWwuanVuaXBlci5uZXQAAAAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAACgAAACdJU0lT LVdHJwAAAAIBCzABAAAAIgAAAFNNVFA6SVNJUy1XR0BFWFRFUk5BTC5KVU5JUEVSLk5FVAAAAAMA ADkAAAAACwBAOgEAAAAeAPZfAQAAAAgAAABJU0lTLVdHAAIB918BAAAALAAAAL8AAAC1O8LALHcQ GqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUfkqBkiAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAA BAAAAAAAAALsVAEEgAEAJAAAAERvdWJ0IHJlZ2FyZGluZyBMU1AgSVAgQWRkcmVzcyBUTFYgALUL AQWAAwAOAAAA0AcGAAIACAAAACAABQAMAQEggAMADgAAANAHBgACAAcANwA3AAUAWQEBCYABACEA AABERThCMjJFNzVBMzhENDExQTg1ODAwMjAzNTFGOTJBMAABBwEDkAYAsAQAACAAAAALAAIAAQAA AAsAIwAAAAAAAwAmAAAAAAALACkAAAAAAAMANgAAAAAAQAA5AGCLZoY6zL8BHgBwAAEAAAAkAAAA RG91YnQgcmVnYXJkaW5nIExTUCBJUCBBZGRyZXNzIFRMViAAAgFxAAEAAAAWAAAAAb/MOoZV5yKL 4zhaEdSoWAAgNR+SoAAAHgAeDAEAAAAFAAAAU01UUAAAAAAeAB8MAQAAAB0AAABzZWx2YXJhanJA ZnV0dXJlLmZ1dHNvZnQuY29tAAAAAAMABhDMh61rAwAHEM4AAAAeAAgQAQAAAGUAAABMU1BJTkNM VURFU09ORU9STU9SRUlQQUREUkVTU0VTT0ZUSEVJTlRFUkZBQ0VTKEZPUkVOQ0FQU1VMQVRJT05P UlRSQU5TTUlTU0lPTk9GTi9XTUdNVFBLVFMpSVNVUFBPU0VJAAAAAAIBCRABAAAAhwEAAIMBAABJ AgAATFpGdSlvLukDAAoAcmNwZzEyNRYyAPgLYG4OEDAzM50B9yACpAPjAgBjaArA4HNldDAgBxMC gwBQ8RB2cHJxDlAQ7wHxEvFDA2MTCUJvb2sDgk+EbGQGAHR5bGUCg8YzAuMTCVRhaANxAoDyfQqB dWMAUAsDC7YKsTMKhAswbGkBwRIBIEzoU1AgC4BjCkABAAQgPQIgZRvABcAEYAlwIElxGyBBZGQJ cAQQG6JmWCB0aBvwC4B0BJBm4wDQB5AuICgCEAXACfAgY2Fwc3ULYHRp0wIgHAJ0cgBxbQQBH4MS Zhm0bi8H4E1nbUEFQHBrdHMpHnBJ4iAfMHBwbxEwGzAFQLcb4AmAIwBvBUAbRSAHQPcDIB2SHJFh HN8d6Bm4GfbiZhqCIEhvB+AdkSKxNRyYKCIAIBMgIqFuPxwgVxMwBUAAwHkgYvcb8BEwFnBjH3MF AR3xBzD8ID8ZuicKGasAoBRABgBwRUxWQQxAAtEW4XNcMTYszRl4GHEAMYAAAwAQEAAAAAADABEQ AAAAAAMAgBD/////QAAHMMCnK+E5zL8BQAAIMMCnK+E5zL8BCwAAgAggBgAAAAAAwAAAAAAAAEYA AAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMABYAIIAYAAAAAAMAA AAAAAABGAAAAAFKFAADzFQAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAAeAAiACCAG AAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAUAAAA4LjA0AAAAAAsACYAIIAYAAAAAAMAAAAAAAABG AAAAAA6FAAAAAAAAAwAKgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADAAuACCAGAAAAAADA AAAAAAAARgAAAAAYhQAAAAAAAB4ADIAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAA AAAeAA2ACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAOgAggBgAAAAAAwAAA AAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAB4APQABAAAAAQAAAAAAAAADAA00/TcAAGrs ------ =_NextPart_000_01BFCC68.A123B440-- From chopps@djinesys.com Mon, 5 Jun 2000 01:56:50 -0400 Date: Mon, 5 Jun 2000 01:56:50 -0400 From: Christian E. Hopps chopps@djinesys.com Subject: [Isis-wg] attached bit I was looking at ``Technical Corrigendum 1'' to 10589.. and I noticed that it changes when an IS should consider itself attached. It adds the condition that if the IS has at least one active reachable address prefix it should consider itself attached. What is the intention of the change to 10589? My initial thought is since the reachability won't be advertised into level 1 the level 1-2 router sets ATT to attract traffic to itself. I suspect I may be missing something though since this change would seem to blackhole things. In any case what is the analogous situation in IP? Would it be: if the IS is announcing any external IP reachability. ? If so thats easy enough but things get more interesting in light of the domain wide draft. For example, domainwide mentions how people have allowed external reachability to be announced into level 1, in which case I think that you would not set the ATT bit. Also, if you are leaking level 2 reachability into level 1 there too I don't think setting ATT would be appropriate. I would appreciate any clarification people can offer. Thanks, Chris. From henk@Procket.com Mon, 5 Jun 2000 15:34:05 +0200 (MEST) Date: Mon, 5 Jun 2000 15:34:05 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] attached bit Hi Chris, > I was looking at ``Technical Corrigendum 1'' to 10589.. and I noticed > that it changes when an IS should consider itself attached. > > It adds the condition that if the IS has at least one active > reachable address prefix it should consider itself attached. > > What is the intention of the change to 10589? My initial thought > is since the reachability won't be advertised into level 1 > the level 1-2 router sets ATT to attract traffic to itself. As usual, attracting traffic is the reason to set the ATT bit. > I suspect I may be missing something though since this change > would seem to blackhole things. The paragraph in the corrigendum seems to explain it. The old rule was: set ATT if you see other areas in your domain. The problem is, what do you do if your area is the only area in your domain ? If there is only one area in the domain, the routers in that area will never see other areas, and thus were never allowed to set the ATT bit. If your domain is connected to other domains, at least one L1L2 router should forward traffic from L1-only routers to the other domain. With the old spec that wouldn't happen, because the L1L2 router wasn't allowed to set the ATT bit. The corrigendum adds explanation that a L1L2 router is allowed to set ATT if it sees either: 1) other areas in its own domain, or 2) sees other domains. > In any case what is the analogous situation in IP? > Would it be: > > if the IS is announcing any external IP reachability. > > ? I think the rule is the same: set ATT if you are connected to either 1) other areas, or 2) other domains. How to determine if you are connected to another area or domain is kinda implementation specific, I am afraid. Esp for IP, as IP addressing is not strictly hierarchical. > If so thats easy enough but things get more interesting in light of > the domain wide draft. For example, domainwide mentions how people > have allowed external reachability to be announced into level 1, > in which case I think that you would not set the ATT bit. Agreed. If you leak specific prefixes into L1, you attact traffic for for those destinations. IMHO there is no need to also set the ATT bit. Unless you leak only a few external prefixes, and don't leak all external prefixes. > Also, if > you are leaking level 2 reachability into level 1 there too I don't > think setting ATT would be appropriate. Agreed again. > I would appreciate any clarification people can offer. I think a L1L2 router should set the ATT bit if it can forward traffic to destinations outside of the L1 area, and those destinations are not explicitely known by L1-only routers. Hope this helps, Henk. From cwk@verio.net Mon, 5 Jun 2000 15:23:04 -0500 Date: Mon, 5 Jun 2000 15:23:04 -0500 From: Carl W. Kalbfleisch cwk@verio.net Subject: [Isis-wg] Agenda for Pittsburgh ... Will there be any discussion of the MIB for ISIS? Carl > -----Original Message----- > From: isis-wg-admin@external.juniper.net > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Tony Przygienda > Sent: Tuesday, May 30, 2000 11:03 PM > To: isis-wg@external.juniper.net > Subject: [Isis-wg] Agenda for Pittsburgh ... > > > it's time to start to gather the agenda (beside the last calls > and new draft versions) for Pittsburgh. Requests for slots pls > to me or Tony Li > > -- tony > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From chopps@djinesys.com Sun, 11 Jun 2000 11:51:03 -0400 Date: Sun, 11 Jun 2000 11:51:03 -0400 From: Christian E. Hopps chopps@djinesys.com Subject: [Isis-wg] too many segments I'm curious what the standard way to deal with overflowing 255 LSP segments for an IS is. At first I was tempted to use the overload state, but this doesn't strike me as fitting well in its definition. (e.g., how do you report which LSP caused the overload when there is no LSP). Also overflowing 255 segments is a gross misconfiguration error which the overload state doesn't appear to be directly intended for (given that it waits some time and then switches back to normal). Its pretty easy to overflow the LSP by redistributing e.g., BGP into ISIS. Even if it doesn't overflow the IS LSPs itself you can then get into trouble at the level 1/level 2 boundary when summarization occurs. I'm curious what other implementations do in this situation. Thanks for any help, Chris. From tli@Procket.com Sun, 11 Jun 2000 10:24:12 -0700 (PDT) Date: Sun, 11 Jun 2000 10:24:12 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] too many segments | I'm curious what the standard way to deal with overflowing 255 LSP | segments for an IS is. At first I was tempted to use the overload | state, but this doesn't strike me as fitting well in its definition. | (e.g., how do you report which LSP caused the overload when there | is no LSP). Also overflowing 255 segments is a gross misconfiguration | error which the overload state doesn't appear to be directly intended | for (given that it waits some time and then switches back to normal). | | Its pretty easy to overflow the LSP by redistributing e.g., BGP | into ISIS. Even if it doesn't overflow the IS LSPs itself you can | then get into trouble at the level 1/level 2 boundary when summarization | occurs. | | I'm curious what other implementations do in this situation. Chris, There is no "standard" way of dealing with this problem. The most commonly suggested local hack for dealing with this, if one intentionally wants to generate more segments, is to have the administrator manually allocate another system ID. You then establish a zero cost adjacency between your primary system ID and your secondary. We discussed this at length back when we were discussing more than 255 adjacencies, tho the driver there was the ability to have more pseudo-node numbers. The same mechanism gives you more space to play in as well... As to the accidental overflow, the simplest mechanism is: don't. ;-) Tony From Radia.Perlman@East.Sun.COM Sun, 11 Jun 2000 21:35:54 -0400 (EDT) Date: Sun, 11 Jun 2000 21:35:54 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] too many segments The 1 byte fragment number is a field that in retrospect should have been larger. As Toni Li pointed out, it should be possible to get around it with the hack of pretending to be two (or more) nodes with zero cost between them, and have part of the information reported by each one. Do people actually do this? Do all implementations calculate correctly when they see this? Does the Dijkstra calculation do anything weird with 0-cost adjacencies? (It should work, but I wouldn't be surprised if some implementations got very confused.) Certainly it has nothing to do with overflow state if a router has more information to report than fits into 255 fragments. If this really is a big problem, it would probably be possible to change the size of the field, but it's tricky to do it in a way without flag days, or in a way that would work if someone accidentally plugs in a router that doesn't know about it. Radia From tli@Procket.com Sun, 11 Jun 2000 22:11:14 -0700 (PDT) Date: Sun, 11 Jun 2000 22:11:14 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] too many segments | The 1 byte fragment number is a field that in retrospect should have | been larger. As Toni Li pointed out, it should be possible to get around | it with the hack of pretending to be two (or more) nodes with zero cost | between them, and have part of the information reported by each one. | Do people actually do this? Do all implementations calculate correctly | when they see this? Does the Dijkstra calculation do anything weird | with 0-cost adjacencies? (It should work, but I wouldn't be surprised | if some implementations got very confused.) As a pseudo-node adjacency is already at zero cost, there's a fairly high chance that this will work in all implementations. And given that the predominant implementations have a fairly restricted set of authors, who are reasonably general, there's an excellent chance that it Just Works. Tony From mshand@cisco.com Mon, 12 Jun 2000 11:10:32 +0100 Date: Mon, 12 Jun 2000 11:10:32 +0100 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] too many segments At 22:11 11/06/2000 -0700, Tony Li wrote: >As a pseudo-node adjacency is already at zero cost, there's a fairly high >chance that this will work in all implementations. And given that the >predominant implementations have a fairly restricted set of authors, who >are reasonably general, there's an excellent chance that it Just Works. Yes, the thing about the pseudonode is that it is carefully crafted such that the zero cost is only in one direction. Dijkstra's algorithm can get upset if the set of LSPs contains a loop who's cost sum is zero. This is avoided in the pseudonode case, but here we would want to have zero cost in BOTH directions (not least, to satisfy the two way check). Its not clear that all implementations would necessarily take kindly to that. The other thing about the zero cost links in pseudonodes, is that you are supposed to give priority to selecting pseudonode LSPs from TENT where there are non-pseudonode LSPs present at equal cost. If we didn't do this and there were equal cost paths one of which was a direct link and the other through the pseudonode, we could fail to detect the path through the pseudonode, because the destination node would already have been added to PATHs and we can't (don't) increment the adjacency set of node already on PATHS. At least I think that was the rationale. So if we have zero cost links which aren't in pseudonodes we might upset an implementation which was doing this (as it is supposed to) on the basis of the LSP being a pseudonode rather than the more general property that it carried zero cost links. Mike Mike From Radia.Perlman@East.Sun.COM Mon, 12 Jun 2000 11:22:49 -0400 (EDT) Date: Mon, 12 Jun 2000 11:22:49 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] too many segments Mike, I didn't quite understand your paragraph >>>we could fail to detect the path through the >>>pseudonode, because the destination node would already have been added to >>>PATHs and we can't (don't) increment the adjacency set of node already on >>>PATHS. But as for your worry about having zero cost loops, I'd think you wouldn't need to have the cost be zero in both directions. For instance, suppose the node that has too much LSP information to fit into 255 fragments is named "A". So A invents new nodes A', A'', A'''. A adds neighbors A', A'', and A''' to its LSP as neighbors with zero cost. A also creates LSPs from A', A'', and A''' with the excess LSP info that didn't fit into the LSP for A, and also each with neighbor A with reasonably large, but finite cost. Would that work, and then eliminate any possible implementation confusion with zero cost loops? Radya ;-) From mshand@cisco.com Mon, 12 Jun 2000 16:38:21 +0100 Date: Mon, 12 Jun 2000 16:38:21 +0100 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] too many segments At 11:22 12/06/2000 -0400, Radia Perlman - Boston Center for Networking wrote: >But as for your worry about having zero cost loops, I'd think you wouldn't >need to have the cost be zero in both directions. For instance, suppose >the node that has too much LSP information to fit into 255 >fragments is named "A". So A invents new nodes A', >A'', A'''. A adds neighbors A', A'', and A''' to its LSP as neighbors with >zero cost. A also creates LSPs from A', A'', and A''' with the excess LSP >info that didn't fit into the LSP for A, and also each with neighbor A with >reasonably large, but finite cost. > >Would that work, and then eliminate any possible implementation confusion >with zero cost loops? I don't think that works in all cases. If the information in A', A'' etc's LSPs are just leaf information, then its fine, but if you had lots of genuine router adjacencies, then I think the two way connectivity check gets you. A' has links to B,C etc. These are real costs. But if we have links from B to A', C to A', then you end up needing to use the A' to A link to compute a route through A. You can't do the obvious thing of making B link directly to A, since then the two way check would get you since there was no link from A to B. Am I making any sense? I admit that the most likely reason for LSP size explosion is lots of imported routes, for which your solution would work fine. Mike From Radia.Perlman@East.Sun.COM Mon, 12 Jun 2000 12:10:42 -0400 (EDT) Date: Mon, 12 Jun 2000 12:10:42 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] too many segments Mike, Your point about the genuine router links is correct...but as you also point out, there is no problem with the assymetric costs (nonzero cost when fake nodes point to the real node) when it's for lots of imported routes. So the rule should be explicit about what information is allowed to hang off fake nodes (only leaf information). Would anyone ever need more than 255 fragments' worth of router neighbor information? (for instance, a really humongous "LAN" with thousands of attached routers). Radia From m1lu@yahoo.com Mon, 12 Jun 2000 09:23:07 -0700 (PDT) Date: Mon, 12 Jun 2000 09:23:07 -0700 (PDT) From: newbie m1lu@yahoo.com Subject: [Isis-wg] RFC 1195 post script version Hi: Could anyone here tell me where I acn find the post script version of RFC 1195? TIA _ming __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com From tli@Procket.com Mon, 12 Jun 2000 10:15:01 -0700 (PDT) Date: Mon, 12 Jun 2000 10:15:01 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] too many segments | Would anyone ever need more than 255 fragments' worth of router neighbor | information? (for instance, a really humongous "LAN" with thousands of | attached routers). Possibly. But the aforementioned solution for creation of additional sysids would apply. The question then degenerates into: do you ever need more than 255 fragments to describe the adjacencies for a single interface? At current technology levels, I bet one can't support the IIH traffic necessary to do this. Tony From m1lu@yahoo.com Mon, 12 Jun 2000 13:59:50 -0700 (PDT) Date: Mon, 12 Jun 2000 13:59:50 -0700 (PDT) From: newbie m1lu@yahoo.com Subject: [Isis-wg] router ID for IS-IS Hi: What does IS-IS use for router ID? NSAP's systme ID? most of vendor uses MAC address for NSAP system ID, but what about there is no ethernet card in the router? what is the role of loopback address in the IS-IS? thanks __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com From rsaluja@nortelnetworks.com Mon, 12 Jun 2000 17:45:25 -0400 Date: Mon, 12 Jun 2000 17:45:25 -0400 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] router ID for IS-IS newbie wrote: > > Hi: > > What does IS-IS use for router ID? NSAP's systme ID? > most of vendor uses MAC address for NSAP system ID, > but what about there is no ethernet card in the > router? what is the role of loopback address in the > IS-IS? It need not be MAC address. It is basically 1 to 8 octets long value ( almost all implementations use 6 octets ) which should be unique in a routing domain. People use loopback address so as to have reachability to a router till there is at least one physical interface to reach the router. ( eg : in BGP next hop ). IS-IS treats loopback address as just another reachability information. Hope it helps. Regards, Rajesh From jparker@nexabit.com Mon, 12 Jun 2000 18:34:38 -0400 Date: Mon, 12 Jun 2000 18:34:38 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] router ID for IS-IS > What does IS-IS use for router ID? If you use the same router ID that BGP and OSPF use, then you may be able to share some information between the protocols. This doesn't really answer your question, but does suggest that you define some answer common to all protocols you support. - jeff parker - Lucent From rsaluja@nortelnetworks.com Mon, 12 Jun 2000 21:41:27 -0400 Date: Mon, 12 Jun 2000 21:41:27 -0400 From: Rajesh Saluja rsaluja@nortelnetworks.com Subject: [Isis-wg] router ID for IS-IS Jeff Parker wrote: > If you use the same router ID that BGP and OSPF > use, then you may be able to share some information > between the protocols. > > This doesn't really answer your question, but > does suggest that you define some answer > common to all protocols you support. Jeff, I was wondering if anybody uses ISIS router ID ( which is 1 to 8 bytes long ) same as BGP router ID ( which is 4 bytes long )? The same router ID for BGP and OSPF is very helpful when you import routes from BGP into OSPF routing domain. I am not sure if anybody distributes BGP routes into IISIS domain in the field? Regards, Rajesh From tli@Procket.com Mon, 12 Jun 2000 19:21:46 -0700 (PDT) Date: Mon, 12 Jun 2000 19:21:46 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] router ID for IS-IS | I was wondering if anybody uses ISIS router ID ( which is 1 to 8 bytes | long ) same as BGP router ID ( which is 4 bytes long )? The same router | ID for BGP and OSPF is very helpful when you import routes from BGP into | OSPF routing domain. Many people do this, but not in the obvious way. They take the IP router ID and convert it into Binary Coded Decimal, concatenate it and then use those resulting 6 bytes as the system id. For example: router id 1.2.3.4 => 001.002.003.004 | V 0x001002003004 | V 0x00 0x10 0x02 0x00 0x30 0x04 Ugly, eh? | I am not sure if anybody distributes BGP routes into IISIS domain in the | field? This turns out to be a very bad idea, in so very many ways. Tony From danny@tcb.net Mon, 12 Jun 2000 20:39:42 -0600 Date: Mon, 12 Jun 2000 20:39:42 -0600 From: Danny McPherson danny@tcb.net Subject: [Isis-wg] router ID for IS-IS > I was wondering if anybody uses ISIS router ID ( which is 1 to 8 bytes > long ) same as BGP router ID ( which is 4 bytes long )? While it could be 1-8 octets in length, nobody ever uses anything other than 6 octets for sysid. > The same router > ID for BGP and OSPF is very helpful when you import routes from BGP into > OSPF routing domain. I am not sure if anybody distributes BGP routes > into IISIS domain in the field? Usually not intentionally, and even if unintentionally, not for very long ;-) A common practice is for service providers to map the loopback IP address of the router to the sysid (4 octets -> 6 octets, padded), this eases management overhead, especially when using automated tools. For example, a router with a IP loopback address of 192.168.56.1 would have a sysid value of 1921.6805.6001. Though this is a bit more intuitive, it's little more. -danny From jparker@nexabit.com Tue, 13 Jun 2000 09:20:04 -0400 Date: Tue, 13 Jun 2000 09:20:04 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] router ID for IS-IS > I was wondering if anybody uses ISIS router ID ( which is > 1 to 8 bytes long ) same as BGP router ID ( which is 4 bytes > long )? Sorry that I continued this confussion. There are two IDs at issue here: the 6 byte System ID, and the 4 byte Router ID used, for example, in Traffic Engineering. I think mostt of the posts on this thread were really about the System ID: I confused things by talking reading the words, rather than the intent of the posting. - jeff parker - Lucent Technology From Radia.Perlman@East.Sun.COM Tue, 13 Jun 2000 11:00:46 -0400 (EDT) Date: Tue, 13 Jun 2000 11:00:46 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] router ID for IS-IS I never thought the variable length system ID was a good idea. Just one of these design by committee things added trying to be fancy, at the expense of ugliness and little or no functionality. Especially since it's the kind of thing that can cause serious problems if anyone really did try to make routers use different sizes. It might be nice someday to rewrite the spec and take out things like that. Radia From m1lu@yahoo.com Tue, 13 Jun 2000 08:55:10 -0700 (PDT) Date: Tue, 13 Jun 2000 08:55:10 -0700 (PDT) From: newbie m1lu@yahoo.com Subject: [Isis-wg] router ID for IS-IS The role of IS-IS is the same as OSPF. If someone wants to redistribute BGP routes into OSPF, then there will be some cases one wants to redistribute BGP into IS-IS. -newbie --- Rajesh Saluja wrote: > > Jeff Parker wrote: > > > If you use the same router ID that BGP and OSPF > > use, then you may be able to share some > information > > between the protocols. > > > > This doesn't really answer your question, but > > does suggest that you define some answer > > common to all protocols you support. > > Jeff, > I was wondering if anybody uses ISIS router ID ( > which is 1 to 8 bytes > long ) same as BGP router ID ( which is 4 bytes long > )? The same router > ID for BGP and OSPF is very helpful when you import > routes from BGP into > OSPF routing domain. I am not sure if anybody > distributes BGP routes > into IISIS domain in the field? > > Regards, > Rajesh > > _______________________________________________ > Isis-wg mailing list - > Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com From mcr@solidum.com Wed, 14 Jun 2000 15:02:50 -0400 Date: Wed, 14 Jun 2000 15:02:50 -0400 From: Michael Richardson mcr@solidum.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit >>>>> "Michael" == Michael Thomas writes: Michael> Paul Koning writes: >> It's never been the point of any of this discussion to deprecate the >> notion that authentication is useful -- the issue is whether it makes >> sense to retain AH when ESP does the job with significantly less >> hassle. Michael> What keeps nagging at me is the overhead of both AH and ESP, not Michael> to mention the added complexity. If two routers need privacy and authenticity, they can use end-to-end ESP, as they can get strong origin authentication by virtue of the integrity check succeeding in the ESP. Don't trust the source IP, rather take the appropriate source IP from the SA to look up the appropriate PCB for the TCP/UDP session you are protecting. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From pkoning@xedia.com Wed, 14 Jun 2000 09:33:05 -0400 (EDT) Date: Wed, 14 Jun 2000 09:33:05 -0400 (EDT) From: Paul Koning pkoning@xedia.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit >>>>> "Waters," == Waters, Stephen writes: Waters,> There has been some discussion recently on the possible Waters,> deprecation of the Authentication Header defined for Waters,> 'whole-packet' authentication. Waters,> I 'think' the decision was to leave it alone, and allow AH Waters,> to wait for its day. >> From reading the various, associated methods of securing ISIS, >> OSPF and Waters,> RIPV2 messages, it seems to me that AH is perfect for the Waters,> protection of these protocols. Waters,> The current HMAC-MD5 options have the following exposures Waters,> that are solved with AH: Waters,> 1) no source address authentication (IP header Waters,> authentication in general) 2) poor/no replay protection 3) Waters,> manual keys - which restricts key length and complexity to Waters,> human-manageable keys, and makes for difficult key change Waters,> procedures. Waters,> IPSEC+AH would seem to be a good choice for all control Waters,> traffic exchange between routers. If this exchange is Waters,> confidential, the ESP could be used as well. Yes, but if it's not confidential (which is the likely case) then ESP in authentication only mode will serve just as well. It's never been the point of any of this discussion to deprecate the notion that authentication is useful -- the issue is whether it makes sense to retain AH when ESP does the job with significantly less hassle. paul From mcr@solidum.com Wed, 14 Jun 2000 16:22:37 -0400 Date: Wed, 14 Jun 2000 16:22:37 -0400 From: Michael Richardson mcr@solidum.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit >>>>> "Michael" == Michael Thomas writes: Michael> Maybe you're misunderstanding me: if ESP had a bit which said Michael> "I'm protecting the outside headers too", it could be either Michael> signaled or potentially even done on an as-needed basis by the Michael> IPsec stack for IP headers which would otherwise require AH. I'm Michael> all for not protecting things that don't need protection Michael> otherwise. The point that Steve Bellovin keeps making, and which he has written about, is that AH does not provide much more in the way of authentication that ESP does not (at least for IPv4). The outer headers are all either irrelevant, or can be derived from the SPD, so you don't have to trust them. I believe that there are other things that AH provides (like the guarantee that the contents are not encrypted and therefore can be audited), and things that will be defined in IPv6-extension land that will make AH a useful thing to keep in the spec, just not MUST it. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From pkoning@xedia.com Wed, 14 Jun 2000 14:19:19 -0400 (EDT) Date: Wed, 14 Jun 2000 14:19:19 -0400 (EDT) From: Paul Koning pkoning@xedia.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit >>>>> "Ben" == Ben McCann writes: Michael> This might be water well under the bridge, but has the Michael> thought of having a mode to ESP which protects the outer Michael> headers? Ben> Aren't your goals met by using ESP _tunnel_ mode? Just tunnel Ben> the OSPF, RIP, etc, packet from one box to the other. The Ben> tunneled packet has an inner IP header is completely secured by Ben> ESP. This is the header seen by OSPF, RIP, etc, once ESP Ben> completes the authentication of the packet. That certainly does the job. The trouble appears if someone wants to use transport mode (perhaps to save a few bytes) and then decides that for some reason there are IP headers worthy of protection. That's where the messy hybrid (AH) appears. paul From bmccann@indusriver.com Wed, 14 Jun 2000 14:07:16 -0400 Date: Wed, 14 Jun 2000 14:07:16 -0400 From: Ben McCann bmccann@indusriver.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit > Michael> This might be water well under the bridge, but has the > Michael> thought of having a mode to ESP which protects the outer > Michael> headers? Aren't your goals met by using ESP _tunnel_ mode? Just tunnel the OSPF, RIP, etc, packet from one box to the other. The tunneled packet has an inner IP header is completely secured by ESP. This is the header seen by OSPF, RIP, etc, once ESP completes the authentication of the packet. -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From mat@cisco.com Wed, 14 Jun 2000 10:20:06 -0700 (PDT) Date: Wed, 14 Jun 2000 10:20:06 -0700 (PDT) From: Michael Thomas mat@cisco.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Paul Koning writes: > Michael> What keeps nagging at me is the overhead of both AH and ESP, > Michael> not to mention the added complexity. > > Michael> This might be water well under the bridge, but has the > Michael> thought of having a mode to ESP which protects the outer > Michael> headers? > > That's no help, because that is exactly the difference that makes AH > so much harder than ESP. (Well, there's details like having the MAC > in the header rather than the trailer. Then again, ESP puts the > NextHeader value in the wrong place, so they're even...) > > The reason I like ESP authentication is precisely the fact that it > doesn't contain all the hair needed to protect a subset of IP header > fields. Maybe you're misunderstanding me: if ESP had a bit which said "I'm protecting the outside headers too", it could be either signaled or potentially even done on an as-needed basis by the IPsec stack for IP headers which would otherwise require AH. I'm all for not protecting things that don't need protection otherwise. Mike From mat@cisco.com Wed, 14 Jun 2000 08:29:41 -0700 (PDT) Date: Wed, 14 Jun 2000 08:29:41 -0700 (PDT) From: Michael Thomas mat@cisco.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Paul Koning writes: > It's never been the point of any of this discussion to deprecate the > notion that authentication is useful -- the issue is whether it makes > sense to retain AH when ESP does the job with significantly less > hassle. What keeps nagging at me is the overhead of both AH and ESP, not to mention the added complexity. This might be water well under the bridge, but has the thought of having a mode to ESP which protects the outer headers? I know that's contrary to the "encapsulating" part, but if we want to converge on one crypto header, it seems to me that placing an artificial restriction that outside headers can never be protected is pretty arbitrary and wrongheaded (even though I'm persuaded by Steve Bellovin's arguments about v4 headers). Mike From pkoning@xedia.com Wed, 14 Jun 2000 13:03:43 -0400 (EDT) Date: Wed, 14 Jun 2000 13:03:43 -0400 (EDT) From: Paul Koning pkoning@xedia.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit >>>>> "Michael" == Michael Thomas writes: Michael> Paul Koning writes: >> It's never been the point of any of this discussion to deprecate >> the notion that authentication is useful -- the issue is whether >> it makes sense to retain AH when ESP does the job with >> significantly less hassle. Michael> What keeps nagging at me is the overhead of both AH and ESP, Michael> not to mention the added complexity. Michael> This might be water well under the bridge, but has the Michael> thought of having a mode to ESP which protects the outer Michael> headers? That's no help, because that is exactly the difference that makes AH so much harder than ESP. (Well, there's details like having the MAC in the header rather than the trailer. Then again, ESP puts the NextHeader value in the wrong place, so they're even...) The reason I like ESP authentication is precisely the fact that it doesn't contain all the hair needed to protect a subset of IP header fields. paul From pkoning@xedia.com Wed, 14 Jun 2000 13:25:08 -0400 (EDT) Date: Wed, 14 Jun 2000 13:25:08 -0400 (EDT) From: Paul Koning pkoning@xedia.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit >>>>> "Michael" == Michael Thomas writes: Michael> Paul Koning writes: What keeps nagging at me is the overhead Michael> of both AH and ESP, not to mention the added complexity. >> Michael> This might be water well under the bridge, but has the Michael> thought of having a mode to ESP which protects the outer Michael> headers? >> That's no help, because that is exactly the difference that makes >> AH so much harder than ESP. (Well, there's details like having >> the MAC in the header rather than the trailer. Then again, ESP >> puts the NextHeader value in the wrong place, so they're even...) >> >> The reason I like ESP authentication is precisely the fact that it >> doesn't contain all the hair needed to protect a subset of IP >> header fields. Michael> Maybe you're misunderstanding me: if ESP had a bit which Michael> said "I'm protecting the outside headers too", it could be Michael> either signaled or potentially even done on an as-needed Michael> basis by the IPsec stack for IP headers which would Michael> otherwise require AH. I'm all for not protecting things that Michael> don't need protection otherwise. I think I understood. The issue is that the bit you're describing is actually the only essential difference between AH and ESP. In other words, you can think of it as the "do AH" bit. You can't just "protect the outside headers too". You have to be selective about it, protecting only immutable ones, skipping fields and headers that change in transit, mumble mumble mumble. That's the "hair" of AH I'm referring to. It doesn't matter what you call it or how you encode it. The hypothetical "ESP with the bit" you describe has to do the same thing so it has to contain the same amount of hair. paul From Stephen.Waters@cabletron.com Wed, 14 Jun 2000 10:38:55 +0100 Date: Wed, 14 Jun 2000 10:38:55 +0100 From: Waters, Stephen Stephen.Waters@cabletron.com Subject: [Isis-wg] Deprecation of AH header from the IPSEC tool kit There has been some discussion recently on the possible deprecation of the Authentication Header defined for 'whole-packet' authentication. I 'think' the decision was to leave it alone, and allow AH to wait for its day. >From reading the various, associated methods of securing ISIS, OSPF and RIPV2 messages, it seems to me that AH is perfect for the protection of these protocols. The current HMAC-MD5 options have the following exposures that are solved with AH: 1) no source address authentication (IP header authentication in general) 2) poor/no replay protection 3) manual keys - which restricts key length and complexity to human-manageable keys, and makes for difficult key change procedures. IPSEC+AH would seem to be a good choice for all control traffic exchange between routers. If this exchange is confidential, the ESP could be used as well. Regards, Steve. From mat@cisco.com Wed, 14 Jun 2000 11:54:05 -0700 (PDT) Date: Wed, 14 Jun 2000 11:54:05 -0700 (PDT) From: Michael Thomas mat@cisco.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Ben McCann writes: > > Michael> This might be water well under the bridge, but has the > > Michael> thought of having a mode to ESP which protects the outer > > Michael> headers? > > Aren't your goals met by using ESP _tunnel_ mode? Just tunnel the OSPF, > RIP, etc, packet from one box to the other. The tunneled packet has an > inner IP header is completely secured by ESP. This is the header seen > by OSPF, RIP, etc, once ESP completes the authentication of the packet. > See my previous post. Throwing bytes at the problem is certainly one way to solve it, but it may not be practical in many, many cases. Mike From mat@cisco.com Wed, 14 Jun 2000 11:48:19 -0700 (PDT) Date: Wed, 14 Jun 2000 11:48:19 -0700 (PDT) From: Michael Thomas mat@cisco.com Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Paul Koning writes: > The issue is that the bit you're describing is actually the only > essential difference between AH and ESP. In other words, you can > think of it as the "do AH" bit. > > You can't just "protect the outside headers too". You have to be > selective about it, protecting only immutable ones, skipping fields > and headers that change in transit, mumble mumble mumble. That's the > "hair" of AH I'm referring to. It doesn't matter what you call it or > how you encode it. The hypothetical "ESP with the bit" you describe > has to do the same thing so it has to contain the same amount of hair. Sure. Doing AH-like functionality is a pain; if you have to do it, you have to do it -- that's just a given. What I don't like is having a completely separate header with its associated complexity and (especially) overhead. Right now though, if I had a flow which for some reason need privacy and outer header protection (ie, AH functionality), you'd have to put on an AH and ESP header. This means that the SPI and the Sequence are completely redundant, as well as having to burn another longword for the redundant header, thus I'm having to add yet another 12 bytes per packet. If we're talking about something like RTP audio, that's probably significant. Then of course there's the issue of, say, CRTP. I don't think that a profile for crypto for CRTP has been done to compress the predictable parts of the crypto headers, (ie, SPI, SEQ, next header), but having to contend with *both* AH and ESP would make crypto-aware CRTP an even uglier proposition. The same, incidentally, goes for normal header compression, and the coming IP enabled cellular stuff is going to absolutely demand both compression as well as security. Whether it is wise to open up this debate yet again is questionable, but life is only going to get more complicated if AH stays around. Pick your poison. Mike From ben.abarbanel@ipoptical.com Thu, 15 Jun 2000 09:58:48 -0700 Date: Thu, 15 Jun 2000 09:58:48 -0700 From: ben abarbanel ben.abarbanel@ipoptical.com Subject: [Isis-wg] Maximum number of adjacencies This is a multi-part message in MIME format. ------=_NextPart_000_0015_01BFD6B0.4CCDB100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What is the absolute maximum number of adjacencies per router various = vendors have defined in their software? I know we have a circuit ID maximum of 255, but assuming we can solve = that with IS-IS 3 way handshake. Thanks in advance for your input. Ben ------=_NextPart_000_0015_01BFD6B0.4CCDB100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
What is the absolute maximum number of = adjacencies=20 per router various vendors have defined in their software?
I know we have a circuit ID maximum of = 255, but=20 assuming we can solve that with IS-IS 3 way handshake.
 
Thanks in advance for your = input.
 
Ben
 
 
------=_NextPart_000_0015_01BFD6B0.4CCDB100-- From Radia.Perlman@East.Sun.COM Thu, 15 Jun 2000 22:32:53 -0700 (PDT) Date: Thu, 15 Jun 2000 22:32:53 -0700 (PDT) From: Radia Perlman Radia.Perlman@East.Sun.COM Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Ran said: >> A counter-example is the Source Routing header, which can >> be authenticated hop-by-hop with AH ... How do you authenticate something hop-by-hop when the key is only known end-to-end? Are you maybe assuming hop-by-hop IPSec tunnels between the routers listed in the source route header? Radia From dkatz@juniper.net Sun, 18 Jun 2000 21:03:59 -0700 (PDT) Date: Sun, 18 Jun 2000 21:03:59 -0700 (PDT) From: Dave Katz dkatz@juniper.net Subject: [Isis-wg] Maximum number of adjacencies There should be no need for an absolute maximum number. The dominant implementations have demonstrated hundreds of adjacencies. There will be a point, of course, where things will no longer work, but there is nothing in the protocol precluding arbitrary numbers of neighbors. X-Sent: 15 Jun 2000 13:56:37 GMT From: "ben abarbanel" Date: Thu, 15 Jun 2000 09:58:48 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01BFD6B0.4CCDB100" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net This is a multi-part message in MIME format. ------=_NextPart_000_0015_01BFD6B0.4CCDB100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What is the absolute maximum number of adjacencies per router various = vendors have defined in their software? I know we have a circuit ID maximum of 255, but assuming we can solve = that with IS-IS 3 way handshake. Thanks in advance for your input. Ben ------=_NextPart_000_0015_01BFD6B0.4CCDB100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
What is the absolute maximum number of = adjacencies=20 per router various vendors have defined in their software?
I know we have a circuit ID maximum of = 255, but=20 assuming we can solve that with IS-IS 3 way handshake.
 
Thanks in advance for your = input.
 
Ben
 
 
------=_NextPart_000_0015_01BFD6B0.4CCDB100-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From emmanuel.dauvergne@rd.francetelecom.fr Mon, 19 Jun 2000 11:56:14 +0200 Date: Mon, 19 Jun 2000 11:56:14 +0200 From: DAUVERGNE Emmanuel FTRD/DAC/ISS emmanuel.dauvergne@rd.francetelecom.fr Subject: [Isis-wg] reservation and preemption Hello, In RFC2702, it's planned to use the preemptive (preemptor and/or preemptable) characteristics of reservations to choose one path or another. To provide this, shouldn't we distinguish the "unreserved bandwidth" from the 'bandwidth already reserved but preemptable", and therefore introduce a new sub-TLV in TLV 22 ? Or is this the aim of the three additional TE-metrics defined in draft-fedyk-isis-ospf-te-metrics-00.txt ? Thanks for clarification Manu From E.T.Metz@kpn.com Mon, 19 Jun 2000 15:40:56 +0100 Date: Mon, 19 Jun 2000 15:40:56 +0100 From: Metz, E.T. E.T.Metz@kpn.com Subject: [Isis-wg] Areas in ISIS Hi all, is it possible to have an ISIS network with different areas, but without an explicit backbone area? I thought it could be done because the L1/L2 routers in each of the areas will form (L2) adjacencies and exchange routing info. So even without a real backbone area, traffic will still flow between differents areas. Is the above correct? Does it make any sense? cheers, Eduard From mshand@cisco.com Mon, 19 Jun 2000 14:56:44 +0100 Date: Mon, 19 Jun 2000 14:56:44 +0100 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Areas in ISIS At 15:40 19/06/2000 +0100, Metz, E.T. wrote: >Hi all, > >is it possible to have an ISIS network with different areas, but without an >explicit backbone area? > >I thought it could be done because the L1/L2 routers in each of the areas >will form (L2) adjacencies and exchange routing info. So even without a real >backbone area, traffic will still flow between differents areas. > >Is the above correct? Does it make any sense? Yes, no problem. All that is required is that there is a connected L2 path linking all the areas. In paritcular if areas A and C are connected through area B, there must be a connected path of L2 routers through B. Mike >cheers, > Eduard > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From amartey@cisco.com Mon, 19 Jun 2000 09:43:36 -0700 Date: Mon, 19 Jun 2000 09:43:36 -0700 From: Abe Martey amartey@cisco.com Subject: [Isis-wg] Areas in ISIS On Mon, Jun 19, 2000 at 03:40:56PM +0100, Metz, E.T. wrote: > Hi all, > > is it possible to have an ISIS network with different areas, but without an > explicit backbone area? Sure! Each router belongs to one area and there is no need for a physically distinct backbone area. The backbone refers to the level-2 routing domain which is a logical area....the group of routers involved in level-2 routing (as you describe below) form the isis backbone...the backbone stretch just has to be contiguous... Cheers. - abe > > I thought it could be done because the L1/L2 routers in each of the areas > will form (L2) adjacencies and exchange routing info. So even without a real > backbone area, traffic will still flow between differents areas. > > Is the above correct? Does it make any sense? > > cheers, > Eduard > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ==.==.==.==.== Abe Martey San Jose, CA 408 527 9149 From Radia.Perlman@East.Sun.COM Mon, 19 Jun 2000 13:54:40 -0400 (EDT) Date: Mon, 19 Jun 2000 13:54:40 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] Areas in ISIS Years ago (like 10) Chris Gunner and I did an internet-draft explaining how a router capable of running multiple instances of IS-IS could be configured to interconnect two areas. It just has to be configured with which ports are in which areas, and which addresses to pass along from one area to another. NLSP did this, and extended the idea with something called "area-hops" which said how many areas you were allowed to learn the address range and pass it along. This allowed interconnecting two areas but not allowing through traffic from other areas (set area-hops to 1), and cut down on the count-to-infinity behavior that could be caused by complex interconnections of areas without a level 2 backbone. This isn't a protocol issue, if you don't add "area-hops". It's solely an implementation issue at the multi-area router. If someone wants to build a router that can do multiple instances of IS-IS and be configured with what to pass between the areas, none of the other routers need to know that this is going on. Radia From: Abe Martey To: "Metz, E.T." Cc: isis-wg@external.juniper.net Subject: Re: [Isis-wg] Areas in ISIS Mime-Version: 1.0 X-Mailman-Version: 1.0rc3 List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net On Mon, Jun 19, 2000 at 03:40:56PM +0100, Metz, E.T. wrote: > Hi all, > > is it possible to have an ISIS network with different areas, but without an > explicit backbone area? Sure! Each router belongs to one area and there is no need for a physically distinct backbone area. The backbone refers to the level-2 routing domain which is a logical area....the group of routers involved in level-2 routing (as you describe below) form the isis backbone...the backbone stretch just has to be contiguous... Cheers. - abe > > I thought it could be done because the L1/L2 routers in each of the areas > will form (L2) adjacencies and exchange routing info. So even without a real > backbone area, traffic will still flow between differents areas. > > Is the above correct? Does it make any sense? > > cheers, > Eduard > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ==.==.==.==.== Abe Martey San Jose, CA 408 527 9149 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From dkatz@juniper.net Mon, 19 Jun 2000 13:19:50 -0700 (PDT) Date: Mon, 19 Jun 2000 13:19:50 -0700 (PDT) From: Dave Katz dkatz@juniper.net Subject: [Isis-wg] Areas in ISIS I fail to see the distinction between what is described and a "physically distinct backbone area." In particular, if there are going to be distinct L1 areas, there must be a contiguous L2 backbone (which could be as small as a single link) to connect the L2 routers. An L1/L2 router is essentially the same thing as an OSPF router with at least one interface in the backbone area and at least one interface in another area. --Dave Date: Mon, 19 Jun 2000 09:43:36 -0700 From: Abe Martey Cc: isis-wg@external.juniper.net References: <59063B5B4D98D311BC0D0001FA7E452201443790@l04.research.kpn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net On Mon, Jun 19, 2000 at 03:40:56PM +0100, Metz, E.T. wrote: > Hi all, > > is it possible to have an ISIS network with different areas, but without an > explicit backbone area? Sure! Each router belongs to one area and there is no need for a physically distinct backbone area. The backbone refers to the level-2 routing domain which is a logical area....the group of routers involved in level-2 routing (as you describe below) form the isis backbone...the backbone stretch just has to be contiguous... Cheers. - abe > > I thought it could be done because the L1/L2 routers in each of the areas > will form (L2) adjacencies and exchange routing info. So even without a real > backbone area, traffic will still flow between differents areas. > > Is the above correct? Does it make any sense? > > cheers, > Eduard > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ==.==.==.==.== Abe Martey San Jose, CA 408 527 9149 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From dkatz@juniper.net Mon, 19 Jun 2000 13:26:29 -0700 (PDT) Date: Mon, 19 Jun 2000 13:26:29 -0700 (PDT) From: Dave Katz dkatz@juniper.net Subject: [Isis-wg] Areas in ISIS This isn't "physically distinct" in the sense that L1 traffic can traverse some of the same links that make up the L2 topology, but it is important to think of the L2 topology as distinct when you design your network, or you can end up in a world of hurt. In particular, if areas A, B, and C are connected through a loop, and there are parts of area B that depend on those L1L2 links for L1 connectivity, a break of the path through area B could not be healed via A and C. In the topology you describe, I would visualize the L2 path as being on the edge of area B, as it (at least to me) presents the weaknesses of the topology more clearly. --Dave X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 19 Jun 2000 14:56:44 +0100 From: Mike Shand Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net At 15:40 19/06/2000 +0100, Metz, E.T. wrote: >Hi all, > >is it possible to have an ISIS network with different areas, but without an >explicit backbone area? > >I thought it could be done because the L1/L2 routers in each of the areas >will form (L2) adjacencies and exchange routing info. So even without a real >backbone area, traffic will still flow between differents areas. > >Is the above correct? Does it make any sense? Yes, no problem. All that is required is that there is a connected L2 path linking all the areas. In paritcular if areas A and C are connected through area B, there must be a connected path of L2 routers through B. Mike >cheers, > Eduard > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From amartey@cisco.com Mon, 19 Jun 2000 15:29:33 -0700 Date: Mon, 19 Jun 2000 15:29:33 -0700 From: Abe Martey amartey@cisco.com Subject: [Isis-wg] Areas in ISIS Dave Katz wrote: > > I fail to see the distinction between what is described and a "physically > distinct backbone area." In particular, if there are going to be distinct > L1 areas, there must be a contiguous L2 backbone (which could be as small > as a single link) to connect the L2 routers. An L1/L2 router is > essentially the same thing as an OSPF router with at least one >interface in the backbone area and at least one interface in another >area. Technically yes...but IS-IS would allow a linear layout of multiple areas whereas OSPF needs all areas touching a _common_ centrally located area 0...unless you wanted to play with virtual links. The IS-IS backbone is not as clearly carved out as the OSPF area 0...a difference probably rooted in ISO node-based addressing vs IP link-based addressing. I'll agree however that in a real network, the IS-IS backbone should be as distinctly carved out as an OSPF backbone.... > > --Dave > > Date: Mon, 19 Jun 2000 09:43:36 -0700 > From: Abe Martey > Cc: isis-wg@external.juniper.net > References: <59063B5B4D98D311BC0D0001FA7E452201443790@l04.research.kpn.com> > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > X-Mailer: Mutt 1.0i > Sender: isis-wg-admin@external.juniper.net > Errors-To: isis-wg-admin@external.juniper.net > X-Mailman-Version: 1.0rc3 > Precedence: bulk > List-Id: IETF IS-IS working group > X-BeenThere: isis-wg@external.juniper.net > > On Mon, Jun 19, 2000 at 03:40:56PM +0100, Metz, E.T. wrote: > > Hi all, > > > > is it possible to have an ISIS network with different areas, but without an > > explicit backbone area? > > Sure! Each router belongs to one area and there is no need for a > physically distinct backbone area. The backbone refers to the level-2 > routing domain which is a logical area....the group of routers involved > in level-2 routing (as you describe below) form the isis backbone...the > backbone stretch just has to be contiguous... > > Cheers. > > - abe > > > > > I thought it could be done because the L1/L2 routers in each of the areas > > will form (L2) adjacencies and exchange routing info. So even without a real > > backbone area, traffic will still flow between differents areas. > > > > Is the above correct? Does it make any sense? > > > > cheers, > > Eduard > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > -- > > ==.==.==.==.== > Abe Martey > San Jose, CA > 408 527 9149 > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From Radia.Perlman@East.Sun.COM Mon, 19 Jun 2000 19:26:38 -0400 (EDT) Date: Mon, 19 Jun 2000 19:26:38 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Ran, another basic question... What's the threat solved by authenticating the source route header at intermediate points? What would be the problem if a packet showed up at the destination, not having traversed the route you wanted? I'm assuming you're not trying to solve the confidentiality problem by making sure that the packet stays in "friendly" parts of the net, and therefore doesn't need encryption, but if it took a different route it would need encryption. Radia From truskows@cisco.com Mon, 19 Jun 2000 18:04:28 PDT Date: Mon, 19 Jun 2000 18:04:28 PDT From: Mike Truskowski truskows@cisco.com Subject: [Isis-wg] Areas in ISIS Sounds to me like you are saying the same things here only in different ways... The difference occurs at the logical layer... an area in OSI is dictated by the nsap while an area in ospf is a logical mapping... OSI backbones can have multiple osi areas while an ospf area 0 is one area with the backbone belonging to it... mike > > I fail to see the distinction between what is described and a "physically > distinct backbone area." In particular, if there are going to be distinct > L1 areas, there must be a contiguous L2 backbone (which could be as small > as a single link) to connect the L2 routers. An L1/L2 router is > essentially the same thing as an OSPF router with at least one interface > in the backbone area and at least one interface in another area. > > --Dave > > Date: Mon, 19 Jun 2000 09:43:36 -0700 > From: Abe Martey > Cc: isis-wg@external.juniper.net > References: <59063B5B4D98D311BC0D0001FA7E452201443790@l04.research.kpn.com> > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > X-Mailer: Mutt 1.0i > Sender: isis-wg-admin@external.juniper.net > Errors-To: isis-wg-admin@external.juniper.net > X-Mailman-Version: 1.0rc3 > Precedence: bulk > List-Id: IETF IS-IS working group > X-BeenThere: isis-wg@external.juniper.net > > > On Mon, Jun 19, 2000 at 03:40:56PM +0100, Metz, E.T. wrote: > > Hi all, > > > > is it possible to have an ISIS network with different areas, but without an > > explicit backbone area? > > Sure! Each router belongs to one area and there is no need for a > physically distinct backbone area. The backbone refers to the level-2 > routing domain which is a logical area....the group of routers involved > in level-2 routing (as you describe below) form the isis backbone...the > backbone stretch just has to be contiguous... > > Cheers. > > - abe > > > > > I thought it could be done because the L1/L2 routers in each of the areas > > will form (L2) adjacencies and exchange routing info. So even without a real > > backbone area, traffic will still flow between differents areas. > > > > Is the above correct? Does it make any sense? > > > > cheers, > > Eduard > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > -- > > > ==.==.==.==.== > Abe Martey > San Jose, CA > 408 527 9149 > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From truskows@cisco.com Mon, 19 Jun 2000 18:14:31 PDT Date: Mon, 19 Jun 2000 18:14:31 PDT From: Mike Truskowski truskows@cisco.com Subject: [Isis-wg] Areas in ISIS I think that you are saying that if you build heirarchically then OSPF and ISIS topologies are the same... AREA0 is equivalent to all those L2 adjacencies... And I agree...but the difference is shown by a little different topology... In ospf, if A is the area0 and B and C are cascading with a virtual link from C to A.. then all traffic from C to B goes thru A... But in ISIS with A being L2/L1 cascaded to B cascaded to C as in above... with L2 connectivity to from A thru B to C, then traffic from C to B merely goes directly to B and never is seen by A... As long as the "loop" is never completed then the topology is fine... The major weakness I see with ISIS in this sense is that a L1 instance must choose the "closest" L2 router which may not be the best L2. Mike > > This isn't "physically distinct" in the sense that L1 traffic can traverse > some of the same links that make up the L2 topology, but it is important > to think of the L2 topology as distinct when you design your network, or > you can end up in a world of hurt. In particular, if areas A, B, and C > are connected through a loop, and there are parts of area B that depend > on those L1L2 links for L1 connectivity, a break of the path through > area B could not be healed via A and C. > > In the topology you describe, I would visualize the L2 path as being > on the edge of area B, as it (at least to me) presents the weaknesses > of the topology more clearly. > > > --Dave > > X-Sender: mshand@jaws.cisco.com > X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 > Date: Mon, 19 Jun 2000 14:56:44 +0100 > From: Mike Shand > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii"; format=flowed > Sender: isis-wg-admin@external.juniper.net > Errors-To: isis-wg-admin@external.juniper.net > X-Mailman-Version: 1.0rc3 > Precedence: bulk > List-Id: IETF IS-IS working group > X-BeenThere: isis-wg@external.juniper.net > > At 15:40 19/06/2000 +0100, Metz, E.T. wrote: > >Hi all, > > > >is it possible to have an ISIS network with different areas, but without an > >explicit backbone area? > > > >I thought it could be done because the L1/L2 routers in each of the areas > >will form (L2) adjacencies and exchange routing info. So even without a real > >backbone area, traffic will still flow between differents areas. > > > >Is the above correct? Does it make any sense? > > Yes, no problem. All that is required is that there is a connected L2 path > linking all the areas. In paritcular if areas A and C are connected through > area B, there must be a connected path of L2 routers through B. > > Mike > > > > >cheers, > > Eduard > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > From NZvaig@adtech-inc.com Mon, 19 Jun 2000 16:31:57 -1000 Date: Mon, 19 Jun 2000 16:31:57 -1000 From: Nava.Zvaig NZvaig@adtech-inc.com Subject: [Isis-wg] ISIS code This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDA5F.B4BB817E Content-Type: text/plain; charset="iso-8859-1" Is there any software/shareware/freeware available for ISIS and ISIS-TE? TIA, Nava ------_=_NextPart_001_01BFDA5F.B4BB817E Content-Type: text/html; charset="iso-8859-1" ISIS code

Is there any software/shareware/freeware available for ISIS and ISIS-TE?

TIA,
Nava

------_=_NextPart_001_01BFDA5F.B4BB817E-- From mshand@cisco.com Tue, 20 Jun 2000 08:02:19 +0100 Date: Tue, 20 Jun 2000 08:02:19 +0100 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Areas in ISIS At 13:26 19/06/2000 -0700, Dave Katz wrote: >This isn't "physically distinct" in the sense that L1 traffic can traverse >some of the same links that make up the L2 topology, but it is important >to think of the L2 topology as distinct when you design your network, or >you can end up in a world of hurt. In particular, if areas A, B, and C >are connected through a loop, and there are parts of area B that depend >on those L1L2 links for L1 connectivity, a break of the path through >area B could not be healed via A and C. > >In the topology you describe, I would visualize the L2 path as being >on the edge of area B, as it (at least to me) presents the weaknesses >of the topology more clearly. Dave, I couldn't agree more. The difference between IS-IS and OSPF is not primarily one of network design, but one of nomenclature. i.e. in IS-IS you still need to design a 'backbone', but the backbone isn't named as a single area (0) as it is in OSPF. In fact it isn't named at all. Its just defined by the connected set of L2 routers. In some designs that will correspond to a single L1 area, but in others it may traverse (or as you rightly point out ,it is better to think of it as skirting around the edge of) multiple L1 areas. Mike From E.T.Metz@kpn.com Tue, 20 Jun 2000 20:14:11 +0100 Date: Tue, 20 Jun 2000 20:14:11 +0100 From: Metz, E.T. E.T.Metz@kpn.com Subject: [Isis-wg] Areas in ISIS Thanks for the clarifications ... As for the situation I was thinking of, this was indeed the case where you have multiple areas and the backbone is formed of the "edges" of the areas and the links between the areas. I didn't really think of a "chain" of areas, the loop issue is although interesting. I like the concept of this "virtual backbone" is ISIS, although in (re)designing networks you'll probably have to clearly keep in mind to keep the backbone contiguos and avoid chains (loops) of areas. While in OSPF this is more or less forced upon th designer due to the explicit area 0 that has to present, and to which all other areas should connect. cheers, Eduard ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area would it? It needs to be L2 or L1/L2 at least. > ---------- > From: Mike Shand[SMTP:mshand@cisco.com] > Sent: dinsdag 20 juni 2000 9:02 > To: Dave Katz > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net > Subject: Re: [Isis-wg] Areas in ISIS > > At 13:26 19/06/2000 -0700, Dave Katz wrote: > >This isn't "physically distinct" in the sense that L1 traffic can > traverse > >some of the same links that make up the L2 topology, but it is important > >to think of the L2 topology as distinct when you design your network, or > >you can end up in a world of hurt. In particular, if areas A, B, and C > >are connected through a loop, and there are parts of area B that depend > >on those L1L2 links for L1 connectivity, a break of the path through > >area B could not be healed via A and C. > > > >In the topology you describe, I would visualize the L2 path as being > >on the edge of area B, as it (at least to me) presents the weaknesses > >of the topology more clearly. > > Dave, > I couldn't agree more. The difference between IS-IS and OSPF is > not primarily one of network design, but one of nomenclature. i.e. in > IS-IS > you still need to design a 'backbone', but the backbone isn't named as a > single area (0) as it is in OSPF. In fact it isn't named at all. Its just > defined by the connected set of L2 routers. In some designs that will > correspond to a single L1 area, but in others it may traverse (or as you > rightly point out ,it is better to think of it as skirting around the edge > > of) multiple L1 areas. > > Mike > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From mshand@cisco.com Tue, 20 Jun 2000 19:34:48 +0100 Date: Tue, 20 Jun 2000 19:34:48 +0100 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] Areas in ISIS At 20:14 20/06/2000 +0100, Metz, E.T. wrote: >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area would >it? It needs to be L2 or L1/L2 at least. Were running into terminological inexactitudes here :-) Yes it does need to be L2, but one way of designing an IS-IS network is to make an area of L1/L2 routers which constitutes the backbone and then hang all the other areas off this one. Of course you need at least one L1/L2 router in each of those areas, so the backbone (in the sense we were talking before, i.e. the set of connected L2 routers - or the distribution domain of L2 LSPs) spans multiple areas. But it does look rather like the OSPF case, where the backbone is a single area (0 in that case). Mike (S) From E.T.Metz@kpn.com Tue, 20 Jun 2000 20:50:38 +0100 Date: Tue, 20 Jun 2000 20:50:38 +0100 From: Metz, E.T. E.T.Metz@kpn.com Subject: [Isis-wg] Areas in ISIS Small question (related to below), if you do create a separate backbone (physically, or at least similar to OSPF area 0), is it then needed or advantagous to have L1 routing in this area. Instead of just L2? cheers, Eduard > ---------- > From: Mike Shand[SMTP:mshand@cisco.com] > Sent: dinsdag 20 juni 2000 20:34 > To: Metz, E.T.; Dave Katz; 'truskows@cisco.com' > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net > Subject: RE: [Isis-wg] Areas in ISIS > > At 20:14 20/06/2000 +0100, Metz, E.T. wrote: > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area > would > >it? It needs to be L2 or L1/L2 at least. > > Were running into terminological inexactitudes here :-) > > Yes it does need to be L2, but one way of designing an IS-IS network is to > > make an area of L1/L2 routers which constitutes the backbone and then hang > > all the other areas off this one. Of course you need at least one L1/L2 > router in each of those areas, so the backbone (in the sense we were > talking before, i.e. the set of connected L2 routers - or the distribution > > domain of L2 LSPs) spans multiple areas. But it does look rather like the > OSPF case, where the backbone is a single area (0 in that case). > > Mike (S) > > From amartey@cisco.com Wed, 21 Jun 2000 09:05:14 -0700 Date: Wed, 21 Jun 2000 09:05:14 -0700 From: Abe Martey amartey@cisco.com Subject: [Isis-wg] Areas in ISIS On Tue, Jun 20, 2000 at 08:50:38PM +0100, Metz, E.T. wrote: > Small question (related to below), if you do create a separate backbone > (physically, or at least similar to OSPF area 0), is it then needed or > advantagous to have L1 routing in this area. Instead of just L2? You could have a physical area x designated as the "core" of the backbone..and all routers in this area don't have to run L1. Actually they shouldn't since it'll be a resource waste....however your "true" isis backbone will extend to the L1L2 border routers of the various other areas. [L1]=====[L1L2]=====[L2]=====[L2]======[L1L2]======[L1] |---area 1----| |--area x---| |----Area 2----| |----------isis backbone-----------| Cheers. - abe > > cheers, > Eduard > > > ---------- > > From: Mike Shand[SMTP:mshand@cisco.com] > > Sent: dinsdag 20 juni 2000 20:34 > > To: Metz, E.T.; Dave Katz; 'truskows@cisco.com' > > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net > > Subject: RE: [Isis-wg] Areas in ISIS > > > > At 20:14 20/06/2000 +0100, Metz, E.T. wrote: > > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area > > would > > >it? It needs to be L2 or L1/L2 at least. > > > > Were running into terminological inexactitudes here :-) > > > > Yes it does need to be L2, but one way of designing an IS-IS network is to > > > > make an area of L1/L2 routers which constitutes the backbone and then hang > > > > all the other areas off this one. Of course you need at least one L1/L2 > > router in each of those areas, so the backbone (in the sense we were > > talking before, i.e. the set of connected L2 routers - or the distribution > > > > domain of L2 LSPs) spans multiple areas. But it does look rather like the > > OSPF case, where the backbone is a single area (0 in that case). > > > > Mike (S) > > > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ==.==.==.==.== Abe Martey San Jose, CA 408 527 9149 From truskows@cisco.com Wed, 21 Jun 2000 9:44:15 PDT Date: Wed, 21 Jun 2000 9:44:15 PDT From: Mike Truskowski truskows@cisco.com Subject: [Isis-wg] Areas in ISIS Ugh... I think this might be a little confusing.... No doubt that this will work but ... Area X "must" have a contiguous space of L2 or L2/L1 connected to each Area N... In other words, Assuming that the Area N's are only connected thru Area X, then there must be a set of L2 instances w/i area X that connect Area N to Area M.... Hence, the L2(/L1) routers in area X and the L1/L2 routers in Area N form the backbone... The L1's are not part of the backbone. The L2's are analogus to ospf's area 0. Not the L1's. Personally, I try to stay far away from this. mike > > > > On Tue, Jun 20, 2000 at 08:50:38PM +0100, Metz, E.T. wrote: > > Small question (related to below), if you do create a separate backbone > > (physically, or at least similar to OSPF area 0), is it then needed or > > advantagous to have L1 routing in this area. Instead of just L2? > > You could have a physical area x designated as the "core" of the > backbone..and all routers in this area don't have to run L1. Actually > they shouldn't since it'll be a resource waste....however your > "true" isis backbone will extend to the L1L2 border routers of the > various other areas. > > [L1]=====[L1L2]=====[L2]=====[L2]======[L1L2]======[L1] > > |---area 1----| |--area x---| |----Area 2----| > |----------isis backbone-----------| > > > Cheers. > > - abe > > > > > cheers, > > Eduard > > > > > ---------- > > > From: Mike Shand[SMTP:mshand@cisco.com] > > > Sent: dinsdag 20 juni 2000 20:34 > > > To: Metz, E.T.; Dave Katz; 'truskows@cisco.com' > > > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net > > > Subject: RE: [Isis-wg] Areas in ISIS > > > > > > At 20:14 20/06/2000 +0100, Metz, E.T. wrote: > > > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area > > > would > > > >it? It needs to be L2 or L1/L2 at least. > > > > > > Were running into terminological inexactitudes here :-) > > > > > > Yes it does need to be L2, but one way of designing an IS-IS network is to > > > > > > make an area of L1/L2 routers which constitutes the backbone and then hang > > > > > > all the other areas off this one. Of course you need at least one L1/L2 > > > router in each of those areas, so the backbone (in the sense we were > > > talking before, i.e. the set of connected L2 routers - or the distribution > > > > > > domain of L2 LSPs) spans multiple areas. But it does look rather like the > > > OSPF case, where the backbone is a single area (0 in that case). > > > > > > Mike (S) > > > > > > > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > -- > > > ==.==.==.==.== > Abe Martey > San Jose, CA > 408 527 9149 > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > From jparker@nexabit.com Fri, 23 Jun 2000 10:05:59 -0400 Date: Fri, 23 Jun 2000 10:05:59 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] RE: LSP hierarchy with MPLS TE > Folks, > > Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.txt > be accepted as a work group document. So far I've only seen support. > If there are no objects by 6/27, we'll declare it so. > > ...George I find this draft a useful addition to the discussion of TE, and would support it's adoption as an MPLS group document. However, I am a bit puzzled by the last paragraph before section 4.3 (bottom of page 5). "Route computation procedures should not perform two-way connectivity check on the links used by the procedures. That is, the two way check should not be performed on one-way pipes, as they will fail." I agree that relaxing this test for one-way links is a Good Thing. But looking at the aged out draft "IS-IS extensions for Traffic Engineering" I don't understand how we distinguish "forward adjacencies" that are unidirectional LSPs from point-to-point adjacencies, where we should retain the test. Perhaps this will be addressed in the next rev of the IS-IS TE doc. - jeff parker - Lucent Technologies From naiming@redback.com Fri, 23 Jun 2000 14:49:29 -0700 Date: Fri, 23 Jun 2000 14:49:29 -0700 From: Naiming Shen naiming@redback.com Subject: [Isis-wg] RE: LSP hierarchy with MPLS TE don't want to speak for the authors, but the difference from a disabled TE link is that this LSP link has a usable TE metric set. this hierarchy scheme is independent of LSP bundling, you can announce and set different metric on different LSPs the same source/dest pair. so i don't see why the Mux TLV should be required. an interesting question is how do you set the link metric to be max(1, (the TE metric of the FA-LSP path) - 1)? something like the one mentioned in an expired draft:-) thanks. ]Naiming Shen wrote: ] ]> I think you can use the cue which normal IS-IS ignores this type of ]> links, which is the links are having the default metric of (2^24 - 1). ] ]there is a chance to confuse that with a disabled TE link of course. ]Also (although that's minor) it's a disadvantage that if i choose not to ]support LSP bundling. I'd loose control about which of the forwarding ]adjacencies other LSRs prefer based on admin metric. ] ]It seems to me much wiser to use the presence of the Link Mux Capability sub- TLV ]as indication that only a one-way check is necessary. I assume that ]sub-TLV is mandatory on forwarding adjacencies, the draft is not 100% ]clear about that one. ] ] any clarification from the authors ? ] ] -- tony ] ] ]> ]> ]> ]> Folks, ]> ]> ]> ]> Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.t xt ]> ]> be accepted as a work group document. So far I've only seen support. ]> ]> If there are no objects by 6/27, we'll declare it so. ]> ]> ]> ]> ...George ]> ] ]> ]I find this draft a useful addition to the discussion of TE, and would ]> ]support it's adoption as an MPLS group document. ]> ] ]> ]However, I am a bit puzzled by the last paragraph before ]> ]section 4.3 (bottom of page 5). ]> ] ]> ] "Route computation procedures should not perform two-way ]> ] connectivity check on the links used by the procedures. ]> ] That is, the two way check should not be performed on ]> ] one-way pipes, as they will fail." ]> ] ]> ]I agree that relaxing this test for one-way links is a Good Thing. But ]> ]looking at the aged out draft "IS-IS extensions for Traffic Engineering" ]> ] I don't understand how we distinguish ]> ]"forward adjacencies" that are unidirectional LSPs from point-to-point ]> ]adjacencies, where we should retain the test. ]> ] ]> ]Perhaps this will be addressed in the next rev of the IS-IS TE doc. ]> ] ] ] ] - Naiming From naiming@redback.com Fri, 23 Jun 2000 08:27:43 -0700 Date: Fri, 23 Jun 2000 08:27:43 -0700 From: Naiming Shen naiming@redback.com Subject: [Isis-wg] RE: LSP hierarchy with MPLS TE I think you can use the cue which normal IS-IS ignores this type of links, which is the links are having the default metric of (2^24 - 1). ]> Folks, ]> ]> Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.txt ]> be accepted as a work group document. So far I've only seen support. ]> If there are no objects by 6/27, we'll declare it so. ]> ]> ...George ] ]I find this draft a useful addition to the discussion of TE, and would ]support it's adoption as an MPLS group document. ] ]However, I am a bit puzzled by the last paragraph before ]section 4.3 (bottom of page 5). ] ] "Route computation procedures should not perform two-way ] connectivity check on the links used by the procedures. ] That is, the two way check should not be performed on ] one-way pipes, as they will fail." ] ]I agree that relaxing this test for one-way links is a Good Thing. But ]looking at the aged out draft "IS-IS extensions for Traffic Engineering" ] I don't understand how we distinguish ]"forward adjacencies" that are unidirectional LSPs from point-to-point ]adjacencies, where we should retain the test. ] ]Perhaps this will be addressed in the next rev of the IS-IS TE doc. ] ]- jeff parker ]- Lucent Technologies ] ] ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming From kireeti@juniper.net Fri, 23 Jun 2000 10:10:36 -0700 (PDT) Date: Fri, 23 Jun 2000 10:10:36 -0700 (PDT) From: Kireeti Kompella kireeti@juniper.net Subject: [Isis-wg] RE: LSP hierarchy with MPLS TE Hi Jeff, > I find this draft a useful addition to the discussion of TE, and would > support it's adoption as an MPLS group document. Thanks! > However, I am a bit puzzled by the last paragraph before > section 4.3 (bottom of page 5). > "Route computation procedures should not perform two-way > connectivity check on the links used by the procedures. > That is, the two way check should not be performed on > one-way pipes, as they will fail." Here's the deal: if you have a unidirectional FA-LSP from A to B, but no LSP from B to A, and you want to compute a _TE_ path for another LSP to tunnel over the FA-LSP, the two-way check will not allow the FA-LSP to be used. Hence the above statement. > I agree that relaxing this test for one-way links is a Good Thing. Note that for CSPF (i.e., TE path) computation, discarding the two-way check will not cause routing loops. However, it's trivial to come up with an example where if a router doesn't do the two-way check for 'regular' SPF but other routers do, you will get permanent routing loops. Yes, it might be a Good Thing to eventually relax the two-way check for regular SPF as well, but that would take much more work. > looking at the aged out draft "IS-IS extensions for Traffic Engineering" > I don't understand how we distinguish > "forward adjacencies" that are unidirectional LSPs from point-to-point > adjacencies, where we should retain the test. Forwarding adjacencies are (almost) indistinguishable from point-to-point links. However, the distinction we're making is CSPF vs. regular SPF, not FAs vs. p2p links. For *all* CSPF computations, we recommend not doing the two-way check. For all SPF computations, we _highly_ recommend doing the two-way check (for fear of routing loops) until such time that there is means to achieve consensus among *all* the routers in an ISIS level/OSPF area not to do the two-way check. Kireeti. From prz@redback.com Fri, 23 Jun 2000 11:07:19 -0700 Date: Fri, 23 Jun 2000 11:07:19 -0700 From: Tony Przygienda prz@redback.com Subject: [Isis-wg] RE: LSP hierarchy with MPLS TE Naiming Shen wrote: > I think you can use the cue which normal IS-IS ignores this type of > links, which is the links are having the default metric of (2^24 - 1). there is a chance to confuse that with a disabled TE link of course. Also (although that's minor) it's a disadvantage that if i choose not to support LSP bundling. I'd loose control about which of the forwarding adjacencies other LSRs prefer based on admin metric. It seems to me much wiser to use the presence of the Link Mux Capability sub-TLV as indication that only a one-way check is necessary. I assume that sub-TLV is mandatory on forwarding adjacencies, the draft is not 100% clear about that one. any clarification from the authors ? -- tony > > > ]> Folks, > ]> > ]> Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.txt > ]> be accepted as a work group document. So far I've only seen support. > ]> If there are no objects by 6/27, we'll declare it so. > ]> > ]> ...George > ] > ]I find this draft a useful addition to the discussion of TE, and would > ]support it's adoption as an MPLS group document. > ] > ]However, I am a bit puzzled by the last paragraph before > ]section 4.3 (bottom of page 5). > ] > ] "Route computation procedures should not perform two-way > ] connectivity check on the links used by the procedures. > ] That is, the two way check should not be performed on > ] one-way pipes, as they will fail." > ] > ]I agree that relaxing this test for one-way links is a Good Thing. But > ]looking at the aged out draft "IS-IS extensions for Traffic Engineering" > ] I don't understand how we distinguish > ]"forward adjacencies" that are unidirectional LSPs from point-to-point > ]adjacencies, where we should retain the test. > ] > ]Perhaps this will be addressed in the next rev of the IS-IS TE doc. > ] From david.wang@metro-optix.com Sat, 17 Jun 2000 16:04:26 -0500 Date: Sat, 17 Jun 2000 16:04:26 -0500 From: David Wang david.wang@metro-optix.com Subject: [Isis-wg] Basic Question about IS-IS Routing protocol Dear Friends, I need to learn some basics of IS-IS routing protocol and how it works in IP environment. I cannot find a book, a tutorial or a white paper. 1. Can somebody recommend me some book or tutorial or a white papers? 2. Who is running CLNP instead of IP in their network beside SONET network management software? Can I learn IS-IS with touch CLNP? 3. What is the major difference between IS-IS and OSPF? 4. When use IS-IS to route IP packets the Link State Advertisement packets are also IP packets. People don't have to worry about the OSI CLNP protocol in IP environment. Is this correct? 5. Any other comment and information about IS-IS protocol. Thanks for your help David From danny@ambernetworks.com Fri, 23 Jun 2000 18:20:22 -0600 Date: Fri, 23 Jun 2000 18:20:22 -0600 From: Danny McPherson danny@ambernetworks.com Subject: [Isis-wg] Basic Question about IS-IS Routing protocol > 1. Can somebody recommend me some book or tutorial or a white papers? Radia Perlman's "Interconnections, Second Edition" is the most useful book I'm aware of. > 2. Who is running CLNP instead of IP in their network beside SONET network > management software? Can I learn IS-IS with touch CLNP? Yes, as CLNS traffic forwarding isn't required (though OSI stack support is per IS-IS packet maintain their original format). IP-only IS-IS is actually the most common implementation of IS-IS today in IP routers (most don't support CLNS traffic forwarding). For IP-only IS-IS, the only OSIish thing you need is NSAP, which is used to determine the routers area and give it a system ID. > 3. What is the major difference between IS-IS and OSPF? The primary difference is that OSPF is an "open standard protocol", was designed expressly for IP, and runs on top of IP. IS-IS was initially designed to support CLNP, then extended to support IP as well. There are lots of other differences, though I'd rather not trigger yet another debate on them. Consulting the MPLS WG mailing list archives, and perhaps the NANOG archives (www.nanog.org) should yield some useful information. > 4. When use IS-IS to route IP packets the Link State Advertisement packets > are also IP packets. People don't have to worry about the OSI CLNP protocol > in IP environment. Is this correct? No. IS-IS LSPs (somewhat synonymous to OSPF LS Updates) contain TLVs that describe IP or CLNP. The encapsulation remains the same and OSI stack support is required. Though again, forwarding capability necessarily isn't. > 5. Any other comment and information about IS-IS protocol. ISO10589 & RFC 1195 may provide some useful information. The OSPF RFC(s) contain a nice "tutorial" on LS routing and the like. -danny From jjl@one.com Mon, 26 Jun 2000 12:18:37 -0400 Date: Mon, 26 Jun 2000 12:18:37 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] Areas in ISIS It's not important to avoid loops of areas. This does not contradict what Mike Shand said. Another way to think of it is that, for robustness, you want to make sure that your backbone is constructed in a way so that no single link or router failure could partition the backbone. Likewise, each area should be constructed so that no single link or router failure can partition the area. In Mike's example, the backbone wouldn't be partitioned, but the area would. As Mike says, you need to carefully plan the toplogy of your "Level 2 subdomain", as it's called in ISO 10589, just as you carefully plan the topology of each area. When showing a graphic of the whole topology, it's usually a good idea to render the L2 links in a special color, so that it jumps out even though it's not physically separate from the rest of the network. Of course, this highlighting is unnecessary if you always plan an "Area 0" containing most (but not all!) of your Level 2 backbone. The rest of the L2 backbone would be the one-hop links from the Area 0 routers to the L2 routers in the other areas. For robustness, you would want at least two L2 routers in each area, each with its own link to a different router in Area 0. But as soon as you depart from this plan (by chaining subtended areas, for example), then you need to look at your L2 backbone and make sure it is contiguous (even in the event of a link or router failure). Regards, Jeff At 08:14 PM 6/20/00 +0100, you wrote: > >Thanks for the clarifications ... > >As for the situation I was thinking of, this was indeed the case where you >have multiple areas and the backbone is formed of the "edges" of the areas >and the links between the areas. I didn't really think of a "chain" of >areas, the loop issue is although interesting. > >I like the concept of this "virtual backbone" is ISIS, although in >(re)designing networks you'll probably have to clearly keep in mind to keep >the backbone contiguos and avoid chains (loops) of areas. While in OSPF this >is more or less forced upon th designer due to the explicit area 0 that has >to present, and to which all other areas should connect. > >cheers, > Eduard > > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area would >it? It needs to be L2 or L1/L2 at least. > >> ---------- >> From: Mike Shand[SMTP:mshand@cisco.com] >> Sent: dinsdag 20 juni 2000 9:02 >> To: Dave Katz >> Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net >> Subject: Re: [Isis-wg] Areas in ISIS >> >> At 13:26 19/06/2000 -0700, Dave Katz wrote: >> >This isn't "physically distinct" in the sense that L1 traffic can >> traverse >> >some of the same links that make up the L2 topology, but it is important >> >to think of the L2 topology as distinct when you design your network, or >> >you can end up in a world of hurt. In particular, if areas A, B, and C >> >are connected through a loop, and there are parts of area B that depend >> >on those L1L2 links for L1 connectivity, a break of the path through >> >area B could not be healed via A and C. >> > >> >In the topology you describe, I would visualize the L2 path as being >> >on the edge of area B, as it (at least to me) presents the weaknesses >> >of the topology more clearly. >> >> Dave, >> I couldn't agree more. The difference between IS-IS and OSPF is >> not primarily one of network design, but one of nomenclature. i.e. in >> IS-IS >> you still need to design a 'backbone', but the backbone isn't named as a >> single area (0) as it is in OSPF. In fact it isn't named at all. Its just >> defined by the connected set of L2 routers. In some designs that will >> correspond to a single L1 area, but in others it may traverse (or as you >> rightly point out ,it is better to think of it as skirting around the edge >> >> of) multiple L1 areas. >> >> Mike >> >> >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg >> > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From jjl@one.com Mon, 26 Jun 2000 12:22:11 -0400 Date: Mon, 26 Jun 2000 12:22:11 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] Areas in ISIS For CLNP, you would need to run L1 as well as L2. Otherwise, you wouldn't be able to manage the routers in Area 0. When a packet arrives in Area 0, the L1 FDB would be consulted, but would be empty or missing, causing the packet to be dropped. I suspect the same might be true for IP traffic. At 09:05 AM 6/21/00 -0700, Abe Martey wrote: > > >On Tue, Jun 20, 2000 at 08:50:38PM +0100, Metz, E.T. wrote: >> Small question (related to below), if you do create a separate backbone >> (physically, or at least similar to OSPF area 0), is it then needed or >> advantagous to have L1 routing in this area. Instead of just L2? > >You could have a physical area x designated as the "core" of the >backbone..and all routers in this area don't have to run L1. Actually >they shouldn't since it'll be a resource waste....however your >"true" isis backbone will extend to the L1L2 border routers of the >various other areas. > > [L1]=====[L1L2]=====[L2]=====[L2]======[L1L2]======[L1] > > |---area 1----| |--area x---| |----Area 2----| > |----------isis backbone-----------| > > >Cheers. > >- abe > >> >> cheers, >> Eduard >> >> > ---------- >> > From: Mike Shand[SMTP:mshand@cisco.com] >> > Sent: dinsdag 20 juni 2000 20:34 >> > To: Metz, E.T.; Dave Katz; 'truskows@cisco.com' >> > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net >> > Subject: RE: [Isis-wg] Areas in ISIS >> > >> > At 20:14 20/06/2000 +0100, Metz, E.T. wrote: >> > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area >> > would >> > >it? It needs to be L2 or L1/L2 at least. >> > >> > Were running into terminological inexactitudes here :-) >> > >> > Yes it does need to be L2, but one way of designing an IS-IS network is to >> > >> > make an area of L1/L2 routers which constitutes the backbone and then hang >> > >> > all the other areas off this one. Of course you need at least one L1/L2 >> > router in each of those areas, so the backbone (in the sense we were >> > talking before, i.e. the set of connected L2 routers - or the distribution >> > >> > domain of L2 LSPs) spans multiple areas. But it does look rather like the >> > OSPF case, where the backbone is a single area (0 in that case). >> > >> > Mike (S) >> > >> > >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg > >-- > > >==.==.==.==.== >Abe Martey >San Jose, CA >408 527 9149 > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From truskows@cisco.com Mon, 26 Jun 2000 11:12:52 PDT Date: Mon, 26 Jun 2000 11:12:52 PDT From: Mike Truskowski truskows@cisco.com Subject: [Isis-wg] Areas in ISIS Somehow I'm lost here... I thought we were talking about what is the backbone... Another way to look at this is to consider it from the L1 router view point...in ISIS. I have a hard time following the discussion when scalability and topologies get in the way... How does a L1 router choose an external path... By closest L2 router. How does a router in one area talk to another in a different area? By L2 path. Hence, the backbone must be the set of all L2 routers with external reachability.... irregardless of connectability Now if you want any2any reachability...then the set of L2 routers must be contiguous... so connect the L2 routers like connecting dots in a drawing. Now, do you want to talk topology? Avoiding loops are important. That is why heirarchical networks are easier to maintain and scale... Further, loops just cause more L2 paths to maintain. So avoid loops. And network reliability and robustness... well you can build a network with single L1/L2 paths between areas... when a L2 path goes down then part of the network goes down... you can help the reliability if there are redundant paths out of an area to the backbone.... miket > > It's not important to avoid loops of areas. This does not contradict > what Mike Shand said. > > Another way to think of it is that, for robustness, you want to make sure > that your backbone is constructed in a way so that no single link or > router failure could partition the backbone. Likewise, each area should > be constructed so that no single link or router failure can partition the > area. In Mike's example, the backbone wouldn't be partitioned, but the > area would. > > As Mike says, you need to carefully plan the toplogy of your "Level 2 > subdomain", as it's called in ISO 10589, just as you carefully plan > the topology of each area. When showing a graphic of the whole topology, > it's usually a good idea to render the L2 links in a special color, > so that it jumps out even though it's not physically separate from > the rest of the network. > > Of course, this highlighting is unnecessary if you always plan an > "Area 0" containing most (but not all!) of your Level 2 backbone. > The rest of the L2 backbone would be the one-hop links from the Area > 0 routers to the L2 routers in the other areas. For robustness, you > would want at least two L2 routers in each area, each with its own link > to a different router in Area 0. But as soon as you depart from this > plan (by chaining subtended areas, for example), then you need to > look at your L2 backbone and make sure it is contiguous (even in the > event of a link or router failure). > > Regards, > Jeff > > At 08:14 PM 6/20/00 +0100, you wrote: > > > >Thanks for the clarifications ... > > > >As for the situation I was thinking of, this was indeed the case where you > >have multiple areas and the backbone is formed of the "edges" of the areas > >and the links between the areas. I didn't really think of a "chain" of > >areas, the loop issue is although interesting. > > > >I like the concept of this "virtual backbone" is ISIS, although in > >(re)designing networks you'll probably have to clearly keep in mind to keep > >the backbone contiguos and avoid chains (loops) of areas. While in OSPF this > >is more or less forced upon th designer due to the explicit area 0 that has > >to present, and to which all other areas should connect. > > > >cheers, > > Eduard > > > > > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area would > >it? It needs to be L2 or L1/L2 at least. > > > >> ---------- > >> From: Mike Shand[SMTP:mshand@cisco.com] > >> Sent: dinsdag 20 juni 2000 9:02 > >> To: Dave Katz > >> Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net > >> Subject: Re: [Isis-wg] Areas in ISIS > >> > >> At 13:26 19/06/2000 -0700, Dave Katz wrote: > >> >This isn't "physically distinct" in the sense that L1 traffic can > >> traverse > >> >some of the same links that make up the L2 topology, but it is important > >> >to think of the L2 topology as distinct when you design your network, or > >> >you can end up in a world of hurt. In particular, if areas A, B, and C > >> >are connected through a loop, and there are parts of area B that depend > >> >on those L1L2 links for L1 connectivity, a break of the path through > >> >area B could not be healed via A and C. > >> > > >> >In the topology you describe, I would visualize the L2 path as being > >> >on the edge of area B, as it (at least to me) presents the weaknesses > >> >of the topology more clearly. > >> > >> Dave, > >> I couldn't agree more. The difference between IS-IS and OSPF is > >> not primarily one of network design, but one of nomenclature. i.e. in > >> IS-IS > >> you still need to design a 'backbone', but the backbone isn't named as a > >> single area (0) as it is in OSPF. In fact it isn't named at all. Its just > >> defined by the connected set of L2 routers. In some designs that will > >> correspond to a single L1 area, but in others it may traverse (or as you > >> rightly point out ,it is better to think of it as skirting around the edge > >> > >> of) multiple L1 areas. > >> > >> Mike > >> > >> > >> > >> _______________________________________________ > >> Isis-wg mailing list - Isis-wg@external.juniper.net > >> http://external.juniper.net/mailman/listinfo/isis-wg > >> > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > ____________________________________________________________________ > > Jeff Learman Internet: jjl@one.com > Engineering Manager Voice: (734)-975-7323 > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > 2725 South Industrial Pkwy, Suite 100 > Ann Arbor, MI 48104 USA > ____________________________________________________________________ > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > From NZvaig@adtech-inc.com Mon, 26 Jun 2000 11:00:23 -1000 Date: Mon, 26 Jun 2000 11:00:23 -1000 From: Nava.Zvaig NZvaig@adtech-inc.com Subject: [Isis-wg] ISIS code This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDFB1.912A6686 Content-Type: text/plain; charset="iso-8859-1" Hi all, I resubmit this message in case someone has some info... > Is there any software/shareware/freeware available for ISIS and ISIS-TE? > TIA, > Nava ------_=_NextPart_001_01BFDFB1.912A6686 Content-Type: text/html; charset="iso-8859-1" ISIS code

Hi all,

I resubmit this message in case someone has some info...


> Is there any software/shareware/freeware available for ISIS and ISIS-TE?

> TIA,
> Nava

------_=_NextPart_001_01BFDFB1.912A6686-- From naiming@redback.com Mon, 26 Jun 2000 15:39:53 -0700 Date: Mon, 26 Jun 2000 15:39:53 -0700 From: Naiming Shen naiming@redback.com Subject: [Isis-wg] Areas in ISIS For IP, level-1 routes can be imported into level-2 domain on the L12 routers. This is done by default on some of the popular ISIS implementations. ] ]For CLNP, you would need to run L1 as well as L2. Otherwise, ]you wouldn't be able to manage the routers in Area 0. ]When a packet arrives in Area 0, the L1 FDB would ]be consulted, but would be empty or missing, causing the ]packet to be dropped. ] ]I suspect the same might be true for IP traffic. ] ]At 09:05 AM 6/21/00 -0700, Abe Martey wrote: ]> ]> ]>On Tue, Jun 20, 2000 at 08:50:38PM +0100, Metz, E.T. wrote: ]>> Small question (related to below), if you do create a separate backbone ]>> (physically, or at least similar to OSPF area 0), is it then needed or ]>> advantagous to have L1 routing in this area. Instead of just L2? ]> ]>You could have a physical area x designated as the "core" of the ]>backbone..and all routers in this area don't have to run L1. Actually ]>they shouldn't since it'll be a resource waste....however your ]>"true" isis backbone will extend to the L1L2 border routers of the ]>various other areas. ]> ]> [L1]=====[L1L2]=====[L2]=====[L2]======[L1L2]======[L1] ]> ]> |---area 1----| |--area x---| |----Area 2----| ]> |----------isis backbone-----------| ]> ]> ]>Cheers. ]> ]>- abe ]> ]>> ]>> cheers, ]>> Eduard ]>> ]>> > ---------- ]>> > From: Mike Shand[SMTP:mshand@cisco.com] ]>> > Sent: dinsdag 20 juni 2000 20:34 ]>> > To: Metz, E.T.; Dave Katz; 'truskows@cisco.com' ]>> > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net ]>> > Subject: RE: [Isis-wg] Areas in ISIS ]>> > ]>> > At 20:14 20/06/2000 +0100, Metz, E.T. wrote: ]>> > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area ]>> > would ]>> > >it? It needs to be L2 or L1/L2 at least. ]>> > ]>> > Were running into terminological inexactitudes here :-) ]>> > ]>> > Yes it does need to be L2, but one way of designing an IS-IS network ]is to ]>> > ]>> > make an area of L1/L2 routers which constitutes the backbone and then ]hang ]>> > ]>> > all the other areas off this one. Of course you need at least one L1/L2 ]>> > router in each of those areas, so the backbone (in the sense we were ]>> > talking before, i.e. the set of connected L2 routers - or the ]distribution ]>> > ]>> > domain of L2 LSPs) spans multiple areas. But it does look rather like ]the ]>> > OSPF case, where the backbone is a single area (0 in that case). ]>> > ]>> > Mike (S) ]>> > ]>> > ]>> ]>> _______________________________________________ ]>> Isis-wg mailing list - Isis-wg@external.juniper.net ]>> http://external.juniper.net/mailman/listinfo/isis-wg ]> ]>-- ]> ]> ]>==.==.==.==.== ]>Abe Martey ]>San Jose, CA ]>408 527 9149 ]> ]>_______________________________________________ ]>Isis-wg mailing list - Isis-wg@external.juniper.net ]>http://external.juniper.net/mailman/listinfo/isis-wg ]> ]> ]____________________________________________________________________ ] ] Jeff Learman Internet: jjl@one.com ] Engineering Manager Voice: (734)-975-7323 ] ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 ] 2725 South Industrial Pkwy, Suite 100 ] Ann Arbor, MI 48104 USA ]____________________________________________________________________ ] ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming From azinin@cisco.com Tue, 27 Jun 2000 08:13:16 -0700 Date: Tue, 27 Jun 2000 08:13:16 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] Areas in ISIS Also, IP forwarding doesn't care about route types. L1 or L2, it just looks for the best match in the very (and single, which is important) routing table. > For IP, level-1 routes can be imported into level-2 domain on the > L12 routers. This is done by default on some of the popular ISIS > implementations. > ] > ]For CLNP, you would need to run L1 as well as L2. Otherwise, > ]you wouldn't be able to manage the routers in Area 0. > ]When a packet arrives in Area 0, the L1 FDB would > ]be consulted, but would be empty or missing, causing the > ]packet to be dropped. > ] > ]I suspect the same might be true for IP traffic. > ] > ]At 09:05 AM 6/21/00 -0700, Abe Martey wrote: > ]> > ]> > ]>On Tue, Jun 20, 2000 at 08:50:38PM +0100, Metz, E.T. wrote: > ]>> Small question (related to below), if you do create a separate backbone > ]>> (physically, or at least similar to OSPF area 0), is it then needed or > ]>> advantagous to have L1 routing in this area. Instead of just L2? > ]> > ]>You could have a physical area x designated as the "core" of the > ]>backbone..and all routers in this area don't have to run L1. Actually > ]>they shouldn't since it'll be a resource waste....however your > ]>"true" isis backbone will extend to the L1L2 border routers of the > ]>various other areas. > ]> > ]> [L1]=====[L1L2]=====[L2]=====[L2]======[L1L2]======[L1] > ]> > ]> |---area 1----| |--area x---| |----Area 2----| > ]> |----------isis backbone-----------| > ]> > ]> > ]>Cheers. > ]> > ]>- abe > ]> > ]>> > ]>> cheers, > ]>> Eduard > ]>> > ]>> > ---------- > ]>> > From: Mike Shand[SMTP:mshand@cisco.com] > ]>> > Sent: dinsdag 20 juni 2000 20:34 > ]>> > To: Metz, E.T.; Dave Katz; 'truskows@cisco.com' > ]>> > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net > ]>> > Subject: RE: [Isis-wg] Areas in ISIS > ]>> > > ]>> > At 20:14 20/06/2000 +0100, Metz, E.T. wrote: > ]>> > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area > ]>> > would > ]>> > >it? It needs to be L2 or L1/L2 at least. > ]>> > > ]>> > Were running into terminological inexactitudes here :-) > ]>> > > ]>> > Yes it does need to be L2, but one way of designing an IS-IS network > ]is to > ]>> > > ]>> > make an area of L1/L2 routers which constitutes the backbone and then > ]hang > ]>> > > ]>> > all the other areas off this one. Of course you need at least one L1/L2 > ]>> > router in each of those areas, so the backbone (in the sense we were > ]>> > talking before, i.e. the set of connected L2 routers - or the > ]distribution > ]>> > > ]>> > domain of L2 LSPs) spans multiple areas. But it does look rather like > ]the > ]>> > OSPF case, where the backbone is a single area (0 in that case). > ]>> > > ]>> > Mike (S) > ]>> > > ]>> > > ]>> > ]>> _______________________________________________ > ]>> Isis-wg mailing list - Isis-wg@external.juniper.net > ]>> http://external.juniper.net/mailman/listinfo/isis-wg > ]> > ]>-- > ]> > ]> > ]>==.==.==.==.== > ]>Abe Martey > ]>San Jose, CA > ]>408 527 9149 > ]> > ]>_______________________________________________ > ]>Isis-wg mailing list - Isis-wg@external.juniper.net > ]>http://external.juniper.net/mailman/listinfo/isis-wg > ]> > ]> > ]____________________________________________________________________ > ] > ] Jeff Learman Internet: jjl@one.com > ] Engineering Manager Voice: (734)-975-7323 > ] ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > ] 2725 South Industrial Pkwy, Suite 100 > ] Ann Arbor, MI 48104 USA > ]____________________________________________________________________ > ] > ]_______________________________________________ > ]Isis-wg mailing list - Isis-wg@external.juniper.net > ]http://external.juniper.net/mailman/listinfo/isis-wg > - Naiming > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From Internet-Drafts@ietf.org Tue, 11 Jul 2000 06:29:49 -0400 Date: Tue, 11 Jul 2000 06:29:49 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mesh-group-01.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Mesh Groups Author(s) : R. Balay, D. Katz, J. Parker Filename : draft-ietf-isis-wg-mesh-group-01.txt Pages : 9 Date : 10-Jul-00 This document describes a mechanism to reduce redundant packet transmissions for the IS-IS Routing protocol, as described in ISO 10589 [1]. The described mechanism can be used to reduce the flooding of Link State PDUs (LSPs) in IS-IS topologies. The net effect is to engineer a flooding topology for LSPs which is a subset of the physical topology. This draft serves to document the existing behavior in deployed implementations. The draft describes behaviors that are backwards compatible with implementations that do not support this feature. This document is provided to the IETF working group on IS-IS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mesh-group-01.txt 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-isis-wg-mesh-group-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-ietf-isis-wg-mesh-group-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. --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: <20000710151110.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mesh-group-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-mesh-group-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000710151110.I-D@ietf.org> --OtherAccess-- --NextPart-- From jparker@nexabit.com Tue, 11 Jul 2000 09:50:40 -0400 Date: Tue, 11 Jul 2000 09:50:40 -0400 From: Jeff Parker jparker@nexabit.com Subject: [Isis-wg] Updates to the ISIS Mib I sent out a list of differences and changes to the ISIS working group about 10 days ago, shortly after the MIB was announced on the mailing list. http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-03.txt It appears that my message was too big to be bounced automatically off the mail relay, and it is sitting now in some relay server limbo waiting to be vetted and sent out. If you would like to get a copy of these files, I would be happy to e-mail them to you privately. > Enclosed below is a high-level list of the changes (changes.txt) > and an edited version of (most of) the diffs between versions -02 and -03. > Suggestions and editorial comments always welcome. > > - jeff parker - jeff parker - Lucent Technology From Internet-Drafts@ietf.org Wed, 12 Jul 2000 06:30:02 -0400 Date: Wed, 12 Jul 2000 06:30:02 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-domain-wide-03.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Domain-wide Prefix Distribution with Two-Level IS-IS Author(s) : T. Li, T. Przygienda, H. Smit Filename : draft-ietf-isis-domain-wide-03.txt Pages : 10 Date : 11-Jul-00 This document describes extensions to the IS-IS protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589 [1], with extensions for supporting IPv4 specified in RFC 1195 [2]. This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) [routers] can distribute IP prefixes between level 1 and level 2 and vice versa. This distribution requires certain restrictions to insure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-domain-wide-03.txt 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-isis-domain-wide-03.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-isis-domain-wide-03.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: <20000711134432.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-domain-wide-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-domain-wide-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000711134432.I-D@ietf.org> --OtherAccess-- --NextPart-- From Internet-Drafts@ietf.org Wed, 12 Jul 2000 06:32:48 -0400 Date: Wed, 12 Jul 2000 06:32:48 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-snp-checksum-02.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Optional Checksums in ISIS Author(s) : A. Przygienda Filename : draft-ietf-isis-wg-snp-checksum-02.txt Pages : 3 Date : 11-Jul-00 This draft describes an optional extension to IS-IS [ISO90, Cal90a, Cal90b], used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. IS-IS originally doesn't provide CSNP adn PSNP checksums, relying on the underlying layers to verify the integrity of information provided. Experience with the protocol shows that this precondition does not always hold and scenarios can be imagined that impact protocol functionality. This document introduces a new optional TLV providing checksums. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-snp-checksum-02.txt 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-isis-wg-snp-checksum-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-isis-wg-snp-checksum-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: <20000711142807.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-snp-checksum-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-snp-checksum-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000711142807.I-D@ietf.org> --OtherAccess-- --NextPart-- From Radia.Perlman@East.Sun.COM Wed, 12 Jul 2000 13:14:50 -0400 (EDT) Date: Wed, 12 Jul 2000 13:14:50 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-wg-snp-checksum-02.txt >> The implementation MUST either omit the optional checksum on an >> interface or send a 0 checksum value if it includes in the PDU >> signatures that provide equivalent or stronger functionality, such as >> HMAC or MD5. Just for curiosity...why not just say it must omit it? What value is there in including the TLV with a 0 checksum value? Radia From david.wang@metro-optix.com Thu, 6 Jul 2000 10:24:55 -0500 Date: Thu, 6 Jul 2000 10:24:55 -0500 From: David Wang david.wang@metro-optix.com Subject: [Isis-wg] Basic Question about IS-IS Routing protocol Dear Friends, Thank you very much for all the precious help you give to me. I am reading those documents and books. At the mean time I want to ask your help one more time. 1. What documents specify all the layer 2 encapsulations for the IS-IS PDU in IP-only environment? For example when use Ethernet, 802.3/LLC frame format must be used and Ethernet II frame format cannot be used. I got this information from draft-kaplan-is-is-ext-eth-02.txt. I assume I should use 0xFE for the SAP value for ISO in the 802.3/LLC frame. How about PPP encapsulation? What value should be put in the "protocol" field of the PPP frame and what NCP packets are used to choose and configure the network-layer protocols? For HDLC what has to be done to accommodate the IS-IS PDU? 2. There is no CLNP address in the IS-IS PDU but why FRC 1195 still ask each node to have OSI-style address? Following are from RFC 1195 section 3.3 : 3.3 Addressing Routers in IS-IS Packets The IS-IS packet formats explicitly require that OSI-style addresses of routers appear in the IS-IS packets. For example, these addresses are used to determine area membership of routers. It is therefore necessary for all routers making use of the IS-IS protocol to have OSI style addresses assigned. For IP-only routers, these addresses will be used only in the operation of the IS-IS protocol, and are not used for any other purpose (such as the operation of EGP, ICMP, or other TCP/IP protocols). 3. What is the possibility that the "IS-IS over IPv4" and the "Extended Ethernet Frame Size Support" be accepted by the industry? Thank You very much David From prz@redback.com Wed, 12 Jul 2000 11:57:16 -0700 Date: Wed, 12 Jul 2000 11:57:16 -0700 From: Tony Przygienda prz@redback.com Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-wg-snp-checksum-02.txt Radia Perlman - Boston Center for Networking wrote: > >> The implementation MUST either omit the optional checksum on an > >> interface or send a 0 checksum value if it includes in the PDU > >> signatures that provide equivalent or stronger functionality, such as > >> HMAC or MD5. > > Just for curiosity...why not just say it must omit it? What value is > there in including the TLV with a 0 checksum value? probably MUST omit would be better, you're right ;-) -- tony From dkatz@juniper.net Wed, 12 Jul 2000 20:16:22 -0700 (PDT) Date: Wed, 12 Jul 2000 20:16:22 -0700 (PDT) From: Dave Katz dkatz@juniper.net Subject: [Isis-wg] Basic Question about IS-IS Routing protocol 1. What documents specify all the layer 2 encapsulations for the IS-IS PDU in IP-only environment? For example when use Ethernet, 802.3/LLC frame format must be used and Ethernet II frame format cannot be used. I got this information from draft-kaplan-is-is-ext-eth-02.txt. I assume I should use 0xFE for the SAP value for ISO in the 802.3/LLC frame. How about PPP encapsulation? What value should be put in the "protocol" field of the PPP frame and what NCP packets are used to choose and configure the network-layer protocols? For HDLC what has to be done to accommodate the IS-IS PDU? Standard OSI framing is used, so you get 802.2/SAP on LAN media, and RFC 1377 for PPP. The cisco HDLC kludge is to use ethertype FEFE. 2. There is no CLNP address in the IS-IS PDU but why FRC 1195 still ask each node to have OSI-style address? Following are from RFC 1195 section 3.3 : Backward compatibility, and laziness. There needs to be a six octet system ID, and at least a one octet area address, so you could configure it any way you want to that will produce values for these items. The first pervasive implementation was dual-mode and so NSAP addresses made sense; later implementations did it the same way since you need to configure those bytes somehow. 3. What is the possibility that the "IS-IS over IPv4" and the "Extended Ethernet Frame Size Support" be accepted by the industry? Extended frame size is likely (since folks want to use >1500 MTU on gigE and also want to use IS-IS), IPv4 framing doesn't seem to have much support among the dominant players (since it buys little or nothing, adds complexity, and removes one of the nice properties of IS-IS, namely, resistance to packet bombs.) --Dave From Internet-Drafts@ietf.org Thu, 13 Jul 2000 06:26:59 -0400 Date: Thu, 13 Jul 2000 06:26:59 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-ipv6-01.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Routing IPv6 with IS-IS Author(s) : C. Hopps Filename : draft-ietf-isis-ipv6-01.txt Pages : 6 Date : 12-Jul-00 This draft specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol [0]. The method utilizes the same mechanisms described in RFC 1195 [1]. This is accomplished by adding 2 new TLVs and defining their use. These new TLVs are patterned from the ones described in 'IS-IS extensions for Traffic Engineering' [2]. Just as in RFC 1195 [1] with IPv4 and OSI, this method allows one to route both IPv4 and IPv6 using a single intra-domain routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-01.txt 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-isis-ipv6-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-ietf-isis-ipv6-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. --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: <20000712140131.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-ipv6-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-ipv6-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000712140131.I-D@ietf.org> --OtherAccess-- --NextPart-- From phigginson@ascend.com Fri, 14 Jul 2000 16:20:04 +0100 Date: Fri, 14 Jul 2000 16:20:04 +0100 From: Peter Higginson phigginson@ascend.com Subject: [Isis-wg] ISIS at Pittsburg IETF? Is there going to be a meeting, we don't appear on the current draft agenda? Peter From Peter.Higginson@ascend.com Sun, 16 Jul 2000 08:15:08 +0100 Date: Sun, 16 Jul 2000 08:15:08 +0100 From: Peter Higginson Peter.Higginson@ascend.com Subject: [Isis-wg] ISIS at Pittsburg IETF? Is there going to be a meeting, we don't appear on the current draft agenda? Peter From Internet-Drafts@ietf.org Mon, 17 Jul 2000 06:39:12 -0400 Date: Mon, 17 Jul 2000 06:39:12 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-3way-03.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Three-Way Handshake for IS-IS Point-to-Point Adjacencies Author(s) : D. Katz, R. Saluja Filename : draft-ietf-isis-3way-03.txt Pages : 7 Date : 14-Jul-00 The IS-IS routing protocol (ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines an backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension. Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router. This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-3way-03.txt 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-isis-3way-03.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-isis-3way-03.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: <20000714142554.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-3way-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-3way-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000714142554.I-D@ietf.org> --OtherAccess-- --NextPart-- From kini@bell-labs.com Sun, 16 Jul 2000 03:01:24 -0400 Date: Sun, 16 Jul 2000 03:01:24 -0400 From: Sriganesh Kini kini@bell-labs.com Subject: [Isis-wg] status of TE draft ? What is the status of the draft draft-ietf-isis-traffic-0x.txt ? Thanks === Sriganesh Kini From kini@dnrc.bell-labs.com Mon, 17 Jul 2000 16:05:10 -0400 Date: Mon, 17 Jul 2000 16:05:10 -0400 From: Sriganesh Kini kini@dnrc.bell-labs.com Subject: [Isis-wg] status of TE draft ? What is the latest status of the draft draft-ietf-isis-traffic-xx.txt ? Thanks === Sriganesh Kini From flefauch@cisco.com Fri, 21 Jul 2000 11:24:20 +0200 Date: Fri, 21 Jul 2000 11:24:20 +0200 From: Francois Le Faucheur flefauch@cisco.com Subject: [Isis-wg] Announcing FYI: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to IS-IS, OSPF, RSVP and CR-LDP for support of Diff-Serv-aware MPLS Traffic Engineering Author(s) : F. Le Faucheur, T. Nadeau, A. Chiu, W. Townsend, D. Skalecki Filename : draft-lefaucheur-diff-te-ext-00.txt Pages : 14 Date : 14-Jul-00 A companion document [DIFF-TE-REQTS] defines the requirements for support of Diff-Serv-aware MPLS Traffic Engineering on a per-Class- Type basis, as discussed in the Traffic Engineering Working Group Framework document [TEWG-FW]. This document proposes corresponding extensions to OSPF, ISIS, RSVP and CR-LDP for support of Traffic Engineering on a per-Class-Type basis. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lefaucheur-diff-te-ext-00.txt 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-lefaucheur-diff-te-ext-00.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-lefaucheur-diff-te-ext-00.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. Content-Type: text/plain Content-ID: <20000714142705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lefaucheur-diff-te-ext-00.txt Francois From flefauch@cisco.com Fri, 21 Jul 2000 11:24:20 +0200 Date: Fri, 21 Jul 2000 11:24:20 +0200 From: Francois Le Faucheur flefauch@cisco.com Subject: [Isis-wg] Announcing FYI: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to IS-IS, OSPF, RSVP and CR-LDP for support of Diff-Serv-aware MPLS Traffic Engineering Author(s) : F. Le Faucheur, T. Nadeau, A. Chiu, W. Townsend, D. Skalecki Filename : draft-lefaucheur-diff-te-ext-00.txt Pages : 14 Date : 14-Jul-00 A companion document [DIFF-TE-REQTS] defines the requirements for support of Diff-Serv-aware MPLS Traffic Engineering on a per-Class- Type basis, as discussed in the Traffic Engineering Working Group Framework document [TEWG-FW]. This document proposes corresponding extensions to OSPF, ISIS, RSVP and CR-LDP for support of Traffic Engineering on a per-Class-Type basis. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lefaucheur-diff-te-ext-00.txt 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-lefaucheur-diff-te-ext-00.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-lefaucheur-diff-te-ext-00.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. Content-Type: text/plain Content-ID: <20000714142705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lefaucheur-diff-te-ext-00.txt Francois From iesg-secretary@ietf.org Fri, 21 Jul 2000 09:27:06 -0400 Date: Fri, 21 Jul 2000 09:27:06 -0400 From: The IESG iesg-secretary@ietf.org Subject: [Isis-wg] Document Action: Domain-wide Prefix Distribution with Two-Level IS-IS to Informational The IESG has approved the Internet-Draft 'Domain-wide Prefix Distribution with Two-Level IS-IS' as an Informational RFC. This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are David Oran and Rob Coltun. From azinin@cisco.com Sat, 22 Jul 2000 16:12:23 -0700 Date: Sat, 22 Jul 2000 16:12:23 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] Flooding optimization ID Folks, FYI the draft below. http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-00.txt Authors: Alex Zinin, Mike Shand. Abstract: The flooding algorithm is one of the most important parts of any link state routing protocol. It ensures that all routers within a link state domain converge on the same topological information within a finite period of time. To ensure reliability, typical implementations of the flooding algorithm send new information via all interfaces other than the one the new piece of information was received on. This redundancy is necessary to guarantee that flooding is performed reliably, but implies considerable overhead of utilized bandwidth and CPU time if neighboring routers are connected with more than one link. This document describes a method that reduces this overhead. -- Alex Zinin From jjl@one.com Mon, 24 Jul 2000 13:20:52 -0400 Date: Mon, 24 Jul 2000 13:20:52 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] Flooding optimization ID This RFC looks like a great idea. I have one concern, though, for the IS-IS changes. I think it would be a mistake to place L2-only circuits in the same group as circuits to L1 routers. If we do, we may inadvertently forward L1 packets on L2-only circuits, which would not be backwards compatible. A receiving system might drop it rather than propagate it. I'm not sure what the best fix is. L2 groups could kept separately from L1 groups, where a group's level indicates which kinds of PDUs can be forwarded on it. Thus L2+L1 routers would have two circuit groups. The rest of the text (other than the part defining the groups) could remain the same. Regards, Jeff At 04:12 PM 7/22/00 -0700, Alex Zinin wrote: > Folks, > > FYI the draft below. > > http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-00.txt > > Authors: Alex Zinin, Mike Shand. > > Abstract: > > The flooding algorithm is one of the most important parts of any link > state routing protocol. It ensures that all routers within a link > state domain converge on the same topological information within a > finite period of time. To ensure reliability, typical implementations > of the flooding algorithm send new information via all interfaces > other than the one the new piece of information was received on. This > redundancy is necessary to guarantee that flooding is performed > reliably, but implies considerable overhead of utilized bandwidth and > CPU time if neighboring routers are connected with more than one > link. This document describes a method that reduces this overhead. >-- >Alex Zinin > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ From azinin@cisco.com Tue, 25 Jul 2000 14:27:08 -0700 Date: Tue, 25 Jul 2000 14:27:08 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] Flooding optimization ID Jeff: It is definitely meant to keep L1 and L2 groups separately... We changed wording for clarity. Thanks for pointing this out. http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-01.txt -- Alex Zinin Monday, July 24, 2000, 10:20 AM, Jeff Learman wrote: > This RFC looks like a great idea. I have one concern, though, > for the IS-IS changes. > I think it would be a mistake to place L2-only circuits in the > same group as circuits to L1 routers. If we do, we may > inadvertently forward L1 packets on L2-only circuits, which would > not be backwards compatible. A receiving system might drop it > rather than propagate it. > I'm not sure what the best fix is. L2 groups could kept separately > from L1 groups, where a group's level indicates which kinds of PDUs > can be forwarded on it. Thus L2+L1 routers would have two circuit > groups. The rest of the text (other than the part defining the groups) > could remain the same. > Regards, > Jeff > At 04:12 PM 7/22/00 -0700, Alex Zinin wrote: >> Folks, >> >> FYI the draft below. >> >> http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-00.txt >> >> Authors: Alex Zinin, Mike Shand. >> >> Abstract: >> >> The flooding algorithm is one of the most important parts of any link >> state routing protocol. It ensures that all routers within a link >> state domain converge on the same topological information within a >> finite period of time. To ensure reliability, typical implementations >> of the flooding algorithm send new information via all interfaces >> other than the one the new piece of information was received on. This >> redundancy is necessary to guarantee that flooding is performed >> reliably, but implies considerable overhead of utilized bandwidth and >> CPU time if neighboring routers are connected with more than one >> link. This document describes a method that reduces this overhead. >>-- >>Alex Zinin >> >> >> >>_______________________________________________ >>Isis-wg mailing list - Isis-wg@external.juniper.net >>http://external.juniper.net/mailman/listinfo/isis-wg > ____________________________________________________________________ > Jeff Learman Internet: jjl@one.com > Engineering Manager Voice: (734)-975-7323 > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > 2725 South Industrial Pkwy, Suite 100 > Ann Arbor, MI 48104 USA > ____________________________________________________________________ > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From pst@juniper.net Tue, 25 Jul 2000 16:30:18 -0700 (PDT) Date: Tue, 25 Jul 2000 16:30:18 -0700 (PDT) From: Paul Traina pst@juniper.net Subject: [Isis-wg] isis-wg mailing list administrative information The machine that runs the IS-IS mailing list was mis-configured in our DNS for a short period of time. That caused it to generate mail sourced from a (seemingly) invalid host name, which set off spam filters for a number of you causing your machines to bounce mail sent via the list. You may wish to check the IS-IS WG archives at: http://external.juniper.net/mailman/listinfo/isis-wg for any e-mail your site might have bounced in the last week. I'm sorry for the problem, the NT weenie who messed with the DNS has been appropriately "educated." We now return you to your regular bits and bytes, Paul From prz@redback.com Thu, 27 Jul 2000 12:21:46 -0700 (PDT) Date: Thu, 27 Jul 2000 12:21:46 -0700 (PDT) From: prz@redback.com prz@redback.com Subject: [Isis-wg] Draft Agenda ... Here what I gathered so far Draft Agenda for Pittsburgh: 5 mins Tony Agenda bashing & result of last calls x draft-ietf-isis-domain-wide-02 x draft-ietf-isis-wg-mesh-group-00 x draft-kaplan-isis-ext-eth-01 10 mins Kireeti draft-kompella-isis-ompls-extensions-00 5 mins Mike draft-ietf-zinin-flood-opt-01 10 mins Francois draft-lefaucheur-diff-te-ext-00 5 mins Tony update draft-ietf-isis-wg-snp-checksum-02 I may have missed a request or two since I was digging up my last 3 months worth of mail to find all those and as goes without saying, it's a lot of mail ;-) Comments pls today/tommorow --- tony From prz@net4u.ch Sun, 30 Jul 2000 07:02:03 +0200 (MEST) Date: Sun, 30 Jul 2000 07:02:03 +0200 (MEST) From: Tony Przygienda prz@net4u.ch Subject: [Isis-wg] ISIS Agenda for Pittsburgh Agenda for Pittsburgh: 5 mins Tony Agenda bashing & result of last calls x draft-ietf-isis-domain-wide-02 x draft-ietf-isis-wg-mesh-group-00 x draft-kaplan-isis-ext-eth-01 10 mins Kireeti draft-kompella-isis-ompls-extensions-00 5 mins Mike draft-ietf-zinin-flood-opt-01 10 mins Francois draft-lefaucheur-diff-te-ext-00 10 mins Christian draft-ietf-isis-ipv6-01 5 mins Tony update draft-ietf-isis-wg-snp-checksum-02 From jchin@equipecom.com Thu, 3 Aug 2000 12:26:39 -0400 Date: Thu, 3 Aug 2000 12:26:39 -0400 From: Jasper Chin jchin@equipecom.com Subject: [Isis-wg] General info about IS-IS I'm new to IS-IS and am looking to learn about this routing protocol. Could anyone suggest a roadmap of reading material that would be beneficial? Is there a FAQ on this topic? TIA, J. Chin From oran@cisco.com Sun, 30 Jul 2000 00:18:27 -0400 Date: Sun, 30 Jul 2000 00:18:27 -0400 From: Dave Oran oran@cisco.com Subject: [Isis-wg] FW: SC6 Liaison Statement to the IETF on IS-IS Routing This is a multi-part message in MIME format. ------=_NextPart_000_004E_01BFF9BB.AF0ABBA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_004F_01BFF9BB.AF10D620" ------=_NextPart_001_004F_01BFF9BB.AF10D620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit -----Original Message----- From: jhouldsworth [mailto:jhouldsworth@iclway.co.uk] Sent: Tuesday, July 25, 2000 3:53 AM To: dave oran Cc: Jim Long Subject: SC6 Liaison Statement to the IETF on IS-IS Routing Dave, you should have received the attached liaison statement from the SC6 Secretariat on the proposed creation of an updated version of the IS-IS Standard. I haven't seen it on the wire so I thought it wise to make sure that you have a copy before the upcoming IETF meeting. You will also see that SC6 is requesting a short BOF at the San Diego meeting to make sure that the IETF requirements are properly taken into account. I will not be at the August meeting but both Jim Long (the new WG7 Convenor) and I will be in San Diego. We welcome your comments and assistance with scheduling the requested BOF with your group. Regards Jack Houldsworth ------=_NextPart_001_004F_01BFF9BB.AF10D620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
-----Original Message-----
From: jhouldsworth=20 [mailto:jhouldsworth@iclway.co.uk]
Sent: Tuesday, July 25, = 2000 3:53=20 AM
To: dave oran
Cc: Jim Long
Subject: SC6 = Liaison=20 Statement to the IETF on IS-IS Routing

Dave, you should have received the = attached=20 liaison statement from the SC6 Secretariat on the proposed creation of = an=20 updated version of the IS-IS Standard.  I haven't seen it on the = wire so I=20 thought it wise to make sure that you have a copy before the upcoming = IETF=20 meeting. 
 
You will also see that SC6 is requesting a short BOF = at the=20 San Diego meeting to make sure that the IETF requirements are properly = taken=20 into account.  I will not be at the August meeting but both Jim = Long (the=20 new WG7 Convenor) and I will be in San Diego.
 
We welcome your comments and assistance with = scheduling the=20 requested BOF with your group.
 
Regards
 
Jack Houldsworth
------=_NextPart_001_004F_01BFF9BB.AF10D620-- ------=_NextPart_000_004E_01BFF9BB.AF0ABBA0 Content-Type: application/msword; name="isisliaison.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="isisliaison.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJQAAAAAAAAAA EAAAJwAAAAEAAAD+////AAAAACQAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEARwAJCAAAABK/AAAAAAAAEAAAAAAABAAACQ4AAA4AYmpiao7ZjtkAAAAAAAAAAAAAAAAAAAAA AAAJBBYAHhYAAOyzAQDsswEACQoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAJIAAAAAAAAAkgAAAJIA AAAAAAAAkgAAAAAAAACSAAAAAAAAAJIAAAAAAAAAkgAAABQAAAAAAAAAAAAAAKYAAAAAAAAApgAA AAAAAACmAAAAAAAAAKYAAAAAAAAApgAAAAwAAACyAAAADAAAAKYAAAAAAAAAFwUAALYAAADKAAAA AAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAMoAAAAA AAAA3AQAAAIAAADeBAAAAAAAAN4EAAAAAAAA3gQAAAAAAADeBAAAAAAAAN4EAAAAAAAA3gQAACQA AADNBQAA9AEAAMEHAAB6AAAAAgUAABUAAAAAAAAAAAAAAAAAAAAAAAAAkgAAAAAAAADKAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADKAAAAAAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAAIFAAAAAAAA AgEAAAAAAACSAAAAAAAAAJIAAAAAAAAAygAAAAAAAAAAAAAAAAAAAMoAAAAAAAAAygAAAAAAAAAC AQAAAAAAAAIBAAAAAAAAAgEAAAAAAADKAAAACgAAAJIAAAAAAAAAygAAAAAAAACSAAAAAAAAAMoA AAAAAAAA3AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAApgAAAAAAAACmAAAAAAAAAJIAAAAAAAAAkgAA AAAAAACSAAAAAAAAAJIAAAAAAAAAygAAAAAAAADcBAAAAAAAAAIBAADaAwAAAgEAAAAAAAAAAAAA AAAAANwEAAAAAAAAkgAAAAAAAACSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3AQAAAAAAADKAAAAAAAAAL4AAAAMAAAAAFkz2gn2 vwGmAAAAAAAAAKYAAAAAAAAA1AAAAC4AAADcBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQkJ CQkJCQkJCTdQMjANDVRpdGxlOiBMaWFpc29uIFJlcG9ydCB0byB0aGUgSUVURiBSb3V0aW5nIEFy ZWEgRGlyZWN0b3Igb24gMm5kIENEIGZvciBJU08vSUVDIDEwNTg5IChJUy1JUyBSb3V0aW5nKQ0N U291cmNlOiBJU08vSUVDIEpUQzEvU0M2DQ1JU08vSUVDIEpUQzEvU0M2IFdHNyBpcyBjdXJyZW50 bHkgY3JlYXRpbmcgYSBuZXcgYmFzZSB0ZXh0IGZvciBJU08xMDU4OS4gICBTQzYgaW50ZW5kcyB0 byB1c2UgdGhpcyBuZXcgdmVyc2lvbiAyIGFzIHRoZSBiYXNlIGZvciBhZGRpbmcgdGhlIGVuaGFu Y2VtZW50cyB3aGljaCBoYXZlIGJlZW4gcmVxdWVzdGVkIGJ5IHRoZSBJRVRGIHRvIG9wdGltaXNl IHRoZSB1c2Ugb2YgSVNPIDEwNTg5IGZvciBJbnRlcm5ldCByb3V0aW5nIHNvbHV0aW9ucy4gIFRo ZSBJRVRGIElTLUlTIFdHIGNvbnZlbm9yIG9yaWdpbmFsbHkgaWRlbnRpZmllZCAgSW50ZXJuZXQg RHJhZnRzOiA8ZHJhZnQtaWV0Zi1pc2lzLWR5bmFtZS0wMi50eHQ+IGFuZCA8ZHJhZnQtaWV0Zi1p c2lzLXRyYWZmaWMtMDEudHh0PiBhcyB0aGUgc291cmNlIGRvY3VtZW50cyB3aGljaCBzcGVjaWZ5 IHRoZXNlIGVuaGFuY2VtZW50cy4gICBTQzYgaW52aXRlcyB0aGUgSUVURiB0byBjb25maXJtIHRo YXQgdGhlIGFib3ZlIEludGVybmV0IERyYWZ0cyBhcmUgdGhlIGNvcnJlY3QgcmVmZXJlbmNlcyBh bmQgdG8gaW5mb3JtIFNDNiBpZiB0aGVyZSBhcmUgYWRkaXRpb25hbCBJRVRGIGRvY3VtZW50cyB3 aGljaCByZWZlciB0byBhbnkgb3RoZXIgcmVxdWlyZW1lbnRzIGZvciAgSVMtSVMgUm91dGluZyBl bmhhbmNlbWVudHMuDQ0gU0M2IHdvdWxkIGxpa2UgdG8gaW50ZXJhY3Qgd2l0aCB0aGUgSUVURiBv biBjbGFyaWZ5aW5nIHRoZSBkZXRhaWxlZCByZXF1aXJlbWVudHMgaW4gdGhlIGhvcGUgdGhhdCBp dCBtYXkgYmUgcG9zc2libGUgdG8gIGludHJvZHVjZSB0aGVtIGR1cmluZyB0aGUgZWRpdGluZyBj eWNsZSBmb3IgdmVyc2lvbiAyIG9mIHRoZSBzdGFuZGFyZC4gICBUbyB0aGlzIGVuZCwgd2Ugd291 bGQgbGlrZSB0aGUgUm91dGluZyBBcmVhIERpcmVjdG9ycyB0byBhcnJhbmdlIGFuIElTLUlTIEJP RiBhdCB0aGUgU2FuIERpZWdvIElFVEYgbWVldGluZyB0byBkaXNjdXNzIHRoZXNlIHJlcXVpcmVt ZW50cyBhbmQgaG93IHRoZXkgY2FuIGJlIGluY29ycG9yYXRlZCBpbnRvIHRoZSBuZXcgdmVyc2lv biBvZiAgSVNPIDEwNTg5Lg0NIFNDNiB3aWxsIHBvc3QgYW4gaW5pdGlhbCBkcmFmdCB2ZXJzaW9u IG9mIHRoZSBuZXcgYmFzZSBkb2N1bWVudCBhcyBhbiBJbnRlcm5ldCBEcmFmdCBpbiBBdWd1c3Qg MjAwMCBidXQgdGhpcyB3aWxsIG5vdCBjb250YWluIHRoZSBjaGFuZ2VzIHJlcXVlc3RlZCBieSB0 aGUgSUVURi4gIEEgYmFsbG90IGNsb3N1cmUgZGF0ZSBvZiBGZWJydWFyeSAyMDAxIGhhcyBiZWVu IHNldCBmb3IgdGhlIDJuZCBDRCBCYWxsb3QgdG8gYWxsb3cgaW5jb3Jwb3JhdGlvbiBvZiBmaW5h bCBpbnB1dCBvbiB0aGUgSW50ZXJuZXQgcmVxdWlyZW1lbnRzIGlmIHRoZXkgY2FuIGJlIGFncmVl ZCBhdCB0aGUgRGVjZW1iZXIgMjAwMCBJRVRGIG1lZXRpbmcuIA0NRm9yIGluZm9ybWF0aW9uLCB0 aGUgY3VycmVudCBpbnN0cnVjdGlvbnMgdG8gdGhlIGVkaXRvciBhcmUgdGhhdCBoZSBzaG91bGQg dXNlIElTTy9JRUMgMTA1ODk6MTk5MiBhcyBhIGJhc2UgZm9yIGVkaXRpbmcsIGFuZCBzaGFsbCBh cHBseSB0aGUgbWluaW11bSB0ZXh0dWFsIGNoYW5nZXMgbWFuZGF0ZWQgYnkgdGhlIGZvbGxvd2lu ZyBUQ3MgYW5kIERSczoNDSAgIElTTy9JRUMgMTA1ODk6MTk5Mi9Db3IuMToxOTkzDSAgIElTTy9J RUMgMTA1ODk6MTk5Mi9Db3IuMjoxOTk2DSAgIElTTy9JRUMgMTA1ODk6MTk5Mi9Db3IuMzoxOTk2 DSAgIElTTy9JRUMgMTA1ODk6MTk5Mi9BbWQgMToxOTk2DSAgIDZOMTAzMjMgLSBEZWZlY3QgUmVw b3J0cyA3LTI2DSAgIDZOMTA2NTkgLSBEZWZlY3QgUmVwb3J0cyAyNy0zNA0gICA2TjEwNzMzIC0g VGVjaG5pY2FsIENvcnJpZ2VuZHVtIDQNICAgVGhlIGVkaXRvciB3aWxsIGFsc28gYXBwbHkgdGhl IG1pbmltYWwgY2hhbmdlcyBuZWNlc3NhcnkgdG8gcmVzb2x2ZSBhZGRpdGlvbmFsIERlZmVjdCBS ZXBvcnRzIDM1LTQ0Lg0NSWYgU0M2IGFuZCB0aGUgSUVURiBhcmUgdW5hYmxlIHRvIHJlc29sdmUg dGhlIHJlcXVpcmVkIGNoYW5nZXMsIHRoZSBFZGl0b3Igd2lsbCBhZGQgYSB0ZW1wb3Jhcnkgbm90 ZSB0byB0aGUgY292ZXIgcGFnZSBhbmQgdGhlIHNjb3BlIGNsYXVzZSBzdGF0aW5nIHRoYXQ6ICCT IElTTyAxMDU4OSBkb2VzIG5vdCBjdXJyZW50bHkgaW5jbHVkZSB0aGUgZXh0ZW5zaW9ucyBvcmln aW5hbGx5IHJlcXVlc3RlZCBieSB0aGUgSUVURiBpbiBJbnRlcm5ldCBEcmFmdHM6IDxkcmFmdC1p ZXRmLWlzaXMtZHluYW1lLTAyLnR4dD4gYW5kIDxkcmFmdC1pZXRmLWlzaXMtdHJhZmZpYy0wMS50 eHQ+LiAgIE5hdGlvbmFsIEJvZHkgYW5kIExpYWlzb24gb3JnYW5pemF0aW9uIGNvbW1lbnRzIGFy ZSBpbnZpdGVkIG9uIHRoZSBiZXN0IHdheSB0byBwcm9ncmVzcyB0aGVzZSBleHRlbnNpb25zLpQN DQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAoEAAAP BAAAEAQAAEwEAABOBAAAjgQAAAkOAAAA+wD59fkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAY1CIFIKgEAAzUIgQc1CIFDShwAAAcABAAADwQAABAE AAB0BAAAdQQAAI4EAACPBAAALgcAAC8HAADBCAAAwggAACwKAAAtCgAA+QoAAPoKAAAbCwAAPAsA AF0LAAB+CwAAnwsAAMELAADmCwAATgwAAE8MAAAIDgAACQ4AAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAGQAEAAAPBAAAEAQA AHQEAAB1BAAAjgQAAI8EAAAuBwAALwcAAMEIAADCCAAALAoAAC0KAAD5CgAA+goAABsLAAA8CwAA XQsAAH4LAACfCwAAwQsAAOYLAABODAAATwwAAAgOAAAJDgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZHAAfsNAvILDgPSGw CAcisAgHI5CgBSSQoAUlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAA8ACgABAFsADwAC AAAAAAAAACQAAEDx/wIAJAAAAAYATgBvAHIAbQBhAGwAAAACAAAABABtSAkEAAAAAAAAAAAAAAAA AAAAAAAAPABBQPL/oQA8AAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABG AG8AbgB0AAAAAAAAAAAAAAAAAAAAAAAJCgAABQAAFgAAAAD/////AAQAAAkOAAAIAAAAAAQAAAkO AAAJAAAAAAQAAAkOAAAKAAAAAAAAAAsKAAAHAAAAAAAvAwAAMAMAAPIDAACyBAAAuQQAAMAEAAAL CgAABwAHAAcABwAaAAcABwD//xQAAAALAGgAbwB1AGwAZABzAHcAbwByAHQAaAASAEEAOgBcAGwA aQBhAGkAcwBvAG4AaQBzAGkAcwAuAGQAbwBjAAsAaABvAHUAbABkAHMAdwBvAHIAdABoABIAQQA6 AFwAbABpAGEAaQBzAG8AbgBpAHMAaQBzAC4AZABvAGMACwBoAG8AdQBsAGQAcwB3AG8AcgB0AGgA EgBBADoAXABsAGkAYQBpAHMAbwBuAGkAcwBpAHMALgBkAG8AYwALAGgAbwB1AGwAZABzAHcAbwBy AHQAaAAqAEMAOgBcAGQAbwBjAHUAbQBlAG4AdABzAFwAcwB0AGEAbgBkAGEAcgBkAHMAXABzAGMA NgBcAGwAaQBhAGkAcwBvAG4AaQBzAGkAcwAuAGQAbwBjAAsAaABvAHUAbABkAHMAdwBvAHIAdABo ABIAQQA6AFwAbABpAGEAaQBzAG8AbgBpAHMAaQBzAC4AZABvAGMAEABKAGEAYwBrACAASABvAHUA bABkAHMAdwBvAHIAdABoACYAQwA6AFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABvAG0AXAAy ADcAMQBcAGwAaQBhAGkAcwBvAG4AaQBzAGkAcwAuAGQAbwBjABAASgBhAGMAawAgAEgAbwB1AGwA ZABzAHcAbwByAHQAaAAuAEMAOgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAcwB0AGEAbgBk AGEAcgBkAHMAXABpAHMAdAA2AFwAaQBzAGkAcwBsAGkAYQBpAHMAbwBuAC4AZABvAGMAEABKAGEA YwBrACAASABvAHUAbABkAHMAdwBvAHIAdABoAC4AQwA6AFwATQB5ACAARABvAGMAdQBtAGUAbgB0 AHMAXABzAHQAYQBuAGQAYQByAGQAcwBcAGkAcwB0ADYAXABpAHMAaQBzAGwAaQBhAGkAcwBvAG4A LgBkAG8AYwAQAEoAYQBjAGsAIABIAG8AdQBsAGQAcwB3AG8AcgB0AGgALgBDADoAXABNAHkAIABE AG8AYwB1AG0AZQBuAHQAcwBcAHMAdABhAG4AZABhAHIAZABzAFwAaQBzAHQANgBcAGkAcwBpAHMA bABpAGEAaQBzAG8AbgAuAGQAbwBjABAASgBhAGMAawAgAEgAbwB1AGwAZABzAHcAbwByAHQAaAAt AEMAOgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAcwB0AGEAbgBkAGEAcgBkAHMAXAB3AGcA NwBcAGkAcwBpAHMAbABpAGEAaQBzAG8AbgAuAGQAbwBjAP9AAYABAF8BAABfAQAABNh0AAcABwBf AQAAAAAAAF8BAAAAAAAAAhAAAAAAAAAACQoAAFAAAAgAQAAAAwAAAEcWkAEAAAICBgMFBAUCAwQD AAAAAAAAAAAAAAAAAAAAAQAAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUW kAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEA AAILBgQCAgICAgQDAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABBAHIAaQBhAGwAAAAiAAQA8AiIGAAA 0AIAAGgBAAAAABvKR0YbykdGAAAAAAIAAAAAAHMBAABGCAAAAQAEAAAABAADEBEAAAAAAAAAAAAA AAEAAQAAAAEAAAAAAAAAJAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApQbAB7QAtACA ADIwAAAQABkAZAAAABkAAAApCgAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAP//EgAAAAAAAAALAEUAdABoAGEAbgAg AEYAcgBvAG0AZQAAAAUARQB0AGgAYQBuAAAACABFAFcALwBMAE4ALwBDAEIAEABKAGEAYwBrACAA SABvAHUAbABkAHMAdwBvAHIAdABoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAA AAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAgAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAAKwA AAAEAAAAuAAAAAUAAADMAAAABgAAANwAAAAHAAAA6AAAAAgAAAD4AAAACQAAABQBAAASAAAAIAEA AAoAAAA8AQAADAAAAEgBAAANAAAAVAEAAA4AAABgAQAADwAAAGgBAAAQAAAAcAEAABMAAAB4AQAA AgAAAOQEAAAeAAAADAAAAEV0aGFuIEZyb21lAB4AAAABAAAAAHRoYR4AAAAJAAAARVcvTE4vQ0IA bWUAHgAAAAYAAABFdGhhbgBDQh4AAAABAAAAAHRoYR4AAAAHAAAATm9ybWFsAEIeAAAAEQAAAEph Y2sgSG91bGRzd29ydGgAAGQAHgAAAAIAAAAyAGNrHgAAABMAAABNaWNyb3NvZnQgV29yZCA4LjAA AEAAAAAAAAAAAAAAAEAAAAAA+ny4Cfa/AUAAAAAA+ny4Cfa/AQMAAAABAAAAAwAAAHMBAAADAAAA RggAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAECgIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC 1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a5IAQAABAEAAAwAAAABAAAAaAAAAA8A AABwAAAABQAAAIwAAAAGAAAAlAAAABEAAACcAAAAFwAAAKQAAAALAAAArAAAABAAAAC0AAAAEwAA ALwAAAAWAAAAxAAAAA0AAADMAAAADAAAAOQAAAACAAAA5AQAAB4AAAAUAAAATHVjZW50IFRlY2hu b2xvZ2llcwADAAAAEQAAAAMAAAAEAAAAAwAAACkKAAADAAAAsw0IAAsAAAAAAAAACwAAAAAAAAAL AAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAMAAAARXRoYW4gRnJvbWUADBAAAAIAAAAeAAAABgAAAFRp dGxlAAMAAAABAAAAAACYAAAAAwAAAAAAAAAgAAAAAQAAADYAAAACAAAAPgAAAAEAAAACAAAACgAA AF9QSURfR1VJRAACAAAA5AQAAEEAAABOAAAAewA0AEQAQgAwAEUAMAA1ADUALQA2AEIANgAyAC0A NAAzADkAQwAtAEEARgBFADgALQAxADIARgAyADEANwAxAEUANwBDADQAOAB9AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAK AAAACwAAAP7///8NAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAA/v///xUAAAAWAAAAFwAAABgA AAAZAAAAGgAAABsAAAD+////HQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAAP7////9////JgAA AP7////+/////v////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAA RgAAAADAQvPZCfa/AeAhRNoJ9r8BKAAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgH/////BQAAAP////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAABAAAAAAAABXAG8AcgBkAEQA bwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgAC AQEAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeFgAA AAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAFAAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBv AHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABAAAA/v////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0 IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA ------=_NextPart_000_004E_01BFF9BB.AF0ABBA0 Content-Type: application/msword; name="isisinstruct.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="isisinstruct.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAIwAAAAAAAAAA EAAAJQAAAAEAAAD+////AAAAACIAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEARwAJCAAAABK/AAAAAAAAEAAAAAAABAAAQwoAAA4AYmpiao7ZjtkAAAAAAAAAAAAAAAAAAAAA AAAJBBYAHhIAAOyzAQDsswEAQwYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAJIAAAAAAAAAkgAAAJIA AAAAAAAAkgAAAAAAAACSAAAAAAAAAJIAAAAAAAAAkgAAABQAAAAAAAAAAAAAAKYAAAAAAAAApgAA AAAAAACmAAAAAAAAAKYAAAAAAAAApgAAAAwAAACyAAAADAAAAKYAAAAAAAAAhwUAALYAAADKAAAA AAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAMoAAAAA AAAATAUAAAIAAABOBQAAAAAAAE4FAAAAAAAATgUAAAAAAABOBQAAAAAAAE4FAAAAAAAATgUAACQA AAA9BgAA9AEAADEIAAAMAQAAcgUAABUAAAAAAAAAAAAAAAAAAAAAAAAAkgAAAAAAAADKAAAAAAAA AAAAAAAAAAAAAAAAAAAAAADKAAAAAAAAAMoAAAAAAAAAygAAAAAAAADKAAAAAAAAAHIFAAAAAAAA kgEAAAAAAACSAAAAAAAAAJIAAAAAAAAAygAAAAAAAAAAAAAAAAAAAMoAAAAAAAAAygAAAAAAAACS AQAAAAAAAJIBAAAAAAAAkgEAAAAAAADKAAAAIgAAAJIAAAAAAAAAygAAAAAAAACSAAAAAAAAAMoA AAAAAAAATAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAApgAAAAAAAACmAAAAAAAAAJIAAAAAAAAAkgAA AAAAAACSAAAAAAAAAJIAAAAAAAAAygAAAAAAAABMBQAAAAAAAJIBAAC6AwAAkgEAAAAAAAAAAAAA AAAAAEwFAAAAAAAAkgAAAAAAAACSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATAUAAAAAAADKAAAAAAAAAL4AAAAMAAAAoEJzAQr2 vwGmAAAAAAAAAKYAAAAAAAAA7AAAAKYAAABMBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVGl0 bGU6IEluc3RydWN0aW9ucyB0byBFZGl0b3IgZm9yIHByb2R1Y3Rpb24gb2YgMm5kIENEIGZvciBJ U08vSUVDIDEwNTg5DVNvdXJjZTogSVNPL0lFQyBKVEMxL1NDNg0NVGhlIHByZWZlcnJlZCBkYXRl IG9mIGNsb3N1cmUgZm9yIHRoZSAoZm91ciBvciAgZml2ZSBtb250aCkgMm5kIENEIEJhbGxvdCBz aG91bGQgaW4gRmVicnVhcnkgMjAwMSwgdG8gZW5hYmxlIGluY29ycG9yYXRpb24gb2YgcG9zc2li bGUgaW5wdXQgb24gaG93IHRvIHByb2dyZXNzIGVuaGFuY2VtZW50cyB0byBtZWV0IEludGVybmV0 IHJlcXVpcmVtZW50cywgcmVjZWl2ZWQgYWZ0ZXIgdGhlIERlY2VtYmVyIDIwMDAgSUVURiBtZWV0 aW5nLg0NU3BlY2lmaWMgSW5zdHJ1Y3Rpb25zIHRvIHRoZSBFZGl0b3I6DQ0xKSBUaGUgZWRpdG9y IHNoYWxsIHVzZSBJU08vSUVDIDEwNTg5OjE5OTIgYXMgYSBiYXNlIGZvciBlZGl0aW5nLCBhbmQg c2hhbGwgYXBwbHkgdGhlIG1pbmltdW0gdGV4dHVhbCBjaGFuZ2VzIG1hbmRhdGVkIGJ5IHRoZSBm b2xsb3dpbmcgIFRDcyBhbmQgRFJzOg0NICAgSVNPL0lFQyAxMDU4OToxOTkyL0Nvci4xOjE5OTMN ICAgSVNPL0lFQyAxMDU4OToxOTkyL0Nvci4yOjE5OTYNICAgSVNPL0lFQyAxMDU4OToxOTkyL0Nv ci4zOjE5OTYNICAgSVNPL0lFQyAxMDU4OToxOTkyL0FtZCAxOjE5OTYNICAgNk4xMDMyMyAtIERl ZmVjdCBSZXBvcnRzIDctMjYNICAgNk4xMDY1OSAtIERlZmVjdCBSZXBvcnRzIDI3LTM0DSAgIDZO MTA3MzMgLSBUZWNobmljYWwgQ29ycmlnZW5kdW0gNA0NMikgVGhlIGVkaXRvciBzaGFsbCBhcHBs eSB0aGUgbWluaW1hbCBjaGFuZ2VzIG5lY2Vzc2FyeSB0byByZXNvbHZlIGFkZGl0aW9uYWwgRGVm ZWN0IFJlcG9ydHMgMzUtNDQuDQ0zKSBUaGUgZWRpdG9yIHNoYWxsIGFkZCB0aGUgZm9sbG93aW5n IHRlbXBvcmFyeSBub3RlIHRvIHRoZSBjb3ZlciBwYWdlIGFuZCB0aGUgc2NvcGUgY2xhdXNlOg0i DVRlbXBvcmFyeSBOb3RlOglUaGUgdGV4dCBpbiB0aGlzIDJuZCBGaW5hbCBDRCBpbmNvcnBvcmF0 ZXMgY2hhbmdlcyB0byB0aGUgMTk5MiBlZGl0aW9uLCByZXN1bHRpbmcgZnJvbSBhcHByb3ZlZCB0 ZWNobmljYWwgY29ycmlnZW5kYSwgYW1lbmRtZW50cywgYW5kIHByb3Bvc2VkIHJlc29sdXRpb25z IHRvIERlZmVjdCBSZXBvcnRzIDM1IC0gNDQuICBUaGUgcHVycG9zZSBvZiB0aGlzIDJuZCBGaW5h bCBDRCBpcyB0byBjcmVhdGUgYSBzdGFibGUgdGV4dCB3aGljaCBjYW4gYmUgdXNlZCBhcyB0aGUg YmFzaXMgZm9yIG9uZ29pbmcgd29yay4NDUl0IGRvZXMgbm90IGN1cnJlbnRseSBpbmNsdWRlIHRo ZSBleHRlbnNpb25zIG9yaWdpbmFsbHkgcmVxdWVzdGVkIGJ5IHRoZSBJRVRGICAoaW4gSW50ZXJu ZXQgRHJhZnRzOiANPGRyYWZ0LWlldGYtaXNpcy1keW5hbWUtMDIudHh0PiwgPGRyYWZ0LWlldGYt aXNpcy10cmFmZmljLTAxLnR4dD4gKSB0byBtZWV0IEludGVybmV0IHJlcXVpcmVtZW50cy4gIE5h dGlvbmFsIEJvZHkgYW5kIExpYWlzb24gb3JnYW5pemF0aW9uIGNvbW1lbnRzIGFyZSBpbnZpdGVk IHRvIGNvbW1lbnQgb24gdGhlIGJlc3Qgd2F5IHRvIHByb2dyZXNzIHRoZXNlIGV4dGVuc2lvbnMu DSINDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAMQQA ADMEAACgBAAAogQAAO8HAADxBwAAqQgAAKsIAABDCgAAAP0A/QD9AP0AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANIKgEACQAEAABJBAAA YgQAAGMEAABeBQAAXwUAAIQFAACFBQAAGwYAABwGAAA9BgAAXgYAAH8GAACgBgAAwQYAAOMGAAAI BwAACQcAAG0HAABuBwAAywcAAM0HAAABCQAAAgkAAGcJAABACgAAQgoAAEMKAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAbAAQAAEkEAABi BAAAYwQAAF4FAABfBQAAhAUAAIUFAAAbBgAAHAYAAD0GAABeBgAAfwYAAKAGAADBBgAA4wYAAAgH AAAJBwAAbQcAAG4HAADLBwAAzQcAAAEJAAACCQAAZwkAAEAKAABCCgAAQwoAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABscAB+w0C8gsOA9 IbAIByKwCAcjkKAFJJCgBSWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIADwAKAAEAWwAP AAIAAAAAAAAAJAAAQPH/AgAkAAAABgBOAG8AcgBtAGEAbAAAAAIAAAAEAG1ICQQAAAAAAAAAAAAA AAAAAAAAAAA8AEFA8v+hADwAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAg AEYAbwBuAHQAAAAAAAAAAAAAAAAAAAAAAEMGAAAFAAASAAAAAP////8ABAAAQwoAAAYAAAAABAAA QwoAAAcAAAAABAAAQwoAAAgAAAAAAAAADgIAABECAAAWAgAAGQIAAEUGAAAHABwABwAcAAcAAAAA AGIAAABjAAAAjwAAAJcAAABdAQAAhQEAAAMCAAARAgAAGgIAABwCAAA3AgAAPAIAAD0CAABYAgAA XQIAAF4CAAB5AgAAfgIAAJQEAADLBAAA1QQAAAAFAABnBQAAaAUAAIUFAADLBQAARQYAAAcABAAH ABoABwAHAAcAGgAHAAcABwAaAAcABwAaAAcABwAaAAcABwAaAAcABwAHABoABwAHAP//EAAAAAgA VABvAG0AIABSAHUAdAB0ADIAQwA6AFwAdwBpAG4AZABvAHcAcwBcAFQARQBNAFAAXABBAHUAdABv AFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABEAG8AYwB1AG0AZQBuAHQAMQAuAGEA cwBkAAgAVABvAG0AIABSAHUAdAB0ACcARAA6AFwAZABhAHQAYQBcAHMAYwA2AFwAdwBnADcAXABw AHIAYQBoAGEAXABpAHMAaQBzAGUAZABpAHQAaQBuAHMAdAByAC4AZABvAGMACABUAG8AbQAgAFIA dQB0AHQANgBDADoAXAB3AGkAbgBkAG8AdwBzAFwAVABFAE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2 AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAGkAcwBpAHMAZQBkAGkAdABpAG4AcwB0AHIALgBhAHMA ZAAIAFQAbwBtACAAUgB1AHQAdAA2AEMAOgBcAHcAaQBuAGQAbwB3AHMAXABUAEUATQBQAFwAQQB1 AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAAaQBzAGkAcwBlAGQAaQB0AGkA bgBzAHQAcgAuAGEAcwBkAAgAVABvAG0AIABSAHUAdAB0ACcARAA6AFwAZABhAHQAYQBcAHMAYwA2 AFwAdwBnADcAXABwAHIAYQBoAGEAXABpAHMAaQBzAGUAZABpAHQAaQBuAHMAdAByAC4AZABvAGMA EABKAGEAYwBrACAASABvAHUAbABkAHMAdwBvAHIAdABoACgAQwA6AFwATQB5ACAARABvAGMAdQBt AGUAbgB0AHMAXABvAG0AXAAyADcAMQBcAGkAcwBpAHMAZQBkAGkAdABpAG4AcwB0AHIALgBkAG8A YwAQAEoAYQBjAGsAIABIAG8AdQBsAGQAcwB3AG8AcgB0AGgAMABDADoAXABNAHkAIABEAG8AYwB1 AG0AZQBuAHQAcwBcAHMAdABhAG4AZABhAHIAZABzAFwAaQBzAHQANgBcAGkAcwBpAHMAZQBkAGkA dABpAG4AcwB0AHIALgBkAG8AYwAQAEoAYQBjAGsAIABIAG8AdQBsAGQAcwB3AG8AcgB0AGgALgBD ADoAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAHMAdABhAG4AZABhAHIAZABzAFwAdwBnADcA XABpAHMAaQBzAGkAbgBzAHQAcgB1AGMAdAAuAGQAbwBjAP9AAIABAAAAAAAAAAAA+BEyAQEAAQAA AAAAAAAAAAAAAAAAAAAAAhAAAAAAAAAAQwYAAFAAAAgAQAAAAwAAAEcWkAEAAAICBgMFBAUCAwQD AAAAAAAAAAAAAAAAAAAAAQAAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUW kAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEA AAILBgQCAgICAgQDAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABBAHIAaQBhAGwAAAAiAAQAcAiIGAAA 0AIAAGgBAAAAAB3KR0YdykdGAAAAAAIAAQAAAOcAAAApBQAAAQACAAAABAADEAsAAAAAAAAAAAAA AAEAAQAAAAEAAAAAAAAAJAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApQbAB7QAtACA ADIwAAAAAAAAAAAAAAAAAABWBgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAP//EgAAAAAAAABZAFQAaABlACAAZQBk AGkAdABvAHIAIABzAGgAYQBsAGwAIABhAGQAZAAgAHQAaABlACAAZgBvAGwAbABvAHcAaQBuAGcA IAB0AGUAbQBwAG8AcgBhAHIAeQAgAG4AbwB0AGUAIAB0AG8AIAB0AGgAZQAgAGMAbwB2AGUAcgAg AHAAYQBnAGUAIABhAG4AZAAgAHQAaABlACAAcwBjAG8AcABlACAAYwBsAGEAdQBzAGUAOgAAAAAA AAAIAFQAbwBtACAAUgB1AHQAdAAQAEoAYQBjAGsAIABIAG8AdQBsAGQAcwB3AG8AcgB0AGgAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAA AAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAADMAQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAA /AAAAAQAAAAIAQAABQAAABwBAAAGAAAAKAEAAAcAAAA0AQAACAAAAEQBAAAJAAAAYAEAABIAAABs AQAACgAAAIgBAAAMAAAAlAEAAA0AAACgAQAADgAAAKwBAAAPAAAAtAEAABAAAAC8AQAAEwAAAMQB AAACAAAA5AQAAB4AAABaAAAAVGhlIGVkaXRvciBzaGFsbCBhZGQgdGhlIGZvbGxvd2luZyB0ZW1w b3Jhcnkgbm90ZSB0byB0aGUgY292ZXIgcGFnZSBhbmQgdGhlIHNjb3BlIGNsYXVzZToAIAAeAAAA AQAAAABoZSAeAAAACQAAAFRvbSBSdXR0AHIgcx4AAAABAAAAAG9tIB4AAAABAAAAAG9tIB4AAAAH AAAATm9ybWFsAHQeAAAAEQAAAEphY2sgSG91bGRzd29ydGgAYWRkHgAAAAIAAAAyAGNrHgAAABMA AABNaWNyb3NvZnQgV29yZCA4LjAAZEAAAAAARsMjAAAAAEAAAAAAhgMACva/AUAAAAAAhgMACva/ AQMAAAABAAAAAwAAAOcAAAADAAAAKQUAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAgAA AALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rpQBAABQAQAADAAAAAEAAABoAAAA DwAAAHAAAAAFAAAAjAAAAAYAAACUAAAAEQAAAJwAAAAXAAAApAAAAAsAAACsAAAAEAAAALQAAAAT AAAAvAAAABYAAADEAAAADQAAAMwAAAAMAAAAMgEAAAIAAADkBAAAHgAAABQAAABMdWNlbnQgVGVj aG5vbG9naWVzAAMAAAALAAAAAwAAAAIAAAADAAAAVgYAAAMAAACzDQgACwAAAAAAAAALAAAAAAAA AAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAFoAAABUaGUgZWRpdG9yIHNoYWxsIGFkZCB0aGUgZm9s bG93aW5nIHRlbXBvcmFyeSBub3RlIHRvIHRoZSBjb3ZlciBwYWdlIGFuZCB0aGUgc2NvcGUgY2xh dXNlOgAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAACYAAAAAwAAAAAAAAAgAAAAAQAAADYA AAACAAAAPgAAAAEAAAACAAAACgAAAF9QSURfR1VJRAACAAAA5AQAAEEAAABOAAAAewA0AEQAQgAw AEUAMAA1ADUALQA2AEIANgAyAC0ANAAzADkAQwAtAEEARgBFADgALQAxADIARgAyADEANwAxAEUA NwBDADQAOAB9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAA AP7///8LAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAA/v///xMAAAAUAAAAFQAAABYAAAAXAAAA GAAAABkAAAD+////GwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAAP7////9////JAAAAP7////+ /////v////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAA AABGAAAAAMCubgEK9r8BYGp8AQr2vwEmAAAAgAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAf////8FAAAA//// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAAAAEAAAAAAAAFcAbwByAGQA RABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAa AAIBAQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4S AAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACgAAgECAAAABAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAASAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBm AG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhgAAABNaWNyb3Nv ZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_004E_01BFF9BB.AF0ABBA0-- From jjl@one.com Thu, 03 Aug 2000 14:52:34 -0400 Date: Thu, 03 Aug 2000 14:52:34 -0400 From: Jeff Learman jjl@one.com Subject: [Isis-wg] General info about IS-IS --=====================_278714320==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Jasper, RFC 1195, "ftp://ftp.isi.edu/in-notes/rfc1195.txt", has a great overview of IS-IS. After that, I recommend Radia Perlman's "Interconnections", although that covers both bridges and routers and a variety of related protocols, and only a relatively small portion of the book concerns IS-IS. But it's very useful because it explains the concepts of link-state routing as differentiated from distance-vector routing, and has amusing anecdotes as well. For a somewhat fluffier overview, you can see "ftp://ftp.atis.org/pub/sif/arch/ar970820.ppt", although this was prepared for an audience that was familiar with OSI addressing. Ignore the last three slides, which are specific to carrier-class SONET management networks. Regards, Jeff At 12:26 PM 8/3/00 -0400, Jasper Chin wrote: >I'm new to IS-IS and am looking to learn about >this routing protocol. > >Could anyone suggest a roadmap of reading material >that would be beneficial? Is there a FAQ on this >topic? > >TIA, > >J. Chin ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ --=====================_278714320==_.ALT Content-Type: text/html; charset="us-ascii"
Jasper,

RFC 1195, "ftp://ftp.isi.edu/in-notes/rfc1195.txt", has a great
overview of IS-IS.  After that, I recommend Radia Perlman's
"Interconnections", although that covers both bridges and routers
and a variety of related protocols, and only a relatively small
portion of the book concerns IS-IS.  But it's very useful because
it explains the concepts of link-state routing as differentiated
from distance-vector routing, and has amusing anecdotes as well.

For a somewhat fluffier overview, you can see
"ftp://ftp.atis.org/pub/sif/arch/ar970820.ppt", although this was
prepared for an audience that was familiar with OSI addressing.
Ignore the last three slides, which are specific to carrier-class
SONET management networks.

Regards,
Jeff

At 12:26 PM 8/3/00 -0400, Jasper Chin wrote:
I'm new to IS-IS and am looking to learn about
this routing protocol.

Could anyone suggest a roadmap of reading material
that would be beneficial?  Is there a FAQ on this
topic?

TIA,

J. Chin


____________________________________________________________________

  Jeff Learman                           Internet:     jjl@one.com
  Engineering Manager                    Voice:     (734)-975-7323
  ONE (Open Networks Engineering, Inc)   Fax:       (734)-975-6940
  2725 South Industrial Pkwy, Suite 100
  Ann Arbor, MI  48104  USA
____________________________________________________________________ --=====================_278714320==_.ALT-- From isip00@yahoo.com Fri, 4 Aug 2000 17:15:54 -0700 (PDT) Date: Fri, 4 Aug 2000 17:15:54 -0700 (PDT) From: Oka Learner isip00@yahoo.com Subject: [Isis-wg] Clarification on isisCircInitFails Could someone please explain me this object? If initialization fails, how a circuit be created? Advance thanks for any response. __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ From iesg-secretary@ietf.org Tue, 15 Aug 2000 16:18:21 -0400 Date: Tue, 15 Aug 2000 16:18:21 -0400 From: The IESG iesg-secretary@ietf.org Subject: [Isis-wg] Document Action: IS-IS Mesh Groups to Informational The IESG has approved the Internet-Draft 'IS-IS Mesh Groups' as an Informational RFC. This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are David Oran and Rob Coltun. From iesg-secretary@ietf.org Tue, 15 Aug 2000 16:18:21 -0400 Date: Tue, 15 Aug 2000 16:18:21 -0400 From: The IESG iesg-secretary@ietf.org Subject: [Isis-wg] Document Action: IS-IS Mesh Groups to Informational The IESG has approved the Internet-Draft 'IS-IS Mesh Groups' as an Informational RFC. This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are David Oran and Rob Coltun. From cai@baynetworks.com Mon, 7 Aug 2000 15:52:06 -0400 (EDT) Date: Mon, 7 Aug 2000 15:52:06 -0400 (EDT) From: Karl Cai cai@baynetworks.com Subject: [Isis-wg] looking for PS version of rfc1195 Hi, Could somebody tell me where I can find a copy of rfc1195 postscript version? I download it from ftp.ietf.org (rfc1195.ps) but it breaks on page9 when I use ghostview to view/print it. Thanks. -- Karl From prz@net4u.ch Mon, 21 Aug 2000 20:43:59 +0200 (MEST) Date: Mon, 21 Aug 2000 20:43:59 +0200 (MEST) From: Tony Przygienda prz@net4u.ch Subject: [Isis-wg] IETF 48 meeting minutes Thanks to Alex for initial version: * Agenda bashing & Administrativa 1. domain-wide passed last call, unfortunately credits have not been given to Quaizar who contributed some key ideas 2. mesh-groups passed last call 3. isis-ext-eth passed last call 4. expired te draft will be re-submitted latest 2 weeks after IETF or another party will take control of the draft * Draft on flooding optimization has not been presented. Couple of comments were made and will be sent to authors. * Kireeti presented draft-kompella-isis-ompls-extensions-00 summarizing extensions to ISIS to support MPL()S. Q: How is this work relative to transport rings? Kireeti: Not quite sure. We can introduce transport ring support if necessary Q: Wrt link protection, not all protection schemes are covered (N:N, and N:1 are not included), why? K: We tried to keep it simple. K: The way to proceed with the draft seems to be to go to the new WG and reach the consensus there and then come back to ISIS WG. TonyP: Agree, let's give it a chance to be discussed in the new WG to fit into any "bigger" scheme of things. If that doesn't happen, we'll take on to work on the issue. * Francois presented draft-lefaucheur-diff-te-ext-00 describing the extensions that need to be made to ISIS TE TLVs to support DiffServ-aware MPLS TE. The main idea is to provide BW info for each class using new sub-TLVs in existing TE TLVs. Francois requested the feedback from the ISIS WG. K: Not sure this is the right forum, but this can be coded more optimal if (announce overall unreserved BW and reserved BW per class ???) F: We couldn't make it work, would be happy to discuss this. (Discussion to go off-line) Curtis: 4 class types is very restrictive and 8 preemption levels may be too much F: Those are sort of things which relate to the definition of requirements and should be discussed in MPLS/TE WGs. TP: You do not address the situation where routers do not udnerstand the new TLVs. This could lead to loops in loose source routes scenarios. F : It is addressed in the signaling component, which is not in the draft TP: it is still a good idea to specify what to do with TLVs if they are not understood. Draft may end up in the new routing area working group or MPLS and architectural/requirement issues will be worked out there first. Output of that work may find its way back into ISIS working group. * Ran Atkinson (engineer at large :) spoke up about draft-ietf-isis-hmac-01.txt. The document was described as stable and clear for implementation. Ran encouraged WG members to read it and post the issues (if any) to the list. TP: There's some confusion about support of 2 keys, people wonder if it's necessary. R : Yes it is, in particular to support smooth key roll-over. TP: Paragraph on the IIH protection is still missing. Contact info needs update. * Chris presented draft-ietf-isis-ipv6-01.txt. The draft describes extensions to ISIS to propagate IPv6 routing information using TLVs similar to wide-metric TLVs for IPv4. One known implementation is gated, other vendors claim to be looking into this. K: Shouldn't the cost be 24 bits as in TE extensions, not 32 bits as in the draft? C: TE has different metrics K: There should be some allignment with TE metrics (24 bits) TP: Double check this, pls. C: I will Mike Shand: What about IPv6-incapable routers? C: Implementations may calculate 2 SPFs---one for IPv4, and another one for IPv6 excluding IPv6-incapable routers. Seems to be more administrative issue. Q: The draft differentiates btw internal and external routes, while TE doesn't, why? A: The draft sticks with original 1195 semantics that was dropped by TE extensions, so the question is to TE authors. T: TE simplified the semantics because nobody was actually using it. It makes sense to stick with 1195 to avoid redistribution loops. IPv6 draft is not implementing the I/E bit (which was not necessary) but only differentiates between external and internal routes which is necessary to prevent those loops. * TP: draft-ietf-isis-hmac-01.txt is to go through the last call after the comments are being incorporated and new version submitted. === tony From rathi@cisco.com Mon, 04 Sep 2000 15:28:44 +0530 Date: Mon, 04 Sep 2000 15:28:44 +0530 From: Ravindra Rathi rathi@cisco.com Subject: [Isis-wg] Doubts in draft-ietf-isis-wg-mib-03.txt Hello all, I have few doubts as well as suggestions for the current version of this draft. Please go through them and let me know your comments. 1. Following object identifiers have "null" description clause in the draft a. isisSystem b. isisCirc c. isisIsAdj d isisReachAddr e. isisIPReachAddr f. isisIPDest Normally description clauses are not null. So either descriptions can be added to them. (The descriptions are already there in the draft before the start of the mib module.) or we can have just something like this. e.g isisSystem OBJECT IDENTIFIER ::= {isis 1 } isisCirc OBJECT IDENTIFIER ::= { isis 2 } etc. 2. At present, type TOS is defined as follows. TOS ::= INTEGER { default(1), delay(2), expense(3), error(4) } This could also have been a TEXTUAL-CONVENTION instead INTEGER. The same thing applies to type 'PathCost.' Am I missing something ? 3. For all of the following tables in the MIB, one of the indices of the table identifies the instance of Integrated IS-IS to which the particular row corresponds. Tables of interest are a. isisSysTable b. isis isisManAreaAddrTable c. isisAreaAddrTable d. isisSysProtSuppTable e. isisSummAddrTable Instead of each of these tables defining one object which acts as an index to identify the same thing (i.e instance of Integrated IS-IS), only one table can (say isisSysTable) define the object to identify the instance of the integrated IS-IS. Presently the object which identifies the instance of Integrated IS-IS in "isisSysTable" is "isisSysInstance". All other tables can use this object as an index(external indexing ) instead of defining their own object to serve the same purpose. Also by using the same object for indexing for all the tables consistency is maintained across the tables to identify the instance of Integrated IS-IS. 4. ResettingTimer behaviour definition The description there applies to objects who follow ResettingTimer behaviour. Defining TEXTUAL-CONVENTION can be better way of documenting the behaviour provided it is possible. I suppose this is not possible here. Same thing applies to "OperationalState behaviour definition". Also definition of these behaviours use the phrase "This object". I feel it would have been more appropriate to use the phrase "objects following this behaviour". 5. The description clause of many objects refer to "replaceOnlyWhile Disabled behaviour". But I was not able to find documentation for this behaviour in the draft. 6. Description clause of few objects is not very clear. e.g for "isisSysPartChanges" it is DESCRIPTION "partition changes". The above description not really indicates what aspect of "partition changes" is being managed by this object ? I might me missing something in above doubts. So please enlighten me with the same. Thanks Rathi -- Ravindra Rathi Cisco Systems "Waterford", #9, Brunton Road Bangalore-560 001 Tel: +91-80-532 1300 - 1306 x: 6315 From henk@Procket.com Tue, 5 Sep 2000 05:17:39 +0200 (MEST) Date: Tue, 5 Sep 2000 05:17:39 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: [Isis-wg] FYI: just submitted draft-ietf-isis-traffic-03.txt Submitted to internet-drafts@ietf.org, I guess it will show up in the drafts repository soon. Just a few minor changes to the previous version. Anyway, here it is for you already. Henk. ---- Network Working Group Tony Li INTERNET DRAFT Procket Networks Henk Smit Procket Networks September 2000 IS-IS extensions for Traffic Engineering Status This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1.0 Abstract This document describes extensions to the IS-IS protocol to support Traffic Engineering [1]. The IS-IS protocol is specified in [2], with extensions for supporting IPv4 specified in [3]. This document extends the IS-IS protocol by specifying new information that a Intermediate System (IS) [router] can place in Link State Protocol Data Units (LSPs). This information describes additional information about the state of the network that is useful for traffic engineering computations. 2.0 Introduction An IS-IS LSP is composed of a fixed header and a number of tuples, each consisting of a Type, a Length, and a Value. Such tuples are commonly known as TLVs, and are a good way of encoding information in a flexible and extensible format. The changes in this document include the design of new TLVs to replace the existing IS Neighbor TLV, IP Reachability TLV and add additional information. Mechanisms and procedures to migrate to the new TLVs are not discussed in this document. The primary goal of these extensions is to add more information about the characteristics of a particular link to an IS-IS's LSP. Secondary goals include increasing the dynamic range of the IS-IS metric and improving the encoding of IP prefixes. The router id is useful for traffic engineering purposes because it describes a single address that can always be used to reference a particular router. This document is a publication of the IS-IS Working Group within the IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual inclusion with ISO 10589. 3.0 The Traffic Engineering router ID TLV The Traffic Engineering router ID TLV is TLV type 134. The router ID TLV contains the 4-octet router ID of the router originating the LSP. This is useful in several regards: For traffic engineering, it guarantees that we have a single stable address that can always be referenced in a path that will be reachable from multiple hops away, regardless of the state of the node's interfaces. If OSPF is also active in the domain, traffic engineering can compute the mapping between the OSPF and IS-IS topologies. If a router advertises the Traffic Engineering router ID TLV in its LSP, and if it advertises BGP routes with the BGP next hop attribute set to the BGP router ID, in that case the Traffic Engineering router ID should be the same as the BGP router ID. Implementations MUST NOT inject a /32 prefix for the router ID into their forwarding table, because this can lead to forwarding loops when interacting with systems that do not support this TLV. 4.0 The extended IP reachability TLV The extended IP reachability TLV is TLV type 135. The existing IP reachability TLV is a single TLV that carries IP prefixes in a format that is analogous to the IS neighbor TLV. It carries four metrics, of which only the default metric is commonly used. Of this, the default metric has a possible range of 0-63. This limitation is one of the restrictions that we would like to lift. In addition, route redistribution (a.k.a. route leaking) is a key problem that is not addressed by the existing IP reachability TLV. This problem occurs when an IP prefix is injected into a level one area, redistributed into level 2, subsequently redistributed into a second level one area, and then redistributed from the second level one area back into level two. This problem occurs because the path that the information can take forms a loop. The likely result is a forwarding loop. To address these issues, the proposed extended IP reachability TLV provides for a 32 bit metric and adds one bit to indicate that a prefix has been redistributed 'down' in the hierarchy. The proposed extended IP reachability TLV contains a new data structure, consisting of: 4 bytes of metric information 1 byte of control information, consisting of 1 bit of up/down information 1 bit indicating the existence of sub-TLVs 6 bits of prefix length 0-4 bytes of IPv4 prefix 0-250 optional octets of sub-TVLs, if present consisting of 1 octet of length of sub-TLVs 0-249 octets of sub-TLVs This data structure can be replicated within the TLV, not to exceed the maximum length of the TLV. The up/down bit shall be set to 0 when a prefix is first injected into IS-IS. If a prefix is redistributed from a higher level to a lower level (e.g. level two to level one), the bit shall be set to 1, to indicate that the prefix has travelled down the hierarchy. Prefixes that have the up/down bit set to 1 must not be redistributed. If a prefix is redistributed from an area to another area at the same level, then the up/down bit shall be set to 1. These semantics apply even if IS-IS is extended in the future to have additional levels. By insuring that prefixes follow only the IS-IS hierarchy, we have insured that the information does not loop, thereby insuring that there are no persistent forwarding loops. If there are no sub-TLVs associated with this IP prefix, the bit indicating the presence of sub-TVLs shall be set to 0. If this bit is set to 1, the first octet after the prefix will be interpreted as the length of sub-TLVs. Please note that while the encoding allows for 255 octets of sub-TLVs, the maximum value cannot fit in the overall extended IP reachability TLV. The practical maximum is 255 octets minus the 5-9 octets described above, or 250 octets. No sub- TLVs for the extended IP reachability TLV have been defined yet. The 6 bits of prefix length can have the values 0-32 and indicate the number of significant bits in the prefix. The prefix is encoded in the minimal number of bytes for the given number of significant bits. This implies: Significant bits Bytes 0 0 1-8 1 9-16 2 17-24 3 25-32 4 The remaining bits of prefix are transmitted as zero and ignored upon receipt. If an IP prefix is advertised with a metric larger then MAX_PATH_METRIC (0xFE000000, see below), this IP prefix should not be considered during the normal SPF computation. This will allow advertisment of an IP prefix for other purposes than building the normal IP routing table. 5.0 The extended IS reachability TLV The extended IS reachability TLV is TLV type 22. The existing IS reachability TLV is a single TLV that contains information about a series of IS neighbors. For each neighbor, there is a structure that contains the default metric, the delay, the monetary cost, the reliability, and the 7-octet ID of the adjacent neighbor. Of this information, the default metric is commonly used. The default metric is currently one octet, with one bit used to indicate that the metric is present and one bit used to indicate whether the metric is internal or external. The remaining 6 bits are used to store the actual metric, resulting a possible metric range of 0-63. This limitation is one of the restrictions that we would like to lift. The remaining three metrics (delay, monetary cost, and reliability) are not commonly implemented and reflect unused overhead in the TLV. The neighbor is identified by its system Id (typically 6-octets), plus one octet to indicate the pseudonode number if the neighbor is on a LAN interface. Thus, the existing TLV consumes 11 octets per neighbor, with 4 octets for metric and 7 octets for neighbor identification. To indicate multiple adjacencies, this structure is repeated within the IS reachability TLV. Because the TLV is limited to 255 octets of content, a single TLV can describe up to 23 neighbors. The IS reachability TLV can be repeated within the LSP fragments to describe further neighbors. The proposed extended IS reachability TLV contains a new data structure, consisting of 7 octets of system Id and pseudonode number 3 octets of default metric 1 octet of length of sub-TLVs 0-244 octets of sub-TLVs Thus, if no sub-TLVs are used, the new encoding requires 11 octets and can contain up to 23 neighbors. Please note that while the encoding allows for 255 octets of sub-TLVs, the maximum value cannot fit in the overall IS reachability TLV. The practical maximum is 255 octets minus the 11 octets described above, or 244 octets. Further, there is no defined mechanism for extending the sub-TLV space for a particular neighbor. Thus, wasting sub-TLV space is discouraged. The metric octets are encoded as a 24-bit unsigned integer. Note that the metric field in the new extended IP reachability TLV is encoded as a 32-bit unsigned integer. These different sizes were chosen so that it is very unlikely that the cost of an intra-area route has to be chopped off to fit in the metric field of an inter-area route. To preclude overflow within an SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC shall be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 - 2^25). If a link is advertised with the maximum link metric (2^24 - 1), this link should not be considered during the normal SPF computation. This will allow advertisment of a link for other purposes than building the normal Shortest Path Tree. An example is a link that is available for traffic engineering, but not for hop-by-hop routing. Certain sub-TLVs are proposed here: Sub-TLV type Length (octets) Name 3 4 Administrative group (color) 6 4 IPv4 interface address 8 4 IPv4 neighbor address 11 32 Unreserved bandwidth 18 3 TE Default metric Each of these sub-TLVs is described below. Unless stated otherwise, multiple occurrences of the information are supported by multiple inclusions of the sub-TLV. 5.1 Sub-TLV 3: Administrative group (color, resource class) The administrative group sub-TLV contains a 4-octet bit mask assigned by the network administrator. Each set bit corresponds to one administrative group assigned to the interface. By convention the least significant bit is referred to as 'group 0', and the most significant bit is referred to as 'group 31'. 5.2 Sub-TLV 6: IPv4 interface address This sub-TLV contains a 4-octet IPv4 address for the interface described by the (main) TLV. This sub-TLV can occur multiple times. If the interface being advertised for Traffic Engineering purposes is unnumbered, the IPv4 interface address sub-TLV is set to the router ID of the advertising router. In combination with the IPv4 neighbor address sub-TLV this identifies the unnumbered link over which the advertised adjacency has been established. Implementations MUST NOT inject a /32 prefix for the interface address into their routing or forwarding table, because this can lead to forwarding loops when interacting with systems that do not support this sub-TLV. If a router implements the basic TLV extensions in this document, it is free to add or omit this sub-TLV to the description of an adjacency. If a router implements traffic engineering, it must include this sub-TLV. 5.3 Sub-TLV 8: IPv4 neighbor address This sub-TLV contains a single IPv4 address for a neighboring router on this link. This sub-TLV can occur multiple times. If the interface being advertised for Traffic Engineering purposes is unnumbered, the first two octets of the IPv4 neighbor address sub-TLV are set to zero and the next two octets are set to the interface ID of the unnumbered interface. In combination with the IPv4 interface address sub-TLV this identifies the unnumbered link over which the advertised adjacency has been established. Implementations MUST NOT inject a /32 prefix for the neighbor address into their routing or forwarding table, because this can lead to forwarding loops when interacting with systems that do not support this sub-TLV. If a router implements the basic TLV extensions in this document, it is free to add or omit this sub-TLV to the description of an adjacency. If a router implements traffic engineering, it must include this sub-TLV on point-to-point adjacencies. 5.4 Sub-TLV 11: Unreserved bandwidth This sub-TLV contains the amount of bandwidth reservable on this direction on this link. Note that for oversubscription purposes, this can be greater than the bandwidth of the link. Because of the need for priority and preemption, each head end needs to know the amount of reserved bandwidth at each priority level. Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers. The units are bytes (not bits!) per second. The values correspond to the bandwidth that can be reserved with a holding of priority 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub-TLV, and priority 7 at the end of the sub-TLV. For stability reasons, rapid changes in the values in this sub-TLV should not cause rapid generation of LSPs. 5.5 Sub-TLV 18: Traffic Engineering Default metric This sub-TLV contains a 24-bit unsigned integer. This metric is administratively assigned and can be used to present a differently weighted topology to traffic engineering SPF calculations. To preclude overflow within an SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC shall be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 - 2^25). If a link is advertised without this sub-TLV, traffic engineering SPF calculations must use the normal default metric of this link, which is advertised in the fixed part of the extended IS reachability TLV. 6.0 Security Considerations This document raises no new security issues for IS-IS. 7.0 Acknowledgments The authors would like to thank Yakov Rekhter and Dave Katz for their comments on this work. 8.0 References [1] RFC 2702, "Requirements for Traffic Engineering Over MPLS," D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, September 1999. [2] ISO 10589, "Intermediate System to Intermediate System Intra- Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)" [Also republished as RFC 1142] [3] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", R.W. Callon, Dec. 1990 9.0 Authors' Addresses Tony Li Procket Networks, Inc. 3850 North First Street San Jose, CA 95134 Email: tli@procket.com Voice: +1 408 9547900 Fax: +1 408 9876166 Henk Smit Procket Networks, Inc. 3850 North First Street San Jose, CA 95134 Email: henk@procket.com Voice: +1 408 9547900 Fax: +1 408 9876166 From Internet-Drafts@ietf.org Wed, 06 Sep 2000 06:44:06 -0400 Date: Wed, 06 Sep 2000 06:44:06 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-traffic-02.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS extensions for Traffic Engineering Author(s) : T. Li, H. Smit Filename : draft-ietf-isis-traffic-02.txt Pages : 9 Date : 05-Sep-00 This document describes extensions to the IS-IS protocol to support Traffic Engineering [1]. The IS-IS protocol is specified in [2], with extensions for supporting IPv4 specified in [3]. This document extends the IS-IS protocol by specifying new information that a Intermediate System (IS) [router] can place in Link State Protocol Data Units (LSPs). This information describes additional information about the state of the network that is useful for traffic engineering computations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-02.txt 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-isis-traffic-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-isis-traffic-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: <20000905135154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-traffic-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-traffic-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000905135154.I-D@ietf.org> --OtherAccess-- --NextPart-- From Internet-Drafts@ietf.org Wed, 06 Sep 2000 06:44:37 -0400 Date: Wed, 06 Sep 2000 06:44:37 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-dharanikota-interarea-mpls-te-ext-00.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OSPF, IS-IS, RSVP, CR-LDP Extensions to Support Inter-Area Traffic Engineering Using MPLS TE Author(s) : S. Dharanikota, S. Venkatachalam Filename : draft-dharanikota-interarea-mpls-te-ext-00.txt Pages : 20 Date : 05-Sep-00 In this draft, we propose the extensions required to the routing protocols, signaling protocols, and the MIB to support the idea of inter-area LSPs. A companion document [INTER_AREA_FWK] provides the architectural requirements for such a concept. This document also provides the signaling extensions to support the crankback as defined in the architecture document [INTER_AREA_FWK]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dharanikota-interarea-mpls-te-ext-00.txt 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-dharanikota-interarea-mpls-te-ext-00.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-dharanikota-interarea-mpls-te-ext-00.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: <20000905135234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dharanikota-interarea-mpls-te-ext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-dharanikota-interarea-mpls-te-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000905135234.I-D@ietf.org> --OtherAccess-- --NextPart-- From oran@cisco.com Thu, 7 Sep 2000 11:44:20 -0400 Date: Thu, 7 Sep 2000 11:44:20 -0400 From: David Oran oran@cisco.com Subject: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing This is a multi-part message in MIME format. ------=_NextPart_000_018E_01C018C0.F5C6AE40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit For those of you who hate MSWORD, I append the text at the end of the message text as well. Are there other drafts they should fold it? If so, please craft a response and I'll get it to them. -----Original Message----- From: Matthew Deane [mailto:mdeane@ANSI.org] Sent: Thursday, September 07, 2000 11:35 AM To: 'oran@cisco.com'; 'rcoltun@redback.com'; 'sob@harvard.edu'; 'mankin@east.isi.edu' Cc: 'Jim Long (SC 6/WG 7 Convenor)'; 'Jooran Lee' Subject: JTC 1/SC 6 Liaison Statement on Routeing > Dear IETF Directors, > > Per ISO/IEC JTC 1/SC 6 Prague Plenary Resolution 6.7.7, the following > document is forwarded to IETF Routeing and Transport Area Directors for > consideration: > > SC 6 N 11618, Liaison Statement to IETF on ISO/IEC CD 10589 (2nd version) > > > Please do not hesitate to contact me should you have any questions. > > Sincerely, > > Matt Deane > JTC 1/SC 6 Secretariat > > <<06n1618.rtf>> SC 6 N 11618 Title: Liaison Report to the IETF Routing Area Director on 2nd CD for ISO/IEC 10589 (IS-IS Routing) Source: ISO/IEC JTC1/SC6 ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for ISO10589. SC6 intends to use this new version 2 as the base for adding the enhancements which have been requested by the IETF to optimise the use of ISO 10589 for Internet routing solutions. The IETF IS-IS WG convenor originally identified Internet Drafts: and as the source documents which specify these enhancements. SC6 invites the IETF to confirm that the above Internet Drafts are the correct references and to inform SC6 if there are additional IETF documents which refer to any other requirements for IS-IS Routing enhancements. SC6 would like to interact with the IETF on clarifying the detailed requirements in the hope that it may be possible to introduce them during the editing cycle for version 2 of the standard. To this end, we would like the Routing Area Directors to arrange an IS-IS BOF at the San Diego IETF meeting to discuss these requirements and how they can be incorporated into the new version of ISO 10586. SC6 will post an initial draft version of the new base document as an Internet Draft in August 2000 but this will not contain the changes requested by the IETF. A ballot closure date of February 2001 has been set for the 2nd CD Ballot to allow incorporation of final input on the Internet requirements if they can be agreed at the December 2000 IETF meeting. For information, the current instructions to the editor are that he should use ISO/IEC 10589:1992 as a base for editing, and shall apply the minimum textual changes mandated by the following TCs and DRs: ISO/IEC 10589:1992/Cor.1:1993 ISO/IEC 10589:1992/Cor.2:1996 ISO/IEC 10589:1992/Cor.3:1996 ISO/IEC 10589:1992/Amd 1:1996 6N10323 - Defect Reports 7-26 6N10659 - Defect Reports 27-34 6N10733 - Technical Corrigendum 4 The editor will also apply the minimal changes necessary to resolve additional Defect Reports 35-44. If SC6 and the IETF are unable to resolve the required changes, the Editor will add a temporary note to the cover page and the scope clause stating that: “ ISO 10589 does not currently include the extensions originally requested by the IETF in Internet Drafts: and . National Body and Liaison organization comments are invited to comment on the best way to progress these extensions.” ------=_NextPart_000_018E_01C018C0.F5C6AE40 Content-Type: application/msword; name="06n1618.rtf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="06n1618.rtf" {\rtf1\ansi\ansicpg1252\uc1 = \deff0\deflang1033\deflangfe1033{\fonttbl{\f0\froman\fcharset0\fprq2{\*\p= anose 02020603050405020304}Times New Roman{\*\falt CG = Times};}{\f2\fmodern\fcharset0\fprq1{\*\panose = 02070309020205020404}Courier New;}} {\colortbl;\red0\green0\blue0;\red0\green0\blue255;\red0\green255\blue255= ;\red0\green255\blue0;\red255\green0\blue255;\red255\green0\blue0;\red255= \green255\blue0;\red255\green255\blue255;\red0\green0\blue128;\red0\green= 128\blue128;\red0\green128\blue0; \red128\green0\blue128;\red128\green0\blue0;\red128\green128\blue0;\red12= 8\green128\blue128;\red192\green192\blue192;}{\stylesheet{\widctlpar\adju= stright \fs20\cgrid \snext0 Normal;}{\*\cs10 \additive Default Paragraph = Font;}{\s15\nowidctlpar \tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7672\tx8631\tx9590= \adjustright \f2\fs20 \sbasedon0 \snext15 Preformatted;}}{\info{\title = Ethan Frome}{\author EW/LN/CB}{\keywords Ethan}{\operator Matthew = Deane}{\creatim\yr2000\mo6\dy9\hr18\min52} {\revtim\yr2000\mo6\dy16\hr14\min3}{\version3}{\edmins1}{\nofpages2}{\nof= words533}{\nofchars3040}{\*\company Lucent = Technologies}{\nofcharsws3733}{\vern89}} \widowctrl\ftnbj\aenddoc\noxlattoyen\expshrtn\noultrlspc\dntblnsbdb\nospa= ceforul\hyphcaps0\formshade\viewkind4\viewscale100\pgbrdrhead\pgbrdrfoot = \fet0\sectd \linex0\endnhere\sectdefaultcl = {\*\pnseclvl1\pnucrm\pnstart1\pnindent720\pnhang{\pntxta .}} {\*\pnseclvl2\pnucltr\pnstart1\pnindent720\pnhang{\pntxta = .}}{\*\pnseclvl3\pndec\pnstart1\pnindent720\pnhang{\pntxta = .}}{\*\pnseclvl4\pnlcltr\pnstart1\pnindent720\pnhang{\pntxta = )}}{\*\pnseclvl5\pndec\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = )}} {\*\pnseclvl6\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = )}}{\*\pnseclvl7\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = )}}{\*\pnseclvl8\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = )}}{\*\pnseclvl9 \pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}\pard\plain = \s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx76= 72\tx8631\adjustright \f2\fs20 {\tab \tab \tab }{ Telecommunications and Information =20 \par Exchange Between Systems = =20 \par=20 \par=20 \par ISO/IEC JTC 1/SC06 N 11618 =20 \par=20 \par DATE: 2000-06-16 =20 \par=20 \par REPLACES =20 \par=20 \par DOC TYPE: \par Outgoing Liaison Statement =20 \par=20 \par TITLE: \par Liaison Statement to IETF on ISO/IEC CD 10589 (2nd version) = =20 \par=20 \par SOURCE: \par SC 6/WG 7 Convener = =20 \par=20 \par PROJECT: =20 \par=20 \par STATUS: \par Per SC 6 Prague Resolution 6.7.7, this document is forwarded to = IETF =20 \par for consideration. = =20 \par=20 \par ACTION ID: ACT=20 \par=20 \par DUE DATE: =20 \par=20 \par DISTRIBUTION: P & L Members; SC Chair; WG Conveners and = Secretaries =20 \par=20 \par=20 \par MEDIUM: =20 \par=20 \par DISKETTE NO.: =20 \par=20 \par NO. OF PAGES: 1 =20 \par=20 \par=20 \par ISO/IEC JTC 1/SC 6 Secretariat = =20 \par ANSI, 11 W. 42nd Street, New York, NY 10036, USA = =20 \par }\pard = \s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx76= 72\tx8631\adjustright {Tel: +1 212 642 4992; Fax: +1 212 84}{0 2298; = E-mail: }{mdeane@ansi.org}{\tab \tab \tab \tab \tab \tab = \tab }{\b\fs28=20 \par }\pard\plain \widctlpar\adjustright \fs20\cgrid {\b\fs28 \page=20 \par \tab \tab \tab \tab \tab \tab \tab \tab \tab SC 6 N 11618 \par }{ \par }{\b Title: Liaison Report to the IETF Routing Area Director on = 2}{\b\super nd}{\b CD for ISO/IEC 10589 (IS-IS Routing) \par=20 \par Source: ISO/IEC JTC1/SC6 \par }{ \par ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for = ISO10589. SC6 intends to use this new version 2 as the base for adding = the enhancements which have been requested by the IETF=20 to optimise the use of ISO 10589 for Internet routing solutions. The = IETF IS-IS WG convenor originally identified Internet Drafts: = and as = the source documents which specify these enhanceme nts. SC6 invites the IETF to confirm that the above Internet Drafts = are the correct references and to inform SC6 if there are additional = IETF documents which refer to any other requirements for IS-IS Routing = enhancements. \par=20 \par SC6 would like to interact wit h the IETF on clarifying the detailed requirements in the hope that it = may be possible to introduce them during the editing cycle for version = 2 of the standard. To this end, we would like the Routing Area = Directors to arrange an IS-IS BOF at the San Di ego IETF meeting to discuss these requirements and how they can be = incorporated into the new version of ISO 10586. \par=20 \par SC6 will post an initial draft version of the new base document as = an Internet Draft in August 2000 but this will not contain the changes r equested by the IETF. A ballot closure date of February 2001 has been = set for the 2nd CD Ballot to allow incorporation of final input on the = Internet requirements if they can be agreed at the December 2000 IETF = meeting.=20 \par=20 \par For information, the current instructions to the editor are that he = should use ISO/IEC 10589:1992 as a base for editing, and shall apply the = minimum textual changes mandated by the following TCs and DRs: \par=20 \par ISO/IEC 10589:1992/Cor.1:1993 \par ISO/IEC 10589:1992/Cor.2:1996 \par ISO/IEC 10589:1992/Cor.3:1996 \par ISO/IEC 10589:1992/Amd 1:1996 \par 6N10323 - Defect Reports 7-26 \par 6N10659 - Defect Reports 27-34 \par 6N10733 - Technical Corrigendum 4 \par The editor will also apply the minimal changes necessary to = resolve additional Defect Reports 35-44. \par=20 \par If SC6 and the IETF are unable to resolve the required changes, the = Editor will add a temporary note to the cover page and the scope clause = stating that: \ldblquote=20 ISO 10589 does not currently include the extensions originally = requested by the IETF in Internet D rafts: and = . National Body and Liaison = organization comments are invited to comment on the best way to progress = these extensions.\rdblquote=20 \par=20 \par=20 \par }} ------=_NextPart_000_018E_01C018C0.F5C6AE40-- From oran@cisco.com Thu, 7 Sep 2000 16:23:02 -0400 Date: Thu, 7 Sep 2000 16:23:02 -0400 From: David Oran oran@cisco.com Subject: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing Copying the WG... -----Original Message----- From: Henk Smit [mailto:henk@Procket.com] Sent: Thursday, September 07, 2000 3:50 PM To: David Oran Subject: Re: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing > For those of you who hate MSWORD, I append the text at the end of the > message text as well. Thank you, I appreciate it ! Pretty weird that a standards body like ISO is using a proprietary files format. ;-) > Are there other drafts they should fold it? If so, please craft a > response and I'll get it to them. draft-ietf-isis-dyname-02.txt is not a draft anymore. It is now an RFC: RFC2763. I have just submitted a new version of draft-ietf-isis-traffic-01.txt, draft-ietf-isis-traffic-02.txt. It might be a while before it becomes an RFC. And what about RFC1195 itself ? There is no mention that this RFC will be incorporated ? If RFC1195 is incorporated, there is one more ISIS draft that I would like to see added. Tony Li, Tony Prziegynda and myself are also authors of a draft that is related. draft-ietf-isis-domain-wide-02.txt. It is slated to be an RFC pretty soon, just waiting for the RFC editor to process it. If 10589 is including IP specific stuff, I think this one should be incorporated too. Henk. > -----Original Message----- > From: Matthew Deane [mailto:mdeane@ANSI.org] > Sent: Thursday, September 07, 2000 11:35 AM > To: 'oran@cisco.com'; 'rcoltun@redback.com'; 'sob@harvard.edu'; > 'mankin@east.isi.edu' > Cc: 'Jim Long (SC 6/WG 7 Convenor)'; 'Jooran Lee' > Subject: JTC 1/SC 6 Liaison Statement on Routeing > > > > Dear IETF Directors, > > > > Per ISO/IEC JTC 1/SC 6 Prague Plenary Resolution 6.7.7, the following > > document is forwarded to IETF Routeing and Transport Area Directors > for > > consideration: > > > > SC 6 N 11618, Liaison Statement to IETF on ISO/IEC CD 10589 (2nd > version) > > > > > > Please do not hesitate to contact me should you have any questions. > > > > Sincerely, > > > > Matt Deane > > JTC 1/SC 6 Secretariat > > > > <<06n1618.rtf>> > > > SC 6 N 11618 > > Title: Liaison Report to the IETF Routing Area Director on 2nd CD for > ISO/IEC 10589 (IS-IS Routing) > > Source: ISO/IEC JTC1/SC6 > > ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for ISO10589. > SC6 intends to use this new version 2 as the base for adding the > enhancements which have been requested by the IETF to optimise the use > of ISO 10589 for Internet routing solutions. The IETF IS-IS WG convenor > originally identified Internet Drafts: > and as the source documents which > specify these enhancements. SC6 invites the IETF to confirm that the > above Internet Drafts are the correct references and to inform SC6 if > there are additional IETF documents which refer to any other > requirements for IS-IS Routing enhancements. > > SC6 would like to interact with the IETF on clarifying the detailed > requirements in the hope that it may be possible to introduce them > during the editing cycle for version 2 of the standard. To this end, > we would like the Routing Area Directors to arrange an IS-IS BOF at the > San Diego IETF meeting to discuss these requirements and how they can be > incorporated into the new version of ISO 10586. > > SC6 will post an initial draft version of the new base document as an > Internet Draft in August 2000 but this will not contain the changes > requested by the IETF. A ballot closure date of February 2001 has been > set for the 2nd CD Ballot to allow incorporation of final input on the > Internet requirements if they can be agreed at the December 2000 IETF > meeting. > > For information, the current instructions to the editor are that he > should use ISO/IEC 10589:1992 as a base for editing, and shall apply the > minimum textual changes mandated by the following TCs and DRs: > > ISO/IEC 10589:1992/Cor.1:1993 > ISO/IEC 10589:1992/Cor.2:1996 > ISO/IEC 10589:1992/Cor.3:1996 > ISO/IEC 10589:1992/Amd 1:1996 > 6N10323 - Defect Reports 7-26 > 6N10659 - Defect Reports 27-34 > 6N10733 - Technical Corrigendum 4 > The editor will also apply the minimal changes necessary to resolve > additional Defect Reports 35-44. > > If SC6 and the IETF are unable to resolve the required changes, the > Editor will add a temporary note to the cover page and the scope clause > stating that: “ ISO 10589 does not currently include the extensions > originally requested by the IETF in Internet Drafts: > and . > National Body and Liaison organization comments are invited to comment > on the best way to progress these extensions.” > > ------=_NextPart_000_018E_01C018C0.F5C6AE40 > Content-Type: application/msword; > name="06n1618.rtf" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: attachment; > filename="06n1618.rtf" > > {\rtf1\ansi\ansicpg1252\uc1 = > \deff0\deflang1033\deflangfe1033{\fonttbl{\f0\froman\fcharset0\fprq2{\*\ p= > anose 02020603050405020304}Times New Roman{\*\falt CG = > Times};}{\f2\fmodern\fcharset0\fprq1{\*\panose = > 02070309020205020404}Courier New;}} > {\colortbl;\red0\green0\blue0;\red0\green0\blue255;\red0\green255\blue25 5= > ;\red0\green255\blue0;\red255\green0\blue255;\red255\green0\blue0;\red25 5= > \green255\blue0;\red255\green255\blue255;\red0\green0\blue128;\red0\gree n= > 128\blue128;\red0\green128\blue0; > \red128\green0\blue128;\red128\green0\blue0;\red128\green128\blue0;\red1 2= > 8\green128\blue128;\red192\green192\blue192;}{\stylesheet{\widctlpar\adj u= > stright \fs20\cgrid \snext0 Normal;}{\*\cs10 \additive Default Paragraph = > Font;}{\s15\nowidctlpar > \tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7672\tx8631\tx959 0= > \adjustright \f2\fs20 \sbasedon0 \snext15 Preformatted;}}{\info{\title = > Ethan Frome}{\author EW/LN/CB}{\keywords Ethan}{\operator Matthew = > Deane}{\creatim\yr2000\mo6\dy9\hr18\min52} > {\revtim\yr2000\mo6\dy16\hr14\min3}{\version3}{\edmins1}{\nofpages2}{\no f= > words533}{\nofchars3040}{\*\company Lucent = > Technologies}{\nofcharsws3733}{\vern89}} > \widowctrl\ftnbj\aenddoc\noxlattoyen\expshrtn\noultrlspc\dntblnsbdb\nosp a= > ceforul\hyphcaps0\formshade\viewkind4\viewscale100\pgbrdrhead\pgbrdrfoot = > \fet0\sectd \linex0\endnhere\sectdefaultcl = > {\*\pnseclvl1\pnucrm\pnstart1\pnindent720\pnhang{\pntxta .}} > {\*\pnseclvl2\pnucltr\pnstart1\pnindent720\pnhang{\pntxta = > .}}{\*\pnseclvl3\pndec\pnstart1\pnindent720\pnhang{\pntxta = > .}}{\*\pnseclvl4\pnlcltr\pnstart1\pnindent720\pnhang{\pntxta = > )}}{\*\pnseclvl5\pndec\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = > )}} > {\*\pnseclvl6\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = > )}}{\*\pnseclvl7\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = > )}}{\*\pnseclvl8\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = > )}}{\*\pnseclvl9 > \pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}\pard\plain = > \s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7 6= > 72\tx8631\adjustright \f2\fs20 {\tab \tab \tab }{ > Telecommunications and Information =20 > \par Exchange Between Systems = > =20 > \par=20 > \par=20 > \par ISO/IEC JTC 1/SC06 N 11618 =20 > \par=20 > \par DATE: 2000-06-16 =20 > \par=20 > \par REPLACES =20 > \par=20 > \par DOC TYPE: > \par Outgoing Liaison Statement =20 > \par=20 > \par TITLE: > \par Liaison Statement to IETF on ISO/IEC CD 10589 (2nd version) = > =20 > \par=20 > \par SOURCE: > \par SC 6/WG 7 Convener = > =20 > \par=20 > \par PROJECT: =20 > \par=20 > \par STATUS: > \par Per SC 6 Prague Resolution 6.7.7, this document is forwarded to = > IETF =20 > \par for consideration. = > =20 > \par=20 > \par ACTION ID: ACT=20 > \par=20 > \par DUE DATE: =20 > \par=20 > \par DISTRIBUTION: P & L Members; SC Chair; WG Conveners and = > Secretaries =20 > \par=20 > \par=20 > \par MEDIUM: =20 > \par=20 > \par DISKETTE NO.: =20 > \par=20 > \par NO. OF PAGES: 1 =20 > \par=20 > \par=20 > \par ISO/IEC JTC 1/SC 6 Secretariat = > =20 > \par ANSI, 11 W. 42nd Street, New York, NY 10036, USA = > =20 > \par }\pard = > \s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7 6= > 72\tx8631\adjustright {Tel: +1 212 642 4992; Fax: +1 212 84}{0 2298; = > E-mail: }{mdeane@ansi.org}{\tab \tab \tab \tab \tab \tab = > \tab }{\b\fs28=20 > \par }\pard\plain \widctlpar\adjustright \fs20\cgrid {\b\fs28 \page=20 > \par \tab \tab \tab \tab \tab \tab \tab \tab \tab SC 6 N 11618 > \par }{ > \par }{\b Title: Liaison Report to the IETF Routing Area Director on = > 2}{\b\super nd}{\b CD for ISO/IEC 10589 (IS-IS Routing) > \par=20 > \par Source: ISO/IEC JTC1/SC6 > \par }{ > \par ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for = > ISO10589. SC6 intends to use this new version 2 as the base for adding = > the enhancements which have been requested by the IETF=20 > to optimise the use of ISO 10589 for Internet routing solutions. The = > IETF IS-IS WG convenor originally identified Internet Drafts: = > and as = > the source documents which specify these enhanceme > nts. SC6 invites the IETF to confirm that the above Internet Drafts = > are the correct references and to inform SC6 if there are additional = > IETF documents which refer to any other requirements for IS-IS Routing = > enhancements. > \par=20 > \par SC6 would like to interact wit > h the IETF on clarifying the detailed requirements in the hope that it = > may be possible to introduce them during the editing cycle for version = > 2 of the standard. To this end, we would like the Routing Area = > Directors to arrange an IS-IS BOF at the San Di > ego IETF meeting to discuss these requirements and how they can be = > incorporated into the new version of ISO 10586. > \par=20 > \par SC6 will post an initial draft version of the new base document as = > an Internet Draft in August 2000 but this will not contain the changes r > equested by the IETF. A ballot closure date of February 2001 has been = > set for the 2nd CD Ballot to allow incorporation of final input on the = > Internet requirements if they can be agreed at the December 2000 IETF = > meeting.=20 > \par=20 > \par For information, the current instructions to the editor are that he = > should use ISO/IEC 10589:1992 as a base for editing, and shall apply the = > minimum textual changes mandated by the following TCs and DRs: > \par=20 > \par ISO/IEC 10589:1992/Cor.1:1993 > \par ISO/IEC 10589:1992/Cor.2:1996 > \par ISO/IEC 10589:1992/Cor.3:1996 > \par ISO/IEC 10589:1992/Amd 1:1996 > \par 6N10323 - Defect Reports 7-26 > \par 6N10659 - Defect Reports 27-34 > \par 6N10733 - Technical Corrigendum 4 > \par The editor will also apply the minimal changes necessary to = > resolve additional Defect Reports 35-44. > \par=20 > \par If SC6 and the IETF are unable to resolve the required changes, the = > Editor will add a temporary note to the cover page and the scope clause = > stating that: \ldblquote=20 > ISO 10589 does not currently include the extensions originally = > requested by the IETF in Internet D > rafts: and = > . National Body and Liaison = > organization comments are invited to comment on the best way to progress = > these extensions.\rdblquote=20 > \par=20 > \par=20 > \par }} > ------=_NextPart_000_018E_01C018C0.F5C6AE40-- > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From mbartell@cisco.com Thu, 07 Sep 2000 16:57:25 -0500 Date: Thu, 07 Sep 2000 16:57:25 -0500 From: Micah Bartell mbartell@cisco.com Subject: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing Folks, I will say that the only documents that I integrated into the ISO 10589 2nd edition were those specified in the "Instructions" from the ISO meeting in Prague. The changes consist of the following documents: ISO/IEC 10589:1992/Cor.1:1993 ISO/IEC 10589:1992/Cor.2:1996 ISO/IEC 10589:1992/Cor.3:1996 ISO/IEC 10589:1992/Amd 1:1996 6N10323 - Defect Reports 7-26 6N10659 - Defect Reports 27-34 6N10733 - Technical Corrigendum 4 The editor will also apply the minimal changes necessary to resolve additional Defect Reports 35-44. Regarding the changes proposed for DR 35-44, the SIF recommendation was used in place of these DRs. Nothing IP specific was added to ISO 10589. The question that the ISO is presenting here to the IETF as I understand it is: What does the IETF recommend as the best method moving forward to handle changes to the ISO spec by the IETF and how best should the IP specific information be handled? The ISO world does not seem intent upon making great sweeping changes to the spec, to the best of my knowledge and most new work is being handled within the IETF. I think it would be wise to develop a method for dealing with all IETF changes before setting the precedent of integrating ANY of the IETF ID's or RFC's directly into the spec. That document is already getting unwieldly in Word and if it is going to be accepting another 100 pages of material, it will very likely need to be restructured. The question of whether the ISO wishes to continue to maintain this spec also needs to be asked. If not, it may be possible to publish the ISO 10589 as a standards track RFC. This would likely require some modification to the structure of the document. ( Does an RFC really need 30 pages of complex conformance tables? ) Also the ISO 10589 spec is not friendly to a purely text based representation. These are just some of my thoughts on the matter. While, I am the current editor for the document, I am not presenting these suggestions as a "representative" of the ISO, or stating this to be their official position. I will investigate further making available the PDF version that I have of the 2nd Edition. This is pending a response from ANSI. /mpb At 04:23 PM 9/7/2000 -0400, David Oran wrote: >Copying the WG... > >-----Original Message----- >From: Henk Smit [mailto:henk@Procket.com] >Sent: Thursday, September 07, 2000 3:50 PM >To: David Oran >Subject: Re: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing > > > > > For those of you who hate MSWORD, I append the text at the end of the > > message text as well. > > Thank you, I appreciate it ! > Pretty weird that a standards body like ISO is using a proprietary > files format. ;-) > > > Are there other drafts they should fold it? If so, please craft a > > response and I'll get it to them. > > draft-ietf-isis-dyname-02.txt is not a draft anymore. > It is now an RFC: RFC2763. > > I have just submitted a new version of draft-ietf-isis-traffic-01.txt, > draft-ietf-isis-traffic-02.txt. It might be a while before it becomes > an RFC. > > And what about RFC1195 itself ? There is no mention that this RFC > will be incorporated ? > > If RFC1195 is incorporated, there is one more ISIS draft that I would > like to see added. Tony Li, Tony Prziegynda and myself are also authors > of a draft that is related. draft-ietf-isis-domain-wide-02.txt. It is > slated to be an RFC pretty soon, just waiting for the RFC editor to > process it. If 10589 is including IP specific stuff, I think this one > should be incorporated too. > > Henk. > > > > > -----Original Message----- > > From: Matthew Deane [mailto:mdeane@ANSI.org] > > Sent: Thursday, September 07, 2000 11:35 AM > > To: 'oran@cisco.com'; 'rcoltun@redback.com'; 'sob@harvard.edu'; > > 'mankin@east.isi.edu' > > Cc: 'Jim Long (SC 6/WG 7 Convenor)'; 'Jooran Lee' > > Subject: JTC 1/SC 6 Liaison Statement on Routeing > > > > > > > Dear IETF Directors, > > > > > > Per ISO/IEC JTC 1/SC 6 Prague Plenary Resolution 6.7.7, the >following > > > document is forwarded to IETF Routeing and Transport Area Directors > > for > > > consideration: > > > > > > SC 6 N 11618, Liaison Statement to IETF on ISO/IEC CD 10589 (2nd > > version) > > > > > > > > > Please do not hesitate to contact me should you have any questions. > > > > > > Sincerely, > > > > > > Matt Deane > > > JTC 1/SC 6 Secretariat > > > > > > <<06n1618.rtf>> > > > > > > SC 6 N 11618 > > > > Title: Liaison Report to the IETF Routing Area Director on 2nd CD for > > ISO/IEC 10589 (IS-IS Routing) > > > > Source: ISO/IEC JTC1/SC6 > > > > ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for >ISO10589. > > SC6 intends to use this new version 2 as the base for adding the > > enhancements which have been requested by the IETF to optimise the use > > of ISO 10589 for Internet routing solutions. The IETF IS-IS WG >convenor > > originally identified Internet Drafts: > > > and as the source documents which > > specify these enhancements. SC6 invites the IETF to confirm that the > > above Internet Drafts are the correct references and to inform SC6 if > > there are additional IETF documents which refer to any other > > requirements for IS-IS Routing enhancements. > > > > SC6 would like to interact with the IETF on clarifying the detailed > > requirements in the hope that it may be possible to introduce them > > during the editing cycle for version 2 of the standard. To this end, > > we would like the Routing Area Directors to arrange an IS-IS BOF at >the > > San Diego IETF meeting to discuss these requirements and how they can >be > > incorporated into the new version of ISO 10586. > > > > SC6 will post an initial draft version of the new base document as an > > Internet Draft in August 2000 but this will not contain the changes > > requested by the IETF. A ballot closure date of February 2001 has >been > > set for the 2nd CD Ballot to allow incorporation of final input on the > > Internet requirements if they can be agreed at the December 2000 IETF > > meeting. > > > > For information, the current instructions to the editor are that he > > should use ISO/IEC 10589:1992 as a base for editing, and shall apply >the > > minimum textual changes mandated by the following TCs and DRs: > > > > ISO/IEC 10589:1992/Cor.1:1993 > > ISO/IEC 10589:1992/Cor.2:1996 > > ISO/IEC 10589:1992/Cor.3:1996 > > ISO/IEC 10589:1992/Amd 1:1996 > > 6N10323 - Defect Reports 7-26 > > 6N10659 - Defect Reports 27-34 > > 6N10733 - Technical Corrigendum 4 > > The editor will also apply the minimal changes necessary to resolve > > additional Defect Reports 35-44. > > > > If SC6 and the IETF are unable to resolve the required changes, the > > Editor will add a temporary note to the cover page and the scope >clause > > stating that: “ ISO 10589 does not currently include the extensions > > originally requested by the IETF in Internet Drafts: > > and . > > National Body and Liaison organization comments are invited to comment > > on the best way to progress these extensions.” > > > > ------=_NextPart_000_018E_01C018C0.F5C6AE40 > > Content-Type: application/msword; > > name="06n1618.rtf" > > Content-Transfer-Encoding: quoted-printable > > Content-Disposition: attachment; > > filename="06n1618.rtf" > > > > {\rtf1\ansi\ansicpg1252\uc1 = > > >\deff0\deflang1033\deflangfe1033{\fonttbl{\f0\froman\fcharset0\fprq2{\*\ >p= > > anose 02020603050405020304}Times New Roman{\*\falt CG = > > Times};}{\f2\fmodern\fcharset0\fprq1{\*\panose = > > 02070309020205020404}Courier New;}} > > >{\colortbl;\red0\green0\blue0;\red0\green0\blue255;\red0\green255\blue25 >5= > > >;\red0\green255\blue0;\red255\green0\blue255;\red255\green0\blue0;\red25 >5= > > >\green255\blue0;\red255\green255\blue255;\red0\green0\blue128;\red0\gree >n= > > 128\blue128;\red0\green128\blue0; > > >\red128\green0\blue128;\red128\green0\blue0;\red128\green128\blue0;\red1 >2= > > >8\green128\blue128;\red192\green192\blue192;}{\stylesheet{\widctlpar\adj >u= > > stright \fs20\cgrid \snext0 Normal;}{\*\cs10 \additive Default >Paragraph = > > Font;}{\s15\nowidctlpar > > >\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7672\tx8631\tx959 >0= > > \adjustright \f2\fs20 \sbasedon0 \snext15 Preformatted;}}{\info{\title >= > > Ethan Frome}{\author EW/LN/CB}{\keywords Ethan}{\operator Matthew = > > Deane}{\creatim\yr2000\mo6\dy9\hr18\min52} > > >{\revtim\yr2000\mo6\dy16\hr14\min3}{\version3}{\edmins1}{\nofpages2}{\no >f= > > words533}{\nofchars3040}{\*\company Lucent = > > Technologies}{\nofcharsws3733}{\vern89}} > > >\widowctrl\ftnbj\aenddoc\noxlattoyen\expshrtn\noultrlspc\dntblnsbdb\nosp >a= > > >ceforul\hyphcaps0\formshade\viewkind4\viewscale100\pgbrdrhead\pgbrdrfoot >= > > \fet0\sectd \linex0\endnhere\sectdefaultcl = > > {\*\pnseclvl1\pnucrm\pnstart1\pnindent720\pnhang{\pntxta .}} > > {\*\pnseclvl2\pnucltr\pnstart1\pnindent720\pnhang{\pntxta = > > .}}{\*\pnseclvl3\pndec\pnstart1\pnindent720\pnhang{\pntxta = > > .}}{\*\pnseclvl4\pnlcltr\pnstart1\pnindent720\pnhang{\pntxta = > > )}}{\*\pnseclvl5\pndec\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta >= > > )}} > > {\*\pnseclvl6\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta = > > )}}{\*\pnseclvl7\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta >= > > )}}{\*\pnseclvl8\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb >(}{\pntxta = > > )}}{\*\pnseclvl9 > > \pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}\pard\plain >= > > >\s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7 >6= > > 72\tx8631\adjustright \f2\fs20 {\tab \tab \tab }{ > > Telecommunications and Information >=20 > > \par Exchange Between Systems >= > > =20 > > \par=20 > > \par=20 > > \par ISO/IEC JTC 1/SC06 N 11618 =20 > > \par=20 > > \par DATE: 2000-06-16 =20 > > \par=20 > > \par REPLACES =20 > > \par=20 > > \par DOC TYPE: > > \par Outgoing Liaison Statement >=20 > > \par=20 > > \par TITLE: > > \par Liaison Statement to IETF on ISO/IEC CD 10589 (2nd version) >= > > =20 > > \par=20 > > \par SOURCE: > > \par SC 6/WG 7 Convener >= > > =20 > > \par=20 > > \par PROJECT: =20 > > \par=20 > > \par STATUS: > > \par Per SC 6 Prague Resolution 6.7.7, this document is forwarded to = > > IETF =20 > > \par for consideration. >= > > =20 > > \par=20 > > \par ACTION ID: ACT=20 > > \par=20 > > \par DUE DATE: =20 > > \par=20 > > \par DISTRIBUTION: P & L Members; SC Chair; WG Conveners and = > > Secretaries =20 > > \par=20 > > \par=20 > > \par MEDIUM: =20 > > \par=20 > > \par DISKETTE NO.: =20 > > \par=20 > > \par NO. OF PAGES: 1 =20 > > \par=20 > > \par=20 > > \par ISO/IEC JTC 1/SC 6 Secretariat >= > > =20 > > \par ANSI, 11 W. 42nd Street, New York, NY 10036, USA >= > > =20 > > \par }\pard = > > >\s15\nowidctlpar\tx0\tx959\tx1918\tx2877\tx3836\tx4795\tx5754\tx6713\tx7 >6= > > 72\tx8631\adjustright {Tel: +1 212 642 4992; Fax: +1 212 84}{0 >2298; = > > E-mail: }{mdeane@ansi.org}{\tab \tab \tab \tab \tab \tab >= > > \tab }{\b\fs28=20 > > \par }\pard\plain \widctlpar\adjustright \fs20\cgrid {\b\fs28 \page=20 > > \par \tab \tab \tab \tab \tab \tab \tab \tab \tab SC 6 N 11618 > > \par }{ > > \par }{\b Title: Liaison Report to the IETF Routing Area Director on = > > 2}{\b\super nd}{\b CD for ISO/IEC 10589 (IS-IS Routing) > > \par=20 > > \par Source: ISO/IEC JTC1/SC6 > > \par }{ > > \par ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for = > > ISO10589. SC6 intends to use this new version 2 as the base for >adding = > > the enhancements which have been requested by the IETF=20 > > to optimise the use of ISO 10589 for Internet routing solutions. The >= > > IETF IS-IS WG convenor originally identified Internet Drafts: = > > and >as = > > the source documents which specify these enhanceme > > nts. SC6 invites the IETF to confirm that the above Internet Drafts >= > > are the correct references and to inform SC6 if there are additional = > > IETF documents which refer to any other requirements for IS-IS >Routing = > > enhancements. > > \par=20 > > \par SC6 would like to interact wit > > h the IETF on clarifying the detailed requirements in the hope that it >= > > may be possible to introduce them during the editing cycle for >version = > > 2 of the standard. To this end, we would like the Routing Area = > > Directors to arrange an IS-IS BOF at the San Di > > ego IETF meeting to discuss these requirements and how they can be = > > incorporated into the new version of ISO 10586. > > \par=20 > > \par SC6 will post an initial draft version of the new base document >as = > > an Internet Draft in August 2000 but this will not contain the changes >r > > equested by the IETF. A ballot closure date of February 2001 has been >= > > set for the 2nd CD Ballot to allow incorporation of final input on the >= > > Internet requirements if they can be agreed at the December 2000 IETF >= > > meeting.=20 > > \par=20 > > \par For information, the current instructions to the editor are that >he = > > should use ISO/IEC 10589:1992 as a base for editing, and shall apply >the = > > minimum textual changes mandated by the following TCs and DRs: > > \par=20 > > \par ISO/IEC 10589:1992/Cor.1:1993 > > \par ISO/IEC 10589:1992/Cor.2:1996 > > \par ISO/IEC 10589:1992/Cor.3:1996 > > \par ISO/IEC 10589:1992/Amd 1:1996 > > \par 6N10323 - Defect Reports 7-26 > > \par 6N10659 - Defect Reports 27-34 > > \par 6N10733 - Technical Corrigendum 4 > > \par The editor will also apply the minimal changes necessary to = > > resolve additional Defect Reports 35-44. > > \par=20 > > \par If SC6 and the IETF are unable to resolve the required changes, >the = > > Editor will add a temporary note to the cover page and the scope >clause = > > stating that: \ldblquote=20 > > ISO 10589 does not currently include the extensions originally = > > requested by the IETF in Internet D > > rafts: and = > > . National Body and Liaison = > > organization comments are invited to comment on the best way to >progress = > > these extensions.\rdblquote=20 > > \par=20 > > \par=20 > > \par }} > > ------=_NextPart_000_018E_01C018C0.F5C6AE40-- > > > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From henk@Procket.com Fri, 8 Sep 2000 00:23:44 +0200 (MEST) Date: Fri, 8 Sep 2000 00:23:44 +0200 (MEST) From: Henk Smit henk@Procket.com Subject: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing > What does the IETF recommend as the best method moving forward to > handle changes to the ISO spec by the IETF and how best should the IP > specific information be handled? Personally I would be in favor of combining all ISO documents and IETF RFCs into one, and then splitting it up in three separate documents. *) one document that specifies the core of ISIS. How to set up adjacencies, what an LSP looks like, what TLVs are, what areas are to ISIS, how to run the SPF itself, etc. *) one document that specifies all TLVs and algorithms related to routing of iso8473 (aka CLNP) *) one document that specifies all TLVs and algorithms related to routing of IP I think especially splitting the core of IS-IS from iso8473 related details will make the protocol much more understandable. Just my 2 cents, I guess it will never happen ... :-( Henk. From ginsberg@pluris.com Thu, 7 Sep 2000 15:38:24 -0700 Date: Thu, 7 Sep 2000 15:38:24 -0700 From: Les Ginsberg ginsberg@pluris.com Subject: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing The original intent of the workplan submitted to ISO was a two step process: 1)To provide a revised version of the base ISO 10589 spec that incorporates the known DRs etc. This is the work that Micah has taken on - for which he deserves much applause as it involved considerable effort and I am sure not all of it was fun. 2)Moving forward from the output of Step #1, to incorporate the IP related extensions so that there was a unified document/set of documents which accurately reflected the current usage of the protocol given its deployment in both OSI and IP environments. The need for this is driven by the evolution of the usage of the protocol in the IP environment and the (potential) use of IS-IS in dual environments. Also, there is the feeling of some (myself included) that the current fragmented definition is less than optimal. How best to implement Step #2 is a question yet to be answered. Whether to try to put everything into a single document or provide a set of documents? How to manage these documents (within IETF, within ISO, liason)? There are obviously very different approaches to both organizations as far as document formats, approval processes, participation in the process etc. The fact that the IETF has been invited into this process is a very good thing for it means that all the interested parties can easily have a voice in defining at least the content of what should go into the document(s). How such documents are to be maintained, while an important issue, I think should be separated from the more immediate questions of: o What set of inputs should be used to create the document(s)? o What form should the document(s) take? I certainly think that RFC 1195, appropriately revised, should be part of the input set. as well as those extensions that are agreed upon. In addition to those extensions mentioned by others I would also add the "3-way handshake" draft as an essential. Les > -----Original Message----- > From: Micah Bartell [mailto:mbartell@cisco.com] > Sent: Thursday, September 07, 2000 2:57 PM > To: David Oran; ISIS WG > Subject: Re: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement > on Routeing > > > Folks, > > I will say that the only documents that I integrated into the > ISO 10589 2nd edition were those specified in the > "Instructions" from the ISO meeting in Prague. The changes > consist of the following documents: > > ISO/IEC 10589:1992/Cor.1:1993 > ISO/IEC 10589:1992/Cor.2:1996 > ISO/IEC 10589:1992/Cor.3:1996 > ISO/IEC 10589:1992/Amd 1:1996 > 6N10323 - Defect Reports 7-26 > 6N10659 - Defect Reports 27-34 > 6N10733 - Technical Corrigendum 4 > The editor will also apply the minimal changes necessary to resolve > additional Defect Reports 35-44. > > Regarding the changes proposed for DR 35-44, the SIF > recommendation was used in place of these DRs. > > Nothing IP specific was added to ISO 10589. The question > that the ISO is presenting here to the IETF as I understand it is: > > What does the IETF recommend as the best method moving > forward to handle changes to the ISO spec by the IETF and how > best should the IP specific information be handled? > > > The ISO world does not seem intent upon making great sweeping > changes to the spec, to the best of my knowledge and most new > work is being handled within the IETF. > > I think it would be wise to develop a method for dealing with > all IETF changes before setting the precedent of integrating > ANY of the IETF ID's or RFC's directly into the spec. That > document is already getting unwieldly in Word and if it is > going to be accepting another 100 pages of material, it will > very likely need to be restructured. > > The question of whether the ISO wishes to continue to > maintain this spec also needs to be asked. If not, it may be > possible to publish the ISO 10589 as a standards track RFC. > This would likely require some modification to the structure > of the document. ( Does an RFC really need 30 pages of > complex conformance tables? ) Also the ISO 10589 spec is not > friendly to a purely text based representation. > > These are just some of my thoughts on the matter. While, I > am the current editor for the document, I am not presenting > these suggestions as a "representative" of the ISO, or > stating this to be their official position. > > I will investigate further making available the PDF version > that I have of the 2nd Edition. This is pending a response from ANSI. > > /mpb > > > At 04:23 PM 9/7/2000 -0400, David Oran wrote: > >Copying the WG... > > > >-----Original Message----- > >From: Henk Smit [mailto:henk@Procket.com] > >Sent: Thursday, September 07, 2000 3:50 PM > >To: David Oran > >Subject: Re: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing > > > > > > > > > For those of you who hate MSWORD, I append the text at > the end of the > > > message text as well. > > > > Thank you, I appreciate it ! > > Pretty weird that a standards body like ISO is using a proprietary > > files format. ;-) > > > > > Are there other drafts they should fold it? If so, please craft a > > > response and I'll get it to them. > > > > draft-ietf-isis-dyname-02.txt is not a draft anymore. > > It is now an RFC: RFC2763. > > > > I have just submitted a new version of > draft-ietf-isis-traffic-01.txt, > > draft-ietf-isis-traffic-02.txt. It might be a while before > it becomes > > an RFC. > > > > And what about RFC1195 itself ? There is no mention that this RFC > > will be incorporated ? > > > > If RFC1195 is incorporated, there is one more ISIS draft > that I would > > like to see added. Tony Li, Tony Prziegynda and myself are > also authors > > of a draft that is related. > draft-ietf-isis-domain-wide-02.txt. It is > > slated to be an RFC pretty soon, just waiting for the RFC editor to > > process it. If 10589 is including IP specific stuff, I > think this one > > should be incorporated too. > > > > Henk. > > > > > > > > > -----Original Message----- > > > From: Matthew Deane [mailto:mdeane@ANSI.org] > > > Sent: Thursday, September 07, 2000 11:35 AM > > > To: 'oran@cisco.com'; 'rcoltun@redback.com'; 'sob@harvard.edu'; > > > 'mankin@east.isi.edu' > > > Cc: 'Jim Long (SC 6/WG 7 Convenor)'; 'Jooran Lee' > > > Subject: JTC 1/SC 6 Liaison Statement on Routeing > > > > > > > > > > Dear IETF Directors, > > > > > > > > Per ISO/IEC JTC 1/SC 6 Prague Plenary Resolution 6.7.7, the > >following > > > > document is forwarded to IETF Routeing and Transport > Area Directors > > > for > > > > consideration: > > > > > > > > SC 6 N 11618, Liaison Statement to IETF on ISO/IEC CD 10589 (2nd > > > version) > > > > > > > > > > > > Please do not hesitate to contact me should you have > any questions. > > > > > > > > Sincerely, > > > > > > > > Matt Deane > > > > JTC 1/SC 6 Secretariat > > > > > > > > <<06n1618.rtf>> > > > > > > > > > > SC 6 N 11618 > > > > > > Title: Liaison Report to the IETF Routing Area Director > on 2nd CD for > > > ISO/IEC 10589 (IS-IS Routing) > > > > > > Source: ISO/IEC JTC1/SC6 > > > > > > ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for > >ISO10589. > > > SC6 intends to use this new version 2 as the base for adding the > > > enhancements which have been requested by the IETF to > optimise the use > > > of ISO 10589 for Internet routing solutions. The IETF IS-IS WG > >convenor > > > originally identified Internet Drafts: > > > > > and as the source documents which > > > specify these enhancements. SC6 invites the IETF to > confirm that the > > > above Internet Drafts are the correct references and to > inform SC6 if > > > there are additional IETF documents which refer to any other > > > requirements for IS-IS Routing enhancements. > > > > > > SC6 would like to interact with the IETF on clarifying > the detailed > > > requirements in the hope that it may be possible to > introduce them > > > during the editing cycle for version 2 of the standard. > To this end, > > > we would like the Routing Area Directors to arrange an > IS-IS BOF at > >the > > > San Diego IETF meeting to discuss these requirements and > how they can > >be > > > incorporated into the new version of ISO 10586. > > > > > > SC6 will post an initial draft version of the new base > document as an > > > Internet Draft in August 2000 but this will not contain > the changes > > > requested by the IETF. A ballot closure date of February 2001 has > >been > > > set for the 2nd CD Ballot to allow incorporation of final > input on the > > > Internet requirements if they can be agreed at the > December 2000 IETF > > > meeting. > > > > > > For information, the current instructions to the editor > are that he > > > should use ISO/IEC 10589:1992 as a base for editing, and > shall apply > >the > > > minimum textual changes mandated by the following TCs and DRs: > > > > > > ISO/IEC 10589:1992/Cor.1:1993 > > > ISO/IEC 10589:1992/Cor.2:1996 > > > ISO/IEC 10589:1992/Cor.3:1996 > > > ISO/IEC 10589:1992/Amd 1:1996 > > > 6N10323 - Defect Reports 7-26 > > > 6N10659 - Defect Reports 27-34 > > > 6N10733 - Technical Corrigendum 4 > > > The editor will also apply the minimal changes > necessary to resolve > > > additional Defect Reports 35-44. > > > > > > If SC6 and the IETF are unable to resolve the required > changes, the > > > Editor will add a temporary note to the cover page and the scope > >clause > > > stating that: " ISO 10589 does not currently include the > extensions > > > originally requested by the IETF in Internet Drafts: > > > and > . > > > National Body and Liaison organization comments are > invited to comment > > > on the best way to progress these extensions." > > > From jude@tcb.net Fri, 8 Sep 2000 21:06:38 -0600 (MDT) Date: Fri, 8 Sep 2000 21:06:38 -0600 (MDT) From: Jude V. Ballard jude@tcb.net Subject: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing Speaking as someone who is in the early stages of experience with this protocol, I would love to see this as a set of documents managed by the IETF. If for no other reason than to have a unified source, and format for the information. (I find the ISO format to be a bit unwieldy, but that is an opinion and not very relevant) It may also lead to development of protocol analysis, and "experience with" docs (additional benifits to the internet community.) I would be more than willing to volunteer my time in order to help complete this work. (Although the majority of you are probably more qualified.) -Jude On Thu, 7 Sep 2000, Les Ginsberg wrote: > The original intent of the workplan submitted to ISO was a two step process: > > 1)To provide a revised version of the base ISO 10589 spec that incorporates > the known DRs etc. This is the work that Micah has taken on - for which he > deserves much applause as it involved considerable effort and I am sure not > all of it was fun. > > 2)Moving forward from the output of Step #1, to incorporate the IP related > extensions so that there was a unified document/set of documents which > accurately reflected the current usage of the protocol given its deployment > in both OSI and IP environments. The need for this is driven by the > evolution of the usage of the protocol in the IP environment and the > (potential) use of IS-IS in dual environments. Also, there is the feeling of > some (myself included) that the current fragmented definition is less than > optimal. > > How best to implement Step #2 is a question yet to be answered. Whether to > try to put everything into a single document or provide a set of documents? > How to manage these documents (within IETF, within ISO, liason)? > > There are obviously very different approaches to both organizations as far > as document formats, approval processes, participation in the process etc. > > The fact that the IETF has been invited into this process is a very good > thing for it means that all the interested parties can easily have a voice > in defining at least the content of what should go into the document(s). How > such documents are to be maintained, while an important issue, I think > should be separated from the more immediate questions of: > > o What set of inputs should be used to create the document(s)? > o What form should the document(s) take? > > I certainly think that RFC 1195, appropriately revised, should be part of > the input set. as well as those extensions that are agreed upon. In addition > to those extensions mentioned by others I would also add the "3-way > handshake" draft as an essential. > > Les > > > -----Original Message----- > > From: Micah Bartell [mailto:mbartell@cisco.com] > > Sent: Thursday, September 07, 2000 2:57 PM > > To: David Oran; ISIS WG > > Subject: Re: FW: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement > > on Routeing > > > > > > Folks, > > > > I will say that the only documents that I integrated into the > > ISO 10589 2nd edition were those specified in the > > "Instructions" from the ISO meeting in Prague. The changes > > consist of the following documents: > > > > ISO/IEC 10589:1992/Cor.1:1993 > > ISO/IEC 10589:1992/Cor.2:1996 > > ISO/IEC 10589:1992/Cor.3:1996 > > ISO/IEC 10589:1992/Amd 1:1996 > > 6N10323 - Defect Reports 7-26 > > 6N10659 - Defect Reports 27-34 > > 6N10733 - Technical Corrigendum 4 > > The editor will also apply the minimal changes necessary to resolve > > additional Defect Reports 35-44. > > > > Regarding the changes proposed for DR 35-44, the SIF > > recommendation was used in place of these DRs. > > > > Nothing IP specific was added to ISO 10589. The question > > that the ISO is presenting here to the IETF as I understand it is: > > > > What does the IETF recommend as the best method moving > > forward to handle changes to the ISO spec by the IETF and how > > best should the IP specific information be handled? > > > > > > The ISO world does not seem intent upon making great sweeping > > changes to the spec, to the best of my knowledge and most new > > work is being handled within the IETF. > > > > I think it would be wise to develop a method for dealing with > > all IETF changes before setting the precedent of integrating > > ANY of the IETF ID's or RFC's directly into the spec. That > > document is already getting unwieldly in Word and if it is > > going to be accepting another 100 pages of material, it will > > very likely need to be restructured. > > > > The question of whether the ISO wishes to continue to > > maintain this spec also needs to be asked. If not, it may be > > possible to publish the ISO 10589 as a standards track RFC. > > This would likely require some modification to the structure > > of the document. ( Does an RFC really need 30 pages of > > complex conformance tables? ) Also the ISO 10589 spec is not > > friendly to a purely text based representation. > > > > These are just some of my thoughts on the matter. While, I > > am the current editor for the document, I am not presenting > > these suggestions as a "representative" of the ISO, or > > stating this to be their official position. > > > > I will investigate further making available the PDF version > > that I have of the 2nd Edition. This is pending a response from ANSI. > > > > /mpb > > > > > > At 04:23 PM 9/7/2000 -0400, David Oran wrote: > > >Copying the WG... > > > > > >-----Original Message----- > > >From: Henk Smit [mailto:henk@Procket.com] > > >Sent: Thursday, September 07, 2000 3:50 PM > > >To: David Oran > > >Subject: Re: [Isis-wg] FW: JTC 1/SC 6 Liaison Statement on Routeing > > > > > > > > > > > > > For those of you who hate MSWORD, I append the text at > > the end of the > > > > message text as well. > > > > > > Thank you, I appreciate it ! > > > Pretty weird that a standards body like ISO is using a proprietary > > > files format. ;-) > > > > > > > Are there other drafts they should fold it? If so, please craft a > > > > response and I'll get it to them. > > > > > > draft-ietf-isis-dyname-02.txt is not a draft anymore. > > > It is now an RFC: RFC2763. > > > > > > I have just submitted a new version of > > draft-ietf-isis-traffic-01.txt, > > > draft-ietf-isis-traffic-02.txt. It might be a while before > > it becomes > > > an RFC. > > > > > > And what about RFC1195 itself ? There is no mention that this RFC > > > will be incorporated ? > > > > > > If RFC1195 is incorporated, there is one more ISIS draft > > that I would > > > like to see added. Tony Li, Tony Prziegynda and myself are > > also authors > > > of a draft that is related. > > draft-ietf-isis-domain-wide-02.txt. It is > > > slated to be an RFC pretty soon, just waiting for the RFC editor to > > > process it. If 10589 is including IP specific stuff, I > > think this one > > > should be incorporated too. > > > > > > Henk. > > > > > > > > > > > > > -----Original Message----- > > > > From: Matthew Deane [mailto:mdeane@ANSI.org] > > > > Sent: Thursday, September 07, 2000 11:35 AM > > > > To: 'oran@cisco.com'; 'rcoltun@redback.com'; 'sob@harvard.edu'; > > > > 'mankin@east.isi.edu' > > > > Cc: 'Jim Long (SC 6/WG 7 Convenor)'; 'Jooran Lee' > > > > Subject: JTC 1/SC 6 Liaison Statement on Routeing > > > > > > > > > > > > > Dear IETF Directors, > > > > > > > > > > Per ISO/IEC JTC 1/SC 6 Prague Plenary Resolution 6.7.7, the > > >following > > > > > document is forwarded to IETF Routeing and Transport > > Area Directors > > > > for > > > > > consideration: > > > > > > > > > > SC 6 N 11618, Liaison Statement to IETF on ISO/IEC CD 10589 (2nd > > > > version) > > > > > > > > > > > > > > > Please do not hesitate to contact me should you have > > any questions. > > > > > > > > > > Sincerely, > > > > > > > > > > Matt Deane > > > > > JTC 1/SC 6 Secretariat > > > > > > > > > > <<06n1618.rtf>> > > > > > > > > > > > > > > SC 6 N 11618 > > > > > > > > Title: Liaison Report to the IETF Routing Area Director > > on 2nd CD for > > > > ISO/IEC 10589 (IS-IS Routing) > > > > > > > > Source: ISO/IEC JTC1/SC6 > > > > > > > > ISO/IEC JTC1/SC6 WG7 is currently creating a new base text for > > >ISO10589. > > > > SC6 intends to use this new version 2 as the base for adding the > > > > enhancements which have been requested by the IETF to > > optimise the use > > > > of ISO 10589 for Internet routing solutions. The IETF IS-IS WG > > >convenor > > > > originally identified Internet Drafts: > > > > > > > and as the source documents which > > > > specify these enhancements. SC6 invites the IETF to > > confirm that the > > > > above Internet Drafts are the correct references and to > > inform SC6 if > > > > there are additional IETF documents which refer to any other > > > > requirements for IS-IS Routing enhancements. > > > > > > > > SC6 would like to interact with the IETF on clarifying > > the detailed > > > > requirements in the hope that it may be possible to > > introduce them > > > > during the editing cycle for version 2 of the standard. > > To this end, > > > > we would like the Routing Area Directors to arrange an > > IS-IS BOF at > > >the > > > > San Diego IETF meeting to discuss these requirements and > > how they can > > >be > > > > incorporated into the new version of ISO 10586. > > > > > > > > SC6 will post an initial draft version of the new base > > document as an > > > > Internet Draft in August 2000 but this will not contain > > the changes > > > > requested by the IETF. A ballot closure date of February 2001 has > > >been > > > > set for the 2nd CD Ballot to allow incorporation of final > > input on the > > > > Internet requirements if they can be agreed at the > > December 2000 IETF > > > > meeting. > > > > > > > > For information, the current instructions to the editor > > are that he > > > > should use ISO/IEC 10589:1992 as a base for editing, and > > shall apply > > >the > > > > minimum textual changes mandated by the following TCs and DRs: > > > > > > > > ISO/IEC 10589:1992/Cor.1:1993 > > > > ISO/IEC 10589:1992/Cor.2:1996 > > > > ISO/IEC 10589:1992/Cor.3:1996 > > > > ISO/IEC 10589:1992/Amd 1:1996 > > > > 6N10323 - Defect Reports 7-26 > > > > 6N10659 - Defect Reports 27-34 > > > > 6N10733 - Technical Corrigendum 4 > > > > The editor will also apply the minimal changes > > necessary to resolve > > > > additional Defect Reports 35-44. > > > > > > > > If SC6 and the IETF are unable to resolve the required > > changes, the > > > > Editor will add a temporary note to the cover page and the scope > > >clause > > > > stating that: " ISO 10589 does not currently include the > > extensions > > > > originally requested by the IETF in Internet Drafts: > > > > and > > . > > > > National Body and Liaison organization comments are > > invited to comment > > > > on the best way to progress these extensions." > > > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From yakov@cisco.com Mon, 04 Sep 2000 10:20:01 -0700 Date: Mon, 04 Sep 2000 10:20:01 -0700 From: Yakov Rekhter yakov@cisco.com Subject: [Isis-wg] draft-kompella-isis-ompls-extensions-00.txt Tony and Tony, Kireeti and myself would like to ask the ISIS working group to accept draft-kompella-isis-ompls-extensions-00.txt as the ISIS WG document. Yakov. From tony1@home.net Sat, 09 Sep 2000 11:15:23 -0700 Date: Sat, 09 Sep 2000 11:15:23 -0700 From: Tony Li tony1@home.net Subject: [Isis-wg] Re: draft-kompella-isis-ompls-extensions-00.txt > Kireeti and myself would like to ask the ISIS working group > to accept draft-kompella-isis-ompls-extensions-00.txt as the > ISIS WG document. I've seen no comments or objections. Please consider this a WG document. Tony From vikram_isis@hotmail.com Mon, 11 Sep 2000 23:15:03 GMT Date: Mon, 11 Sep 2000 23:15:03 GMT From: vikram isis vikram_isis@hotmail.com Subject: [Isis-wg] Hello Intervals Hi, A question on hello interval timers. Cisco implements hellos times as follows: 1> hello interval : 10 2> hello multiplier: 3 does anybody have some suggestions as to where these values have been specified? Any help is appreciated. Vikram _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From Radia.Perlman@East.Sun.COM Mon, 11 Sep 2000 19:39:03 -0400 (EDT) Date: Mon, 11 Sep 2000 19:39:03 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] Hello Intervals >> From: "vikram isis" >> 1> hello interval : 10 >> 2> hello multiplier: 3 >> does anybody have some suggestions as to where these values have been >> specified? I think the Cisco numbers are reasonable. The hello timer must be settable, and perhaps the holding multiplier is as well. So the "hello interval" of 10 is a default, right? By the way, the holding multiplier was something I discovered, to my surprise (and not happiness) that 10589 specified to be a constant, and 10 times the hello timer, which is way too much. I think it was specified as 2+fudge factor, or perhaps 3, in the DECnet Phase 5 routing spec. At any rate, when I asked on the mailing list about how the multiplier got to be specified as 10 (and not settable...an architectural constant), the answer was that everyone was ignoring that, so it wasn't a problem! There's no magic to the numbers, and there was no careful analysis done, but 2 or 3 times for the multiplier seems about right, and 10 times seems definitely wrong. As for the hello timer, I'd think it would have to be a parameter, since if you want to notice a router down within a few seconds, you'll have to send more frequent hellos, and if it were always, say, 1 second, that might be too much overhead in most cases. Radia From danny@tcb.net Mon, 11 Sep 2000 18:02:48 -0600 Date: Mon, 11 Sep 2000 18:02:48 -0600 From: Danny McPherson danny@tcb.net Subject: [Isis-wg] Hello Intervals > There's no magic to the numbers, and there was no careful analysis > done, but 2 or 3 times for the multiplier > seems about right, and 10 times seems definitely > wrong. As for the hello timer, I'd think it would have to be > a parameter, since if you want to notice a router down within a few > seconds, you'll have to send more frequent hellos, and if it were > always, say, 1 second, that might be too much overhead in most cases. Several service provider networks I'm familiar with actually increase the multiplier to 4 or 5 and lower the interval to 1-2s. The b/w utilization is negligible (especially on OC-n connections), and even less when implementations stop padding hellos after adjacency establishment. The benefit (i.e. detecting faults nearly an order of magnitude faster) certainly is interesting, especially when comparing to typical default values. Then again, others increase the interval to cut down on chatting (especially w/large NBMA clouds -- where they need it most *8^/). Of course, it goes without saying -- mucking with values without understanding the full impact on the network is a bad idea. -danny From Radia.Perlman@East.Sun.COM Mon, 11 Sep 2000 21:17:01 -0400 (EDT) Date: Mon, 11 Sep 2000 21:17:01 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] Hello Intervals >> From: Danny McPherson >> Several service provider networks I'm familiar with actually increase the >> multiplier to 4 or 5 and lower the interval to 1-2s. What is the value in increasing the multiplier? I understand why you'd want to set the hello interval to be small in order to detect failure quickly. The only reason I could imagine for setting the multiplier higher is if the link is very flaky and it's likely you'll miss several hellos in a row. Are the networks you refer to using very fast and very flaky links? Or are the routers likely to lose a lot of packets without looking at them first, so that most hellos do get lost? Just curious... Radia From danny@tcb.net Mon, 11 Sep 2000 20:13:41 -0600 Date: Mon, 11 Sep 2000 20:13:41 -0600 From: Danny McPherson danny@tcb.net Subject: [Isis-wg] Hello Intervals > What is the value in increasing the multiplier? I understand why you'd > want to set the hello interval to be small in order to detect failure > quickly. The only reason I could imagine for setting the multiplier > higher is if the link is very flaky and it's likely you'll miss > several hellos in a row. Are the networks you refer to > using very fast and very flaky links? > Or are the routers likely to lose a lot of packets without looking at > them first, so that most hellos do get lost? There are a number of reasons, actually. A couple of the networks I refer to are indeed very fast and usually very reliable, though the reasoning equally applies to the lower-speed networks as well. Increasing the multiplier seems to provide a sense of security when decreasing the interval, primarily in order to avoid instability or oscillation as a result of bursts of errors (on usually very reliable links, perhaps when switching to protected SONET paths, though applicable to "non-protected" links as well), or dealing with bursty traffic resulting in temporal congestion (perhaps as the result of circuit failures or other anomalies in the network). And, of course, to deal with "platform" issues (e.g. lack or system bandwidth, processor cycles, plain old flakiness, etc..). Similarly, such models have been deployed w/BGP and other routing protocols, as well as link layer keepalives, etc.. -danny From selvarajr@future.futsoft.com Mon, 11 Sep 2000 20:44:56 +0530 Date: Mon, 11 Sep 2000 20:44:56 +0530 From: selvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubt Hi, My doubt is regarding , having more than one adjacency with same system Id but different SNPA. I hope this is possible when there is any backup link present I assume that, if any Hello PDU be received by an IS with system Id same as the received IS, then it can be discarded. ie Receiving own hello PDU. IS - 1 IS - 2 | | | c1 | c2 ----------------------------------------------------------- c3 | | c4 | | | | IS - 3 For the above broadcast topology let, IS-1, IS-2 & IS-3 be three L1 intermediate systems c1, c2, c3, c4 be the respective IS's circuits. where c4 be the back up link for IS-3. Let priority of c1 be 10, c2 be 20, c3 be 30 and c4 be 40. Here, IS -1 and IS -2 will have two adjacencies for IS -3 with same s ystem Id but, different SNPA. But, IS -3 won't have any adjacency of it's own. ie c4 is not known to c3 and vice versa DOUBTS: 1. After DR election c1 , c2 and c4 will say c4 as the DR. But c3 will say c3 as the DR. So the LAN will have more than on DR at a time 2. If the IS won't have two interfaces on the same LAN as in the above topology , then why do we need to check for system ID and SNPA. for creating new adjacency over a circuit. I feel checking for System ID alone sufficient. So we can discard duplicate IIH. Pls correct me , if I'm wrong. Selva. From selvarajr@future.futsoft.com Mon, 11 Sep 2000 20:44:56 +0530 Date: Mon, 11 Sep 2000 20:44:56 +0530 From: selvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubt ------ =_NextPart_000_01C01C9D.78498060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, My doubt is regarding , having more than one adjacency with same system Id but different SNPA. I hope this is possible when there is any backup link present I assume that, if any Hello PDU be received by an IS with system Id same as the received IS, then it can be discarded. ie Receiving own hello PDU. IS - 1 IS - 2 | | | c1 | c2 ----------------------------------------------------------- c3 | | c4 | | | | IS - 3 For the above broadcast topology let, IS-1, IS-2 & IS-3 be three L1 intermediate systems c1, c2, c3, c4 be the respective IS's circuits. where c4 be the back up link for IS-3. Let priority of c1 be 10, c2 be 20, c3 be 30 and c4 be 40. Here, IS -1 and IS -2 will have two adjacencies for IS -3 with same s ystem Id but, different SNPA. But, IS -3 won't have any adjacency of it's own. ie c4 is not known to c3 and vice versa DOUBTS: 1. After DR election c1 , c2 and c4 will say c4 as the DR. But c3 will say c3 as the DR. So the LAN will have more than on DR at a time 2. If the IS won't have two interfaces on the same LAN as in the above topology , then why do we need to check for system ID and SNPA. for creating new adjacency over a circuit. I feel checking for System ID alone sufficient. So we can discard duplicate IIH. Pls correct me , if I'm wrong. Selva. ------ =_NextPart_000_01C01C9D.78498060 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhUEAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAqAEAAAEAAAAQAAAAAwAAMAUAAAAL AA8OAAAAAAIB/w8BAAAAbQAAAAAAAAC1O8LALHcQGqG8CAArKlbCFQAAAO07sbk4atQRlnAAIDUf kqCEhQAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAASVNJU1dHAFNNVFAAaXNpcy13Z0BleHRlcm5h bC5qdW5pcGVyLm5ldAAAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAHQAAAGlzaXMtd2dA ZXh0ZXJuYWwuanVuaXBlci5uZXQAAAAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAACQAAACdJU0lT V0cnAAAAAAIBCzABAAAAIgAAAFNNVFA6SVNJUy1XR0BFWFRFUk5BTC5KVU5JUEVSLk5FVAAAAAMA ADkAAAAACwBAOgEAAAAeAPZfAQAAAAcAAABJU0lTV0cAAAIB918BAAAALAAAAL8AAAC1O8LALHcQ GqG8CAArKlbCFQAAAO07sbk4atQRlnAAIDUfkqCEhQAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAA BAAAAAAAAAUWVgEEgAEABgAAAERvdWJ0AP4BAQWAAwAOAAAA0AcJAAsAFAAsADgAAQBkAQEggAMA DgAAANAHCQALABMALQABAAEALQEBCYABACEAAAA3RkNENTk0N0NEODdENDExOTY3MDAwMjAzNTFG OTJBMAAABwEDkAYAaAsAACAAAAALAAIAAQAAAAsAIwAAAAAAAwAmAAAAAAALACkAAAAAAAMANgAA AAAAQAA5AIDwOQsDHMABHgBwAAEAAAAGAAAARG91YnQAAAACAXEAAQAAABYAAAABwBwDCuZHWc2+ h80R1JZwACA1H5KgAAAeAB4MAQAAAAUAAABTTVRQAAAAAB4AHwwBAAAAHQAAAHNlbHZhcmFqckBm dXR1cmUuZnV0c29mdC5jb20AAAAAAwAGEEHHhQYDAAcQ2AMAAB4ACBABAAAAZQAAAEhJLE1ZRE9V QlRJU1JFR0FSRElORyxIQVZJTkdNT1JFVEhBTk9ORUFESkFDRU5DWVdJVEhTQU1FU1lTVEVNSURC VVRESUZGRVJFTlRTTlBBSUhPUEVUSElTSVNQT1NTSUJMRVcAAAAAAgEJEAEAAABcCAAAWAgAABwT AABMWkZ1dX1fHgMACgByY3BnMTI1cjIMYGMxAzABBwtgbpEOEDAzMw8WZmUPkk8B9wKkA2MCAGNo CsBzhGV0AtFwcnEyAACSKgqhbm8SUCAwAdCFAdA2D6AwNTA0FCHzAdAUEDR9B20CgwBQA9T7Ef8T C2IT4RRQE7IY9BTQiwcTFeQ2EY4yMzgXVKIgB20gQ0UV5Dcaf6cUQBuvHLV5chXkORGOrxpQFjEe /wOCRwnRawKD3wwBIP8OUCIvA3NUCHAj1LsWMSENOBphJZ8DgkIHQP50DeAj1CVhFmwbeAcTHQb/ G3Aq/x63LJUgVQ4wFk4h6P8slCOJGmEwTiVmLJQm5x2RvzBNKJcslComApEI5jsJb+owOL9lDjA1 Oeo7ATq//zvJOdQ78jpfPi897T1vO5/zOe8QYDI4Q7pE0USPRZn/OdRFwkQvR/9HvUc/RW9JNH45 DlBMhE3hRgNN4AKCc6h0eWwHkGgJ4HQAAGED8GRjdGwKsQBgZMxqdU9QBRBnaAVCFjIdDAFjCcBQ IAMwc25lvngXMAewBbAAwAJzcwBQWHNiMhRQT0BhE/Bc+msJ4HALkFAYCGBQUAuA+mVPgHZVwAFA ULsMMFGEbxuQVGAEoAuAZ0XRUgZi+mEXEGQCIFLAUmZPsFCw+VfxIDFPEw5QU79Uz1XT/wBRVlwA oFGOWN9Z5k8ED8D/Wu9b/1XTDlBWT16vX79aE/YzAoITEGNTgGaBULBaEJMqUFXwIEQBEGF1KkAU IFAKwGEJwGFwaJwgRgIhU0QwEWktD5BeOAFAVZBrE1AYYgsgcs8JUGxyFqBscnc0QyEXAP5wAdBo UlDfZX9mhmqwaXBbBRACMC1qEANhOikQb6Fx0FN1YmoFkHRx0OBEYXRlOlNEGmFq//9sD20fbixP oFoDDiFmgVcWNw5Qb49wnlJV4RcBIEj/WfEEkFNEHZFzr3S/dc9VXy93Dw+BghAI0GIKsHQ4/2Ta D1RhsHkfeiaCoHswC1C8eS9qIHYQCxF7pXNTRP8bkXyvfb9+z24vbz+Ez4XZf3HycZRyySDQUB+L NIJTOYeLf4yPkcBEb2N1B4CfAjAF0GngN+GP8m93kDD7iTEBgG5yUABgCfBogJQgdwIBUwB3smUA 8JQgT2BwSTxgXHYIkHdrC4Bk/x7Al8IE8AdAEGEBQA4AiQL3WeKZJQIQbwVCFyES8nLgjm0LUXLg HQA6XFxxIHpvacFtahADEAeQm9BNkw3gA2BzbwGAIE8BIGsN4JcQXJ2GRQDAAxAufWZQdJTwFxCQ MFJBgBJ4ewFAliFuT7A40J8kaRRjzwMgEvMAgAWQbHZdQWJw/w5wUwChsgGQACCiQpgRlGH/AcGh sRbgD3AAAGJwDNABkPwgLjfyoagOUKJiKkBQkP+i36PvpP8PwGJwBYGmn6ev7ai/bB7AYnBspl+r H6wlPimlLDAQqf+u36wUYiD+KAKRr/+h8xpgra+yb7N//7SPoiAdkLXSoq+3P7hPpSz/G5C137tf vG+9f6IgINC6X/+/78D/wgQK+QMwkA+LP1IxEHtIaSwKhU15IK9mUHJABUAEACA40GcLEfVaIixZ 0GGXwFoxBGA40PQgdKvBIAIgE4DIQQDQ3QnwY8qwA/DM4CBh8AeATc5QeU9QmzAgSVJAYj9/8MrA BpAQUDjQlHFTTqhQQS4KhUlZ0G+XgPfM0csxyzFwE2AAkAJgE4D+d0+wA6DM4KBhyyIAcMqwQWYQ Y2t1cCCAEWt/0dA40BcQAjAKhdCHZiBz25RBzNJ0zADLIGbTQ3uw5mwJAGlwRFXPQBOAONDfncBo wc8xyrADkUkF8M4U/87HzmNmINKy19jY0MwA0sH7A6BooCCYsAOg17FaEJih+wsgCYAuyyATgHsw 2AJaIv+VQAOgT7DXNdB21MzgGNjR33FwDpDhL+H64MMy37/gEf584f/lv+RU42/kcw6B6L/35i/b 8ONWLeuP7J/tr+4ls+c/4BljM+SV6HE07z+/6d/m3/Tv84/0n+AtM9TMt4YB2mMBoG9o0YkAb8hA 35iwT1DM0NEgCPFnyrDT8H8XIMom4JOHkMwA/QEpACaf/PLxANexzOAJ0SBMDpC/cUEEkAeAWhCb cs6lc/bIrw6AzADq8ADxMwDxNP4UP9fCimBycWjC2NBDwHF1Z5pgzpHb8GlylDBooHPf3QDSccyx AZjTkiDT1paRt/3D0HbgEUwXINRBafoQ/2igyrCdQOiC17EPkADy16L/DAABMteiFBDTQVJAAZQU UP/ezXuwOND9Qp+AliFmIGoA/+ihChIMKSkAFnDXMMwSzMH+d9dQzWeX0NMwBhIMGvEA384fzyTM AM+fylNCEjIQHP9mYAMGmnAOY9bSzXgIEWigXwMI3fHdAwGRyzFummFr/xjA3gH7gPDiDQKXwJ3A GfAFe2Fh3txET1VCVNRTOt7VMd0AQZWwV8D5aPBSIIBBAoFmYOiCCMP/ChUOE2Hw+/ABkdpFHPDd AN8T0fDiHqcZgx94U9dQ2nL5/qBBTg4JzJoc4nLQzWDXzNAl8d7VMt0ASdaw2mP/2NIVDw6y/uNp IJ3AF8HSo/8RJCKC2kHHYfpI+4fbZdJw/8qyENAIgFKA2EEZYk+wBWH7BhLOtkQKA9AzBgPDcFnw 9zewWjFSgHcWSntRJIEDpf/dAOChBgA5QKFgLHNaIgYS/lMtKDhQzUHV4J2Sl9DGQP8h4yvB3ALc dcrA09CAEJiwkZuBSUlI3s1QbNMw/9vw+hDX4Zpw2hHMANahzxD7AwacUHedEHgA3s85k8YBp8Fg ciCAgHZhpRB7OlaPxtPHj8iVO5d9AAA+sAMAEBAAAAAAAwAREAEAAAADAIAQ/////0AABzAgT4Ss +hvAAUAACDAgT4Ss+hvAAQsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAA AAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAWACCAGAAAAAADAAAAAAAAARgAAAABShQAA8xUAAAMA B4AIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAHgAIgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUA AAEAAAAFAAAAOC4wNAAAAAALAAmACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMACoAIIAYA AAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwALgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAe AAyACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgANgAggBgAAAAAAwAAAAAAA AEYAAAAAN4UAAAEAAAABAAAAAAAAAB4ADoAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAA AAAAAAAeAD0AAQAAAAEAAAAAAAAAAwANNP03AAARAw== ------ =_NextPart_000_01C01C9D.78498060-- From raszuk@cisco.com Mon, 11 Sep 2000 20:55:16 -0700 Date: Mon, 11 Sep 2000 20:55:16 -0700 From: Robert Raszuk raszuk@cisco.com Subject: [Isis-wg] Hello Intervals Radia, One of the reasons I know of for incresing the multiplier would be to avoid unnecessary adj. flaps when you have bursts of traffic - hence temporary congestions - and your hardware is not capable of separating discarded protocol packets from data packets on an ingress line card. (I know a few boxes which have such a characteristic :). R. > >> From: Danny McPherson > > >> Several service provider networks I'm familiar with actually increase > the > >> multiplier to 4 or 5 and lower the interval to 1-2s. > > What is the value in increasing the multiplier? I understand why you'd > want to set the hello interval to be small in order to detect failure > quickly. The only reason I could imagine for setting the multiplier > higher is if the link is very flaky and it's likely you'll miss > several hellos in a row. Are the networks you refer to > using very fast and very flaky links? > Or are the routers likely to lose a lot of packets without looking at > them first, so that most hellos do get lost? > > Just curious... > > Radia > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From tli@Procket.com Mon, 11 Sep 2000 22:53:52 -0700 (PDT) Date: Mon, 11 Sep 2000 22:53:52 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] Hello Intervals | One of the reasons I know of for incresing the multiplier would be to | avoid unnecessary adj. flaps when you have bursts of traffic - hence | temporary congestions - and your hardware is not capable of separating | discarded protocol packets from data packets on an ingress line card. (I | know a few boxes which have such a characteristic :). And before this provokes a discussion, I think most folks would agree that that's not a particularly robust implementation. Tony From naiming@redback.com Tue, 12 Sep 2000 00:34:14 -0700 Date: Tue, 12 Sep 2000 00:34:14 -0700 From: Naiming Shen naiming@redback.com Subject: [Isis-wg] Doubt ] ] IS - 1 IS - 2 ] | | ] | c1 | c2 ]----------------------------------------------------------- ] c3 | | c4 ] | | ] | | ] IS - 3 ] ]For the above broadcast topology let, ] IS-1, IS-2 & IS-3 be three L1 intermediate systems ] c1, c2, c3, c4 be the respective IS's circuits. where c4 be the back up ]link for IS-3. ] Let priority of c1 be 10, c2 be 20, c3 be 30 and c4 be 40. ] ]Here, IS -1 and IS -2 will have two adjacencies for IS -3 with same s ]ystem Id but, different SNPA. ]But, IS -3 won't have any adjacency of it's own. ie c4 is not known to c3 ]and vice versa ] ]DOUBTS: ]1. After DR election c1 , c2 and c4 will say c4 as the DR. But c3 will say ] c3 as the DR. So the LAN will have more than on DR at a time this actually will be worse, the IS-1 and IS-2 may randomly setup adjacnecies with IS-3 on either c3 or c4 depends on the timing. since they will rejects the second adjacency setup due to conflict in systemID and mac addresses. ]2. If the IS won't have two interfaces on the same LAN as in the above ]topology , then why do we need to check for system ID and SNPA. for ]creating new adjacency over a circuit. I feel checking for System ID ]alone sufficient. So we can discard duplicate IIH. i guess the idea was to prevent accident. if you want to bring a new router into the LAN and misconfigure the systemID which duplicates the one already in operation, the proper behaviour should be the new router can not join the ISIS on this LAN instead of knocking off the one already working. since the chances are the new router probably is configured wrong. so this check on both systemID and mac address is useful. ] ]Pls correct me , if I'm wrong. ] - Naiming From larmer@commsense.net Tue, 12 Sep 2000 10:29:11 -0400 Date: Tue, 12 Sep 2000 10:29:11 -0400 From: larmer@commsense.net larmer@commsense.net Subject: [Isis-wg] Doubt Hi Selva, >I assume that, if any Hello PDU be received by an IS with system >Id same as the received IS, then it can be discarded. ie Receiving >own hello PDU. I could not find reference to this in ISO 10589, where is this spelled out? If they were not discarded, wouldn't the DR election process work correctly? > DOUBTS: > 1. After DR election c1 , c2 and c4 will say c4 as the DR. But c3 >will say c3 as the DR. So the LAN will have more than one DR at a >time ISO 10589 states the following pertinent information in section 8.4.4 LAN Designated Intermediate Systems: d)After waiting ISISHelloTimer * 2 seconds, run the Level 1 and or the Level 2 Designated Intermediate System election process depending on the Intermediate system type. This shall be run subsequently whenever an IIH PDU is received or transmitted...(For these purposes, the transmission of the system's own IIH PDU is equivalent to receiving it)... If IS-3 discards one of the IIH PDUs, I don't believe the DR election process during circuit initialization will work properly. However, subsequent DR elections should work properly because IS-3 will know about both IIH PDUs being generated. Am I off in the weeds? Cheers, Ken Larmer CommSense Networks From larmer@commsense.net Tue, 12 Sep 2000 16:44:27 -0400 Date: Tue, 12 Sep 2000 16:44:27 -0400 From: larmer@commsense.net larmer@commsense.net Subject: [Isis-wg] SRMflag & SSNflag settings --larmer.commsense.net|E07E020FC8E32FC4A15FEACA3E3B906C-15074 Content-Type: text/plain; charset="iso-8859-1" Hi, I hope this is the correct forum for asking these questions. I am developing an IS-IS technology course and I have some questions, which I can't seem to get the answers to. I have included a text version of my questions and also a word attachment. I apologize for the lengthy questionnaire, though I appreciate any assistance in this area! I am trying to determine the correct settings for the SRMflag and SSNflag when a CSNP or PSNP are received over a Point-to-Point or Broadcast link. ISO-10589, Section 7.3.15.2, sub-section b) details what actions to take with respect to the SRMflag and the SSNflag when a SNP (either CSNP or PSNP) are received over a circuit (either broadcast or non-broadcast). It states the following: My interpretations and questions are proceeded by #. 7.3.15.2 Action on Receipt of a Sequence Numbers PDU When a Sequence Numbers PDU (Complete or Partial...) is received on circuit C the IS shall perform the following functions: a) Perform the following PDU acceptance tests: ... ... ... ... b) For each LSP reported in the Sequence Number PDU: 1)If the reported value equals the database value and C is a non-broadcast Circuit, Clear SRMflag for C for that LSP. #Non-broadcast: #PSNP received - Acknowledged receipt of LSP. #What do we do with the SSNflag? #CSNP received - Don't update a LSP on a circuit where an adjacent IS already possesses it. #Again, what do we do with the SSNflag? #Broadcast: #PSNP received - The DR sets the SRMflag for this LSP to update the LAN IS requesting this LSP. #Is this interpretation correct? #CSNP received - Do nothing, the LSP databases are synchronized with respect to this LSP. #Is this interpretation correct? 2)If the reported value is older than the database value, Clear SSNflag, and Set SRMflag. #Non-broadcast: #PSNP received - Acknowledgement of a received LSP, however, since the LSP was propagated minimumLSPTransmissionInterval expiration (lastSent) onto this circuit, the receiving IS has received a newer version of this LSP. Consequently, it will update the adjacent IS. #Is this why the SSNflag is cleared? #CSNP received - Update the adjacent IS. Why are we clearing the SSNflag? If this is circuit initialization, because we just received a CSNP, should any SSNflags for this circuit be set? Or, could the circuit have restarted and the SSNflags may represent a left over state? #Broadcast: #PSNP received - Does this mean that the requesting IS is out of date (perhaps dropped the latest CSNP due to congestion and is just getting around to requesting an update) and DR may have had its LSP updated since it sent the last CSNP? #If not, why are we requesting an older LSP? #CSNP received - Update the DR. 3)If the reported value is newer than the database value, Set SSNflag, and if C is a non-broadcast circuit Clear SRMflag. #Non-broadcast: #PSNP received - We are acknowledging a newer LSP than the adjacent IS possesses. #Why is the adjacent IS acknowledging a LSP we have not sent them? Or could this be a previous incarnation? #CSNP received - Do not update the adjacent IS with an older LSP. #Though, why set the SSNflag? #Broadcast: #PSNP received - We are requesting a newer LSP than the DR possesses. Why is this IS requesting a newer LSP and what should the DR do in this situation? #CSNP received - Request an updated LSP from the DR. 4)If no database entry exists for the LSP, and the reported Remaining Lifetime, Checksum and Sequence Number fields of the LSP are all non-zero, create an entry with sequence number 0 and set SSNflag for that entry and circuit C. Under no circumstances shall SRMflag be set for such an LSP with zero sequence number. #Non-Broadcast: #PSNP received - This makes no sense for a PSNP. #??? #CSNP received - Create an entry, but do not propagate. #Why set the SSNflag for a LSP we have not yet received? #Broadcast: #PSNP received - This makes no sense for a PSNP. #??? #CSNP received - Create an entry, but do not propagate and request this LSP from the DR. Regards, Ken Larmer CommSense Networks --larmer.commsense.net|E07E020FC8E32FC4A15FEACA3E3B906C-15074 Content-Type: application/msword Content-Disposition: attachment; filename="SRMflag & SSNflag.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAKwAAAAAAAAAA EAAALQAAAAEAAAD+////AAAAACoAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEANyAJBAAA8BK/AAAAAAAAEAAAAAAABAAAmhMAAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIh4AADd8AAA3fAAAmg8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAKgAAAAAAAAAqAAAAKgA AAAAAAAAqAAAAAAAAACoAAAAAAAAAKgAAAAAAAAAqAAAABQAAAAAAAAAAAAAALwAAAAAAAAAMgcA AAAAAAAyBwAAAAAAADIHAAAAAAAAMgcAAAwAAAA+BwAAHAAAALwAAAAAAAAA+Q8AALYAAABmBwAA AAAAAGYHAAAAAAAAZgcAAAAAAABmBwAAAAAAAGYHAAAAAAAAZgcAAAAAAABmBwAAAAAAAGYHAAAA AAAAeA8AAAIAAAB6DwAAAAAAAHoPAAAAAAAAeg8AAAAAAAB6DwAAAAAAAHoPAAAAAAAAeg8AACQA AACvEAAAIAIAAM8SAAD4AAAAng8AABUAAAAAAAAAAAAAAAAAAAAAAAAAqAAAAAAAAABmBwAAAAAA AAAAAAAAAAAAAAAAAAAAAABmBwAAAAAAAGYHAAAAAAAAZgcAAAAAAABmBwAAAAAAAJ4PAAAAAAAA hgcAAAAAAACoAAAAAAAAAKgAAAAAAAAAZgcAAAAAAAAAAAAAAAAAAGYHAAAAAAAAsw8AABYAAACG BwAAAAAAAIYHAAAAAAAAhgcAAAAAAABmBwAAFgAAAKgAAAAAAAAAZgcAAAAAAACoAAAAAAAAAGYH AAAAAAAAeA8AAAAAAAAAAAAAAAAAAIYHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAZgcAAAAAAAB4DwAAAAAAAIYHAAB+BQAAhgcAAAAAAAAEDQAA HgAAACwPAAAYAAAAqAAAAAAAAACoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeA8AAAAAAABmBwAAAAAAAFoHAAAMAAAAEKYAjPIc wAG8AAAAdgYAADIHAAAAAAAAfAcAAAoAAABEDwAACAAAAAAAAAAAAAAAeA8AAAAAAADJDwAAMAAA APkPAAAAAAAATA8AACwAAADHEwAAAAAAAIYHAAAAAAAAxxMAAAAAAAB4DwAAAAAAAIYHAAAAAAAA vAAAAAAAAAC8AAAAAAAAAKgAAAAAAAAAqAAAAAAAAACoAAAAAAAAAKgAAAAAAAAAAgDZAAAASGks DQ0gICAgSSBob3BlIHRoaXMgaXMgdGhlIGNvcnJlY3QgZm9ydW0gZm9yIGFza2luZyB0aGVzZSBx dWVzdGlvbnMuIEkgYW0gZGV2ZWxvcGluZyBhbiBJUy1JUyB0ZWNobm9sb2d5IGNvdXJzZSBhbmQg SSBoYXZlIHNvbWUgcXVlc3Rpb25zLCB3aGljaCBJIGNhbpJ0IHNlZW0gdG8gZ2V0IHRoZSBhbnN3 ZXJzIHRvLiBJIGhhdmUgaW5jbHVkZWQgYSB0ZXh0IHZlcnNpb24gb2YgbXkgcXVlc3Rpb25zIGFu ZCBhbHNvIGEgd29yZCBhdHRhY2htZW50LiBJIGFwb2xvZ2l6ZSBmb3IgdGhlIGxlbmd0aHkgcXVl c3Rpb25uYWlyZSwgdGhvdWdoIEkgYXBwcmVjaWF0ZSBhbnkgYXNzaXN0YW5jZSBpbiB0aGlzIGFy ZWEhIA0NICAgIEkgYW0gdHJ5aW5nIHRvIGRldGVybWluZSB0aGUgY29ycmVjdCBzZXR0aW5ncyBm b3IgdGhlIFNSTWZsYWcgYW5kIFNTTmZsYWcgd2hlbiBhIENTTlAgb3IgUFNOUCBhcmUgcmVjZWl2 ZWQgb3ZlciBhIFBvaW50LXRvLVBvaW50IG9yIEJyb2FkY2FzdCBsaW5rLiBJU08tMTA1ODksIFNl Y3Rpb24gNy4zLjE1LjIsIHN1Yi1zZWN0aW9uIGIpIGRldGFpbHMgd2hhdCBhY3Rpb25zIHRvIHRh a2Ugd2l0aCByZXNwZWN0IHRvIHRoZSBTUk1mbGFnIGFuZCB0aGUgU1NOZmxhZyB3aGVuIGEgU05Q IChlaXRoZXIgQ1NOUCBvciBQU05QKSBhcmUgcmVjZWl2ZWQgb3ZlciBhIGNpcmN1aXQgKGVpdGhl ciBicm9hZGNhc3Qgb3IgUG9pbnQtdG8tUG9pbnQpLiBJdCBzdGF0ZXMgdGhlIGZvbGxvd2luZzog TXkgaW50ZXJwcmV0YXRpb25zIGFuZCBxdWVzdGlvbnMgYXJlIHByb2NlZWRlZCBieSAjLg0NNy4z LjE1LjIgQWN0aW9uIG9uIFJlY2VpcHQgb2YgYSBTZXF1ZW5jZSBOdW1iZXJzIFBEVQ1XaGVuIGEg U2VxdWVuY2UgTnVtYmVycyBQRFUgKENvbXBsZXRlIG9yIFBhcnRpYWyFKSBpcyByZWNlaXZlZCBv biBjaXJjdWl0IEMgdGhlIElTIHNoYWxsIHBlcmZvcm0gdGhlIGZvbGxvd2luZyBmdW5jdGlvbnM6 DWEpIIUNhQ2FDYUNhQ1iKSBGb3IgZWFjaCBMU1AgcmVwb3J0ZWQgaW4gdGhlIFNlcXVlbmNlIE51 bWJlciBQRFU6DQ1JZiB0aGUgcmVwb3J0ZWQgdmFsdWUgZXF1YWxzIHRoZSBkYXRhYmFzZSB2YWx1 ZSBhbmQgQyBpcyBhIG5vbi1icm9hZGNhc3QgQ2lyY3VpdCwgQ2xlYXIgU1JNZmxhZyBmb3IgQyBm b3IgdGhhdCBMU1AuDQ0jTm9uLWJyb2FkY2FzdDoNI1BTTlAgcmVjZWl2ZWQgliBBY2tub3dsZWRn ZWQgcmVjZWlwdCBvZiBMU1AuIA0jV2hhdCBkbyB3ZSBkbyB3aXRoIHRoZSBTU05mbGFnPw0NI0NT TlAgcmVjZWl2ZWQgLSBEb26SdCB1cGRhdGUgYSBMU1Agb24gYSBjaXJjdWl0IHdoZXJlIGFuIGFk amFjZW5jeSBJUy4gI2FscmVhZHkgcG9zc2Vzc2VzIGl0Lg0jQWdhaW4sIHdoYXQgZG8gd2UgZG8g d2l0aCB0aGUgU1NOZmxhZz8NDSNCcm9hZGNhc3Q6DSNQU05QIHJlY2VpdmVkIJYgVGhlIERSIHNl dHMgdGhlIFNSTWZsYWcgZm9yIHRoaXMgTFNQIHRvIHVwZGF0ZSB0aGUgTEFOIElTICNyZXF1ZXN0 aW5nIHRoaXMgTFNQLg0jV2h5IGlzbpJ0IHRoaXMgc3RhdGVkPw0NI0NTTlAgcmVjZWl2ZWQgliBE byBub3RoaW5nLCB0aGUgTFNQIGRhdGFiYXNlcyBhcmUgc3luY2hyb25pemVkIHdpdGggcmVzcGVj dCAjdG8gdGhpcyBMU1AuDSNBZ2Fpbiwgd2h5IGlzbpJ0IHRoaXMgc3RhdGVkDQ1JZiB0aGUgcmVw b3J0ZWQgdmFsdWUgaXMgb2xkZXIgdGhhbiB0aGUgZGF0YWJhc2UgdmFsdWUsIENsZWFyIFNTTmZs YWcsIGFuZCBTZXQgU1JNZmxhZy4NDSNOb24tYnJvYWRjYXN0Og0jUFNOUCByZWNlaXZlZCCWIEFj a25vd2xlZGdlbWVudCBvZiBhIHJlY2VpdmVkIExTUCwgaG93ZXZlciwgc2luY2UgdGhlIExTUCAj d2FzIHByb3BhZ2F0ZWQgbWluaW11bUxTUFRyYW5zbWlzc2lvbkludGVydmFsIGV4cGlyYXRpb24g KGxhc3RTZW50KSBvbnRvICN0aGlzIGNpcmN1aXQsIHRoZSByZWNlaXZpbmcgSVMgaGFzIHJlY2Vp dmVkIGEgbmV3ZXIgdmVyc2lvbiBvZiB0aGlzIExTUC4gI0NvbnNlcXVlbnRseSBpdCB3aWxsIHVw ZGF0ZSB0aGUgYWRqYWNlbnQgSVMuIA0jSXMgdGhpcyB3aHkgdGhlIFNTTmZsYWcgaXMgY2xlYXJl ZD8gDQ0jQ1NOUCByZWNlaXZlZCAtIFVwZGF0ZSB0aGUgYWRqYWNlbnQgSVMuDSNXaHkgYXJlIHdl IGNsZWFyaW5nIHRoZSBTU05mbGFnPyBJZiB0aGlzIGlzIGNpcmN1aXQgaW5pdGlhbGl6YXRpb24s IGJlY2F1c2Ugd2UganVzdCAjcmVjZWl2ZWQgYSBDU05QLCBzaG91bGQgYW55IFNTTmZsYWdzIGZv ciB0aGlzIGNpcmN1aXQgYmUgc2V0PyBPciwgY291bGQgdGhlICNjaXJjdWl0IGhhdmUgcmVzdGFy dGVkIGFuZCB0aGUgU1NOZmxhZ3MgbWF5IHJlcHJlc2VudCBhIGxlZnQgb3ZlciBzdGF0ZT8NDSNC cm9hZGNhc3Q6DSNQU05QIHJlY2VpdmVkIJYgRG9lcyB0aGlzIG1lYW4gdGhhdCB0aGUgcmVxdWVz dGluZyBJUyBpcyBvdXQgb2YgZGF0ZSAocGVyaGFwcyBkcm9wcGVkIHRoZSBsYXRlc3QgQ1NOUCBk dWUgdG8gY29uZ2VzdGlvbiBhbmQgaXMganVzdCBnZXR0aW5nIGFyb3VuZCB0byByZXF1ZXN0aW5n IGFuIHVwZGF0ZSkgYW5kIERSIG1heSBoYXZlIGhhZCBpdHMgTFNQIHVwZGF0ZWQgc2luY2UgaXQg c2VudCB0aGUgbGFzdCBDU05QPw0jSWYgbm90LCB3aHkgYXJlIHdlIHJlcXVlc3RpbmcgYW4gb2xk ZXIgTFNQPyANDSNDU05QIHJlY2VpdmVkIJYgVXBkYXRlIHRoZSBEUi4NDUlmIHRoZSByZXBvcnRl ZCB2YWx1ZSBpcyBuZXdlciB0aGFuIHRoZSBkYXRhYmFzZSB2YWx1ZSwgU2V0IFNTTmZsYWcsIGFu ZCBpZiBDIGlzIGEgbm9uLWJyb2FkY2FzdCBjaXJjdWl0IENsZWFyIFNSTWZsYWcuDQ0jTm9uLWJy b2FkY2FzdDoNI1BTTlAgcmVjZWl2ZWQgliBXZSBhcmUgYWNrbm93bGVkZ2luZyBhIG5ld2VyIExT UCB0aGFuIHRoZSBhZGphY2VudCBJUyAjcG9zc2Vzc2VzLg0jV2h5IGlzIHRoZSBhZGphY2VudCBJ UyBhY2tub3dsZWRnaW5nIGEgTFNQIHdlIGhhdmUgbm90IHNlbnQgdGhlbT8gT3IgY291bGQgI3Ro aXMgYmUgYSBwcmV2aW91cyBpbmNhcm5hdGlvbiBvZiBzb21lIHNvcnQ/DQ0jQ1NOUCByZWNlaXZl ZCCWIERvIG5vdCB1cGRhdGUgdGhlIGFkamFjZW50IElTIHdpdGggYW4gb2xkZXIgTFNQLiANI1Ro b3VnaCwgd2h5IHNldCB0aGUgU1NOZmxhZz8gDQ0jQnJvYWRjYXN0Og0jUFNOUCByZWNlaXZlZCCW IFdlIGFyZSByZXF1ZXN0aW5nIGEgbmV3ZXIgTFNQIHRoYW4gdGhlIERSIHBvc3Nlc3Nlcy4NI1do eSBpcyB0aGlzIElTIHJlcXVlc3RpbmcgYSBuZXdlciBMU1AgYW5kIHdoYXQgc2hvdWxkIHRoZSBE UiBkbyBpbiB0aGlzICNzaXR1YXRpb24/IA0NI0NTTlAgcmVjZWl2ZWQgliBSZXF1ZXN0IGFuIHVw ZGF0ZWQgTFNQIGZyb20gdGhlIERSLiAgDQ1JZiBubyBkYXRhYmFzZSBlbnRyeSBleGlzdHMgZm9y IHRoZSBMU1AsIGFuZCB0aGUgcmVwb3J0ZWQgUmVtYWluaW5nIExpZmV0aW1lLCBDaGVja3N1bSBh bmQgU2VxdWVuY2UgTnVtYmVyIGZpZWxkcyBvZiB0aGUgTFNQIGFyZSBhbGwgbm9uLXplcm8sIGNy ZWF0ZSBhbiBlbnRyeSB3aXRoIHNlcXVlbmNlIG51bWJlciAwIGFuZCBzZXQgU1NOZmxhZyBmb3Ig dGhhdCBlbnRyeSBhbmQgY2lyY3VpdCBDLiBVbmRlciBubyBjaXJjdW1zdGFuY2VzIHNoYWxsIFNS TWZsYWcgYmUgc2V0IGZvciBzdWNoIGFuIExTUCB3aXRoIHplcm8gc2VxdWVuY2UgbnVtYmVyLg0N I05vbi1Ccm9hZGNhc3Q6DSNQU05QIHJlY2VpdmVkIJYgVGhpcyBtYWtlcyBubyBzZW5zZSBmb3Ig YSBQU05QLiANIz8/Pw0NI0NTTlAgcmVjZWl2ZWQgliBDcmVhdGUgYW4gZW50cnksIGJ1dCBkbyBu b3QgcHJvcGFnYXRlLg0jV2h5IHNldCB0aGUgU1NOZmxhZyBmb3IgYSBMU1Agd2UgaGF2ZSBub3Qg eWV0IHJlY2VpdmVkPw0NI0Jyb2FkY2FzdDoNI1BTTlAgcmVjZWl2ZWQgliBUaGlzIG1ha2VzIG5v IHNlbnNlIGZvciBhIFBTTlAuDSM/Pz8NDSNDU05QIHJlY2VpdmVkIJYgQ3JlYXRlIGFuIGVudHJ5 LCBidXQgZG8gbm90IHByb3BhZ2F0ZSBhbmQgcmVxdWVzdCB0aGlzIExTUCAjZnJvbSB0aGUgRFIu DQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAACaEwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAQAAAQEAAAFBAAA XgUAAF8FAAAdBwAAHgcAAFMHAADNBwAA0gcAANQHAADWBwAA2AcAANoHAAAPCAAAEAgAAIQIAACF CAAAlQgAAMQIAADlCAAA5ggAAEUJAABtCQAAbgkAAHoJAADbCQAA8wkAAPQJAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAA AAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAA AAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADy AAAAAAAAAAAAAAAAAAAAAAAFAAAPhNACXoTQAgUAAAomAAtGAQAAAQAAABwABAAAmhMAAP0AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEAAEBAfQJAABPCgAAbQoAAG4K AADGCgAAxwoAANcKAADlCwAACwwAAAwMAAA1DAAAIQ0AACINAAAuDQAAHA4AAEoOAABLDgAAaw4A AGwOAADkDgAA5Q4AAPUOAABIDwAAwg8AAMMPAAAGEAAAJRAAACYQAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPcAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADyAAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAA AAAABQAAD4RoAV6EaAEFAAAKJgALRgEAAAEAAAAFAAAPhNACXoTQAgAbJhAAADIQAAB4EAAAzhAA AM8QAAAGEQAABxEAAEISAABDEgAAUxIAAIUSAACKEgAAixIAAMMSAAD8EgAA/RIAAAkTAAA6EwAA PxMAAEATAACaEwAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAFAAAKJgALRgEAAAUAAA+EaAFehGgBAAUAAA+E0AJehNACABQgADGQaAEfsNAvILDgPSGw CAcisAgHI5CgBSSQoAUlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQADwAKAAEAaQAPAAMAAAAA AAAAAAA4AABA8f8CADgADAAGAE4AbwByAG0AYQBsAAAAAgAAABgAQ0oYAF9IAQRhShgAbUgJBHNI CQR0SAkEAAAAAAAAAAAAAAAAAAAAAAAAPABBQPL/oQA8AAwAFgBEAGUAZgBhAHUAbAB0ACAAUABh AHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAAAAAAACaDwAACwAAHgAADAD///// AAAAAAQAAAAFAAAAXgEAAF8BAAAdAwAAHgMAAFMDAADNAwAA0gMAANQDAADWAwAA2AMAANoDAAAP BAAAEAQAAIQEAACFBAAAlQQAAMQEAADlBAAA5gQAAEUFAABtBQAAbgUAAHoFAADbBQAA8wUAAPQF AABPBgAAbQYAAG4GAADGBgAAxwYAANcGAADlBwAACwgAAAwIAAA1CAAAIQkAACIJAAAuCQAAHAoA AEoKAABLCgAAawoAAGwKAADkCgAA5QoAAPUKAABICwAAwgsAAMMLAAAGDAAAJQwAACYMAAAyDAAA eAwAAM4MAADPDAAABg0AAAcNAABCDgAAQw4AAFMOAACFDgAAig4AAIsOAADDDgAA/A4AAP0OAAAJ DwAAOg8AAD8PAABADwAAnA8AAJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAASAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAASAAMAEAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAASAAMAIA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAASAAMAMAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACAAAAA gAAEAACaEwAACgAAAAAEAAD0CQAAJhAAAJoTAAALAAAADQAAAA4AAAAABAAAmhMAAAwAAAAAAAAA ZQkAAGcJAACcDwAABwAbAAcAAAAAAJwPAAAHAP//FAAAAAoASwBlAG4AIABMAGEAcgBtAGUAcgAl AEQAOgBcAEkAcwAtAGkAcwAgAGMAbwB1AHIAcwBlAFwAUwBSAE0AZgBsAGEAZwAgACYAIABTAFMA TgBmAGwAYQBnAC4AZABvAGMACgBLAGUAbgAgAEwAYQByAG0AZQByAGsAQwA6AFwARABvAGMAdQBt AGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAEwAYQByAG0AZQByAFwAQQBwAHAA bABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABc AEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAFMAUgBNAGYAbABhAGcA IAAmACAAUwBTAE4AZgBsAGEAZwAuAGEAcwBkAAoASwBlAG4AIABMAGEAcgBtAGUAcgAlAEQAOgBc AEkAcwAtAGkAcwAgAGMAbwB1AHIAcwBlAFwAUwBSAE0AZgBsAGEAZwAgACYAIABTAFMATgBmAGwA YQBnAC4AZABvAGMACgBLAGUAbgAgAEwAYQByAG0AZQByACUARAA6AFwASQBzAC0AaQBzACAAYwBv AHUAcgBzAGUAXABTAFIATQBmAGwAYQBnACAAJgAgAFMAUwBOAGYAbABhAGcALgBkAG8AYwAKAEsA ZQBuACAATABhAHIAbQBlAHIAJQBEADoAXABJAHMALQBpAHMAIABjAG8AdQByAHMAZQBcAFMAUgBN AGYAbABhAGcAIAAmACAAUwBTAE4AZgBsAGEAZwAuAGQAbwBjAAoASwBlAG4AIABMAGEAcgBtAGUA cgAlAEQAOgBcAEkAcwAtAGkAcwAgAGMAbwB1AHIAcwBlAFwAUwBSAE0AZgBsAGEAZwAgACYAIABT AFMATgBmAGwAYQBnAC4AZABvAGMACgBLAGUAbgAgAEwAYQByAG0AZQByAGsAQwA6AFwARABvAGMA dQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAEwAYQByAG0AZQByAFwAQQBw AHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIA ZABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAFMAUgBNAGYAbABh AGcAIAAmACAAUwBTAE4AZgBsAGEAZwAuAGEAcwBkAAoASwBlAG4AIABMAGEAcgBtAGUAcgAlAEQA OgBcAEkAcwAtAGkAcwAgAGMAbwB1AHIAcwBlAFwAUwBSAE0AZgBsAGEAZwAgACYAIABTAFMATgBm AGwAYQBnAC4AZABvAGMACgBLAGUAbgAgAEwAYQByAG0AZQByACUARAA6AFwASQBzAC0AaQBzACAA YwBvAHUAcgBzAGUAXABTAFIATQBmAGwAYQBnACAAJgAgAFMAUwBOAGYAbABhAGcALgBkAG8AYwAK AEsAZQBuACAATABhAHIAbQBlAHIAawBDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAA UwBlAHQAdABpAG4AZwBzAFwATABhAHIAbQBlAHIAXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABE AGEAdABhAFwATQBpAGMAcgBvAHMAbwBmAHQAXABXAG8AcgBkAFwAQQB1AHQAbwBSAGUAYwBvAHYA ZQByAHkAIABzAGEAdgBlACAAbwBmACAAUwBSAE0AZgBsAGEAZwAgACYAIABTAFMATgBmAGwAYQBn AC4AYQBzAGQAAQC2YxwzOChgO/8P/w//D/8P/w//D/8P/w//DxAAAQAAAAAAAQAAAAAAAAAAAGgB AAAAAAAAABgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/gIAAAApAAEAAAAEgAEAAAAAAAAAAAAA AAAAAAAAAAAYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP4CAAEALgABAAAAAoIBAAAAAAAAAAAA AAAAAAAAAAAAGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/AgACAC4AAQAAAACAAQAAAAAAAAAA AAAAAAAAAAAAABgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/gIAAwAuAAEAAAAEgAEAAAAAAAAA AAAAAAAAAAAAAAAYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP4CAAQALgABAAAAAoIBAAAAAAAA AAAAAAAAAAAAAAAAGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/AgAFAC4AAQAAAACAAQAAAAAA AAAAAAAAAAAAAAAAABgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/gIABgAuAAEAAAAEgAEAAAAA AAAAAAAAAAAAAAAAAAAYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP4CAAcALgABAAAAAoIBAAAA AAAAAAAAAAAAAAAAAAAAGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/AgAIAC4AAQAAALZjHDMA AAAAAAAAAAAAAAD///////8BAAAAAAD//wEAAAASABEACQQZAAkEGwAJBA8ACQQZAAkEGwAJBA8A CQQZAAkEGwAJBP9AA4ABAIwPAACMDwAArIxzAAEAMACMDwAAAAAAAIwPAAAAAAAAAhAAAAAAAAAA mg8AALAAAAgAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAAAAAAAAAAAAD//wEAAAAA AP//AAACAP//AAAAAP//AAACAP//AAAAAAMAAABHFpABAAACAgYDBQQFAgMEh3oAIAAAAIAIAAAA AAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcG AgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIE h3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAIgAEAHEIiRgA8NACAABoAQAAAABV Y0lG8WNJRgAAAAAIAJQAAABBAgAA3QwAAAEABgAAAAQAAxAbAAAAAAAAAAAAAAABAAEAAAABAAAA AAAAACEDAPAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgHoAW0ALQAgYFyMAAAAAAAAAAA AAAAAAAAzA8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEIOAAAA AAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAACDKDUQDwEAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP//EgAAAAAAUABDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBl AHQAdABpAG4AZwBzAFwATABhAHIAbQBlAHIAXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABEAGEA dABhAFwATQBpAGMAcgBvAHMAbwBmAHQAXABUAGUAbQBwAGwAYQB0AGUAcwBcAE4AbwByAG0AYQBs AC4AZABvAHQAAwBIAGkALAAAAAAAAAAKAEsAZQBuACAATABhAHIAbQBlAHIACgBLAGUAbgAgAEwA YQByAG0AZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAAAQAA AOCFn/L5T2gQq5EIACsns9kwAAAAcAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAAKQAAAAEAAAA sAAAAAUAAADEAAAABgAAANAAAAAHAAAA3AAAAAgAAADwAAAACQAAAAQBAAASAAAAEAEAAAoAAAAs AQAADAAAADgBAAANAAAARAEAAA4AAABQAQAADwAAAFgBAAAQAAAAYAEAABMAAABoAQAAAgAAAOQE AAAeAAAABAAAAEhpLAAeAAAAAQAAAABpLAAeAAAACwAAAEtlbiBMYXJtZXIAAB4AAAABAAAAAGVu IB4AAAABAAAAAGVuIB4AAAALAAAATm9ybWFsLmRvdAAAHgAAAAsAAABLZW4gTGFybWVyAAAeAAAA AgAAADgAbiAeAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDkuMAAAQAAAAAB45KwUAAAAQAAAAAAm09Hd HMABQAAAAACet37yHMABAwAAAAEAAAADAAAAQQIAAAMAAADdDAAAAwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4b EJOXCAArLPmuMAAAAAABAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACQAAAABgAAAJgAAAARAAAA oAAAABcAAACoAAAACwAAALAAAAAQAAAAuAAAABMAAADAAAAAFgAAAMgAAAANAAAA0AAAAAwAAADg AAAAAgAAAOQEAAAeAAAAFgAAAENvbW1TZW5zZSBFbmdpbmVlcmluZwBlAAMAAAAbAAAAAwAAAAYA AAADAAAAzA8AAAMAAACgCgkACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAA AAQAAABIaSwADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAA AAwAAAANAAAADgAAAA8AAAD+////EQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAA /v///xsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAD+////IwAAACQAAAAlAAAAJgAAACcAAAAo AAAAKQAAAP7////9////LAAAAP7////+/////v////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAA AAAAAAAAADBHCIzyHMABLgAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD///////////////8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAxxMAAAAAAABXAG8AcgBkAEQAbwBjAHUA bQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQUAAAD/ /////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiHgAAAAAAAAUA UwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GgAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBh AHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAiAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0AFAAbwBv AGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAwRwiM8hzAATBHCIzyHMABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAABAAAA/v////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQg RG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA --larmer.commsense.net|E07E020FC8E32FC4A15FEACA3E3B906C-15074-- From Radia.Perlman@East.Sun.COM Tue, 12 Sep 2000 18:08:12 -0400 (EDT) Date: Tue, 12 Sep 2000 18:08:12 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] SRMflag & SSNflag settings I don't have the time to answer thoroughly, but let me make a comment that will hopefully make things easier to understand. I don't remember why this was specified as two binary flags SRM and SSN. Instead I think it's clearer to think of it as a single "state" variable with 3 settings: OK (don't need to send ack or LSP) ACK (i.e., SSN, need to send ack) XMIT (i.e., SRM, need to transmit LSP) You never should have both SSN and SRM flags set. You send an ack once and then change the state to "OK". You send an LSP if SRM is set (state is "XMIT") until you get an ack or the same LSP from that neighbor. If an ack, you change state to "OK". If you receive the same LSP from a neighbor N you set the state to "ack" for that neighbor. If you receive a new LSP from N you set the state to N to "ack" and to everyone else as "XMIT". You keep transmitting to a neighbor until you get an ack from that nbr, or the same LSP from that nbr. This isn't very complete, I'm sure...but the main thing I wanted to clarify is (unless I've completely forgotten this...it's been about 85 years ... ) that you'd never want both SSN and SRM set. Radia From selvarajr@future.futsoft.com Thu, 14 Sep 2000 15:29:12 +0530 Date: Thu, 14 Sep 2000 15:29:12 +0530 From: selvarajR selvarajr@future.futsoft.com Subject: [Isis-wg] Doubt >this actually will be worse, the IS-1 and IS-2 may randomly setup >adjacnecies with IS-3 on either c3 or c4 depends on the timing. since >they will rejects the second adjacency setup due to conflict in systemID >and mac addresses. Yes that is possible if c1 and c2 already exist on the network before c3 or c4. For instance if another IS , IS-4, be commimg up then there is no gaurentee that IS-4 also will form the same adjacency with IS-3 as IS-1 & IS-2. Selva -----Original Message----- From: Naiming Shen [SMTP:naiming@redback.com] Sent: Tuesday, September 12, 2000 1:04 PM To: selvarajr@future.futsoft.com Cc: 'ISISWG' Subject: Re: [Isis-wg] Doubt ] ] IS - 1 IS - 2 ] | | ] | c1 | c2 ]----------------------------------------------------------- ] c3 | | c4 ] | | ] | | ] IS - 3 ] ]For the above broadcast topology let, ] IS-1, IS-2 & IS-3 be three L1 intermediate systems ] c1, c2, c3, c4 be the respective IS's circuits. where c4 be the back up ]link for IS-3. ] Let priority of c1 be 10, c2 be 20, c3 be 30 and c4 be 40. ] ]Here, IS -1 and IS -2 will have two adjacencies for IS -3 with same s ]ystem Id but, different SNPA. ]But, IS -3 won't have any adjacency of it's own. ie c4 is not known to c3 ]and vice versa ] ]DOUBTS: ]1. After DR election c1 , c2 and c4 will say c4 as the DR. But c3 will say ] c3 as the DR. So the LAN will have more than on DR at a time this actually will be worse, the IS-1 and IS-2 may randomly setup adjacnecies with IS-3 on either c3 or c4 depends on the timing. since they will rejects the second adjacency setup due to conflict in systemID and mac addresses. ]2. If the IS won't have two interfaces on the same LAN as in the above ]topology , then why do we need to check for system ID and SNPA. for ]creating new adjacency over a circuit. I feel checking for System ID ]alone sufficient. So we can discard duplicate IIH. i guess the idea was to prevent accident. if you want to bring a new router into the LAN and misconfigure the systemID which duplicates the one already in operation, the proper behaviour should be the new router can not join the ISIS on this LAN instead of knocking off the one already working. since the chances are the new router probably is configured wrong. so this check on both systemID and mac address is useful. ] ]Pls correct me , if I'm wrong. ] - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From selvarajr@future.futsoft.com Thu, 14 Sep 2000 15:31:46 +0530 Date: Thu, 14 Sep 2000 15:31:46 +0530 From: selvarajR selvarajr@future.futsoft.com Subject: FW: [Isis-wg] Doubt Hi, I was out of station for the past two days. So I couldn't reply imedietly Sorry. If adjacency with neighbours having same system Id as the local system be established then those neighbours won't get in the SPF tree construction. Because local systems cost will be zero and hence the neighbour gets overridden. So no way the adjacency is usefull. If there is no such validation then there will be a possibility that all IS on the LAN ( even whole domain) having same system ID. Won't it be ? So neighbours with conflicting SNPA and System ID be detected it can better be ignored. In any way it is NOT useful. Having useless things is better not having it. Selva. -----Original Message----- From: larmer@commsense.net [SMTP:larmer@commsense.net] Sent: Tuesday, September 12, 2000 7:59 PM To: selvarajr@kailash.future.futsoft.com Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Doubt Hi Selva, >I assume that, if any Hello PDU be received by an IS with system >Id same as the received IS, then it can be discarded. ie Receiving >own hello PDU. I could not find reference to this in ISO 10589, where is this spelled out? If they were not discarded, wouldn't the DR election process work correctly? > DOUBTS: > 1. After DR election c1 , c2 and c4 will say c4 as the DR. But c3 >will say c3 as the DR. So the LAN will have more than one DR at a >time ISO 10589 states the following pertinent information in section 8.4.4 LAN Designated Intermediate Systems: d)After waiting ISISHelloTimer * 2 seconds, run the Level 1 and or the Level 2 Designated Intermediate System election process depending on the Intermediate system type. This shall be run subsequently whenever an IIH PDU is received or transmitted...(For these purposes, the transmission of the system's own IIH PDU is equivalent to receiving it)... If IS-3 discards one of the IIH PDUs, I don't believe the DR election process during circuit initialization will work properly. However, subsequent DR elections should work properly because IS-3 will know about both IIH PDUs being generated. Am I off in the weeds? Cheers, Ken Larmer CommSense Networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From ben.abarbanel@ipoptical.com Thu, 14 Sep 2000 10:52:59 -0400 Date: Thu, 14 Sep 2000 10:52:59 -0400 From: ben abarbanel ben.abarbanel@ipoptical.com Subject: [Isis-wg] IS-IS TE Question This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C01E39.F2750BA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a = question came to mind regarding=20 unreserved bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth = states "for stability reasons, rapid changes in the values in this = sub-TLV should not cause rapid generation of LSPs".=20 =20 I was wondering what if 2 ingress (head end RSVP) LSR routers are = provisioning LSPs (each wanting 100 Mbytes) through the same core = convergent LSR interface and each one of the routers at the time they = privision their LSP think there is 100 Mbyte of bandwidth free to = complete the job. In reality there is a total of 100 MBYTE for the whole = interface, the first RSVP reservation succeeds while the second fails.=20 =20 The second LSP Ingress router would ask TE Source routing for another = next bandwidth constraint best path to setup the LSP. How efficient is = that if many LSPs coverge in the core of the network this way and there = is no precise way to say what is available at the time RSVP is trigered = on? Also, since the IS-IS and its TE source routing engine take snap shots = of the bandwidth resources in the network it has a tunnel view of what = other IS-IS(LSR) routers are doing to this information at that moment in = time, and are making inaccurate determination of what is reserved and = what is free. The IS-IS route convergent time could be much slower than = the RSVP signalling time. The following is my assumption, please clarify if I am wrong, thanks if a series of LSP requests are hitting a given IS-IS router (TE source = routing engine) at the same processing window/cycle, it makes = assignments based on a frozen snap shot of the bandwidth in the network. = Assignments are made without consideration for their RSVP signalling = success/failure and eventually the signalling components would fail = their reservation requests causing turbulance with LSP attempts. Assuming most of what i said is true, do we need another more precise = mechanism to solve this? =20 Regards, Ben=20 =20 Ben Abarbanel, Software Engineering, =20 Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ------=_NextPart_000_0047_01C01E39.F2750BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
I was reading the latest draft=20 "draft-ietf-isis-traffic-02.txt" and a question came to mind regarding=20
unreserved bandwidth. In section 5.4 = SUB-TLV 11:=20 Unreserved bandwidth states "for stability reasons, rapid changes in the values in this sub-TLV should not cause = rapid=20 generation of LSPs".
 
I was wondering what=20 if  2 ingress (head end RSVP) LSR routers are provisioning LSPs = (each=20 wanting 100 Mbytes) through the same = core=20 convergent LSR interface and each one = of the routers at the time they = privision their LSP think there is 100 Mbyte of bandwidth free to complete = the job. In reality there is a total of 100 MBYTE = for the=20 whole interface, the first RSVP reservation succeeds while the second = fails.=20
 
The second LSP Ingress router = would ask TE=20 Source routing for another next bandwidth constraint best path to setup = the=20 LSP.  How efficient is that if many LSPs coverge in the core of the network this = way and=20 there is no precise way to say what is available=20 at the time RSVP is trigered on?
 
Also, since the IS-IS and its TE = source=20 routing engine take snap shots of the bandwidth resources in the = network it=20 has a tunnel view of what other IS-IS(LSR) routers are doing to this information at that moment in time, and are = making=20 inaccurate determination of what is reserved and what is free. The IS-IS = route=20 convergent time could be much slower than the RSVP signalling = time.
 
The following is my assumption, please clarify if I am wrong, = thanks
 
if a series of LSP=20 requests are hitting a given IS-IS router (TE source routing = engine) at the=20 same processing window/cycle, it makes=20 assignments based on a frozen snap shot of the bandwidth in the network. = Assignments are made without consideration for=20 their RSVP signalling success/failure and eventually the signalling = components=20 would fail their reservation requests causing turbulance with LSP attempts.
 
 
Assuming most of what i said is true, = do we need=20 another more precise mechanism to solve this? 
 
Regards,
Ben 
 
 
Ben Abarbanel,  Software = Engineering, =20
 
Phone:  703 456=20 2982
FAX:     703 456 2952
 
IPOptical, Inc.
11480 Sunset Hills = Road
Suite=20 #200E
Reston, VA 20190
------=_NextPart_000_0047_01C01E39.F2750BA0-- From sudheer@nayna.com Thu, 14 Sep 2000 08:05:12 -0700 Date: Thu, 14 Sep 2000 08:05:12 -0700 From: Sudheer Dharnikota sudheer@nayna.com Subject: [Isis-wg] IS-IS TE Question Bena: This is a famous problem with the receiver-oriented reservation mechanims. Where on the downstream side you do the CAC and on the upstream side you do the actual reservaion. I am not sure if we have a straight-forward answer for this. I would also assume that the geneic consensus is pray god that it will not happen (which is the generic approach taken till now) or use different criteria for the second LSP after it failed - as proposed in draft-dharanikota-interarea-mpls-te-ext-00.txt Cheers, sudheer > ben abarbanel wrote: > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a > question came to mind regarding > unreserved bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth > states "for stability reasons, rapid changes in the values in this > sub-TLV should not cause rapid generation of LSPs". > > I was wondering what if 2 ingress (head end RSVP) LSR routers are > provisioning LSPs (each wanting 100 Mbytes) through the same core > convergent LSR interface and each one of the routers at the time they > privision their LSP think there is 100 Mbyte of bandwidth free to > complete the job. In reality there is a total of 100 MBYTE for the > whole interface, the first RSVP reservation succeeds while the second > fails. > > The second LSP Ingress router would ask TE Source routing for another > next bandwidth constraint best path to setup the LSP. How efficient > is that if many LSPs coverge in the core of the network this way and > there is no precise way to say what is available at the time RSVP is > trigered on? > > Also, since the IS-IS and its TE source routing engine take snap shots > of the bandwidth resources in the network it has a tunnel view of what > other IS-IS(LSR) routers are doing to this information at that moment > in time, and are making inaccurate determination of what is reserved > and what is free. The IS-IS route convergent time could be much slower > than the RSVP signalling time. > > The following is my assumption, please clarify if I am wrong, thanks > > if a series of LSP requests are hitting a given IS-IS router (TE > source routing engine) at the same processing window/cycle, it makes > assignments based on a frozen snap shot of the bandwidth in the > network. Assignments are made without consideration for their RSVP > signalling success/failure and eventually the signalling components > would fail their reservation requests causing turbulance with LSP > attempts. > > > Assuming most of what i said is true, do we need another more precise > mechanism to solve this? > > Regards, > Ben > > > Ben Abarbanel, Software Engineering, > > Phone: 703 456 2982 > FAX: 703 456 2952 > > IPOptical, Inc. > 11480 Sunset Hills Road > Suite #200E > Reston, VA 20190 From dareks@nortelnetworks.com Thu, 14 Sep 2000 12:25:29 -0400 Date: Thu, 14 Sep 2000 12:25:29 -0400 From: Darek Skalecki dareks@nortelnetworks.com Subject: [Isis-wg] IS-IS TE Question This is a multi-part message in MIME format. --------------7D3D0D0254DA76A03206253F Content-Type: multipart/alternative; boundary="------------5FA9CB3C8BB65B95B52F29AF" --------------5FA9CB3C8BB65B95B52F29AF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ben abarbanel wrote: > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a > question came to mind regardingunreserved bandwidth. In section 5.4 > SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid > changes in the values in this sub-TLV should not cause rapid > generation of LSPs". > I was wondering what if 2 ingress (head end RSVP) LSR routers are > provisioning LSPs (each wanting 100 Mbytes) through the same core > convergent LSR interface and each one of the routers at the time they > privision their LSP think there is 100 Mbyte of bandwidth free to > complete the job. In reality there is a total of 100 MBYTE for the > whole interface, the first RSVP reservation succeeds while the second > fails. > The second LSP Ingress router would ask TE Source routing for another > next bandwidth constraint best path to setup the LSP. How efficient > is that if many LSPs coverge in the core of the network this way and > there is no precise way to say what is available at the time RSVP is > trigered on? > Also, since the IS-IS and its TE source routing engine take snap shots > of the bandwidth resources in the network it has a tunnel view of what > other IS-IS(LSR) routers are doing to this information at that moment > in time, and are making inaccurate determination of what is reserved > and what is free. The IS-IS route convergent time could be much slower > than the RSVP signalling time. For CR-LDP a feedback mechanism was proposed to learn at signaling intervals/speed whether or not there was b/w at interfaces. A snapshot of that b/w is fed into TE database based on which source routes are computed. With feedback, if there is insufficient b/w at an interface to accomodate an LSP, a notification message with a feedback TLV is carried towards the source. The feedback information is then input into TE database at source and a new route computed. That route should now not contain the interface where there was insufficient b/w. The feedback mechanism is described in: http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > The following is my assumption, please clarify if I am wrong, thanks > if a series of LSP requests are hitting a given IS-IS router (TE > source routing engine) at the same processing window/cycle, it makes > assignments based on a frozen snap shot of the bandwidth in the > network. Assignments are made without consideration for their RSVP > signalling success/failure and eventually the signalling components > would fail their reservation requests causing turbulance with LSP > attempts. > Assuming most of what i said is true, do we need another more precise > mechanism to solve this? Regards, The feedback provides you ability to try, fail, learn and try again. >From our experience, a proprietary signaling protocol with feedback worked just fine, i.e. convergence was fast (one or two tries/failures and a satisfactory route was found). > Ben Ben Abarbanel, Software Engineering, Phone: 703 456 2982 > FAX: 703 456 2952 IPOptical, Inc. > 11480 Sunset Hills Road > Suite #200E > Reston, VA 20190 -- Darek Skalecki Nortel (613) 765-2252 --------------5FA9CB3C8BB65B95B52F29AF Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit ben abarbanel wrote:
I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a question came to mind regardingunreserved bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid changes in the values in this sub-TLV should not cause rapid generation of LSPs".
I was wondering what if  2 ingress (head end RSVP) LSR routers are provisioning LSPs (each wanting 100 Mbytes) through the same core convergent LSR interface and each one of the routers at the time they privision their LSP think there is 100 Mbyte of bandwidth free to complete the job. In reality there is a total of 100 MBYTE for the whole interface, the first RSVP reservation succeeds while the second fails.
The second LSP Ingress router would ask TE Source routing for another next bandwidth constraint best path to setup the LSP.  How efficient is that if many LSPs coverge in the core of the network this way and there is no precise way to say what is available at the time RSVP is trigered on?
Also, since the IS-IS and its TE source routing engine take snap shots of the bandwidth resources in the network it has a tunnel view of what other IS-IS(LSR) routers are doing to this information at that moment in time, and are making inaccurate determination of what is reserved and what is free. The IS-IS route convergent time could be much slower than the RSVP signalling time.
For CR-LDP a feedback mechanism was proposed to learn at signaling intervals/speed whether or not there was b/w at interfaces. A snapshot of that b/w is fed into TE database based on which source routes are computed. With feedback, if there is insufficient b/w at an interface to accomodate an LSP, a notification message with a feedback TLV is carried towards the source. The feedback information is then input into TE database at source and a new route computed. That route should now not contain the interface where there was insufficient b/w. The feedback mechanism is described in:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt
The following is my assumption, please clarify if I am wrong, thanks
if a series of LSP requests are hitting a given IS-IS router (TE source routing engine) at the same processing window/cycle, it makes assignments based on a frozen snap shot of the bandwidth in the network. Assignments are made without consideration for their RSVP signalling success/failure and eventually the signalling components would fail their reservation requests causing turbulance with LSP attempts.
Assuming most of what i said is true, do we need another more precise mechanism to solve this? Regards,
The feedback provides you ability to try, fail, learn and try again. From our experience, a proprietary signaling protocol with feedback worked just fine, i.e. convergence was fast (one or two tries/failures and a satisfactory route was found).
 
Ben  Ben Abarbanel,  Software Engineering, Phone:  703 456 2982
FAX:     703 456 2952 IPOptical, Inc.
11480 Sunset Hills Road
Suite #200E
Reston, VA 20190
-- 
Darek Skalecki
Nortel 
(613) 765-2252
  --------------5FA9CB3C8BB65B95B52F29AF-- --------------7D3D0D0254DA76A03206253F Content-Type: text/plain; charset=iso-8859-1; name="draft-ietf-mpls-te-feed-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="draft-ietf-mpls-te-feed-01.txt" MPLS Working Group Peter Ashwood-Smit= h Internet Draft Bilel Jamoussi Expiration Date: December 2000 Don Fedyk Darek Skalecki Nortel Networks July 2000 Improving Topology Data Base Accuracy with LSP Feedback draft-ietf-mpls-te-feed-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract One key component of traffic engineering is a concept known as constraint based routing. In constraint based routing a topology database is maintained on all participating nodes. This database contains a complete list of all the links in the network that participate in traffic engineering and for each of these links a set of constraints which those links can meet. Bandwidth, for example, is one essential constraint. Since the bandwidth available changes as new LSPs are established and terminated the topology database will develop inconsistencies with respect to the real network. It is not possible to increase the flooding rates arbitrarily to keep the database discrepancies from growing. We propose a new mechanism whereby a source node can learn about the successes or failures of its path selections by receiving feedback from the paths it is attempting. This fed-back information can be incorporated into subsequent route computations, which greatly improves the accuracy Ashwood-Smith, et. al. [Page 1] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 of the overall routing solution by significantly reducing the database discrepancies. 1. Introduction Because the network is a distributed system, it is necessary to have a mechanism to advertise information about links to all nodes in the network [IS-IS], [OSPF]. A node can then build a topology map of the network. This information is required to be as up-to-date as possible for accurate traffic engineered paths. Information about link or node failures must be rapidly propagated through the network so that recovery can be initiated. Other information about links that may be useful for reasons of quality of service include parameters such as available bandwidth, and delay. The information in this topology database is often out of date with respect to the real network. Available bandwidth is the most critical of these attributes and it can drift substantially with respect to reality due to the low frequency of link state updates that can be sustained in a very large topology. We refer to the deviation in the topology database available bandwidth as being optimistic if the database shows more available bandwidth than there really is, or pessimistic if the topology database shows less bandwidth than there really is. This distinction is important because we shall propose an efficient algorithm to deal with optimistic databases without resorting to shorter flooding intervals. One of the major problems for a constraint based routing system is dealing with changing constraints. Obviously, since bandwidth is one of the essential constraints, dealing with the rapid changes in reserved bandwidth poses some interesting challenges. In smaller networks, one can resort to higher frequency flooding but this obviously does not scale. The basic proposal is to add to the signaling protocol the ability to piggyback actual link bandwidth availability information at every link that the signaling traverses. This is done as part of the reverse messaging on success or failure (mapping, release, withdraw or notification). What this means is that every time signaling messages flow backwards toward a source to tell it of the success, failure or termination of a request, that message contains a detailed slice of bandwidth availability information for the exact path that the message has followed. This slice of reservation information, which is very up to date, is received by the source node and attached to the source node's topology database prior to making any further source route computations. The result is that the source node's topology database will tend to stay synchronized with the slices of the network through which it is establishing paths. This is nothing more than learning from successes and failures and represents an intelligent alternative to either waiting for floods or introducing non-determinism (guessing) into the source algorithms. It is important to note that the fed-back data is never Ashwood-Smith, et. al. July 2000 [Page 2] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 re-flooded. It simply overrides flooded information for the purpose of route computation until a superceding flood or fed-back value arrives. As such, it is not actually inserted into a topology database, most likely it simply is linked to that database as an override used only by source route computations. Operating a constraint based routing system without such feedback is inefficient at best since a source node will continue to give out incorrect route over and over again until it gets an IGP update. This could be minutes away and as a result the worst case blocking time for a new route is the minimum repeatable flooding interval (often several minutes in big networks). Alternatives to feedback mechanisms involve adding some non-determinism (randomness) to the routing algorithm in the hopes that it will stumble onto a path that works. These sorts of approaches are seen in ATM dynamic routing systems, which do not have these forms of feedback. In order to get a good understanding of how the feedback works, imagine a network with precisely one path (with sufficient unreserved bandwidth) available from the source to the destination. Further, imagine that the topology database at the source is significantly out of date with respect to the real network in that the source topology database sees sufficient bandwidth available on many different routes to the destination. We call this being optimistic with respect to the network since the source thinks that more bandwidth is available than there really is. When such an optimistic source selects its first path it will likely contain links that do not in reality have sufficient unreserved bandwidth. Therefore, the path is only established up to the link that does not have sufficient bandwidth. A notification message is formatted that contains the actual unreserved bandwidth for this blocking link which flows back toward the source, collapsing the partially created path as it goes. In addition, at every link that this notification traverses, the current unreserved bandwidth information for each corresponding link is appended to the vector of unreserved bandwidth along the path. In this manner, an accurate view of the slice through the network we are traversing is constructed. Eventually this message arrives back at the source node, where the vector is taken and used to temporarily override the topology database for route computations. This node has just learned from its mistake and is now slightly less optimistic with respect to the real network conditions. Path selection can be attempted again but this time the node will not make the same mistake it made the previous time. The link in question, at which rejection occurred the first time, will not even be eligible this time around, so a source route computation is guaranteed to produce a different path (or none). The same procedure may be repeated as many times as is necessary, each time learning from its mistakes, until eventually no paths remain in the source topology to the destination, or we actually find a path that works. Ashwood-Smith, et. al. July 2000 [Page 3] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 This tendency to converge either to a solution or determine that there is no solution is an important property of a routing system (it actually behaves a lot like a depth first search). This property is not present with flooding mechanisms alone since the source node must randomly hunt, or continually make the same mistakes, or abort until the next flood arrives. In addition to feeding back bandwidth on failure, we also recommend feedback on success. This has important consequences on our ability to spread load or to spill over to new links as existing links fill. It is true that spilling over to new links does not require feedback on success since we could simply wait for a feedback on failure, but we can achieve better load spreading earlier. Finally, when a path is torn down the release/withdraw messages also contain bandwidth information that can be fed back to override the source topology database. This is very important during failure scenarios where the links we need to use to reroute the path share common sub-segments with the failed path. Without the feedback, the common sub-segments may not indicate sufficient available bandwidth until we get a flood that may mean many seconds without a connection. With feedback at least we will be up to date with respect to available bandwidth up to the point of failure in the path. Also since failure involves many paths tearing down and re- establishing this is the time that it is most critical to have an accurate view. When preemption is being employed it is also extremely important that the topology database inconsistencies be small. If not, high setup priority LSPs may unnecessarily preempt lower holding priority LSPs to obtain bandwidth that, had they had a more up to date view of unreserved bandwidth, they would have been able to find elsewhere. Since preempted LSPs may in turn preempt other LSPs in a domino like effect, the results of such database inconsistencies can have wide reaching ripple like impacts. These feedback mechanisms help reduce these occurrences significantly. There are a number of network conditions where feedback shows its value. One can think of a constraint-based network as being in one of three conditions. The first is called ramp-up, this is when the rate of arriving reservations exceeds the rate of departing reservations. The second is called steady-state, this is when the rate of arriving reservations is about the same as the rate of departing reservations. Finally, the ramp-down condition is that which has a greater rate of departing reservations than arriving reservations. These three network conditions show distinctly different types of error in the topology databases. In particular an optimistic view of available bandwidth by a source node is characteristic of the ramp- up condition of a network. A pessimistic view of available bandwidth by a source node is characteristic of the ramp-down condition of a Ashwood-Smith, et. al. July 2000 [Page 4] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 network. If one plots the average error in the topology databases with respect to the real network for the three different network conditions, one will see the error slowly go positive during ramp up, slowly go negative during ramp down, and drift slowly around 0 for the steady condition. The effect of flooding on this plot is to periodically snap the error back to 0 at flooding intervals. The effect of the feedback algorithm is to bring an optimistic error back to zero without having to wait for the flood interval. On average then, the feedback algorithm tends to halve the absolute error, keeping it mostly negative or pessimistic. This makes sense since a routing system will never give paths to links that it thinks do not have resources and as a result its pessimistic view of the world stays that way until it gets a flood. This relieves the IGP updates of the most urgent requirement of flooding when bandwidth is consumed. Availability of new bandwidth occurs when paths are released or new links become available. New links are accompanied by floods. Significant releases of bandwidth can be broadcast at relatively low frequencies in the order of several minutes with little operational impact. Extensive operational experience with this feedback protocol in proprietary Nortel Networks (pre-standard CR-LDP) products has shown it to work very well for networks up to 1000 nodes with significant flooding intervals damped to several minutes. Without this protocol, these networks would block setups for up to several minutes. With this protocol, the blocking in most cases is reduced to a small number of retry attempts which is usually sub-second depending mostly on the propagation delays in the network. These feedback algorithms have been particularly beneficial in cases of failure recovery during which the network is in a sudden condition of ramp-up. Since a large number of reservations must be remade, it is highly likely that we will exceed the limits of certain key links in the network. Without feedback, the rerouting must block until a flood arrives telling us of the situation at those key links at which time rerouting can continue. With feedback, the rerouting simply continues until a feedback indicates that a link is full. In addition since reservation-balancing algorithms are also often used, feedback allows the balancing algorithms to make better distribution decisions based on immediate feedback. We have also explored through simulation and implementation a variety of mechanisms to deal with the pessimistic error in the database. One simple proposal is to use selective forgetting. In this algorithm, a reserved bandwidth value slowly drops back to zero over a relatively short time interval. The theory being that you shift the network back to an optimistic state (by forgetting your pessimism) where the feedback algorithm will again correctly operate. These algorithms have not shown any great advantage and are actually non-optimal when the error is purely optimistic. Ashwood-Smith, et. al. July 2000 [Page 5] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 Other algorithmic permutations we have explored include such variations as: Feeding-back to all intermediate nodes, information learned from control messages upstream of that intermediate node. Feeding back in both directions so that both the source and destination node's databases stay synchronized. Allowing a request to continue to its destination despite there being insufficient bandwidth at some intermediate hop. Then, rejecting the request with a full bandwidth vector slice all the way to the destination instead of just to the point of rejection. Our simulations have not show significant benefits relative to the simpler algorithm proposed here. However, it is an interesting research topic to explore and quantify the different feedback algorithms and their impacts on blocking times so we do not want to discourage the interested reader from exploring these concepts more fully. 2. Adding feedback TLVs to CR-LDP Two new TLVs are optionally added to the CR-LDP mapping, notification, and withdraw messages. There may be an arbitrary number of these TLV in any order or position in the message. It is recommended that they be placed such that they can be read and applied to override the topology database by scanning the message forwards and walking the topology database from the point where the last link feedback TLV left off. Each TLV consists of the 8 unreserved bandwidth values for each holding priority 0 through 7 as IEEE floating point numbers (the units are unidirectional bytes per second). Following this are the IP addresses of the two ends of the interface. Two TLVs are possible, one for IPV4 and one for IPV6 addressing of the link. Note: the feedback TLVs may also optionally be included in query or query-reply messages in response to bandwidth update queries from an LER. Details of this mechanism are provided in [QUERY]. 2.1 Bandwidth directionality considerations The order of the two addresses in the feedback TLV implies the direction in which the bandwidth is available. For example if the first address is A and the second address is B the bandwidth is unreserved in the A to B direction. It is possible for an implementation to provide both the A to B direction and the B to A direction as part of the same feedback message. This is done by simply including a TLV with A,B as the addresses of the link and a different TLV with B,A as the addresses Ashwood-Smith, et. al. July 2000 [Page 6] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 of the link. Should CR-LDP evolve to be able to support bi- directional traffic flow and reservations it is expected that bi- directional feedback would also be implemented via this mechanism. Ashwood-Smith, et. al. July 2000 [Page 7] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 3. IPV4 specified link feedback TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x830 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV4 address of interface (near end) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV4 address of interface (far end) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. IPV6 specified link feedback TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x831 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address of interface (near end) | | _____ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address of interface (far end) | | _____ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. Detailed Procedures On receipt of a withdraw, notification, query-reply, or mapping message pertaining to a request made by CR-LDP (as opposed to LDP), a feedback TLV of the appropriate format for the interface over which the message was received is inserted into the message before forwarding it back to the source of the request. The 8 bandwidth values are filled in with the outgoing bandwidth available on this interface for each of the 8 holding priorities in bytes per second. Finally the interface's address and far end address are placed in the TLV. Ashwood-Smith, et. al. July 2000 [Page 8] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 On receipt of a CR-LDP request message which cannot be satisfied. A notification message is formatted normally. The 8-bandwidth values are filled in with the outgoing bandwidth available on this interface for each of the 8 holding priorities in bytes per second. Finally, the interface's address and far end address are placed in the TLV. On receipt of a CR-LDP request message which has been satisfied and which results in a mapping being generated. No feedback TLV is added since the previous node will insert the proper TLV when it receives the reverse flowing mapping. When an LDP session goes down either because of a link failure, TCP/IP timeout, keepalive timeout, adjacency timeout etc. Other LDP sessions in the module must generate either notification, withdraw or release messages for LSPs that traversed the LDP in question. In the case that the LSP was created by CR-LDP and that a withdraw or notification is about to be generated, LDP will insert a feedback TLV for the interface which just went down that contains 0's for all the bandwidth values and attach to it the proper interface addresses. When the LDP session that originated a CR-LDP label request receives a mapping that contains feedback TLV's it is recommended that these bandwidth values supersede the corresponding values in the node's topology database for source route computations. Doing so permits this node to immediately synchronize its topology with respect to the real bandwidth reservations along the path that was just established. When the LDP session that originated a CR-LDP label request receives a notification that contains feedback TLV's it is recommended that these bandwidth values supersede the corresponding values in the node's topology database for source route computations. Doing so permits this node to immediately synchronize its topology with respect to the real bandwidth reservations along the path that just failed to establish. The source node may then re-compute a path knowing that the computation will take into account the failure if it was caused by the topology database being in error with respect to the real network state. 6. IGP considerations Implementations MUST NOT permit bandwidth information learned by this feedback mechanism to be re-flooded via IS-IS, OSPF or any other IGP. The bandwidth information learned via these feedback mechanisms is to be used ONLY for source route computations on the nodes that are directly on the path that fed back the bandwidth. Normally only the source node of the LSP, or perhaps intermediate gateway nodes will use this information. It is however permitted for intermediate nodes that are forwarding this feedback information to store it for their own local source route computations. Ashwood-Smith, et. al. July 2000 [Page 9] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 There is a possibility of a race condition between the bandwidth information that is received via feedback and that which is received via a normal IGP flood. While there may be a discrepancy between the two, both are within a few 100 milliseconds of being correct. Solutions to allow us to determine which information is most up to date (say by adding a sequence number) do not add any significant benefit. Constraint based, source routed systems will always have errors in the local topology database with respect to the real network. We can reduce these errors through reduced flooding intervals, path following feedback and selective flooding but we cannot realistically reduce the errors below the second or so range. As a result propagation delay order race conditions are noise with respect to the average expected errors. An implementation SHOULD therefore consider the most recently received update (IGP or feedback) as being the most up to date. 7. Future considerations Constraint based routing systems such as CR-LDP will in the future offer other forms of constraint than simply reserved bandwidth. Actual utilization levels, current congestion levels, number of discrete channels/wavelengths available etc. are all possible constraints that change rapidly and which must be taken into consideration when computing a route. It is expected that this mechanism will be used to feedback these and other new forms of link constraining data. 8. RSVP consideration Nothing precludes the use of such feedback mechanisms with a similar TLV structure in the RSVP Resv and other reverse flowing messages although repeatedly applying a fed-back should be avoided since it increases the race condition window with flooded LSPs. This could be accomplished by a simple rule that only permits fed-back information on the original RESV, not on subsequent refreshes. 9. Intellectual Property Consideration The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 10. Security Considerations This document raises no new security considerations for CR-LDP, RSVP or MPLS in general. 11. Acknowledgments Ashwood-Smith, et. al. July 2000 [Page 10] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 The authors would like to thank Keith Dysart for his guidance, and Jerzy Miernik for helping implement these concepts and bringing them to life. 12. References [CR-LDP] Constraint-Based LSP Setup using LDP, draft-ietf-mpls-cr- ldp-04.txt [LDP] LDP Specification, draft-ietf-mpls-ldp-05.txt [IS-IS] Extensions to IS-IS for traffic engineering, draft-ietf- isis-traffic-01.txt [QUERY] MPLS LDP Query Message Description, draft-paraschiv-mpls- lsp-query-00.txt. 13. Author's Addresses Peter Ashwood-Smith Bilel Jamoussi Nortel Networks Corp. Nortel Networks Corp. P.O. Box 3511 Station C, 600 Technology Park Drive Ottawa, ON K1Y 4H7 Billerica, MA 01821 Canada USA Phone: +1 613-763-4534 phone: +1 978-288-4506 petera@nortelnetworks.com jamoussi@nortelnetworks.com Darek Skalecki Don Fedyk Nortel Networks Corp. Nortel Networks Corp. P.O. Box 3511 Station C, 600 Technology Park Drive Ottawa, On K1Y 4H7 Billerica, MA 01821 Canada USA Phone: +1 613-765-2252 Phone: +1 978-228-3041 dareks@nortelnetworks.com dwfedyk@nortelnetworks.com Full Copyright Statement Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Ashwood-Smith, et. al. July 2000 [Page 11] =0CInternet Draft LSP Feedback with CR-LDP July, 2000 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Ashwood-Smith, et. al. July 2000 [Page 12] --------------7D3D0D0254DA76A03206253F-- From cmj@3Com.com Thu, 14 Sep 2000 11:50:36 -0700 Date: Thu, 14 Sep 2000 11:50:36 -0700 From: Cyndi Jung cmj@3Com.com Subject: [Isis-wg] Simple question about IS-IS mixed domains If you can't mix dual and non-dual routers in the same area and have routing work for the non-OSI protocols supported (IP and IPv6), then how can it work at Level 2 if all the Level 2 routers do not support all the same non-OSI protocols? It seems to have the same problem - routes will be computed through routers that do not support the protocol of the data, just because the link costs are lowest. Am I missing something? Cyndi From Mkontoff@Kontoff.com Thu, 14 Sep 2000 16:08:44 -0400 Date: Thu, 14 Sep 2000 16:08:44 -0400 From: Matthew Kontoff Mkontoff@Kontoff.com Subject: [Isis-wg] IS-IS TE Question Darek Skalecki wrote: > > ben abarbanel wrote: > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a question came to mind regardingunreserved > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid changes in the > > values in this sub-TLV should not cause rapid generation of LSPs". You still need to regenerate and flood LSPs when an interface state (i.e. bandwidth) changes. How you do this is up to you. For example, you could reflood LSPs at an interval that could be tied to the amount of bandwidth being used. The more frequently LSPs are reflooded the closer an approximation of actual unreserved bandwidth in the network you will have. > > > I was wondering what if 2 ingress (head end RSVP) LSR routers are provisioning LSPs (each wanting 100 Mbytes) > > through the same core convergent LSR interface and each one of the routers at the time they privision their LSP > > think there is 100 Mbyte of bandwidth free to complete the job. In reality there is a total of 100 MBYTE for the > > whole interface, the first RSVP reservation succeeds while the second fails. > > > The second LSP Ingress router would ask TE Source routing for another next bandwidth constraint best path to setup > > the LSP. How efficient is that if many LSPs coverge in the core of the network this way and there is no precise way > > to say what is available at the time RSVP is trigered on? > > > Also, since the IS-IS and its TE source routing engine take snap shots of the bandwidth resources in the network it > > has a tunnel view of what other IS-IS(LSR) routers are doing to this information at that moment in time, and are > > making inaccurate determination of what is reserved and what is free. The IS-IS route convergent time could be much > > slower than the RSVP signalling time. > > For CR-LDP a feedback mechanism was proposed to learn at signaling intervals/speed whether or not there was b/w at > interfaces. A snapshot of that b/w is fed into TE database based on which source routes are computed. With feedback, > if there is insufficient b/w at an interface to accomodate an LSP, a notification message with a feedback TLV is > carried towards the source. The feedback information is then input into TE database at source and a new route > computed. That route should now not contain the interface where there was insufficient b/w. The feedback mechanism is > described in: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt Why would you need a feedback mechanism if you regenerate and flood IS-IS LSPs with updated TE TLVs that contain up to the moment (second, millisecond, whatever) bandwidth info? > > The following is my assumption, please clarify if I am wrong, thanks > > > if a series of LSP requests are hitting a given IS-IS router (TE source routing engine) at the same processing > > window/cycle, it makes assignments based on a frozen snap shot of the bandwidth in the network. Assignments are made > > without consideration for their RSVP signalling success/failure and eventually the signalling components would fail > > their reservation requests causing turbulance with LSP attempts. > > > Assuming most of what i said is true, do we need another more precise mechanism to solve this? Regards, > > The feedback provides you ability to try, fail, learn and try again. From our experience, a proprietary signaling > protocol with feedback worked just fine, i.e. convergence was fast (one or two tries/failures and a satisfactory route > was found). I agree with the 'try fail and learn again' approach but I don't think you need a separate feedback mechanism other than recent IS-IS LSPs from other LSRs. Matt Kontoff From dareks@nortelnetworks.com Thu, 14 Sep 2000 16:29:06 -0400 Date: Thu, 14 Sep 2000 16:29:06 -0400 From: Darek Skalecki dareks@nortelnetworks.com Subject: [Isis-wg] IS-IS TE Question --------------B64AA65EFD07897516D25EF7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Matthew Kontoff wrote: > Darek Skalecki wrote: > > > > ben abarbanel wrote: > > > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a question came to mind regardingunreserved > > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid changes in the > > > values in this sub-TLV should not cause rapid generation of LSPs". > > You still need to regenerate and flood LSPs when an interface state (i.e. bandwidth) > changes. How you do this is up to you. For example, you could reflood LSPs at an interval > that could be tied to the amount of bandwidth being used. The more frequently LSPs > are reflooded the closer an approximation of actual unreserved bandwidth in the > network you will have. > > > > > > > I was wondering what if 2 ingress (head end RSVP) LSR routers are provisioning LSPs (each wanting 100 Mbytes) > > > through the same core convergent LSR interface and each one of the routers at the time they privision their LSP > > > think there is 100 Mbyte of bandwidth free to complete the job. In reality there is a total of 100 MBYTE for the > > > whole interface, the first RSVP reservation succeeds while the second fails. > > > > > The second LSP Ingress router would ask TE Source routing for another next bandwidth constraint best path to setup > > > the LSP. How efficient is that if many LSPs coverge in the core of the network this way and there is no precise way > > > to say what is available at the time RSVP is trigered on? > > > > > Also, since the IS-IS and its TE source routing engine take snap shots of the bandwidth resources in the network it > > > has a tunnel view of what other IS-IS(LSR) routers are doing to this information at that moment in time, and are > > > making inaccurate determination of what is reserved and what is free. The IS-IS route convergent time could be much > > > slower than the RSVP signalling time. > > > > For CR-LDP a feedback mechanism was proposed to learn at signaling intervals/speed whether or not there was b/w at > > interfaces. A snapshot of that b/w is fed into TE database based on which source routes are computed. With feedback, > > if there is insufficient b/w at an interface to accomodate an LSP, a notification message with a feedback TLV is > > carried towards the source. The feedback information is then input into TE database at source and a new route > > computed. That route should now not contain the interface where there was insufficient b/w. The feedback mechanism is > > described in: > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > > Why would you need a feedback mechanism if you regenerate and flood IS-IS LSPs with updated TE TLVs > that contain up to the moment (second, millisecond, whatever) bandwidth info? If your flooding interval is very short then there is no need for feedback but you don't want to flood too frequently or else only control traffic is running in the network and the network doesn't scale too well. We employed feedback in a system where regular floods were every 30 minutes, feedback updates were at path establishment rates, i.e. feedback information was piggy-backed on top of appropriate signaling messages. > > > > > The following is my assumption, please clarify if I am wrong, thanks > > > > > if a series of LSP requests are hitting a given IS-IS router (TE source routing engine) at the same processing > > > window/cycle, it makes assignments based on a frozen snap shot of the bandwidth in the network. Assignments are made > > > without consideration for their RSVP signalling success/failure and eventually the signalling components would fail > > > their reservation requests causing turbulance with LSP attempts. > > > > > Assuming most of what i said is true, do we need another more precise mechanism to solve this? Regards, > > > > The feedback provides you ability to try, fail, learn and try again. From our experience, a proprietary signaling > > protocol with feedback worked just fine, i.e. convergence was fast (one or two tries/failures and a satisfactory route > > was found). > > I agree with the 'try fail and learn again' approach but I don't think you need > a separate feedback mechanism other than recent IS-IS LSPs from other LSRs. > > Matt Kontoff -- Darek Skalecki Nortel (613) 765-2252 --------------B64AA65EFD07897516D25EF7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Matthew Kontoff wrote:
Darek Skalecki wrote:
>
> ben abarbanel wrote:
>
> > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a question came to mind regardingunreserved
> > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid changes in the
> > values in this sub-TLV should not cause rapid generation of LSPs".

You still need to regenerate and flood LSPs when an interface state (i.e. bandwidth)
changes. How you do this is up to you. For example, you could reflood LSPs at an interval
that could be tied to the amount of bandwidth being used. The more frequently LSPs
are reflooded the closer an approximation of actual unreserved bandwidth in the
network you will have.

 

>
> > I was wondering what if  2 ingress (head end RSVP) LSR routers are provisioning LSPs (each wanting 100 Mbytes)
> > through the same core convergent LSR interface and each one of the routers at the time they privision their LSP
> > think there is 100 Mbyte of bandwidth free to complete the job. In reality there is a total of 100 MBYTE for the
> > whole interface, the first RSVP reservation succeeds while the second fails.
>
> > The second LSP Ingress router would ask TE Source routing for another next bandwidth constraint best path to setup
> > the LSP.  How efficient is that if many LSPs coverge in the core of the network this way and there is no precise way
> > to say what is available at the time RSVP is trigered on?
>
> > Also, since the IS-IS and its TE source routing engine take snap shots of the bandwidth resources in the network it
> > has a tunnel view of what other IS-IS(LSR) routers are doing to this information at that moment in time, and are
> > making inaccurate determination of what is reserved and what is free. The IS-IS route convergent time could be much
> > slower than the RSVP signalling time.
>
> For CR-LDP a feedback mechanism was proposed to learn at signaling intervals/speed whether or not there was b/w at
> interfaces. A snapshot of that b/w is fed into TE database based on which source routes are computed. With feedback,
> if there is insufficient b/w at an interface to accomodate an LSP, a notification message with a feedback TLV is
> carried towards the source. The feedback information is then input into TE database at source and a new route
> computed. That route should now not contain the interface where there was insufficient b/w. The feedback mechanism is
> described in:
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt

Why would you need a feedback mechanism if you regenerate and flood IS-IS LSPs with updated TE TLVs
that contain up to the moment (second, millisecond, whatever) bandwidth info?

If your flooding interval is very short then there is no need for feedback but you don't want to flood too frequently or else only control traffic is running in the network and the network doesn't scale too well. We employed feedback in a system where regular floods were every 30 minutes, feedback updates were at path establishment rates, i.e. feedback information was piggy-backed on top of appropriate signaling messages.
 

> > The following is my assumption, please clarify if I am wrong, thanks
>
> > if a series of LSP requests are hitting a given IS-IS router (TE source routing engine) at the same processing
> > window/cycle, it makes assignments based on a frozen snap shot of the bandwidth in the network. Assignments are made
> > without consideration for their RSVP signalling success/failure and eventually the signalling components would fail
> > their reservation requests causing turbulance with LSP attempts.
>
> > Assuming most of what i said is true, do we need another more precise mechanism to solve this? Regards,
>
> The feedback provides you ability to try, fail, learn and try again. >From our experience, a proprietary signaling
> protocol with feedback worked just fine, i.e. convergence was fast (one or two tries/failures and a satisfactory route
> was found).

I agree with the 'try fail and learn again' approach but I don't think you need
a separate feedback mechanism other than recent IS-IS LSPs from other LSRs.

Matt Kontoff

-- 
Darek Skalecki
Nortel 
(613) 765-2252
  --------------B64AA65EFD07897516D25EF7-- From ben.abarbanel@ipoptical.com Thu, 14 Sep 2000 16:44:25 -0400 Date: Thu, 14 Sep 2000 16:44:25 -0400 From: ben abarbanel ben.abarbanel@ipoptical.com Subject: [Isis-wg] IS-IS TE Question Matthew and Darek: I kind of like the feedback mechanism defined in "draft-ietf-mpls-te-feed-01.txt". I think what is missing and maybe Bilel or Darek can add it to their spec is that a timestamp be added to both the flooded LSA/LSP TE TLV to identify when the bandwidth sample was taken. Also the CR/LDP or RSVP-TE new TLV have a time stamp identifying when the reservation denial and bandwidth sample was taken from the rejecting LSR. As the message is returned to the ingress LSR its bandwidth will be overwritten into the linkstate database, since its the most up to date information. I can see a race condition where IGP converging link state information might have older data then Reservation Release/Withdrawl messages containing the same (feedback) data. Thus its possible for the ingress LSR IGP to momentarily over-write newer bandwidth with bad/older bandwidth into the ingress LSR linkstate database. Ingress LSR IGP should check the timestamp in the database with its current LSA/LSP packet and only update the bandwidth value if it has the newer timestamp in the LSA/LSP packet. regards, Ben Ben Abarbanel, Software Engineering, Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ----- Original Message ----- From: "Matthew Kontoff" To: "Darek Skalecki" Cc: "ben abarbanel" ; "isis-wg" Sent: Thursday, September 14, 2000 4:08 PM Subject: Re: [Isis-wg] IS-IS TE Question > > > Darek Skalecki wrote: > > > > ben abarbanel wrote: > > > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a question came to mind regardingunreserved > > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid changes in the > > > values in this sub-TLV should not cause rapid generation of LSPs". > > You still need to regenerate and flood LSPs when an interface state (i.e. bandwidth) > changes. How you do this is up to you. For example, you could reflood LSPs at an interval > that could be tied to the amount of bandwidth being used. The more frequently LSPs > are reflooded the closer an approximation of actual unreserved bandwidth in the > network you will have. > > > > > > I was wondering what if 2 ingress (head end RSVP) LSR routers are provisioning LSPs (each wanting 100 Mbytes) > > > through the same core convergent LSR interface and each one of the routers at the time they privision their LSP > > > think there is 100 Mbyte of bandwidth free to complete the job. In reality there is a total of 100 MBYTE for the > > > whole interface, the first RSVP reservation succeeds while the second fails. > > > > > The second LSP Ingress router would ask TE Source routing for another next bandwidth constraint best path to setup > > > the LSP. How efficient is that if many LSPs coverge in the core of the network this way and there is no precise way > > > to say what is available at the time RSVP is trigered on? > > > > > Also, since the IS-IS and its TE source routing engine take snap shots of the bandwidth resources in the network it > > > has a tunnel view of what other IS-IS(LSR) routers are doing to this information at that moment in time, and are > > > making inaccurate determination of what is reserved and what is free. The IS-IS route convergent time could be much > > > slower than the RSVP signalling time. > > > > For CR-LDP a feedback mechanism was proposed to learn at signaling intervals/speed whether or not there was b/w at > > interfaces. A snapshot of that b/w is fed into TE database based on which source routes are computed. With feedback, > > if there is insufficient b/w at an interface to accomodate an LSP, a notification message with a feedback TLV is > > carried towards the source. The feedback information is then input into TE database at source and a new route > > computed. That route should now not contain the interface where there was insufficient b/w. The feedback mechanism is > > described in: > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > > Why would you need a feedback mechanism if you regenerate and flood IS-IS LSPs with updated TE TLVs > that contain up to the moment (second, millisecond, whatever) bandwidth info? > > > > The following is my assumption, please clarify if I am wrong, thanks > > > > > if a series of LSP requests are hitting a given IS-IS router (TE source routing engine) at the same processing > > > window/cycle, it makes assignments based on a frozen snap shot of the bandwidth in the network. Assignments are made > > > without consideration for their RSVP signalling success/failure and eventually the signalling components would fail > > > their reservation requests causing turbulance with LSP attempts. > > > > > Assuming most of what i said is true, do we need another more precise mechanism to solve this? Regards, > > > > The feedback provides you ability to try, fail, learn and try again. >From our experience, a proprietary signaling > > protocol with feedback worked just fine, i.e. convergence was fast (one or two tries/failures and a satisfactory route > > was found). > > I agree with the 'try fail and learn again' approach but I don't think you need > a separate feedback mechanism other than recent IS-IS LSPs from other LSRs. > > > Matt Kontoff > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From ben.abarbanel@ipoptical.com Thu, 14 Sep 2000 14:02:03 -0400 Date: Thu, 14 Sep 2000 14:02:03 -0400 From: ben abarbanel ben.abarbanel@ipoptical.com Subject: [Isis-wg] IS-IS TE Question This is a multi-part message in MIME format. ------=_NextPart_000_0092_01C01E54.5BE69C60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Darek: Thanks for the kind response. I was thinking about your answer. What = happens if you have multiple LSP attempts with multiple retries does the = originating LSR take into account potential attempts that have not = initiated yet, but could collide in the core LSR interface and thus = forces other potential LSP to go to different paths (although less = optimal), or does it simply assume that all colliding LSPs have plenty = of bandwidth even before they are actually assigned or signalled through = the domain? Second question, how do you keep the feedback information carried back = in CR/LDP from being overwritten by the IGP flooding of the same = bandwidth data? Could this propose a synchronization issue or is the = assumption that the IGP data will be as good as the feedback data? Regards, Ben Ben Abarbanel, Software Engineering, =20 Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ----- Original Message -----=20 From: Darek Skalecki=20 To: ben abarbanel=20 Cc: isis-wg=20 Sent: Thursday, September 14, 2000 12:25 PM Subject: Re: [Isis-wg] IS-IS TE Question ben abarbanel wrote:=20 I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and = a question came to mind regardingunreserved bandwidth. In section 5.4 = SUB-TLV 11: Unreserved bandwidth states "for stability reasons, rapid = changes in the values in this sub-TLV should not cause rapid generation = of LSPs". I was wondering what if 2 ingress (head end RSVP) LSR routers are = provisioning LSPs (each wanting 100 Mbytes) through the same core = convergent LSR interface and each one of the routers at the time they = privision their LSP think there is 100 Mbyte of bandwidth free to = complete the job. In reality there is a total of 100 MBYTE for the whole = interface, the first RSVP reservation succeeds while the second fails. The second LSP Ingress router would ask TE Source routing for = another next bandwidth constraint best path to setup the LSP. How = efficient is that if many LSPs coverge in the core of the network this = way and there is no precise way to say what is available at the time = RSVP is trigered on? Also, since the IS-IS and its TE source routing engine take snap = shots of the bandwidth resources in the network it has a tunnel view of = what other IS-IS(LSR) routers are doing to this information at that = moment in time, and are making inaccurate determination of what is = reserved and what is free. The IS-IS route convergent time could be much = slower than the RSVP signalling time. For CR-LDP a feedback mechanism was proposed to learn at signaling = intervals/speed whether or not there was b/w at interfaces. A snapshot = of that b/w is fed into TE database based on which source routes are = computed. With feedback, if there is insufficient b/w at an interface to = accomodate an LSP, a notification message with a feedback TLV is carried = towards the source. The feedback information is then input into TE = database at source and a new route computed. That route should now not = contain the interface where there was insufficient b/w. The feedback = mechanism is described in:=20 http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt=20 The following is my assumption, please clarify if I am wrong, thanks if a series of LSP requests are hitting a given IS-IS router (TE = source routing engine) at the same processing window/cycle, it makes = assignments based on a frozen snap shot of the bandwidth in the network. = Assignments are made without consideration for their RSVP signalling = success/failure and eventually the signalling components would fail = their reservation requests causing turbulance with LSP attempts. Assuming most of what i said is true, do we need another more = precise mechanism to solve this? Regards, The feedback provides you ability to try, fail, learn and try again. = >From our experience, a proprietary signaling protocol with feedback = worked just fine, i.e. convergence was fast (one or two tries/failures = and a satisfactory route was found).=20 =20 Ben Ben Abarbanel, Software Engineering, Phone: 703 456 2982=20 FAX: 703 456 2952 IPOptical, Inc.=20 11480 Sunset Hills Road=20 Suite #200E=20 Reston, VA 20190 --=20 Darek Skalecki Nortel=20 (613) 765-2252 =20 -------------------------------------------------------------------------= ----- MPLS Working Group Peter = Ashwood-Smith Internet Draft Bilel Jamoussi Expiration Date: December 2000 Don Fedyk Darek Skalecki Nortel Networks July 2000 Improving Topology Data Base Accuracy with LSP Feedback draft-ietf-mpls-te-feed-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other = documents at any time. It is inappropriate to use Internet-Drafts as = reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract One key component of traffic engineering is a concept known as constraint based routing. In constraint based routing a topology database is maintained on all participating nodes. This database contains a complete list of all the links in the network that participate in traffic engineering and for each of these links a = set of constraints which those links can meet. Bandwidth, for example, is one essential constraint. Since the bandwidth available changes as new LSPs are established and terminated the topology database will develop inconsistencies with respect to the real network. It = is not possible to increase the flooding rates arbitrarily to keep the database discrepancies from growing. We propose a new mechanism whereby a source node can learn about the successes or failures of its path selections by receiving feedback from the paths it is attempting. This fed-back information can be incorporated into subsequent route computations, which greatly improves the accuracy Ashwood-Smith, et. al. [Page 1] Internet Draft LSP Feedback with CR-LDP July, 2000 of the overall routing solution by significantly reducing the database discrepancies. 1. Introduction Because the network is a distributed system, it is necessary to = have a mechanism to advertise information about links to all nodes in = the network [IS-IS], [OSPF]. A node can then build a topology map of the network. This information is required to be as up-to-date as possible for accurate traffic engineered paths. Information about link or node failures must be rapidly propagated through the = network so that recovery can be initiated. Other information about links that may be useful for reasons of quality of service include parameters such as available bandwidth, and delay. The information in this topology database is often out of date with respect to the real network. Available bandwidth is the most critical of these attributes and it can drift substantially with respect to reality due to the low frequency of link state updates that can be = sustained in a very large topology. We refer to the deviation in the topology database available bandwidth as being optimistic if the database shows more available bandwidth than there really is, or pessimistic if the topology database shows less bandwidth than there really is. This distinction is important because we shall propose an efficient algorithm to deal with optimistic databases without resorting to shorter flooding intervals. One of the major problems for a constraint based routing system is dealing with changing constraints. Obviously, since bandwidth is = one of the essential constraints, dealing with the rapid changes in reserved bandwidth poses some interesting challenges. In smaller networks, one can resort to higher frequency flooding but this obviously does not scale. The basic proposal is to add to the signaling protocol the ability to piggyback actual link bandwidth availability information at = every link that the signaling traverses. This is done as part of the reverse messaging on success or failure (mapping, release, withdraw or notification). What this means is that every time signaling messages flow backwards toward a source to tell it of the success, failure or termination of a request, that message contains a detailed slice of bandwidth availability information for the exact path that the message has followed. This slice of reservation information, which is very up to date, is received by the source node and attached to the source node's topology database prior to making any further source route computations. The result is that = the source node's topology database will tend to stay synchronized with the slices of the network through which it is establishing paths. This is nothing more than learning from successes and failures and represents an intelligent alternative to either waiting for floods or introducing non-determinism (guessing) into the source algorithms. It is important to note that the fed-back data is never Ashwood-Smith, et. al. July 2000 [Page 2] Internet Draft LSP Feedback with CR-LDP July, 2000 re-flooded. It simply overrides flooded information for the purpose of route computation until a superceding flood or fed-back value arrives. As such, it is not actually inserted into a topology database, most likely it simply is linked to that database as an override used only by source route computations. Operating a constraint based routing system without such feedback = is inefficient at best since a source node will continue to give out incorrect route over and over again until it gets an IGP update. This could be minutes away and as a result the worst case blocking time for a new route is the minimum repeatable flooding interval (often several minutes in big networks). Alternatives to feedback mechanisms involve adding some non-determinism (randomness) to the routing algorithm in the hopes that it will stumble onto a path = that works. These sorts of approaches are seen in ATM dynamic routing systems, which do not have these forms of feedback. In order to get a good understanding of how the feedback works, imagine a network with precisely one path (with sufficient unreserved bandwidth) available from the source to the destination. Further, imagine that the topology database at the source is significantly out of date with respect to the real network in that the source topology database sees sufficient bandwidth available on many different routes to the destination. We call this being optimistic with respect to the network since the source thinks that more bandwidth is available than there really is. When such an optimistic source selects its first path it will = likely contain links that do not in reality have sufficient unreserved bandwidth. Therefore, the path is only established up to the link that does not have sufficient bandwidth. A notification message is formatted that contains the actual unreserved bandwidth for this blocking link which flows back toward the source, collapsing the partially created path as it goes. In addition, at every link that this notification traverses, the current unreserved bandwidth information for each corresponding link is appended to the vector = of unreserved bandwidth along the path. In this manner, an accurate view of the slice through the network we are traversing is constructed. Eventually this message arrives back at the source node, where the vector is taken and used to temporarily override = the topology database for route computations. This node has just = learned from its mistake and is now slightly less optimistic with respect = to the real network conditions. Path selection can be attempted again but this time the node will not make the same mistake it made the previous time. The link in question, at which rejection occurred the first time, will not even be eligible this time around, so a source route computation is guaranteed to produce a different path (or none). The same = procedure may be repeated as many times as is necessary, each time learning from its mistakes, until eventually no paths remain in the source topology to the destination, or we actually find a path that works. Ashwood-Smith, et. al. July 2000 [Page 3] Internet Draft LSP Feedback with CR-LDP July, 2000 This tendency to converge either to a solution or determine that there is no solution is an important property of a routing system (it actually behaves a lot like a depth first search). This = property is not present with flooding mechanisms alone since the source node must randomly hunt, or continually make the same mistakes, or abort until the next flood arrives. In addition to feeding back bandwidth on failure, we also recommend feedback on success. This has important consequences on our ability to spread load or to spill over to new links as existing links = fill. It is true that spilling over to new links does not require = feedback on success since we could simply wait for a feedback on failure, = but we can achieve better load spreading earlier. Finally, when a path is torn down the release/withdraw messages = also contain bandwidth information that can be fed back to override the source topology database. This is very important during failure scenarios where the links we need to use to reroute the path share common sub-segments with the failed path. Without the feedback, the common sub-segments may not indicate sufficient available bandwidth until we get a flood that may mean many seconds without a connection. With feedback at least we will be up to date with respect to available bandwidth up to the point of failure in the path. Also since failure involves many paths tearing down and re- establishing this is the time that it is most critical to have an accurate view. When preemption is being employed it is also extremely important that the topology database inconsistencies be small. If not, high setup priority LSPs may unnecessarily preempt lower holding = priority LSPs to obtain bandwidth that, had they had a more up to date view of unreserved bandwidth, they would have been able to find elsewhere. Since preempted LSPs may in turn preempt other LSPs in a domino like effect, the results of such database inconsistencies = can have wide reaching ripple like impacts. These feedback mechanisms help reduce these occurrences significantly. There are a number of network conditions where feedback shows its value. One can think of a constraint-based network as being in one of three conditions. The first is called ramp-up, this is when the rate of arriving reservations exceeds the rate of departing reservations. The second is called steady-state, this is when the rate of arriving reservations is about the same as the rate of departing reservations. Finally, the ramp-down condition is that which has a greater rate of departing reservations than arriving reservations. These three network conditions show distinctly different types of error in the topology databases. In particular an optimistic view = of available bandwidth by a source node is characteristic of the ramp- up condition of a network. A pessimistic view of available = bandwidth by a source node is characteristic of the ramp-down condition of a Ashwood-Smith, et. al. July 2000 [Page 4] Internet Draft LSP Feedback with CR-LDP July, 2000 network. If one plots the average error in the topology databases with respect to the real network for the three different network conditions, one will see the error slowly go positive during ramp up, slowly go negative during ramp down, and drift slowly around 0 for the steady condition. The effect of flooding on this plot is to periodically snap the error back to 0 at flooding intervals. The effect of the feedback algorithm is to bring an optimistic error back to zero without having to wait for the flood interval. On average then, the feedback algorithm tends to halve the absolute error, keeping it mostly negative or pessimistic. This makes sense since a routing system will never give paths to links that it = thinks do not have resources and as a result its pessimistic view of the world stays that way until it gets a flood. This relieves the IGP updates of the most urgent requirement of flooding when bandwidth = is consumed. Availability of new bandwidth occurs when paths are released or new links become available. New links are accompanied by floods. Significant releases of bandwidth can be broadcast at relatively low frequencies in the order of several minutes with little operational impact. Extensive operational experience with this feedback protocol in proprietary Nortel Networks (pre-standard CR-LDP) products has = shown it to work very well for networks up to 1000 nodes with significant flooding intervals damped to several minutes. Without this = protocol, these networks would block setups for up to several minutes. With this protocol, the blocking in most cases is reduced to a small number of retry attempts which is usually sub-second depending mostly on the propagation delays in the network. These feedback algorithms have been particularly beneficial in = cases of failure recovery during which the network is in a sudden condition of ramp-up. Since a large number of reservations must be remade, it is highly likely that we will exceed the limits of certain key links in the network. Without feedback, the rerouting must block until a flood arrives telling us of the situation at those key links at which time rerouting can continue. With = feedback, the rerouting simply continues until a feedback indicates that a link is full. In addition since reservation-balancing algorithms = are also often used, feedback allows the balancing algorithms to make better distribution decisions based on immediate feedback. We have also explored through simulation and implementation a variety of mechanisms to deal with the pessimistic error in the database. One simple proposal is to use selective forgetting. In this algorithm, a reserved bandwidth value slowly drops back to = zero over a relatively short time interval. The theory being that you shift the network back to an optimistic state (by forgetting your pessimism) where the feedback algorithm will again correctly operate. These algorithms have not shown any great advantage and = are actually non-optimal when the error is purely optimistic. Ashwood-Smith, et. al. July 2000 [Page 5] Internet Draft LSP Feedback with CR-LDP July, 2000 Other algorithmic permutations we have explored include such variations as: Feeding-back to all intermediate nodes, information learned from control messages upstream of that intermediate node. Feeding back in both directions so that both the source and destination node's databases stay synchronized. Allowing a request to continue to its destination despite there being insufficient bandwidth at some intermediate hop. Then, rejecting the request with a full bandwidth vector slice all the = way to the destination instead of just to the point of rejection. Our simulations have not show significant benefits relative to the simpler algorithm proposed here. However, it is an interesting research topic to explore and quantify the different feedback algorithms and their impacts on blocking times so we do not want to discourage the interested reader from exploring these concepts more fully. 2. Adding feedback TLVs to CR-LDP Two new TLVs are optionally added to the CR-LDP mapping, notification, and withdraw messages. There may be an arbitrary number of these TLV in any order or position in the message. It is recommended that they be placed such that they can be read and applied to override the topology database by scanning the message forwards and walking the topology database from the point where the last link feedback TLV left off. Each TLV consists of the 8 unreserved bandwidth values for each holding priority 0 through 7 as IEEE floating point numbers (the units are unidirectional bytes per second). Following this are the IP addresses of the two ends of the interface. Two TLVs are possible, one for IPV4 and one for IPV6 addressing of the link. Note: the feedback TLVs may also optionally be included in query or query-reply messages in response to bandwidth update queries from = an LER. Details of this mechanism are provided in [QUERY]. 2.1 Bandwidth directionality considerations The order of the two addresses in the feedback TLV implies the direction in which the bandwidth is available. For example if the first address is A and the second address is B the bandwidth is unreserved in the A to B direction. It is possible for an implementation to provide both the A to B direction and the B to A direction as part of the same feedback message. This is done by simply including a TLV with A,B as the addresses of the link and a different TLV with B,A as the addresses Ashwood-Smith, et. al. July 2000 [Page 6] Internet Draft LSP Feedback with CR-LDP July, 2000 of the link. Should CR-LDP evolve to be able to support bi- directional traffic flow and reservations it is expected that bi- directional feedback would also be implemented via this mechanism. Ashwood-Smith, et. al. July 2000 [Page 7] Internet Draft LSP Feedback with CR-LDP July, 2000 3. IPV4 specified link feedback TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x830 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV4 address of interface (near end) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV4 address of interface (far end) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. IPV6 specified link feedback TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x831 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE float) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address of interface (near end) | | _____ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address of interface (far end) | | _____ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. Detailed Procedures On receipt of a withdraw, notification, query-reply, or mapping message pertaining to a request made by CR-LDP (as opposed to LDP), a feedback TLV of the appropriate format for the interface over which the message was received is inserted into the message before forwarding it back to the source of the request. The 8 bandwidth values are filled in with the outgoing bandwidth available on this interface for each of the 8 holding priorities in bytes per second. Finally the interface's address and far end address are placed in the TLV. Ashwood-Smith, et. al. July 2000 [Page 8] Internet Draft LSP Feedback with CR-LDP July, 2000 On receipt of a CR-LDP request message which cannot be satisfied. A notification message is formatted normally. The 8-bandwidth values are filled in with the outgoing bandwidth available on this interface for each of the 8 holding priorities in bytes per second. Finally, the interface's address and far end address are placed in the TLV. On receipt of a CR-LDP request message which has been satisfied and which results in a mapping being generated. No feedback TLV is = added since the previous node will insert the proper TLV when it receives the reverse flowing mapping. When an LDP session goes down either because of a link failure, TCP/IP timeout, keepalive timeout, adjacency timeout etc. Other LDP sessions in the module must generate either notification, withdraw or release messages for LSPs that traversed the LDP in question. In the case that the LSP was created by CR-LDP and that a withdraw or notification is about to be generated, LDP will insert a feedback TLV for the interface which just went down that contains 0's for = all the bandwidth values and attach to it the proper interface addresses. When the LDP session that originated a CR-LDP label request = receives a mapping that contains feedback TLV's it is recommended that these bandwidth values supersede the corresponding values in the node's topology database for source route computations. Doing so permits this node to immediately synchronize its topology with respect to the real bandwidth reservations along the path that was just established. When the LDP session that originated a CR-LDP label request = receives a notification that contains feedback TLV's it is recommended that these bandwidth values supersede the corresponding values in the node's topology database for source route computations. Doing so permits this node to immediately synchronize its topology with respect to the real bandwidth reservations along the path that just failed to establish. The source node may then re-compute a path knowing that the computation will take into account the failure if it was caused by the topology database being in error with respect to the real network state. 6. IGP considerations Implementations MUST NOT permit bandwidth information learned by this feedback mechanism to be re-flooded via IS-IS, OSPF or any other IGP. The bandwidth information learned via these feedback mechanisms is to be used ONLY for source route computations on the nodes that are directly on the path that fed back the bandwidth. Normally only the source node of the LSP, or perhaps intermediate gateway nodes will use this information. It is however permitted = for intermediate nodes that are forwarding this feedback information to store it for their own local source route computations. Ashwood-Smith, et. al. July 2000 [Page 9] Internet Draft LSP Feedback with CR-LDP July, 2000 There is a possibility of a race condition between the bandwidth information that is received via feedback and that which is = received via a normal IGP flood. While there may be a discrepancy between = the two, both are within a few 100 milliseconds of being correct. Solutions to allow us to determine which information is most up to date (say by adding a sequence number) do not add any significant benefit. Constraint based, source routed systems will always have errors in the local topology database with respect to the real network. We can reduce these errors through reduced flooding intervals, path following feedback and selective flooding but we cannot realistically reduce the errors below the second or so = range. As a result propagation delay order race conditions are noise with respect to the average expected errors. An implementation SHOULD therefore consider the most recently received update (IGP or feedback) as being the most up to date. 7. Future considerations Constraint based routing systems such as CR-LDP will in the future offer other forms of constraint than simply reserved bandwidth. Actual utilization levels, current congestion levels, number of discrete channels/wavelengths available etc. are all possible constraints that change rapidly and which must be taken into consideration when computing a route. It is expected that this mechanism will be used to feedback these and other new forms of = link constraining data. 8. RSVP consideration Nothing precludes the use of such feedback mechanisms with a = similar TLV structure in the RSVP Resv and other reverse flowing messages although repeatedly applying a fed-back should be avoided since it increases the race condition window with flooded LSPs. This could = be accomplished by a simple rule that only permits fed-back = information on the original RESV, not on subsequent refreshes. 9. Intellectual Property Consideration The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 10. Security Considerations This document raises no new security considerations for CR-LDP, = RSVP or MPLS in general. 11. Acknowledgments Ashwood-Smith, et. al. July 2000 [Page 10] Internet Draft LSP Feedback with CR-LDP July, 2000 The authors would like to thank Keith Dysart for his guidance, and Jerzy Miernik for helping implement these concepts and bringing = them to life. 12. References [CR-LDP] Constraint-Based LSP Setup using LDP, draft-ietf-mpls-cr- ldp-04.txt [LDP] LDP Specification, draft-ietf-mpls-ldp-05.txt [IS-IS] Extensions to IS-IS for traffic engineering, draft-ietf- isis-traffic-01.txt [QUERY] MPLS LDP Query Message Description, draft-paraschiv-mpls- lsp-query-00.txt. 13. Author's Addresses Peter Ashwood-Smith Bilel Jamoussi Nortel Networks Corp. Nortel Networks Corp. P.O. Box 3511 Station C, 600 Technology Park Drive Ottawa, ON K1Y 4H7 Billerica, MA 01821 Canada USA Phone: +1 613-763-4534 phone: +1 978-288-4506 petera@nortelnetworks.com jamoussi@nortelnetworks.com Darek Skalecki Don Fedyk Nortel Networks Corp. Nortel Networks Corp. P.O. Box 3511 Station C, 600 Technology Park Drive Ottawa, On K1Y 4H7 Billerica, MA 01821 Canada USA Phone: +1 613-765-2252 Phone: +1 978-228-3041 dareks@nortelnetworks.com dwfedyk@nortelnetworks.com Full Copyright Statement Copyright (C) The Internet Society (date). All Rights Reserved. = This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain = it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Ashwood-Smith, et. al. July 2000 [Page 11] Internet Draft LSP Feedback with CR-LDP July, 2000 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Ashwood-Smith, et. al. July 2000 [Page 12] ------=_NextPart_000_0092_01C01E54.5BE69C60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Darek:
  Thanks for the kind response. I = was thinking=20 about your answer. What happens if you have multiple LSP attempts with = multiple=20 retries does the originating LSR take into account potential attempts = that have=20 not initiated yet, but could collide in the core LSR interface and thus = forces=20 other potential LSP to go to different paths (although less = optimal),=20 or does it simply assume that all colliding LSPs have plenty of = bandwidth even=20 before they are actually assigned or signalled through the=20 domain?
 
Second question, how do you keep the = feedback=20 information carried back in CR/LDP from being overwritten by the IGP = flooding of=20 the same bandwidth data?   Could this propose a = synchronization issue=20 or is the assumption that the IGP data will be as good as the feedback=20 data?
 
Regards,
Ben
 
 
Ben Abarbanel,  Software Engineering, 
 
Phone:  703 456 2982
FAX:      703 = 456=20 2952
 
IPOptical, Inc.
11480 Sunset Hills Road
Suite = #200E
Reston, VA=20 20190
----- Original Message -----
From:=20 Darek Skalecki
To: ben abarbanel
Cc: isis-wg
Sent: Thursday, September 14, = 2000 12:25=20 PM
Subject: Re: [Isis-wg] IS-IS TE = Question

ben abarbanel wrote:=20
I was reading the latest draft=20 "draft-ietf-isis-traffic-02.txt" and a question came to mind=20 regardingunreserved bandwidth. In section 5.4 SUB-TLV 11: Unreserved = bandwidth states "for stability reasons, rapid changes in the values = in this=20 sub-TLV should not cause rapid generation of = LSPs".
I was = wondering what=20 if  2 ingress (head end RSVP) LSR routers are provisioning LSPs = (each=20 wanting 100 Mbytes) through the same core convergent LSR interface = and each=20 one of the routers at the time they privision their LSP think there = is 100=20 Mbyte of bandwidth free to complete the job. In reality there is a = total of=20 100 MBYTE for the whole interface, the first RSVP reservation = succeeds while=20 the second fails.
The = second LSP=20 Ingress router would ask TE Source routing for another next = bandwidth=20 constraint best path to setup the LSP.  How efficient is that = if many=20 LSPs coverge in the core of the network this way and there is no = precise way=20 to say what is available at the time RSVP is trigered=20 on?
Also, = since the IS-IS=20 and its TE source routing engine take snap shots of the bandwidth = resources=20 in the network it has a tunnel view of what other IS-IS(LSR) routers = are=20 doing to this information at that moment in time, and are making = inaccurate=20 determination of what is reserved and what is free. The IS-IS route=20 convergent time could be much slower than the RSVP signalling=20 time.
For CR-LDP a feedback mechanism was = proposed=20 to learn at signaling intervals/speed whether or not there was b/w at=20 interfaces. A snapshot of that b/w is fed into TE database = based on=20 which source routes are computed. With feedback, if there is = insufficient b/w=20 at an interface to accomodate an LSP, a notification message with a = feedback=20 TLV is carried towards the source. The feedback information is = then input=20 into TE database at source and a new route computed. That route = should=20 now not contain the interface where there was insufficient b/w. The = feedback=20 mechanism is described in:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt= =20
The = following is my=20 assumption, please clarify if I am wrong, = thanks
if a = series of LSP=20 requests are hitting a given IS-IS router (TE source routing engine) = at the=20 same processing window/cycle, it makes assignments based on a frozen = snap=20 shot of the bandwidth in the network. Assignments are made without=20 consideration for their RSVP signalling success/failure and = eventually the=20 signalling components would fail their reservation requests causing=20 turbulance with LSP attempts.
Assuming = most of what=20 i said is true, do we need another more precise mechanism to solve=20 this? Regards,
The feedback provides you = ability=20 to try, fail, learn and try again. From our experience, a proprietary=20 signaling protocol with feedback worked just fine, i.e. convergence = was fast=20 (one or two tries/failures and a satisfactory route was found). =
 =20
Ben  Ben=20 Abarbanel,  Software Engineering, Phone:  703 456 2982
FAX:     703 456 2952 = IPOptical, Inc.
11480 Sunset Hills Road =
Suite #200E
Reston, VA = 20190
-- 
Darek Skalecki
Nortel 
(613) 765-2252
 =20



   MPLS Working=20 = Group           &n= bsp;           &nb= sp;         =20 Peter Ashwood-Smith
   Internet=20 = Draft           &n= bsp;           &nb= sp;           &nbs= p; =20 Bilel Jamoussi
   Expiration Date: December=20 = 2000           &nb= sp;         =20 Don=20 = Fedyk
          &nbs= p;            = ;            =             &= nbsp;      =20 Darek=20 = Skalecki
          &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       =20 Nortel=20 = Networks

         &nb= sp;           &nbs= p;            = ;            =         =20 July 2000

         = Improving=20 Topology Data Base Accuracy with LSP=20 = Feedback

         &nb= sp;          =20 draft-ietf-mpls-te-feed-01.txt



Status of this=20 Memo

   This document is an Internet-Draft and is in = full=20 conformance with
   all provisions of Section 10 of=20 RFC2026.

   Internet-Drafts are working documents of = the=20 Internet Engineering
   Task Force (IETF), its areas, and = its=20 working groups. Note that
   other groups may also = distribute=20 working documents as Internet-
   = Drafts.

  =20 Internet-Drafts are draft documents valid for a maximum of = six
  =20 months and may be updated, replaced, or obsoleted by other=20 documents
   at any time. It is inappropriate to use=20 Internet-Drafts as reference
   material or to cite them = other=20 than as "work in progress."

   The list of current=20 Internet-Drafts can be accessed at
  =20 http://www.ietf.org/ietf/1id-abstracts.txt

   The = list of=20 Internet-Draft Shadow Directories can be accessed at
  =20 http://www.ietf.org/shadow.html.

Abstract

   = One key=20 component of traffic engineering is a concept known as
   = constraint based routing. In constraint based routing a=20 topology
   database is maintained on all participating = nodes.=20 This database
   contains a complete list of all the = links in the=20 network that
   participate in traffic engineering and = for each=20 of these links a set
   of constraints which those links = can=20 meet. Bandwidth, for example,
   is one essential = constraint.=20 Since the bandwidth available changes
   as new LSPs are=20 established and terminated the topology database
   will = develop=20 inconsistencies with respect to the real network. It = is
   not=20 possible to increase the flooding rates arbitrarily to keep=20 the
   database discrepancies from growing. We propose a = new=20 mechanism
   whereby a source node can learn about the = successes=20 or failures of
   its path selections by receiving = feedback from=20 the paths it is
   attempting. This fed-back information = can be=20 incorporated into
   subsequent route computations, which = greatly=20 improves the accuracy


Ashwood-Smith, et.=20 = al.           &nbs= p;            = ;            =    =20 [Page 1]
Internet Draft      LSP Feedback = with=20 CR-LDP    July, 2000


   of the = overall=20 routing solution by significantly reducing the
   = database=20 discrepancies.

1. Introduction

   Because the = network=20 is a distributed system, it is necessary to have
   a = mechanism=20 to advertise information about links to all nodes in = the
  =20 network [IS-IS], [OSPF].  A node can then build a topology map=20 of
   the network.  This information is required to = be as=20 up-to-date as
   possible for accurate traffic engineered = paths.  Information about
   link or node failures = must be=20 rapidly propagated through the network
   so that = recovery can be=20 initiated. Other information about links
   that may be = useful=20 for reasons of quality of service include
   parameters = such as=20 available bandwidth, and delay. The information
   in = this=20 topology database is often out of date with respect to = the
  =20 real network. Available bandwidth is the most critical of=20 these
   attributes and it can drift substantially with = respect=20 to reality
   due to the low frequency of link state = updates that=20 can be sustained
   in a very large topology. We refer to = the=20 deviation in the topology
   database available bandwidth = as=20 being optimistic if the database
   shows more available=20 bandwidth than there really is, or pessimistic
   if the = topology=20 database shows less bandwidth than there really is.
   = This=20 distinction is important because we shall propose an = efficient
  =20 algorithm to deal with optimistic databases without resorting=20 to
   shorter flooding intervals.

   One = of the=20 major problems for a constraint based routing system = is
  =20 dealing with changing constraints. Obviously, since bandwidth is=20 one
   of the essential constraints, dealing with the = rapid=20 changes in
   reserved bandwidth poses some interesting=20 challenges. In smaller
   networks, one can resort to = higher=20 frequency flooding but this
   obviously does not=20 scale.

   The basic proposal is to add to the = signaling=20 protocol the ability
   to piggyback actual link = bandwidth=20 availability information at every
   link that the = signaling=20 traverses. This is done as part of the
   reverse = messaging on=20 success or failure (mapping, release, withdraw
   or=20 notification). What this means is that every time = signaling
  =20 messages flow backwards toward a source to tell it of the=20 success,
   failure or termination of a request, that = message=20 contains a
   detailed slice of bandwidth availability=20 information for the exact
   path that the message has = followed.=20 This slice of reservation
   information, which is very = up to=20 date, is received by the source
   node and attached to = the=20 source node's topology database prior to
   making any = further=20 source route computations. The result is that the
   = source=20 node's topology database will tend to stay synchronized = with
  =20 the slices of the network through which it is establishing=20 paths.
   This is nothing more than learning from = successes and=20 failures and
   represents an intelligent alternative to = either=20 waiting for floods
   or introducing non-determinism = (guessing)=20 into the source
   algorithms. It is important to note = that the=20 fed-back data is never


Ashwood-Smith, et.=20 al.       July =20 2000        [Page 2]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   re-flooded. It simply overrides = flooded=20 information for the purpose
   of route computation until = a=20 superceding flood or fed-back value
   arrives. As such, = it is=20 not actually inserted into a topology
   database, most = likely it=20 simply is linked to that database as an
   override used = only by=20 source route computations.

   Operating a constraint = based=20 routing system without such feedback is
   inefficient at = best=20 since a source node will continue to give out
   = incorrect route=20 over and over again until it gets an IGP update.
   This = could be=20 minutes away and as a result the worst case blocking
   = time for=20 a new route is the minimum repeatable flooding = interval
   (often=20 several minutes in big networks). Alternatives to = feedback
  =20 mechanisms involve adding some non-determinism (randomness) to=20 the
   routing algorithm in the hopes that it will = stumble onto a=20 path that
   works. These sorts of approaches are seen in = ATM=20 dynamic routing
   systems, which do not have these forms = of=20 feedback.

   In order to get a good understanding of = how the=20 feedback works,
   imagine a network with precisely one = path=20 (with sufficient
   unreserved bandwidth) available from = the=20 source to the destination.
   Further, imagine that the = topology=20 database at the source is
   significantly out of date = with=20 respect to the real network in that
   the source = topology=20 database sees sufficient bandwidth available on
   many = different=20 routes to the destination. We call this being
   = optimistic with=20 respect to the network since the source thinks that
   = more=20 bandwidth is available than there really is.

   When = such an=20 optimistic source selects its first path it will = likely
  =20 contain links that do not in reality have sufficient=20 unreserved
   bandwidth. Therefore, the path is only = established=20 up to the link
   that does not have sufficient = bandwidth. A=20 notification message is
   formatted that contains the = actual=20 unreserved bandwidth for this
   blocking link which = flows back=20 toward the source, collapsing the
   partially created = path as it=20 goes. In addition, at every link that
   this = notification=20 traverses, the current unreserved bandwidth
   = information for=20 each corresponding link is appended to the vector of
  =20 unreserved bandwidth along the path. In this manner, an=20 accurate
   view of the slice through the network we are=20 traversing is
   constructed. Eventually this message = arrives=20 back at the source
   node, where the vector is taken and = used to=20 temporarily override the
   topology database for route=20 computations. This node has just learned
   from its = mistake and=20 is now slightly less optimistic with respect to
   the = real=20 network conditions.

   Path selection can be = attempted again=20 but this time the node will
   not make the same mistake = it made=20 the previous time. The link in
   question, at which = rejection=20 occurred the first time, will not even
   be eligible = this time=20 around, so a source route computation is
   guaranteed to = produce=20 a different path (or none). The same procedure
   may be = repeated=20 as many times as is necessary, each time learning
   from = its=20 mistakes, until eventually no paths remain in the = source
  =20 topology to the destination, or we actually find a path that=20 works.

Ashwood-Smith, et. = al.      =20 July  2000        [Page = 3]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   This tendency to converge either to = a=20 solution or determine that
   there is no solution is an=20 important property of a routing system
   (it actually = behaves a=20 lot like a depth first search). This property
   is not = present=20 with flooding mechanisms alone since the source node
   = must=20 randomly hunt, or continually make the same mistakes, or = abort
  =20 until the next flood arrives.

   In addition to = feeding back=20 bandwidth on failure, we also recommend
   feedback on = success.=20 This has important consequences on our ability
   to = spread load=20 or to spill over to new links as existing links fill.
   = It is=20 true that spilling over to new links does not require = feedback
  =20 on success since we could simply wait for a feedback on failure,=20 but
   we can achieve better load spreading=20 earlier.

   Finally, when a path is torn down the=20 release/withdraw messages also
   contain bandwidth = information=20 that can be fed back to override the
   source topology = database.=20 This is very important during failure
   scenarios where = the=20 links we need to use to reroute the path share
   common=20 sub-segments with the failed path. Without the feedback, = the
  =20 common sub-segments may not indicate sufficient available=20 bandwidth
   until we get a flood that may mean many = seconds=20 without a
   connection. With feedback at least we will = be up to=20 date with
   respect to available bandwidth up to the = point of=20 failure in the
   path. Also since failure involves many = paths=20 tearing down and re-
   establishing this is the time = that it is=20 most critical to have an
   accurate = view.

  =20 When preemption is being employed it is also extremely=20 important
   that the topology database inconsistencies = be small.=20 If not, high
   setup priority LSPs may unnecessarily = preempt=20 lower holding priority
   LSPs to obtain bandwidth that, = had they=20 had a more up to date view
   of unreserved bandwidth, = they would=20 have been able to find
   elsewhere. Since preempted LSPs = may in=20 turn preempt other LSPs in a
   domino like effect, the = results=20 of such database inconsistencies can
   have wide = reaching ripple=20 like impacts. These feedback mechanisms
   help reduce = these=20 occurrences significantly.

   There are a number of = network=20 conditions where feedback shows its
   value. One can = think of a=20 constraint-based network as being in one
   of three = conditions.=20 The first is called ramp-up, this is when the
   rate of = arriving=20 reservations exceeds the rate of departing
   = reservations. The=20 second is called steady-state, this is when the
   rate = of=20 arriving reservations is about the same as the rate of
   = departing reservations. Finally, the ramp-down condition is=20 that
   which has a greater rate of departing = reservations than=20 arriving
   reservations.

   These three = network=20 conditions show distinctly different types of
   error in = the=20 topology databases. In particular an optimistic view = of
  =20 available bandwidth by a source node is characteristic of the=20 ramp-
   up condition of a network. A pessimistic view of = available bandwidth
   by a source node is characteristic = of the=20 ramp-down condition of a

Ashwood-Smith, et.=20 al.       July =20 2000        [Page 4]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   network. If one plots the average = error in=20 the topology databases
   with respect to the real = network for=20 the three different network
   conditions, one will see = the error=20 slowly go positive during ramp
   up, slowly go negative = during=20 ramp down, and drift slowly around 0
   for the steady = condition.=20 The effect of flooding on this plot is to
   periodically = snap=20 the error back to 0 at flooding intervals. The
   effect = of the=20 feedback algorithm is to bring an optimistic error
   = back to=20 zero without having to wait for the flood interval. On
   = average=20 then, the feedback algorithm tends to halve the = absolute
  =20 error, keeping it mostly negative or pessimistic. This makes=20 sense
   since a routing system will never give paths to = links=20 that it thinks
   do not have resources and as a result = its=20 pessimistic view of the
   world stays that way until it = gets a=20 flood.  This relieves the IGP
   updates of the most = urgent=20 requirement of flooding when bandwidth is
   consumed.=20 Availability of new bandwidth occurs when paths are
   = released=20 or new links become available.  New links are = accompanied
  =20 by floods. Significant releases of bandwidth can be broadcast=20 at
   relatively low frequencies in the order of several = minutes=20 with
   little operational impact.

   = Extensive=20 operational experience with this feedback protocol in
  =20 proprietary Nortel Networks (pre-standard CR-LDP) products has=20 shown
   it to work very well for networks up to 1000 = nodes with=20 significant
   flooding intervals damped to several = minutes.=20 Without this protocol,
   these networks would block = setups for=20 up to several minutes. With
   this protocol, the = blocking in=20 most cases is reduced to a small
   number of retry = attempts=20 which is usually sub-second depending
   mostly on the=20 propagation delays in the network.

   These feedback=20 algorithms have been particularly beneficial in cases
   = of=20 failure recovery during which the network is in a = sudden
  =20 condition of ramp-up. Since a large number of reservations must=20 be
   remade, it is highly likely that we will exceed the = limits=20 of
   certain key links in the network. Without feedback, = the=20 rerouting
   must block until a flood arrives telling us = of the=20 situation at
   those key links at which time rerouting = can=20 continue. With feedback,
   the rerouting simply = continues until=20 a feedback indicates that a
   link is full. In addition = since=20 reservation-balancing algorithms are
   also often used, = feedback=20 allows the balancing algorithms to make
   better = distribution=20 decisions based on immediate feedback.

   We have = also=20 explored through simulation and implementation a
   = variety of=20 mechanisms to deal with the pessimistic error in the
   = database.=20 One simple proposal is to use selective forgetting. In
   = this=20 algorithm, a reserved bandwidth value slowly drops back to=20 zero
   over a relatively short time interval. The theory = being=20 that you
   shift the network back to an optimistic state = (by=20 forgetting your
   pessimism) where the feedback = algorithm will=20 again correctly
   operate. These algorithms have not = shown any=20 great advantage and are
   actually non-optimal when the = error is=20 purely optimistic.



Ashwood-Smith, et.=20 al.       July =20 2000        [Page 5]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   Other algorithmic permutations we = have=20 explored include such
   variations = as:

  =20 Feeding-back to all intermediate nodes, information learned=20 from
   control messages upstream of that intermediate=20 node.

   Feeding back in both directions so that both = the=20 source and
   destination node's databases stay=20 synchronized.

   Allowing a request to continue to = its=20 destination despite there
   being insufficient bandwidth = at some=20 intermediate hop. Then,
   rejecting the request with a = full=20 bandwidth vector slice all the way
   to the destination = instead=20 of just to the point of rejection.

   Our simulations = have=20 not show significant benefits relative to the
   simpler=20 algorithm proposed here. However, it is an interesting
   = research topic to explore and quantify the different = feedback
  =20 algorithms and their impacts on blocking times so we do not want=20 to
   discourage the interested reader from exploring = these=20 concepts more
   fully.

2. Adding feedback TLVs to = CR-LDP

   Two new TLVs are optionally added to the = CR-LDP=20 mapping,
   notification, and withdraw messages. There = may be an=20 arbitrary
   number of these TLV in any order or position = in the=20 message. It is
   recommended that they be placed such = that they=20 can be read and
   applied to override the topology = database by=20 scanning the message
   forwards and walking the topology = database from the point where the
   last link feedback = TLV left=20 off.

   Each TLV consists of the 8 unreserved = bandwidth=20 values for each
   holding priority 0 through 7 as IEEE = floating=20 point numbers (the
   units are unidirectional bytes per = second).=20 Following this are the
   IP addresses of the two ends of = the=20 interface. Two TLVs are
   possible, one for IPV4 and one = for=20 IPV6 addressing of the link.

   Note: the feedback = TLVs may=20 also optionally be included in query or
   query-reply = messages=20 in response to bandwidth update queries from an
   LER. = Details=20 of this mechanism are provided in [QUERY].

2.1 Bandwidth = directionality=20 considerations

   The order of the two addresses in = the=20 feedback TLV implies the
   direction in which the = bandwidth is=20 available. For example if the
   first address is A and = the=20 second address is B the bandwidth is
   unreserved in the = A to B=20 direction.

   It is possible for an implementation to = provide=20 both the A to B
   direction and the B to A direction as = part of=20 the same feedback
   message. This is done by simply = including a=20 TLV with A,B as the
   addresses of the link and a = different TLV=20 with B,A as the addresses

Ashwood-Smith, et.=20 al.       July =20 2000        [Page 6]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   of the link. Should CR-LDP evolve = to be=20 able to support bi-
   directional traffic flow and = reservations=20 it is expected that bi-
   directional feedback would = also be=20 implemented via this=20 = mechanism.
































=
















Ashwo= od-Smith,=20 et. al.       July =20 2000        [Page 7]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000



3. IPV4 specified link feedback=20 TLV

  =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9=20 0 1
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 |U|F|         =20 = 0x830           =20 |     =20 = Length           &= nbsp;      =20 |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 |   BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE=20 float)     |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    =20 . . . . . . . .
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 |   BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE=20 float)     |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 = |            =      =20 IPV4 address of interface (near=20 end)         |
   = = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 = |            =      =20 IPV4 address of interface (far=20 end)          = |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

= 4.=20 IPV6 specified link feedback TLV

  =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9=20 0 1
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 |U|F|         =20 = 0x831           =20 |     =20 = Length           &= nbsp;      =20 |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 |   BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE=20 float)     |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    =20 . . . . . . . .
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 |   BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE=20 float)     |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 = |            =      =20 IPV6 address of interface (near=20 end)         |
   = = |            =             &= nbsp; =20 = _____           &n= bsp;           &nb= sp;      =20 |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p; =20 = |            =      =20 IPV6 address of interface (far=20 end)          = |
  =20 = |            =             &= nbsp; =20 = _____           &n= bsp;           &nb= sp;      =20 |
  =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

= 5.=20 Detailed Procedures

   On receipt of a withdraw,=20 notification, query-reply, or mapping
   message = pertaining to a=20 request made by CR-LDP (as opposed to LDP),
   a feedback = TLV of=20 the appropriate format for the interface over
   which = the=20 message was received is inserted into the message = before
  =20 forwarding it back to the source of the request. The 8=20 bandwidth
   values are filled in with the outgoing = bandwidth=20 available on this
   interface for each of the 8 holding=20 priorities in bytes per second.
   Finally the = interface's=20 address and far end address are placed in
   the=20 TLV.



Ashwood-Smith, et. = al.      =20 July  2000        [Page = 8]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   On receipt of a CR-LDP request = message=20 which cannot be satisfied. A
   notification message is = formatted=20 normally. The 8-bandwidth values
   are filled in with = the=20 outgoing bandwidth available on this
   interface for = each of the=20 8 holding priorities in bytes per second.
   Finally, the = interface's address and far end address are placed in
   = the=20 TLV.

   On receipt of a CR-LDP request message which = has been=20 satisfied and
   which results in a mapping being = generated. No=20 feedback TLV is added
   since the previous node will = insert the=20 proper TLV when it receives
   the reverse flowing=20 mapping.

   When an LDP session goes down either = because of a=20 link failure,
   TCP/IP timeout, keepalive timeout, = adjacency=20 timeout etc. Other LDP
   sessions in the module must = generate=20 either notification, withdraw
   or release messages for = LSPs=20 that traversed the LDP in question. In
   the case that = the LSP=20 was created by CR-LDP and that a withdraw or
   = notification is=20 about to be generated, LDP will insert a feedback
   TLV = for the=20 interface which just went down that contains 0's for = all
   the=20 bandwidth values and attach to it the proper interface
   = addresses.

   When the LDP session that originated a = CR-LDP=20 label request receives
   a mapping that contains = feedback TLV's=20 it is recommended that these
   bandwidth values = supersede the=20 corresponding values in the node's
   topology database = for=20 source route computations. Doing so permits
   this node = to=20 immediately synchronize its topology with respect to
   = the real=20 bandwidth reservations along the path that was just
  =20 established.

   When the LDP session that originated = a CR-LDP=20 label request receives
   a notification that contains = feedback=20 TLV's it is recommended that
   these bandwidth values = supersede=20 the corresponding values in the
   node's topology = database for=20 source route computations. Doing so
   permits this node = to=20 immediately synchronize its topology with
   respect to = the real=20 bandwidth reservations along the path that just
   failed = to=20 establish. The source node may then re-compute a path
   = knowing=20 that the computation will take into account the failure = if
   it=20 was caused by the topology database being in error with=20 respect
   to the real network state.

   = 6. IGP=20 considerations

   Implementations MUST NOT permit = bandwidth=20 information learned by
   this feedback mechanism to be=20 re-flooded via IS-IS, OSPF or any
   other IGP. The = bandwidth=20 information learned via these feedback
   mechanisms is = to be=20 used ONLY for source route computations on the
   nodes = that are=20 directly on the path that fed back the bandwidth.
   = Normally=20 only the source node of the LSP, or perhaps = intermediate
  =20 gateway nodes will use this information. It is however permitted=20 for
   intermediate nodes that are forwarding this = feedback=20 information to
   store it for their own local source = route=20 computations.

Ashwood-Smith, et.=20 al.       July =20 2000        [Page 9]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   There is a possibility of a race = condition=20 between the bandwidth
   information that is received via = feedback and that which is received
   via a normal IGP = flood.=20 While there may be a discrepancy between the
   two, both = are=20 within a few 100 milliseconds of being correct.
   = Solutions to=20 allow us to determine which information is most up to
   = date=20 (say by adding a sequence number) do not add any = significant
  =20 benefit. Constraint based, source routed systems will always=20 have
   errors in the local topology database with = respect to the=20 real
   network. We can reduce these errors through = reduced=20 flooding
   intervals, path following feedback and = selective=20 flooding but we
   cannot realistically reduce the errors = below=20 the second or so range.
   As a result propagation delay = order=20 race conditions are noise with
   respect to the average = expected=20 errors. An implementation SHOULD
   therefore consider = the most=20 recently received update (IGP or
   feedback) as being = the most=20 up to date.

7. Future considerations

   = Constraint=20 based routing systems such as CR-LDP will in the = future
   offer=20 other forms of constraint than simply reserved = bandwidth.
  =20 Actual utilization levels, current congestion levels, number=20 of
   discrete channels/wavelengths available etc. are = all=20 possible
   constraints that change rapidly and which = must be=20 taken into
   consideration when computing a route. It is = expected that this
   mechanism will be used to feedback = these=20 and other new forms of link
   constraining = data.

8. RSVP=20 consideration

   Nothing precludes the use of such = feedback=20 mechanisms with a similar
   TLV structure in the RSVP = Resv and=20 other reverse flowing messages
   although repeatedly = applying a=20 fed-back should be avoided since it
   increases the race = condition window with flooded LSPs. This could be
   = accomplished=20 by a simple rule that only permits fed-back = information
   on the=20 original RESV, not on subsequent refreshes.

9. Intellectual = Property=20 Consideration

   The IETF has been notified of = intellectual=20 property rights claimed
   in regard to some or all of = the=20 specification contained in this
   document.  For = more=20 information consult the online list of claimed
  =20 rights.

10. Security Considerations

   This = document=20 raises no new security considerations for CR-LDP, RSVP
   = or MPLS=20 in general.

11. = Acknowledgments




Ashwood-Smith, et.=20 al.       July =20 2000        [Page 10]
Internet=20 Draft      LSP Feedback with = CR-LDP   =20 July, 2000


   The authors would like to thank = Keith=20 Dysart for his guidance, and
   Jerzy Miernik for helping = implement these concepts and bringing them
   to = life.

12.=20 References

   [CR-LDP] Constraint-Based LSP Setup = using LDP,=20 draft-ietf-mpls-cr-
   ldp-04.txt

   = [LDP] LDP=20 Specification, draft-ietf-mpls-ldp-05.txt

   [IS-IS]=20 Extensions to IS-IS for traffic engineering, = draft-ietf-
  =20 isis-traffic-01.txt

   [QUERY] MPLS LDP Query Message = Description, draft-paraschiv-mpls-
  =20 lsp-query-00.txt.

13. Author's Addresses

   = Peter=20 = Ashwood-Smith          =     =20 Bilel Jamoussi
   Nortel Networks=20 = Corp.           &n= bsp;=20 Nortel Networks Corp.
   P.O. Box 3511 Station=20 C,          600 = Technology Park=20 Drive
   Ottawa, ON K1Y=20 = 4H7           &nbs= p;   =20 Billerica, MA 01821
  =20 = Canada           &= nbsp;           &n= bsp;   =20 USA
   Phone: +1=20 = 613-763-4534          &= nbsp;=20 phone: +1 978-288-4506
  =20 = petera@nortelnetworks.com        = =20 jamoussi@nortelnetworks.com

   Darek=20 = Skalecki           = ;        =20 Don Fedyk
   Nortel Networks=20 = Corp.           &n= bsp;=20 Nortel Networks Corp.
   P.O. Box 3511 Station=20 C,          600 = Technology Park=20 Drive
   Ottawa, On K1Y=20 = 4H7           &nbs= p;   =20 Billerica, MA 01821
  =20 = Canada           &= nbsp;           &n= bsp;   =20 USA
   Phone: +1=20 = 613-765-2252          &= nbsp;=20 Phone: +1 978-228-3041
  =20 = dareks@nortelnetworks.com        = =20 dwfedyk@nortelnetworks.com


Full Copyright=20 Statement

   Copyright (C) The Internet Society = (date). All=20 Rights Reserved. This
   document and translations of it = may be=20 copied and furnished to
   others, and derivative works = that=20 comment on or otherwise explain it
   or assist in its=20 implementation may be prepared, copied, published
   and=20 distributed, in whole or in part, without restriction of = any
  =20 kind, provided that the above copyright notice and this=20 paragraph
   are included on all such copies and = derivative=20 works. However, this
   document itself may not be = modified in=20 any way, such as by removing
   the copyright notice or=20 references to the Internet Society or other
   Internet=20 organizations, except as needed for the purpose of
   = developing=20 Internet standards in which case the procedures for
   = copyrights=20 defined in the Internet Standards process must be
   = followed, or=20 as required to translate it into languages other than
  =20 English.

Ashwood-Smith, et. = al.      =20 July  2000        [Page=20 11]
Internet Draft      LSP Feedback with=20 CR-LDP    July, 2000



   The = limited=20 permissions granted above are perpetual and will not = be
  =20 revoked by the Internet Society or its successors or=20 = assigns.















<= BR>
































Ashwood= -Smith,=20 et. al.       July =20 2000        [Page=20 12]
------=_NextPart_000_0092_01C01E54.5BE69C60-- From sudheer@nayna.com Thu, 14 Sep 2000 15:12:24 -0700 Date: Thu, 14 Sep 2000 15:12:24 -0700 From: Sudheer Dharnikota sudheer@nayna.com Subject: [Isis-wg] IS-IS TE Question Hi Guys: According to our draft.. our approach to this problem is: 1. use a primary criteria to find a path 2. if it fails due to any reasons (unavailability of the resources is being one of them) then use the crankback from the previous ABR by removing the links that are failed. Note that we donot have to consider the convergence problem in this case. 3. If there are no other paths with the same characteistic then use the secondary criteria to identify the best path. No links attached to the convergence and playing with the timers. Although i agree that changes in the ABW need to be propagated sooner. Cheers, sudheer Darek Skalecki wrote: > > Matthew Kontoff wrote: > > > Darek Skalecki wrote: > > > > > > ben abarbanel wrote: > > > > > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" > > and a question came to mind regardingunreserved > > > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth > > states "for stability reasons, rapid changes in the > > > > values in this sub-TLV should not cause rapid generation of > > LSPs". > > > > You still need to regenerate and flood LSPs when an interface state > > (i.e. bandwidth) > > changes. How you do this is up to you. For example, you could > > reflood LSPs at an interval > > that could be tied to the amount of bandwidth being used. The more > > frequently LSPs > > are reflooded the closer an approximation of actual unreserved > > bandwidth in the > > network you will have. > > > > > > > > > > > > I was wondering what if 2 ingress (head end RSVP) LSR routers > > are provisioning LSPs (each wanting 100 Mbytes) > > > > through the same core convergent LSR interface and each one of > > the routers at the time they privision their LSP > > > > think there is 100 Mbyte of bandwidth free to complete the job. > > In reality there is a total of 100 MBYTE for the > > > > whole interface, the first RSVP reservation succeeds while the > > second fails. > > > > > > > The second LSP Ingress router would ask TE Source routing for > > another next bandwidth constraint best path to setup > > > > the LSP. How efficient is that if many LSPs coverge in the core > > of the network this way and there is no precise way > > > > to say what is available at the time RSVP is trigered on? > > > > > > > Also, since the IS-IS and its TE source routing engine take snap > > shots of the bandwidth resources in the network it > > > > has a tunnel view of what other IS-IS(LSR) routers are doing to > > this information at that moment in time, and are > > > > making inaccurate determination of what is reserved and what is > > free. The IS-IS route convergent time could be much > > > > slower than the RSVP signalling time. > > > > > > For CR-LDP a feedback mechanism was proposed to learn at signaling > > intervals/speed whether or not there was b/w at > > > interfaces. A snapshot of that b/w is fed into TE database based > > on which source routes are computed. With feedback, > > > if there is insufficient b/w at an interface to accomodate an LSP, > > a notification message with a feedback TLV is > > > carried towards the source. The feedback information is then input > > into TE database at source and a new route > > > computed. That route should now not contain the interface where > > there was insufficient b/w. The feedback mechanism is > > > described in: > > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > > > > Why would you need a feedback mechanism if you regenerate and flood > > IS-IS LSPs with updated TE TLVs > > that contain up to the moment (second, millisecond, whatever) > > bandwidth info? > > If your flooding interval is very short then there is no need for > feedback but you don't want to flood too frequently or else only > control traffic is running in the network and the network doesn't > scale too well. We employed feedback in a system where regular floods > were every 30 minutes, feedback updates were at path establishment > rates, i.e. feedback information was piggy-backed on top of > appropriate signaling messages. > > > > > > > > > The following is my assumption, please clarify if I am wrong, > > thanks > > > > > > > if a series of LSP requests are hitting a given IS-IS router (TE > > source routing engine) at the same processing > > > > window/cycle, it makes assignments based on a frozen snap shot > > of the bandwidth in the network. Assignments are made > > > > without consideration for their RSVP signalling success/failure > > and eventually the signalling components would fail > > > > their reservation requests causing turbulance with LSP attempts. > > > > > > > > > Assuming most of what i said is true, do we need another more > > precise mechanism to solve this? Regards, > > > > > > The feedback provides you ability to try, fail, learn and try > > again. >From our experience, a proprietary signaling > > > protocol with feedback worked just fine, i.e. convergence was fast > > (one or two tries/failures and a satisfactory route > > > was found). > > > > I agree with the 'try fail and learn again' approach but I don't > > think you need > > a separate feedback mechanism other than recent IS-IS LSPs from > > other LSRs. > > > > Matt Kontoff > > -- > Darek Skalecki > Nortel > (613) 765-2252 > > From ben.abarbanel@ipoptical.com Thu, 14 Sep 2000 20:18:30 -0400 Date: Thu, 14 Sep 2000 20:18:30 -0400 From: ben abarbanel ben.abarbanel@ipoptical.com Subject: [Isis-wg] IS-IS TE Question Hi Sudheer: Your draft/idea sounds like a good alternative. But if I understand darek's spec. They are trying to adapt the topology to bandwidth changes as quickly as possible so that the source routing engines can give the best possible answer. I agree most solutions still have that level of inaccuracy, cause the data gathering mechanism (link state flooding) is much slower than the execution (signalling) mechanism. Regards, Ben Ben Abarbanel, Software Engineering, Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ----- Original Message ----- From: "Sudheer Dharnikota" To: "Darek Skalecki" Cc: "Matthew Kontoff" ; "ben abarbanel" ; "isis-wg" Sent: Thursday, September 14, 2000 6:12 PM Subject: Re: [Isis-wg] IS-IS TE Question > Hi Guys: > > According to our draft.. our approach to this problem is: > > 1. use a primary criteria to find a path > 2. if it fails due to any reasons (unavailability of the > resources is being one of them) then use the crankback > from the previous ABR by removing the links that are > failed. Note that we donot have to consider the > convergence problem in this case. > 3. If there are no other paths with the same characteistic > then use the secondary criteria to identify the > best path. > > No links attached to the convergence and playing with the > timers. Although i agree that changes in the ABW need to > be propagated sooner. > > Cheers, > > sudheer > > Darek Skalecki wrote: > > > > Matthew Kontoff wrote: > > > > > Darek Skalecki wrote: > > > > > > > > ben abarbanel wrote: > > > > > > > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" > > > and a question came to mind regardingunreserved > > > > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth > > > states "for stability reasons, rapid changes in the > > > > > values in this sub-TLV should not cause rapid generation of > > > LSPs". > > > > > > You still need to regenerate and flood LSPs when an interface state > > > (i.e. bandwidth) > > > changes. How you do this is up to you. For example, you could > > > reflood LSPs at an interval > > > that could be tied to the amount of bandwidth being used. The more > > > frequently LSPs > > > are reflooded the closer an approximation of actual unreserved > > > bandwidth in the > > > network you will have. > > > > > > > > > > > > > > > > > I was wondering what if 2 ingress (head end RSVP) LSR routers > > > are provisioning LSPs (each wanting 100 Mbytes) > > > > > through the same core convergent LSR interface and each one of > > > the routers at the time they privision their LSP > > > > > think there is 100 Mbyte of bandwidth free to complete the job. > > > In reality there is a total of 100 MBYTE for the > > > > > whole interface, the first RSVP reservation succeeds while the > > > second fails. > > > > > > > > > The second LSP Ingress router would ask TE Source routing for > > > another next bandwidth constraint best path to setup > > > > > the LSP. How efficient is that if many LSPs coverge in the core > > > of the network this way and there is no precise way > > > > > to say what is available at the time RSVP is trigered on? > > > > > > > > > Also, since the IS-IS and its TE source routing engine take snap > > > shots of the bandwidth resources in the network it > > > > > has a tunnel view of what other IS-IS(LSR) routers are doing to > > > this information at that moment in time, and are > > > > > making inaccurate determination of what is reserved and what is > > > free. The IS-IS route convergent time could be much > > > > > slower than the RSVP signalling time. > > > > > > > > For CR-LDP a feedback mechanism was proposed to learn at signaling > > > intervals/speed whether or not there was b/w at > > > > interfaces. A snapshot of that b/w is fed into TE database based > > > on which source routes are computed. With feedback, > > > > if there is insufficient b/w at an interface to accomodate an LSP, > > > a notification message with a feedback TLV is > > > > carried towards the source. The feedback information is then input > > > into TE database at source and a new route > > > > computed. That route should now not contain the interface where > > > there was insufficient b/w. The feedback mechanism is > > > > described in: > > > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > > > > > > Why would you need a feedback mechanism if you regenerate and flood > > > IS-IS LSPs with updated TE TLVs > > > that contain up to the moment (second, millisecond, whatever) > > > bandwidth info? > > > > If your flooding interval is very short then there is no need for > > feedback but you don't want to flood too frequently or else only > > control traffic is running in the network and the network doesn't > > scale too well. We employed feedback in a system where regular floods > > were every 30 minutes, feedback updates were at path establishment > > rates, i.e. feedback information was piggy-backed on top of > > appropriate signaling messages. > > > > > > > > > > > > > The following is my assumption, please clarify if I am wrong, > > > thanks > > > > > > > > > if a series of LSP requests are hitting a given IS-IS router (TE > > > source routing engine) at the same processing > > > > > window/cycle, it makes assignments based on a frozen snap shot > > > of the bandwidth in the network. Assignments are made > > > > > without consideration for their RSVP signalling success/failure > > > and eventually the signalling components would fail > > > > > their reservation requests causing turbulance with LSP attempts. > > > > > > > > > > > > Assuming most of what i said is true, do we need another more > > > precise mechanism to solve this? Regards, > > > > > > > > The feedback provides you ability to try, fail, learn and try > > > again. >From our experience, a proprietary signaling > > > > protocol with feedback worked just fine, i.e. convergence was fast > > > (one or two tries/failures and a satisfactory route > > > > was found). > > > > > > I agree with the 'try fail and learn again' approach but I don't > > > think you need > > > a separate feedback mechanism other than recent IS-IS LSPs from > > > other LSRs. > > > > > > Matt Kontoff > > > > -- > > Darek Skalecki > > Nortel > > (613) 765-2252 > > > > From tli@Procket.com Thu, 14 Sep 2000 23:15:33 -0700 (PDT) Date: Thu, 14 Sep 2000 23:15:33 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] Simple question about IS-IS mixed domains | If you can't mix dual and non-dual routers in the same area and | have routing work for the non-OSI protocols supported (IP and IPv6), | then how can it work at Level 2 if all the Level 2 routers do not | support all the same non-OSI protocols? It seems to have the same | problem - routes will be computed through routers that do not support | the protocol of the data, just because the link costs are lowest. | | Am I missing something? If one Really Wanted to do this, then one would have to SPF independently for each protocol. Plus, because adjacency information is not carried on a per-protocol basis, you would still have the restriction that any link between two routers supporting a protocol would have to have the protocol working on that link. So for example, the link between two IPv6 routers had better be configured for IPv6. This seems like more complexity than it's worth. After all, there's only one important network layer. ;-) Tony From Internet-Drafts@ietf.org Fri, 15 Sep 2000 07:00:05 -0400 Date: Fri, 15 Sep 2000 07:00:05 -0400 From: Internet-Drafts@ietf.org Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-00.txt --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Extensions in Support of Generalized MPLS Author(s) : K. Kompella, Y. Rekhter, A. Banerjee, J. Drake, G. Bernstein, D. Fedyk, E. Mannie, D. Saha, V. Sharma Filename : draft-ietf-isis-gmpls-extensions-00.txt Pages : 11 Date : 14-Sep-00 This document specifies extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (previously known as Multi-Protocol Lambda Switching). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-00.txt 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-isis-gmpls-extensions-00.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-isis-gmpls-extensions-00.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: <20000914115817.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000914115817.I-D@ietf.org> --OtherAccess-- --NextPart-- From dareks@nortelnetworks.com Fri, 15 Sep 2000 08:49:14 -0400 Date: Fri, 15 Sep 2000 08:49:14 -0400 From: Darek Skalecki dareks@nortelnetworks.com Subject: [Isis-wg] IS-IS TE Question --------------BC2DCA0DA047B7565F1C5115 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ben abarbanel wrote: > Matthew and Darek: > I kind of like the feedback mechanism defined in > "draft-ietf-mpls-te-feed-01.txt". I think what is missing and maybe Bilel or > Darek can add it to their spec is that a timestamp be added to both the > flooded LSA/LSP TE TLV to identify when the bandwidth sample was taken. Also > the CR/LDP or RSVP-TE new TLV have a time stamp identifying when the > reservation denial and bandwidth sample was taken from the rejecting LSR. As > the message is returned to the ingress LSR its bandwidth will be overwritten > into the linkstate database, since its the most up to date information. > > I can see a race condition where IGP converging link state information might > have older data then Reservation Release/Withdrawl messages containing the > same (feedback) data. Thus its possible for the ingress LSR IGP to > momentarily over-write newer bandwidth with bad/older bandwidth into the > ingress LSR linkstate database. Ingress LSR IGP should check the timestamp > in the database with its current LSA/LSP packet and only update the > bandwidth value if it has the newer timestamp in the LSA/LSP packet. > > regards, > Ben > > Ben Abarbanel, Software Engineering, > > Phone: 703 456 2982 > FAX: 703 456 2952 > > IPOptical, Inc. > 11480 Sunset Hills Road > Suite #200E > Reston, VA 20190 Timestamping is a fine idea but in our proprietary system we simply wrote any learned information into a database, whether the information was from feedback or flooding. You are right that more-up-to-date feedback information may be then overwritten by older flooding information but in that case we may simply re-learn newer information via feedback when needed so we never implemented timestamping. Darek > > > > ----- Original Message ----- > From: "Matthew Kontoff" > To: "Darek Skalecki" > Cc: "ben abarbanel" ; "isis-wg" > > Sent: Thursday, September 14, 2000 4:08 PM > Subject: Re: [Isis-wg] IS-IS TE Question > > > > > > > Darek Skalecki wrote: > > > > > > ben abarbanel wrote: > > > > > > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a > question came to mind regardingunreserved > > > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for > stability reasons, rapid changes in the > > > > values in this sub-TLV should not cause rapid generation of LSPs". > > > > You still need to regenerate and flood LSPs when an interface state (i.e. > bandwidth) > > changes. How you do this is up to you. For example, you could reflood LSPs > at an interval > > that could be tied to the amount of bandwidth being used. The more > frequently LSPs > > are reflooded the closer an approximation of actual unreserved bandwidth > in the > > network you will have. > > > > > > > > > I was wondering what if 2 ingress (head end RSVP) LSR routers are > provisioning LSPs (each wanting 100 Mbytes) > > > > through the same core convergent LSR interface and each one of the > routers at the time they privision their LSP > > > > think there is 100 Mbyte of bandwidth free to complete the job. In > reality there is a total of 100 MBYTE for the > > > > whole interface, the first RSVP reservation succeeds while the second > fails. > > > > > > > The second LSP Ingress router would ask TE Source routing for another > next bandwidth constraint best path to setup > > > > the LSP. How efficient is that if many LSPs coverge in the core of > the network this way and there is no precise way > > > > to say what is available at the time RSVP is trigered on? > > > > > > > Also, since the IS-IS and its TE source routing engine take snap shots > of the bandwidth resources in the network it > > > > has a tunnel view of what other IS-IS(LSR) routers are doing to this > information at that moment in time, and are > > > > making inaccurate determination of what is reserved and what is free. > The IS-IS route convergent time could be much > > > > slower than the RSVP signalling time. > > > > > > For CR-LDP a feedback mechanism was proposed to learn at signaling > intervals/speed whether or not there was b/w at > > > interfaces. A snapshot of that b/w is fed into TE database based on > which source routes are computed. With feedback, > > > if there is insufficient b/w at an interface to accomodate an LSP, a > notification message with a feedback TLV is > > > carried towards the source. The feedback information is then input into > TE database at source and a new route > > > computed. That route should now not contain the interface where there > was insufficient b/w. The feedback mechanism is > > > described in: > > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > > > > Why would you need a feedback mechanism if you regenerate and flood IS-IS > LSPs with updated TE TLVs > > that contain up to the moment (second, millisecond, whatever) bandwidth > info? > > > > > > The following is my assumption, please clarify if I am wrong, thanks > > > > > > > if a series of LSP requests are hitting a given IS-IS router (TE > source routing engine) at the same processing > > > > window/cycle, it makes assignments based on a frozen snap shot of the > bandwidth in the network. Assignments are made > > > > without consideration for their RSVP signalling success/failure and > eventually the signalling components would fail > > > > their reservation requests causing turbulance with LSP attempts. > > > > > > > Assuming most of what i said is true, do we need another more precise > mechanism to solve this? Regards, > > > > > > The feedback provides you ability to try, fail, learn and try again. > >From our experience, a proprietary signaling > > > protocol with feedback worked just fine, i.e. convergence was fast (one > or two tries/failures and a satisfactory route > > > was found). > > > > I agree with the 'try fail and learn again' approach but I don't think you > need > > a separate feedback mechanism other than recent IS-IS LSPs from other > LSRs. > > > > > > Matt Kontoff > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg -- Darek Skalecki Nortel (613) 765-2252 --------------BC2DCA0DA047B7565F1C5115 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit ben abarbanel wrote:
Matthew and Darek:
  I kind of like the feedback mechanism defined in
"draft-ietf-mpls-te-feed-01.txt". I think what is missing and maybe Bilel or
Darek can add it to their spec is that a timestamp be added to both the
flooded LSA/LSP TE TLV to identify when the bandwidth sample was taken. Also
the CR/LDP or RSVP-TE new TLV have a time stamp identifying when the
reservation denial and bandwidth sample was taken from the rejecting LSR. As
the message is returned to the ingress LSR its bandwidth will be overwritten
into the linkstate database, since its the most up to date information.

I can see a race condition where IGP converging link state information might
have older data then Reservation Release/Withdrawl messages containing the
same (feedback) data. Thus its possible for the ingress LSR IGP to
momentarily over-write newer bandwidth with bad/older bandwidth into the
ingress LSR linkstate database. Ingress LSR IGP should check the timestamp
in the database with its current LSA/LSP packet and only update the
bandwidth value if it has the newer timestamp in the LSA/LSP packet.

regards,
Ben

Ben Abarbanel,  Software Engineering,

Phone:  703 456 2982
FAX:      703 456 2952

IPOptical, Inc.
11480 Sunset Hills Road
Suite #200E
Reston, VA 20190

Timestamping is a fine idea but in our proprietary system we simply wrote any learned  information into a database,
whether the information was from feedback or flooding. You are right that more-up-to-date feedback information
may be then overwritten by older flooding information but in that case we may  simply re-learn newer information via feedback when needed so we never implemented timestamping.

Darek

 
 

----- Original Message -----
From: "Matthew Kontoff" <Mkontoff@Kontoff.com>
To: "Darek Skalecki" <dareks@nortelnetworks.com>
Cc: "ben abarbanel" <ben.abarbanel@ipoptical.com>; "isis-wg"
<isis-wg@spider.juniper.net>
Sent: Thursday, September 14, 2000 4:08 PM
Subject: Re: [Isis-wg] IS-IS TE Question

>
>
> Darek Skalecki wrote:
> >
> > ben abarbanel wrote:
> >
> > > I was reading the latest draft "draft-ietf-isis-traffic-02.txt" and a
question came to mind regardingunreserved
> > > bandwidth. In section 5.4 SUB-TLV 11: Unreserved bandwidth states "for
stability reasons, rapid changes in the
> > > values in this sub-TLV should not cause rapid generation of LSPs".
>
> You still need to regenerate and flood LSPs when an interface state (i.e.
bandwidth)
> changes. How you do this is up to you. For example, you could reflood LSPs
at an interval
> that could be tied to the amount of bandwidth being used. The more
frequently LSPs
> are reflooded the closer an approximation of actual unreserved bandwidth
in the
> network you will have.
>
> >
> > > I was wondering what if  2 ingress (head end RSVP) LSR routers are
provisioning LSPs (each wanting 100 Mbytes)
> > > through the same core convergent LSR interface and each one of the
routers at the time they privision their LSP
> > > think there is 100 Mbyte of bandwidth free to complete the job. In
reality there is a total of 100 MBYTE for the
> > > whole interface, the first RSVP reservation succeeds while the second
fails.
> >
> > > The second LSP Ingress router would ask TE Source routing for another
next bandwidth constraint best path to setup
> > > the LSP.  How efficient is that if many LSPs coverge in the core of
the network this way and there is no precise way
> > > to say what is available at the time RSVP is trigered on?
> >
> > > Also, since the IS-IS and its TE source routing engine take snap shots
of the bandwidth resources in the network it
> > > has a tunnel view of what other IS-IS(LSR) routers are doing to this
information at that moment in time, and are
> > > making inaccurate determination of what is reserved and what is free.
The IS-IS route convergent time could be much
> > > slower than the RSVP signalling time.
> >
> > For CR-LDP a feedback mechanism was proposed to learn at signaling
intervals/speed whether or not there was b/w at
> > interfaces. A snapshot of that b/w is fed into TE database based on
which source routes are computed. With feedback,
> > if there is insufficient b/w at an interface to accomodate an LSP, a
notification message with a feedback TLV is
> > carried towards the source. The feedback information is then input into
TE database at source and a new route
> > computed. That route should now not contain the interface where there
was insufficient b/w. The feedback mechanism is
> > described in:
> > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt
>
> Why would you need a feedback mechanism if you regenerate and flood IS-IS
LSPs with updated TE TLVs
> that contain up to the moment (second, millisecond, whatever) bandwidth
info?
>
> > > The following is my assumption, please clarify if I am wrong, thanks
> >
> > > if a series of LSP requests are hitting a given IS-IS router (TE
source routing engine) at the same processing
> > > window/cycle, it makes assignments based on a frozen snap shot of the
bandwidth in the network. Assignments are made
> > > without consideration for their RSVP signalling success/failure and
eventually the signalling components would fail
> > > their reservation requests causing turbulance with LSP attempts.
> >
> > > Assuming most of what i said is true, do we need another more precise
mechanism to solve this? Regards,
> >
> > The feedback provides you ability to try, fail, learn and try again.
>From our experience, a proprietary signaling
> > protocol with feedback worked just fine, i.e. convergence was fast (one
or two tries/failures and a satisfactory route
> > was found).
>
> I agree with the 'try fail and learn again' approach but I don't think you
need
> a separate feedback mechanism other than recent IS-IS LSPs from other
LSRs.
>
>
> Matt Kontoff
>
> _______________________________________________
> Isis-wg mailing list  -  Isis-wg@external.juniper.net
> http://external.juniper.net/mailman/listinfo/isis-wg

-- 
Darek Skalecki
Nortel 
(613) 765-2252
  --------------BC2DCA0DA047B7565F1C5115-- From dwfedyk@nortelnetworks.com Fri, 15 Sep 2000 10:30:16 -0400 Date: Fri, 15 Sep 2000 10:30:16 -0400 From: Don Fedyk dwfedyk@nortelnetworks.com Subject: [Isis-wg] IS-IS TE Question This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C01F21.77860EB0 Content-Type: text/plain; charset="iso-8859-1" All Just to add one thing to the time stamping idea. We do not consider it necessary since the database is still really maintained by the IGP flood. (Which does not use timestamps but sequence numbers). The feedback is more targeted information that is used in the interim. Although there are small windows of opportunities for the feedback to be miss ordered this is still leagues ahead of not having feedback. By the way, the most likely misordering is an old LSP (LSA) announcing more bandwidth than actually exists and overwriting a feedback message that has reported less bandwidth. This could result in a LSP signaling that has to learn from feedback again. (We prefer to deal with the timing issues not pray they will not happen!). Relying on timestamps or sequence numbers for feedback requires synchronization between peers and designers of IGPs have way more years of experience and code to deal with this. Don -----Original Message----- From: Skalecki, Darek [CAR:CS56:EXCH] Sent: Friday, September 15, 2000 8:49 AM To: ben abarbanel Cc: Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH]; Fedyk, Don [BL60:9553:EXCH]; Jamoussi, Bilel [BL3:T823-M:EXCH] Subject: Re: [Isis-wg] IS-IS TE Question ben abarbanel wrote: Matthew and Darek: I kind of like the feedback mechanism defined in "draft-ietf-mpls-te-feed-01.txt". I think what is missing and maybe Bilel or Darek can add it to their spec is that a timestamp be added to both the flooded LSA/LSP TE TLV to identify when the bandwidth sample was taken. Also the CR/LDP or RSVP-TE new TLV have a time stamp identifying when the reservation denial and bandwidth sample was taken from the rejecting LSR. As the message is returned to the ingress LSR its bandwidth will be overwritten into the linkstate database, since its the most up to date information. I can see a race condition where IGP converging link state information might have older data then Reservation Release/Withdrawl messages containing the same (feedback) data. Thus its possible for the ingress LSR IGP to momentarily over-write newer bandwidth with bad/older bandwidth into the ingress LSR linkstate database. Ingress LSR IGP should check the timestamp in the database with its current LSA/LSP packet and only update the bandwidth value if it has the newer timestamp in the LSA/LSP packet. regards, Ben Ben Abarbanel, Software Engineering, Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 Timestamping is a fine idea but in our proprietary system we simply wrote any learned information into a database, whether the information was from feedback or flooding. You are right that more-up-to-date feedback information may be then overwritten by older flooding information but in that case we may simply re-learn newer information via feedback when needed so we never implemented timestamping. Darek -- Darek Skalecki Nortel (613) 765-2252 ------_=_NextPart_001_01C01F21.77860EB0 Content-Type: text/html; charset="iso-8859-1"
All
 
Just to add one thing to the time stamping idea. We do not consider it necessary since
the database is still really maintained by the IGP flood. (Which does not use timestamps
but sequence numbers). The feedback is more targeted information that is used in the
interim. Although there are small windows of opportunities for the feedback to be miss ordered
this is still leagues ahead of not having feedback. By the way, the most likely misordering is an
old LSP (LSA) announcing more bandwidth than actually exists and overwriting a feedback message
that has reported less bandwidth. This could result in a LSP signaling that has to learn from feedback
again. (We prefer to deal with the timing issues not pray they will not happen!).
Relying on timestamps or sequence numbers for feedback requires synchronization between peers
and designers of IGPs have way more years of experience and code to deal with this.
 
Don
 
 
 -----Original Message-----
From: Skalecki, Darek [CAR:CS56:EXCH]
Sent: Friday, September 15, 2000 8:49 AM
To: ben abarbanel
Cc: Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH]; Fedyk, Don [BL60:9553:EXCH]; Jamoussi, Bilel [BL3:T823-M:EXCH]
Subject: Re: [Isis-wg] IS-IS TE Question

ben abarbanel wrote:
Matthew and Darek:
  I kind of like the feedback mechanism defined in
"draft-ietf-mpls-te-feed-01.txt". I think what is missing and maybe Bilel or
Darek can add it to their spec is that a timestamp be added to both the
flooded LSA/LSP TE TLV to identify when the bandwidth sample was taken. Also
the CR/LDP or RSVP-TE new TLV have a time stamp identifying when the
reservation denial and bandwidth sample was taken from the rejecting LSR. As
the message is returned to the ingress LSR its bandwidth will be overwritten
into the linkstate database, since its the most up to date information.

I can see a race condition where IGP converging link state information might
have older data then Reservation Release/Withdrawl messages containing the
same (feedback) data. Thus its possible for the ingress LSR IGP to
momentarily over-write newer bandwidth with bad/older bandwidth into the
ingress LSR linkstate database. Ingress LSR IGP should check the timestamp
in the database with its current LSA/LSP packet and only update the
bandwidth value if it has the newer timestamp in the LSA/LSP packet.

regards,
Ben

Ben Abarbanel,  Software Engineering,

Phone:  703 456 2982
FAX:      703 456 2952

IPOptical, Inc.
11480 Sunset Hills Road
Suite #200E
Reston, VA 20190

Timestamping is a fine idea but in our proprietary system we simply wrote any learned  information into a database,
whether the information was from feedback or flooding. You are right that more-up-to-date feedback information
may be then overwritten by older flooding information but in that case we may  simply re-learn newer information via feedback when needed so we never implemented timestamping.

Darek

 

-- 
Darek Skalecki
Nortel 
(613) 765-2252
 
------_=_NextPart_001_01C01F21.77860EB0-- From cmj@3Com.com Fri, 15 Sep 2000 10:47:07 -0700 Date: Fri, 15 Sep 2000 10:47:07 -0700 From: Cyndi Jung cmj@3Com.com Subject: [Isis-wg] Simple question about IS-IS mixed domains Of course, there is really only one important network layer, IP, but it has taken over the only routing protocol that CLNP ever had :-) So, it's most prevalent use is in IP-only networks, or purely dual domains. In fact, without the SPF per-protocol (assuming there were some information in the LSPs that they could use to imply the missing Supported Protocol field), a "mixed" domain is a misconfiguration, just as a mixed area is. Cyndi At 11:15 PM 9/14/00 -0700, Tony Li wrote: > > | If you can't mix dual and non-dual routers in the same area and > | have routing work for the non-OSI protocols supported (IP and IPv6), > | then how can it work at Level 2 if all the Level 2 routers do not > | support all the same non-OSI protocols? It seems to have the same > | problem - routes will be computed through routers that do not support > | the protocol of the data, just because the link costs are lowest. > | > | Am I missing something? > > >If one Really Wanted to do this, then one would have to SPF independently >for each protocol. > >Plus, because adjacency information is not carried on a per-protocol basis, >you would still have the restriction that any link between two routers >supporting a protocol would have to have the protocol working on that >link. So for example, the link between two IPv6 routers had better be >configured for IPv6. > >This seems like more complexity than it's worth. After all, there's only >one important network layer. ;-) > >Tony > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > > From ben.abarbanel@ipoptical.com Fri, 15 Sep 2000 14:30:50 -0400 Date: Fri, 15 Sep 2000 14:30:50 -0400 From: ben abarbanel ben.abarbanel@ipoptical.com Subject: [Isis-wg] IS-IS TE Question This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C01F21.8C0FC740 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Don: Comments below Ben Ben Abarbanel, Software Engineering, =20 Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ----- Original Message -----=20 From: Don Fedyk=20 To: Darek Skalecki ; ben abarbanel=20 Cc: Matthew Kontoff ; isis-wg ; Peter Ashwood-Smith ; Bilel Jamoussi=20 Sent: Friday, September 15, 2000 10:30 AM Subject: RE: [Isis-wg] IS-IS TE Question All =20 Just to add one thing to the time stamping idea. We do not consider it = necessary since=20 the database is still really maintained by the IGP flood. (Which does = not use timestamps but sequence numbers). The feedback is more targeted information that = is used in the=20 interim. Although there are small windows of opportunities for the = feedback to be miss ordered=20 this is still leagues ahead of not having feedback. By the way, the = most likely misordering is an old LSP (LSA) announcing more bandwidth than actually exists and = overwriting a feedback message that has reported less bandwidth. This could result in a LSP signaling = that has to learn from feedback=20 again. (We prefer to deal with the timing issues not pray they will = not happen!). Relying on timestamps or sequence numbers for feedback requires = synchronization between peers=20 and designers of IGPs have way more years of experience and code to = deal with this. =20 I only mentioned timestamp cause I did not think we can use the IGP = sequence number as it is picked for IGP flooding for LSP signalling. The timestamp is only relevent to the = router that is originating the LSA/LSP=20 so there is no synchronization requirements between peers/neighbors. = I think eventually the IGP flooding mechanism=20 will adjust to the correct value, but in the interim the routers in = the domain could drift of actual capacities and thus create more LSP reservation failures. It would be nice to cover this = hole no matter how small with a solution in the specification and leave it up to the implementor to choose. I = guess since you guys went this far in trying to close down the inaccuracies between the routers in the domain. Regards, Ben =20 -----Original Message----- From: Skalecki, Darek [CAR:CS56:EXCH]=20 Sent: Friday, September 15, 2000 8:49 AM To: ben abarbanel Cc: Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH]; = Fedyk, Don [BL60:9553:EXCH]; Jamoussi, Bilel [BL3:T823-M:EXCH] Subject: Re: [Isis-wg] IS-IS TE Question ben abarbanel wrote:=20 Matthew and Darek:=20 I kind of like the feedback mechanism defined in=20 "draft-ietf-mpls-te-feed-01.txt". I think what is missing and = maybe Bilel or=20 Darek can add it to their spec is that a timestamp be added to = both the=20 flooded LSA/LSP TE TLV to identify when the bandwidth sample was = taken. Also=20 the CR/LDP or RSVP-TE new TLV have a time stamp identifying when = the=20 reservation denial and bandwidth sample was taken from the = rejecting LSR. As=20 the message is returned to the ingress LSR its bandwidth will be = overwritten=20 into the linkstate database, since its the most up to date = information.=20 I can see a race condition where IGP converging link state = information might=20 have older data then Reservation Release/Withdrawl messages = containing the=20 same (feedback) data. Thus its possible for the ingress LSR IGP to = momentarily over-write newer bandwidth with bad/older bandwidth = into the=20 ingress LSR linkstate database. Ingress LSR IGP should check the = timestamp=20 in the database with its current LSA/LSP packet and only update = the=20 bandwidth value if it has the newer timestamp in the LSA/LSP = packet.=20 regards,=20 Ben=20 Ben Abarbanel, Software Engineering,=20 Phone: 703 456 2982=20 FAX: 703 456 2952=20 IPOptical, Inc.=20 11480 Sunset Hills Road=20 Suite #200E=20 Reston, VA 20190 Timestamping is a fine idea but in our proprietary system we simply = wrote any learned information into a database,=20 whether the information was from feedback or flooding. You are right = that more-up-to-date feedback information=20 may be then overwritten by older flooding information but in that = case we may simply re-learn newer information via feedback when needed = so we never implemented timestamping.=20 Darek=20 --=20 Darek Skalecki Nortel=20 (613) 765-2252 =20 ------=_NextPart_000_0029_01C01F21.8C0FC740 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Don:
 Comments below
 
Ben
 
 
Ben Abarbanel,  Software Engineering, 
 
Phone:  703 456 2982
FAX:      703 = 456=20 2952
 
IPOptical, Inc.
11480 Sunset Hills Road
Suite = #200E
Reston, VA=20 20190
----- Original Message -----
From:=20 Don Fedyk
To: Darek=20 Skalecki ; ben abarbanel
Cc: Matthew Kontoff ; isis-wg ; Peter=20 Ashwood-Smith ; Bilel Jamoussi
Sent: Friday, September 15, = 2000 10:30=20 AM
Subject: RE: [Isis-wg] IS-IS TE = Question

All
 
Just=20 to add one thing to the time stamping idea. We do not consider it = necessary=20 since
the database is still really maintained by the = IGP flood.=20 (Which does not use timestamps
but=20 sequence numbers). The feedback is more targeted information that is = used in=20 the
interim. Although there are small windows of = opportunities=20 for the feedback to be miss ordered
this=20 is still leagues ahead of not having feedback. By the way, the most = likely=20 misordering is an
old LSP (LSA) announcing more bandwidth than = actually exists=20 and overwriting a feedback message
that has reported less bandwidth. This could = result in a LSP=20 signaling that has to learn from feedback
again. (We prefer to deal with the timing issues = not pray=20 they will not happen!).
Relying on timestamps or sequence numbers=20 for feedback requires synchronization between = peers=20
and=20 designers of IGPs have way more years of experience and code to deal = with=20 this.
 
I only mentioned timestamp cause I = did not think=20 we can use the IGP sequence number as it is picked for
IGP flooding for LSP signalling. The = timestamp is=20 only relevent to the router that is originating the LSA/LSP =
so there is no synchronization = requirements=20 between peers/neighbors.  I think eventually the IGP flooding = mechanism=20
will adjust to the correct value, but = in the=20 interim the routers in the domain could drift of actual capacities and = thus
create more LSP reservation failures. = It would be=20 nice to cover this hole no matter how small with a solution = in
the specification and leave it up to = the=20 implementor to choose. I guess since you guys went this far in trying = to=20 close
down the inaccuracies between = the routers in=20 the domain.
 
Regards,
Ben
 
 
 
 
 
 -----Original=20 Message-----
From: Skalecki, Darek [CAR:CS56:EXCH] =
Sent:=20 Friday, September 15, 2000 8:49 AM
To: ben = abarbanel
Cc:=20 Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH]; Fedyk, = Don=20 [BL60:9553:EXCH]; Jamoussi, Bilel [BL3:T823-M:EXCH]
Subject: = Re:=20 [Isis-wg] IS-IS TE Question

ben=20 abarbanel wrote:=20
Matthew and Darek:
  I kind of = like the=20 feedback mechanism defined in =
"draft-ietf-mpls-te-feed-01.txt". I=20 think what is missing and maybe Bilel or
Darek can add it to = their=20 spec is that a timestamp be added to both the
flooded LSA/LSP = TE TLV=20 to identify when the bandwidth sample was taken. Also
the = CR/LDP or=20 RSVP-TE new TLV have a time stamp identifying when the =
reservation=20 denial and bandwidth sample was taken from the rejecting LSR. As =
the=20 message is returned to the ingress LSR its bandwidth will be = overwritten=20
into the linkstate database, since its the most up to date=20 information.=20

I can see a race condition where IGP converging link state = information=20 might
have older data then Reservation Release/Withdrawl = messages=20 containing the
same (feedback) data. Thus its possible for the = ingress=20 LSR IGP to
momentarily over-write newer bandwidth with = bad/older=20 bandwidth into the
ingress LSR linkstate database. Ingress LSR = IGP=20 should check the timestamp
in the database with its current = LSA/LSP=20 packet and only update the
bandwidth value if it has the newer = timestamp in the LSA/LSP packet.=20

regards,
Ben=20

Ben Abarbanel,  Software Engineering,=20

Phone:  703 456 2982 =
FAX:      703=20 456 2952=20

IPOptical, Inc.
11480 Sunset Hills Road
Suite #200E =
Reston,=20 VA 20190

Timestamping is a fine idea but in our = proprietary=20 system we simply wrote any learned  information into a = database,=20
whether the information was from feedback or flooding. You are = right=20 that more-up-to-date feedback information
may be then = overwritten by=20 older flooding information but in that case we may  simply = re-learn=20 newer information via feedback when needed so we never implemented=20 timestamping.=20

Darek=20

 

-- 
Darek Skalecki
Nortel 
(613) 765-2252
  ------=_NextPart_000_0029_01C01F21.8C0FC740-- From tli@Procket.com Fri, 15 Sep 2000 15:07:56 -0700 (PDT) Date: Fri, 15 Sep 2000 15:07:56 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] IS-IS TE Question Folks, About 99% of this conversation is about signaling and crankback and not about IS-IS. Could we take it to a more appropriate mailing list, please? Thanks, Tony co-chair From ben.abarbanel@ipoptical.com Fri, 15 Sep 2000 18:35:31 -0400 Date: Fri, 15 Sep 2000 18:35:31 -0400 From: ben abarbanel ben.abarbanel@ipoptical.com Subject: [Isis-wg] IS-IS TE Question Sure, I think I am done. Ben Abarbanel, Software Engineering, Phone: 703 456 2982 FAX: 703 456 2952 IPOptical, Inc. 11480 Sunset Hills Road Suite #200E Reston, VA 20190 ----- Original Message ----- From: "Tony Li" To: "ben abarbanel" Cc: "Don Fedyk" ; "Darek Skalecki" ; "Matthew Kontoff" ; "isis-wg" ; "Peter Ashwood-Smith" ; "Bilel Jamoussi" Sent: Friday, September 15, 2000 6:07 PM Subject: Re: [Isis-wg] IS-IS TE Question > > > Folks, > > About 99% of this conversation is about signaling and crankback and not > about IS-IS. Could we take it to a more appropriate mailing list, please? > > Thanks, > Tony > co-chair > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From dwfedyk@nortelnetworks.com Fri, 15 Sep 2000 17:54:17 -0500 Date: Fri, 15 Sep 2000 17:54:17 -0500 From: Don Fedyk dwfedyk@nortelnetworks.com Subject: [Isis-wg] IS-IS TE Question This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C01F67.E03C88D0 Content-Type: text/plain; charset="iso-8859-1" Tony I am perplexed by your statement. This spreads across several groups and we get disjoint consensus. >From an IS-IS standpoint you should be concerned what scales and what does not. Feedback is in IS-IS's best interest. Are you suggesting anything that is accepted in MPLS just be rubber stamped in IS-IS? Don > -----Original Message----- > From: Tony Li [mailto:tli@Procket.com] > Sent: Friday, September 15, 2000 6:08 PM > To: ben abarbanel > Cc: Fedyk, Don [BL60:9553:EXCH]; Skalecki, Darek [CAR:CS56:EXCH]; > Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH]; > Jamoussi, Bilel [BL3:T823-M:EXCH] > Subject: Re: [Isis-wg] IS-IS TE Question > > > > > Folks, > > About 99% of this conversation is about signaling and > crankback and not > about IS-IS. Could we take it to a more appropriate mailing > list, please? > > Thanks, > Tony > co-chair > > ------_=_NextPart_001_01C01F67.E03C88D0 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] IS-IS TE Question

Tony

I am perplexed by your statement. This spreads across
several groups and we get disjoint consensus.

From an IS-IS standpoint you should be concerned what scales
and what does not. Feedback is in IS-IS's best interest.
Are you suggesting anything that is accepted in MPLS just
be rubber stamped in IS-IS?

Don


> -----Original Message-----
> From: Tony Li [mailto:tli@Procket.com]
> Sent: Friday, September 15, 2000 6:08 PM
> To: ben abarbanel
> Cc: Fedyk, Don [BL60:9553:EXCH]; Skalecki, Darek [CAR:CS56:EXCH];
> Matthew Kontoff; isis-wg; Ashwood-Smith, Peter [CAR:CS57:EXCH];
> Jamoussi, Bilel [BL3:T823-M:EXCH]
> Subject: Re: [Isis-wg] IS-IS TE Question
>
>
>
>
> Folks,
>
> About 99% of this conversation is about signaling and
> crankback and not
> about IS-IS.  Could we take it to a more appropriate mailing
> list, please?
>
> Thanks,
> Tony
> co-chair
>
>

------_=_NextPart_001_01C01F67.E03C88D0-- From rja@extremenetworks.com Fri, 15 Sep 2000 19:04:39 -0400 Date: Fri, 15 Sep 2000 19:04:39 -0400 From: RJ Atkinson rja@extremenetworks.com Subject: [Isis-wg] IS-IS TE Question At 18:54 15/09/00, Don Fedyk wrote: Don, Going forward,could you kindly send mail to IETF lists using plain-text ASCII rather than some fancy format as you just did ? A lot of us are NOT using MS-Outlook and at least some folks are on low-bandwidth connectivity, so using IETF standard US-ASCII (or ISO-8859-N) in text/plain format is customary on all IETF mailing lists. Thanks very much, Ran rja@inet.org From vikram_isis@hotmail.com Tue, 19 Sep 2000 01:39:06 GMT Date: Tue, 19 Sep 2000 01:39:06 GMT From: vikram isis vikram_isis@hotmail.com Subject: [Isis-wg] DIS election question??? Hi, I just have question on DIS election. Assuming, an unintended DIS(less capacity or something) is elected, due to misconfiguration of priority or by virtue of its mac address. And that, it is unable to bear the load and submits to another DIS (less priority or low MAC address) in the next DRHold Interval. When its less loaded, is elected again as the DIS and the ping pong between DISs continue. Is there a mechanism by which the DIS which is stable can stick around by distributed/centralised mechanism for a certain period? Any insight would be helpful. Thanks Vikram _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From dkatz@juniper.net Mon, 18 Sep 2000 18:46:49 -0700 (PDT) Date: Mon, 18 Sep 2000 18:46:49 -0700 (PDT) From: Dave Katz dkatz@juniper.net Subject: [Isis-wg] DIS election question??? Use the priority mechanism. X-Originating-IP: [209.58.11.227] From: "vikram isis" Date: Tue, 19 Sep 2000 01:39:06 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 19 Sep 2000 01:39:06.0616 (UTC) FILETIME=[661D5780:01C021DA] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Hi, I just have question on DIS election. Assuming, an unintended DIS(less capacity or something) is elected, due to misconfiguration of priority or by virtue of its mac address. And that, it is unable to bear the load and submits to another DIS (less priority or low MAC address) in the next DRHold Interval. When its less loaded, is elected again as the DIS and the ping pong between DISs continue. Is there a mechanism by which the DIS which is stable can stick around by distributed/centralised mechanism for a certain period? Any insight would be helpful. Thanks Vikram _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From ashish_b_mehta@hotmail.com Thu, 05 Oct 2000 20:45:55 GMT Date: Thu, 05 Oct 2000 20:45:55 GMT From: Ashish Mehta ashish_b_mehta@hotmail.com Subject: [Isis-wg] Complete sequence number packets Hi all, I am new member of this mailing list and had some issues with the complete sequence number PDU received from Juniper box. As per ISO 10589 standard, the SourceID in the CSNP header is ID Length + 1, where Source ID is the system ID of Intermidiate System(with zero Cicuit ID) generating this Sequence Number PDU. I have set up the following ISO NET address on the interface configured for ISIS 49.0001.00a0.c96b.c490.00. When I receive the packet I get following from the SourceID. srcid[0] 0x0 srcid[1] 0xa0 srcid[2] 0xc9 srcid[3] 0x6b srcid[4] 0xc4 srcid[5] 0x90 srcid[6] 0x2 If you see the last byte is 0x2 insted of 0x0. An update on this issue will be appreciated. Thanks. -Ashish _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From tli@Procket.com Thu, 5 Oct 2000 15:21:29 -0700 (PDT) Date: Thu, 5 Oct 2000 15:21:29 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] Complete sequence number packets Sounds to me like the guy who did Juniper's IS-IS implementation bcopy'ed the system ID and forgot to zero the circuit ID. Not too surprising, I know him and he's an idiot. ;-) In any case, this is clearly a case for Juniper technical support, not an IETF issue. Thanks, Tony Ashish Mehta writes: | Hi all, | | I am new member of this mailing list and had some issues with the | complete sequence number PDU received from Juniper box. As per ISO 10589 | standard, the SourceID in the CSNP header is ID Length + 1, where Source | ID is the system ID of Intermidiate System(with zero Cicuit ID) | generating this Sequence Number PDU. | | I have set up the following ISO NET address on the interface | configured for ISIS 49.0001.00a0.c96b.c490.00. When I receive the packet | I get following from the SourceID. | | srcid[0] | 0x0 | srcid[1] | 0xa0 | srcid[2] | 0xc9 | srcid[3] | 0x6b | srcid[4] | 0xc4 | srcid[5] | 0x90 | srcid[6] | 0x2 | | If you see the last byte is 0x2 insted of 0x0. | An update on this issue will be appreciated. | | Thanks. | | -Ashish | | _________________________________________________________________________ | Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. | | Share information about yourself, create your own public profile at | http://profiles.msn.com. | | | | _______________________________________________ | Isis-wg mailing list - Isis-wg@external.juniper.net | http://external.juniper.net/mailman/listinfo/isis-wg | | _______________________________________________ | Isis-wg-external mailing list | Isis-wg-external@mailist.procket.com | http://mailist.procket.com/mailman/listinfo/isis-wg-external From azinin@cisco.com Mon, 9 Oct 2000 18:21:25 -0700 Date: Mon, 9 Oct 2000 18:21:25 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] draft-ietf-zinin-flood-opt-01.txt Folks, The new version of the flooding optimization draft has been submitted to the IETF directories today. So far, it is available at the following URL: http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-01.txt Regards, -- Alex Zinin From azinin@cisco.com Tue, 10 Oct 2000 11:19:23 -0700 Date: Tue, 10 Oct 2000 11:19:23 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt Thanks, Jim. Regarding the fully meshed topo's. To begin with, I'm not a big fan (gently put) of "optimizing" dynamic algorithms with some manually configured stuff... So, for me personally, the mesh group in ISIS and LSA blocking in OSPF (yes, we have it implemented) is not an option (again, it's just my opinion). As far as automated algorithms are concerned, pure spanning flooding tree over the topo graph is a non-starter, I think. Redundant spanning tree may not be worth spending time since a) regions with highly redundant topology (like fully meshed groups) may be addressed more optimally, I guess, and b) not so redundant regions may not be interesting... We could discuss this, actually, with the first question being "do we really need this" ? ;) Cheers, -- Alex Zinin Tuesday, October 10, 2000, 2:48 AM, Jim Boyle wrote: > this is very good for addressing how to optimize flooding w/ multiple > links between two nodes. > How can a fully meshed topology w/ on the order of 1 link between each > node be addressed (I'm not sure how mesh groups work). > I've heard of a hack that limits flooding from N^2 to more like 6N > so there is an adjacency/forwarding topology and a flooding topology > This could be useful with either manual configuration like "no > ospf flood" or via automated pruning to a certain level of adjacency (even > with SRLGs taken into account, perhaps). > regards, > Jim > p.s. - pruned mpls wg > On Mon, 9 Oct 2000, Alex Zinin wrote: >> >> Folks, >> >> The new version of the flooding optimization draft >> has been submitted to the IETF directories today. >> >> So far, it is available at the following URL: >> >> http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-01.txt >> >> Regards, >> -- >> Alex Zinin >> From tli@Procket.com Tue, 10 Oct 2000 11:42:27 -0700 (PDT) Date: Tue, 10 Oct 2000 11:42:27 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt | We could discuss this, actually, with the first question being | "do we really need this" ? ;) IM(ns)HO, we are in dire need of a replacement flooding algorithm that scales much more nicely. It needs to adapt to the topology as end-users cannot be expected to provide us with additional configuration information about their topology. It needs to be robust in the case of failure, not causing massive pertubations of the flooding path on a single link failure. It needs to restrict the amount of flooding that any single node needs to do. Currently, my best guess is that a redundant spanning tree is the best known direction. Tony From dkatz@juniper.net Tue, 10 Oct 2000 11:51:08 -0700 (PDT) Date: Tue, 10 Oct 2000 11:51:08 -0700 (PDT) From: Dave Katz dkatz@juniper.net Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt I concur. The mesh group hack is just that, a hack. It saved our bacon in a pinch. The fact that it's been documented is a little embarassing. I tried to hide the awful truth, but I was exposed. Oh, well. ;-) IM(ns)HO, we are in dire need of a replacement flooding algorithm that scales much more nicely. It needs to adapt to the topology as end-users cannot be expected to provide us with additional configuration information about their topology. It needs to be robust in the case of failure, not causing massive pertubations of the flooding path on a single link failure. It needs to restrict the amount of flooding that any single node needs to do. From jboyle@Level3.net Tue, 10 Oct 2000 15:36:39 -0600 (MDT) Date: Tue, 10 Oct 2000 15:36:39 -0600 (MDT) From: Jim Boyle jboyle@Level3.net Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt I don't know. Imagine a 1000xOC192 router, and a service provider using it in say, 100 markets. You are going to get some meshing here. As for parallel links between two nodes, bundle the links if possible, if not (e.g. some go N some go S) - you're draft sounds good for that portion of the flooding. However, you are still left w/ a full mesh (or close) topology - perhaps one that isn't as bad as some of the ATM meshes of yesteryear, and processors are much faster today, so... maybe it's not worth it. Then again..... maybe that big old router doesn't want to deal w/ making 100 copies of the LSA, or checking the 100 or so he gets echo'd back. I just hope there aren't cases where that mesh loses, for instance, 25% of it's links, affecting 75% of the routers. Hmmm... 75 routers, 75 LSAs, 75-100 to flood (to non-affected adjacencies), that's 75^2 before we even get to the echo. Then again.... with link bundling, infinitely huge routers, dirt cheap router ports (and OEO), maybe we can pull all IP traffic through most routers, even if it's transit. Then with a simple topology, we have no worries. Jim On Tue, 10 Oct 2000, Alex Zinin wrote: > > Thanks, Jim. > > Regarding the fully meshed topo's. > > To begin with, I'm not a big fan (gently put) of "optimizing" > dynamic algorithms with some manually configured stuff... > So, for me personally, the mesh group in ISIS and LSA blocking > in OSPF (yes, we have it implemented) is not an option (again, > it's just my opinion). > > As far as automated algorithms are concerned, pure spanning > flooding tree over the topo graph is a non-starter, I think. > Redundant spanning tree may not be worth spending time since > a) regions with highly redundant topology (like fully meshed groups) > may be addressed more optimally, I guess, and b) not so redundant > regions may not be interesting... > > We could discuss this, actually, with the first question being > "do we really need this" ? ;) > > Cheers, > > -- > Alex Zinin > > Tuesday, October 10, 2000, 2:48 AM, Jim Boyle wrote: > > > > this is very good for addressing how to optimize flooding w/ multiple > > links between two nodes. > > > How can a fully meshed topology w/ on the order of 1 link between each > > node be addressed (I'm not sure how mesh groups work). > > > I've heard of a hack that limits flooding from N^2 to more like 6N > > so there is an adjacency/forwarding topology and a flooding topology > > This could be useful with either manual configuration like "no > > ospf flood" or via automated pruning to a certain level of adjacency (even > > with SRLGs taken into account, perhaps). > > > regards, > > > Jim > > > p.s. - pruned mpls wg > > > On Mon, 9 Oct 2000, Alex Zinin wrote: > > >> > >> Folks, > >> > >> The new version of the flooding optimization draft > >> has been submitted to the IETF directories today. > >> > >> So far, it is available at the following URL: > >> > >> http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-01.txt > >> > >> Regards, > >> -- > >> Alex Zinin > >> > From rfc-ed@ISI.EDU Wed, 11 Oct 2000 11:59:09 -0700 Date: Wed, 11 Oct 2000 11:59:09 -0700 From: RFC Editor rfc-ed@ISI.EDU Subject: [Isis-wg] RFC 2973 on IS-IS Mesh Groups --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2973 Title: IS-IS Mesh Groups Author(s): R. Balay, D. Katz, J. Parker Status: Informational Date: October 2000 Mailbox: Rajesh.Balay@cosinecom.com, jparker@axiowave.com, jparker@nexabit.com Pages: 8 Characters: 14846 Updates/Obsoletes/SeeAlso: none I-D Tag: draft-ietf-isis-wg-mesh-group-01.txt URL: ftp://ftp.isi.edu/in-notes/rfc2973.txt This document describes a mechanism to reduce redundant packet transmissions for the Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. The described mechanism can be used to reduce the flooding of Link State PDUs (Protocol Data Units) (LSPs) in IS-IS topologies. The net effect is to engineer a flooding topology for LSPs which is a subset of the physical topology. This document serves to document the existing behavior in deployed implementations. The document describes behaviors that are backwards compatible with implementations that do not support this feature. This document is a product of the IS-IS for IP Internets Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <001011115719.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2973 --OtherAccess Content-Type: Message/External-body; name="rfc2973.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <001011115719.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From jboyle@Level3.net Tue, 10 Oct 2000 03:48:16 -0600 (MDT) Date: Tue, 10 Oct 2000 03:48:16 -0600 (MDT) From: Jim Boyle jboyle@Level3.net Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt this is very good for addressing how to optimize flooding w/ multiple links between two nodes. How can a fully meshed topology w/ on the order of 1 link between each node be addressed (I'm not sure how mesh groups work). I've heard of a hack that limits flooding from N^2 to more like 6N so there is an adjacency/forwarding topology and a flooding topology This could be useful with either manual configuration like "no ospf flood" or via automated pruning to a certain level of adjacency (even with SRLGs taken into account, perhaps). regards, Jim p.s. - pruned mpls wg On Mon, 9 Oct 2000, Alex Zinin wrote: > > Folks, > > The new version of the flooding optimization draft > has been submitted to the IETF directories today. > > So far, it is available at the following URL: > > http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-01.txt > > Regards, > -- > Alex Zinin > From rfc-ed@ISI.EDU Wed, 11 Oct 2000 11:56:52 -0700 Date: Wed, 11 Oct 2000 11:56:52 -0700 From: RFC Editor rfc-ed@ISI.EDU Subject: [Isis-wg] RFC 2966 on Domain-wide Prefix Distribution --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2966 Title: Domain-wide Prefix Distribution with Two-Level IS-IS Author(s): T. Li, T. Przygienda, H. Smit Status: Informational Date: October 2000 Mailbox: tli@procket.com, prz@redback.com, henk@procket.com Pages: 14 Characters: 32465 Updates/Obsoletes/SeeAlso: none I-D Tag: draft-ietf-isis-domain-wide-03.txt URL: ftp://ftp.isi.edu/in-notes/rfc2966.txt This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195. This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) [routers] can distribute IP prefixes between level 1 and level 2 and vice versa. This distribution requires certain restrictions to insure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. This document is a product of the IS-IS for IP Internets Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <001011115456.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2966 --OtherAccess Content-Type: Message/External-body; name="rfc2966.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <001011115456.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From azinin@cisco.com Wed, 11 Oct 2000 17:43:56 -0700 Date: Wed, 11 Oct 2000 17:43:56 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt Tony: > | We could discuss this, actually, with the first question being > | "do we really need this" ? ;) > IM(ns)HO, we are in dire need of a replacement flooding algorithm that > scales much more nicely. I don't really like that "replacement" word ;), but I agree we may need to modify the algo in some places... > It needs to adapt to the topology as end-users cannot be expected to > provide us with additional configuration information about their topology. Agree. > It needs to be robust in the case of failure, not causing massive > pertubations of the flooding path on a single link failure. Agree. > It needs to restrict the amount of flooding that any single node needs to > do. Not sure what you mean here... > Currently, my best guess is that a redundant spanning tree is the best > known direction. If there are enough interested parties, we could create a design group made of ISIS and OSPF guys and consider possible options. Alex. From tli@Procket.com Wed, 11 Oct 2000 18:07:52 -0700 (PDT) Date: Wed, 11 Oct 2000 18:07:52 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt | > It needs to restrict the amount of flooding that any single node needs to | > do. | | Not sure what you mean here... Think about the amount of replication that a single node needs to perform. Imagine that you have a network of tens of thousands of routers that are fully meshed on a L2 fabric. All of the other requirements as specified might result in a single node being selected as the replication engine and it having to transmit each LSP/LSA tens of thousands of times. This does not scale. However, hierarchy would scale. If the result is a flooding tree where each node performs a limited number of replications, then no processor is unduly burdened. The only question now is how much replication we would like a processor to do. More formally, what is the degree of the node in the flooding graph? Higher degree requires more processor but results in a shallower tree with lower flooding latency. Lower degree results in less work and longer latency. | > IM(ns)HO, we are in dire need of a replacement flooding algorithm that | > scales much more nicely. | | I don't really like that "replacement" word ;), but I agree we | may need to modify the algo in some places... If you can meet all of the requirements and still interoperate or even function without a flag day, that would be a genuine coup. ;-) | > Currently, my best guess is that a redundant spanning tree is the best | > known direction. | | If there are enough interested parties, we could create | a design group made of ISIS and OSPF guys and consider | possible options. I'm game. However, interest to date on this has been.... low. Tony From riad@caspiannetworks.com Wed, 11 Oct 2000 19:02:18 -0700 Date: Wed, 11 Oct 2000 19:02:18 -0700 From: Riad Hartani riad@caspiannetworks.com Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt I would support Alex's idea to create an OSPF/ISIS design group working on this problem. Reducing flooding in Link State Protocols under failure conditions is certainly a very interesting and useful problem to work on. Obviously, one of the key problems would be to remain backward compatible. There have been some attempts in the past within the ATM F to discuss some techniques to analyze/reduce flooding in PNNI (e.g. ATMF 00-0249 for problem statement). Nothing specified though. Some research has been going on as well in terms of OSPF/ISIS flooding reduction with proposals ranging from the use of broadcast servers to increased hierarchy/partitioning to preemptive acknowledgment of updates, etc. Nothing concrete at this stage. Riad > -----Original Message----- > From: Alex Zinin [mailto:azinin@cisco.com] > Sent: Wednesday, October 11, 2000 5:44 PM > To: Tony Li > Cc: Jim Boyle; ospf@discuss.microsoft.com; 'ISISWG' > Subject: Re: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt > > > > Tony: > > > | We could discuss this, actually, with the first question being > > | "do we really need this" ? ;) > > > IM(ns)HO, we are in dire need of a replacement flooding > algorithm that > > scales much more nicely. > > I don't really like that "replacement" word ;), but I agree we > may need to modify the algo in some places... > > > It needs to adapt to the topology as end-users cannot be expected to > > provide us with additional configuration information about > their topology. > > Agree. > > > It needs to be robust in the case of failure, not causing massive > > pertubations of the flooding path on a single link failure. > > Agree. > > > It needs to restrict the amount of flooding that any single > node needs to > > do. > > Not sure what you mean here... > > > Currently, my best guess is that a redundant spanning tree > is the best > > known direction. > > If there are enough interested parties, we could create > a design group made of ISIS and OSPF guys and consider > possible options. > > > Alex. > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From azinin@cisco.com Wed, 11 Oct 2000 19:16:00 -0700 Date: Wed, 11 Oct 2000 19:16:00 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt Tony: > Think about the amount of replication that a single node needs to perform. Agree. This could be *partially* be addressed with: a) good pointer-work in the code :) b) notion of "replication groups" when flooding newly installed LS{A|P}s over a bunch of interfaces. This can be "a bit" of mess, though (the keyword is "peer-groups" ;). > Imagine that you have a network of tens of thousands of routers that are > fully meshed on a L2 fabric. Sounds familiar :) > All of the other requirements as specified > might result in a single node being selected as the replication engine and > it having to transmit each LSP/LSA tens of thousands of times. Yeah... Multicast/broadcast capabilities of the L2 part would definitely help, but I agree, if we have a large number of interfaces in a box and the guy with sysadmin rights has configured them to be in one area... > This does not scale. > However, hierarchy would scale. If the result is a flooding tree where > each node performs a limited number of replications, then no processor is > unduly burdened. There's always the other part in this equation --- the number of LSAs... If we continue going the same direction (flat IGP domains, flat TE domains, etc.), we may hit the same problem later... > The only question now is how much replication we would > like a processor to do. More formally, what is the degree of the node in > the flooding graph? Higher degree requires more processor but results in a > shallower tree with lower flooding latency. Lower degree results in less > work and longer latency. Not only this is the question. We would need to assure the same level of determinism in flooding as we have today. It's definitely going to be more than just pruning the flooding topo to the tree. > | I don't really like that "replacement" word ;), but I agree we > | may need to modify the algo in some places... > If you can meet all of the requirements and still interoperate or even > function without a flag day, that would be a genuine coup. ;-) I do not think we should consider other options... > I'm game. However, interest to date on this has been.... low. Yeah... And this time, I'm not going to ask on the NANOG list :) Those who are interested or have something to say, please, speak up. So far we have Jim, Tony, Dave [if I understood him correctly ;)] and me... Alex. From tli@Procket.com Wed, 11 Oct 2000 23:04:04 -0700 (PDT) Date: Wed, 11 Oct 2000 23:04:04 -0700 (PDT) From: Tony Li tli@Procket.com Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt Alex, | Agree. | This could be *partially* be addressed with: | | a) good pointer-work in the code :) | | b) notion of "replication groups" when flooding newly installed LS{A|P}s | over a bunch of interfaces. This can be "a bit" of mess, though | (the keyword is "peer-groups" ;). With all due respect, I don't believe that these are sufficient. Even with optimal pointer work, you're maintaining a list of transmissions and retransmissions per adjacency, or a scanner and one bit per adjacency. This implies that your overhead scales linearly with the number of adjacencies, which is exactly the situation that we'd like to avoid. The "peer groups" (ala BGP) are really only of use when you have to compute the updates and can amortize the computation across the numbers of the group. | > However, hierarchy would scale. If the result is a flooding tree where | > each node performs a limited number of replications, then no processor is | > unduly burdened. | | There's always the other part in this equation --- the number of | LSAs... If we continue going the same direction (flat IGP domains, | flat TE domains, etc.), we may hit the same problem later... Correct, this would decrease the other multiplier. However, when a network operator is given the choice of restricting the growth of his network, restricting its feature set and therefore optimality or inspiring his network equipment vendor to work harder, which do you think they will prefer? Yes, that's a rhetorical question. ;-) | We would need to assure the same level of determinism in flooding as | we have today. It's definitely going to be more than just pruning | the flooding topo to the tree. I'm not sure that I understand this requirement. Are you suggesting that we need a deterministic flooding algorithm? Or that there needs to be user control over the resulting active flooding topology? Tony From azinin@cisco.com Thu, 12 Oct 2000 11:18:22 -0700 Date: Thu, 12 Oct 2000 11:18:22 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt Tony: > With all due respect, I don't believe that these are sufficient. [...] That's why I said "*partially* addressed". > | > However, hierarchy would scale. If the result is a flooding tree where > | > each node performs a limited number of replications, then no processor is > | > unduly burdened. > | > | There's always the other part in this equation --- the number of > | LSAs... If we continue going the same direction (flat IGP domains, > | flat TE domains, etc.), we may hit the same problem later... > Correct, this would decrease the other multiplier. However, when a network > operator is given the choice of restricting the growth of his network, > restricting its feature set and therefore optimality or inspiring his > network equipment vendor to work harder, which do you think they will > prefer? > Yes, that's a rhetorical question. ;-) I think I meant a bit different thing, but I won't start another discussion... ;) > | We would need to assure the same level of determinism in flooding as > | we have today. It's definitely going to be more than just pruning > | the flooding topo to the tree. > I'm not sure that I understand this requirement. Are you suggesting that > we need a deterministic flooding algorithm? Or that there needs to be user > control over the resulting active flooding topology? I mean we need to make sure the flooding algorithm (if modified) guarantees the same results in PDU delivery in the presence of arbitrary topology changes (including those killing both branches of the redundant tree), as the current one. Alex. From prz@net4u.ch Thu, 12 Oct 2000 20:58:21 +0200 (MEST) Date: Thu, 12 Oct 2000 20:58:21 +0200 (MEST) From: Tony Przygienda prz@net4u.ch Subject: [Isis-wg] test message (ignore please) just test to see whether this one gets through, looks like my messages don't get out to the list (again ;-) and I grew tired of re-typing messages trying to get them out -- tony From prz@net4u.ch Fri, 13 Oct 2000 08:47:16 +0200 (MEST) Date: Fri, 13 Oct 2000 08:47:16 +0200 (MEST) From: Tony Przygienda prz@net4u.ch Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt Here's my jest on the flooding-optimization problem: First, I think it's a good idea to get a small group of people in a room and after some high-flying discussions get some rough-cut proposal out that preferrably a Ph.D. candidate or an agressive company goes off to tinker with and comes back with implemenation results as either papers or competitive advantage. To get anything done, my opinion is that group has to be restricted to people with at least one deployed commercial link-state under their belt or serious researchers that dealt with link-state and a group of more than 15 people won't get anything done anyway ;-) BTW, I tried to encourage 2-3 candidates in last years to pick up the topic but without success. Either the topic is not sexy enough or I'm a really bad sales-guy ;-) Withough someone willing to go and do the work on gated or a commercial piece of software the topic will end up as it always ended up so far, an interesting discussion without practical implications. There was a flurry of activity on the research side about 2-3 years ago and to my knowledge 2 streams of thinking are around: one is the spanning tree on top of topology (Bala's paper is an example, convergence has been proven) algorithms are variations of 802.1 mostly or distributed Bellman-Ford, the other one, much less known is a variation of a token-passing algorithm building hierarchical trees (kind like multi-cast in PNNI, not algorithm- wise but in the sense of trees built). Some thinking was spend on building 2 redundant trees that can fall-over when first one is cut or alternatively the two sides of the tree operate independently until merged again. Not sure that has been published and if, it's a while and not in IP context. Both approaches have an obvious common underlying problem: When converging the tree, the very underlying mechanism (flooding) is being fiddled with, possibly affecting flooding-speed and therefore the convergence of the tree. So the so-formed control-loop needs to be broken or dampened somehow obviously. so who's game & when ? -- tony From prz@net4u.ch Fri, 13 Oct 2000 09:19:29 +0200 (MEST) Date: Fri, 13 Oct 2000 09:19:29 +0200 (MEST) From: Tony Przygienda prz@net4u.ch Subject: [Isis-wg] ISO ballot --ELM971421569-26217-0_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Following ballot from ISO for the working group. I honestly tried to convert the enclosed word to PDF first but mickey-soft word just died repeatedly on me so I just added the ZIP containing version 2 of the spec and the attached ballot. I know it's humongeous and some people downloading through slow phone lines will hate me but I couldn't think of a better way to get it out. Looks like the ballot is open to the whole working group so everybody goes ahead and posts input to the list and Tony & me will summarize to ISO I guess ... thanks -- tony ------------------------------------------- Telecommunications and Information Exchange Between Systems ISO/IEC JTC 1/SC06 N 11704 DATE: 2000-09-20 REPLACES DOC TYPE: Text for CD ballot or comment TITLE: ISO/IEC FCD 10589, Information technology – Telecommunications and information exchange between systems – Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473) SOURCE: Project Editor (M. Bartell) PROJECT: STATUS: Per SC 6 Prague Resolution 6.7.5, this text is circulated for FCD ballot closing 2001-02-15 to allow IETF input to the process so that extensions for IETF requirements can be included as ballot comments. ACTION ID: LB DUE DATE: 2001-02-15 DISTRIBUTION: P & L Members; SC Chair; WG Conveners and Secretaries MEDIUM: DISKETTE NO.: NO. OF PAGES: 175 ISO/IEC JTC 1/SC 6 Secretariat ANSI, 11 W. 42nd Street, New York, NY 10036, USA Tel: +1 212 642 4992; Fax: +1 212 840 2298; E-mail: mdeane@ansi.org --ELM971421569-26217-0_ Content-Type: *unknown*/ Content-Disposition: attachment; filename=06n1704.ZIP Content-Description: 06n1704.ZIP Content-Transfer-Encoding: base64 UEsDBBQAAAAIAPCCNClFRUhlpwkAAAAwAAAMAAAAMDZuMTcwNGMuZG9j7VpdbBTXFT6z9hobvGA7 4FDHrW6AUii22V1sY4PS2l6vYYP/6l2HUJEq492Ld2B3xszOYsxDFauq+lCSkFQKeUhVU0HbkKpS 2kpVf6TSqI+tiqOmaqVKMWoeKpQ+xOKhNAnb78zM2uu1wUahUmn3s47OzDnn/p177t17z/j6H2rn Lr3ZcIOK8AUqozu5KqookCmgDfmXGqJqV3Ynl8uxaD0oV8JDhb9eSVJ8rqqc508WzDWmn65WEn1Y R8tw1btctgwbid4qW+Rv1Trie/HN4H9y39fCOd7mXJ6Xvw8eAr/pvn8S7iGnProPvhf+ehr8G+BW gbwY+XHfXNB7sdYU/BX3pBjF+veL3os9u9Z67saL6yl+L67/2X/cuNK1/ZpSPGOrRcBq/fjPICZT Mm6k01ldi6uWZugZoeoJEdFPGGbaFog1wBc+G0+q+rgUPdKalFIX0amMJdOZ1YsWwufzRaJDeyPh kHgyFhKBvdGQv10MikBgv7+12LS3OxY+IETQ7/c3+zubg35XPhIe7u8OhaMr1L8cqGYoJGLHhsMH fDF51hIYtgj1ijE1lTIsgRd2jtSt1aty4fPFIrF+VJcfSR+qC/jbOjqblnjVkvGkbqSM8SnxirjL LGgF9jLv4THXwxnXw6+gWkuaaZnQVEu6YmEZK4o13TLV5oSRVjVdmEbWkpo+vnI7E6ZhGXEjZbsk m5GwgjP0k1k9bhtOalZSWMkiQ7yc0RJcKatgr0vbPCUzmea0kZBiEP03zFMiKs0zWlyKXXCU6Gjd v283pj86NDoSgvOGTeMkCopwQrNQ666BFtGjmpZMpXavPgWL8PmGR4aeDIdiB1ZURmPdsdEoWpOm iIZEuxg21fGsFCMyY6Sy9ijbW/a3tDVhMFoGU4YAAY9rZjybglcT9pD7FuMlnjIyPHYEZaDZH2wO tPFEsG5SRMKxPvhwImuxzHVcHG4RGX5VLbjeknrGnn2u1y5gytNZzZQcgmhY1TH9qCSeyibQuppZ aNiJ0kyLz9cdikWGBkWkF2Pu77FDfDQsFleL2zGII9HYSKRnlM2hGhY7Rb8YkOkxaWYOsj9CSVUz D4qjh0TI0M9IHXI7LKMybkpLNTWZWXClbyDcGxkdOGC/oOYj4VgsLAaHWpZ43ueDRAz1ieHuQ+Eo VIH9bYu6ZYsfM7LQlrrmJejrHoxGmrBpiKMtojXIHbZMKa0mhN6kOIbYw9MxrEn/vvYmMRrtvks1 WJTo4Z6ACAaCor01KFo7O4MHhehTzy7KO1r9Ihjs7IA83IxVlSqONF86IVVddqmY2RbDHF+xrdXh 8wm6pNBFem3G++0Z7+Xre6/MPfG9Ge/3Z7w/mPG+PuO9uvpeX8IKcM95vwPRnVWtS/gfgiereHj+ D4FeAL0IugD6OegXoFnQ23yGx+1AAW0AjYCioC+Dnsc94AXQi6CLoHdBc6CPQB+DvLg8zoLeBv0N 9B7oX6APQYfWER0GRUAx0CjIAE2Avgk6D3oe9EfQY4jNMdDrle6dxOl+ia2F3aYi8I29XNCmcuXM Z6lpI+2mSsiO0CZbu4Oo64OcB7xikM9EKft2tSVB9QnahxuKWlUe31pcJbCNurvmc5fA63vlCTWb ssSwitOEqU4kRZ+hWwW2O+nOkEIeZSdtgq2ma/ZJI4bDGqEvm2gLUT3bfd62mwcvtOvXMhbnIWqo NqnkTWkrbOdztcpWWr9oixvcU9ONTmvUSJ7DAYRyHVUqlTQ6HffTqR3U4GoboA1C+wi0XtbCEYW6 fdBtzusauVVHVw9dK3RboPNAV1imDfL6fJnNS+trh+7RvK6GSLg6Qeu6EwkTxyL2xVbXFzwOx+Jl RdD6npQRP3U6a1gSNp+imqQCVxBGxj64pNRReSgSC9ul6m3Zm0o9ZEO9YczgM2WEzrD8u/QbyCvD 6YmkmtEytn2DLZ9VGqjq8NSENFOafoo3gK8oY55ttu6Gso1q+ww+08lEsU11o93eB0ojVR6RU2OG aiaIve20OuiM0jNI1cOmdA7dOEZSM8btjHTTdk4x/brsq+ue2PDRxl/WnavvbPjnp3/2OGK1APlR tKI+jtZWqjnX3GNYlpEWxgnEG0Kpih4nr7KPdh7jaDk+/YzHDl74OuiWCpLvXHPMmFgogjLb7DK7 lpVx/Bjw1FNFVE1PpCQ2TvQBMcE+6fZshtwyDX2cOAocL3zJ00jrY/DQpKnhKrLE9/M5FXVVPsUn uzHUlo/U+dxplNpwODaAs6hqnspOsGePT49VOKWmUWpdyDntclwcn2Z/cEamzN4bFTsDx7s6/6J7 F37fKyjXFaItdRcQJzEtjZMrHwZHcBHSqbrmAmI3OpUeM1K0YRubdKNbKaoN8HPIyOKoa3IBuIcz Rc9hB7juIeKgQ9hdjvQ9CuJnW0CzoDf4R8NOoZTT1+DYRSi2lVI4n3aqpO/B3MVRk28AYZXE+Hr5 6Ln0jUooBE8DT5L7M88RY+d88bNLfCTkieP87segje5zvcvvhdX0Jfx3YIQM/FnYf8Okg5s0hdld e/6nHvtlvi57SVd57Li65oSXvSnk8z/5zKCP9Qg4zv8cResmJagXPE5ZSpO0+0G0tvwPfkuVfPxy H9aS/+E+cV6b8z8KhdBymiZoiMboJDT3l/+pQ/uF/lwp/0MrgFvi/I+Xovao06Tavo9g9Cdsn7DE Ig3POmzvlv/Z5bZfnh//Ejj5n+K22V+3MFmc/8l/v1lt/fN3H/7ew3OX3wdKePihYCbL1juxU7x2 +Zw/oMVNI2OcsMRRw0yIXiOetY8efCsYiLIMIv4YSPzckte3tNOtzh+fplVxJ8dx51km57ic+/p3 5m8PJWveeKmS9nzuJ3/xQ/ZbKGpd/QVyYvlVctb/38mJ4VvkxHG14sTyVsWJ5x2KE9OtihPX/faZ mehpxfmG9JzixPh5xYnzVxUn1i+D8+3oh4r92ZN+Cv4I+K8Up/330OhnwA/Rg/qe4NSXPyLxM/dj 6TlmYNEG9S48ozQ/83jdC5xYufygXd67bOdd236URwc8UBhPtAawryuXnv8+Ee63/QeNh7n9wvVf 8QDXf8cK6/8sLV0vvEY5V02zBxRev7wmy1yb/P8Z5Hl1jSN/wOusjEoooYQSSiihhBJKKKGEEv5P wHeqgJtLYCq673Hu86imJ4zJjOhsowR1FZS1n8/vePeL268p9vPNWy9xfpcvVXy9Zz7rcv4ctNJl 6175H887v3/ntZbHar51sZL2NN3+Eed//kxOboP1XeTkZQ6Tc5fk/7vlfM+z5Nwbk+TkaybIyeuU 7p/L8W9QSwMEFAAAAAgA770mKYphIDF/HQYAAA4aAAsAAAAwNm4xNzA0LmRvY+xcW4wk11muTSzw YrfB2A4RCdJREGiXzIy7q+9jFGl2Znbd1u7sZntMIkiEqqvPdNdudVWnTvXMjoUQ4iHiOaD1AwgF FIMi5QEkLiZcYnNzQEbkgRfewlscRSgPPMCLl+8/l6pTPV3dvRfbL26ptneqzv+f//znP/+9+jv/ /vR3/+BPf/q/nLnPZ5yPOu/eO+/8iHXvE7j+9cf0Hz/hOG/j/x/Ff9+9d+8e3foz/P3nuP4C11/i eh3XX+H6Jq6/xvU3uP4W19/h+hauN3C9ievvcf0Drn/E9U+4/hnXW7i+jetfcP0Q1ytPYIInHefX cX0P170PP4/k84PX3nS+5Jx/zHEe/8lvZTuLD+4M3n7cecoZ3BrcSj+dfto58zn/2Mect+vPOR/b OSevT371cecXnnGcr8yN+9pj6vvevR/P7pX933y+KP/9+ONO9k3XV/H/1/E9xXf4pHpmfz/7kRzD bzxV/t2B2L7+tOP8Gr4bzznO7/1s/vzwj845XzvnOD/Ywf0fdZzf6jnOBdz/k556nn2/pL5/9/OO 8xTm/vrQcVLg+5kxJB3wO6+dc4icXXw79/H9v398zvkfmv/r55wDff9p9ajwMev+z+DsM/q89bLj /MdHFH32OPNt5vvE/6m/L5wvfpt1mg+t96eeUHyx4ea/Cf9/f07h+eWPaDzncnoN33ZeW7Ao5+x+ zdM1/23Ws2Ot54eP5fQ88a7j/P7PO86/ffmc8w2osN/EGr7v5PQ86MfMZ9bznY7jfBI0vfGN73/z yx9/49z8Ot56E7LVdpzTPzznfNuS0w/204tSnkReGsSRF55n5Z9e//rzvf3dSj/1oqGXDM8vGyw/ tWqz061U+tyPoyHbHwY0ScWtVqub1e5mtVbRn8dx9aKjOJlIMljK/XEUh/HolN1lhzwE/GQyiwJf PhYM87PAGs/v+GMvGnE24OkJ5xETpyLlEwFouboJHwZeyvVtlsYLbwdRmnibw3jiBRFL4lnKg2i0 eJ5pEqexH4cMz9hMcIxiWOOtWeTLgSdBOmbpeG4g/jgOhoSUHmF8xOXwkAuxOYmHnB2A/ji5zfo8 OQ58zi6A56zTaNcvgkOHhisBFwyDw6/YtN1luzaTaMAQM7yDsTxl72jChzYMnmDJav3fm3Bi1w1N Ly9wgxM24ognUcwiA0KjwMd3wMcAiL7Llj1KgzAQPJGMiunpBNMz75j7LMw5xcGqWRIFQnh4ij+F 5gWR8I7g3gxUM8ktjBCKjXdoxXPMmkzjxEtO2UGc8m3GDsHylN9JaavScSCYCyG6HEDm2e4ebvpx QgAp2KB4JUhOaKNq3a7LuBLeDZZwMQtT2sSjJJ4wb0q7yodKZsH8EBQlSTDiOCMbzMMah7ROsSGl FoOnscBwoInDmdoFzLPHjyAL7CYHDalg9SbbZI3GliJ7OksIiMVHiyiX8H7CSZI9JlJvEOqVnowD f8x8L8K5ICkdMk/IFQ08ATASyTgaxbQWkrotHMIUQoOVR3HK/FmSgPDwlJgTzsBvAgVeHglJdoxV EhUYkfAvzTgO0ZANTuWw3v7hZcYugNdKvUAE9xLvKBXbrPKLQ/rfZsDTo80AhGwOTyPwabPqbqV3 0s9ssDMDIIlHR4EPjSFHsIu05AkH0gw7UQA5k6wG2w60PmOX4uGp5PxVyKGAlMTJyIuCV9QhIb1C EMxLSGCPA1oCsVPdZ6SLiF9YGzvxTukRdnCEzZOMFDY/tkiRPbkbgyJgrDzDDq/vsi/E7FO1TfdT 7NnLccLB5eH5Z9iNnSv7N/cvs189jP1G16263WbdZV8Ys3PPHgfPVWqs78dTXjKwrgbWnqu4EG15 ko9xMiA/2C2fixKwRgZWJ2ELIinOZaObarSL0Vs1SKVGLo9diJO4Cr5lwbuZVgu9Uxx/L/HH4LOf zhK+Bqq2hao+j2o4pK0gAV6NqGMharCrMR1VbLvHIo1zNYquhaLJbhoTcZRAfNdD0ahaKFpsZ6jU ircGUxs1BVp/rtJg/dPJIA6VJfQGg4QfB94yWDeHxYbueakHVR2kZcPr1nA3MwpsuAquYcHVaXW0 PWUy2dBS1qDRDXYtED4PQy/i8awMopVBNNnh6RQn0ZuOtdKNjnHulrCgncG22PVjMir8RKnU3PiU gHZyUHCvr72I02npyroWgMv6s4GRsSVATS0aTQKqs0MYCmXrS4bXrOGNVbxuutboJrusHRUwTulD IaWnBFZLQ4tgW9AeIhhFbBR7Wv6iONqUf5WANyzwNtuHlk3iiNQrZrfVdgm4lpIOgXfKKKeNFDmb g2jIp7C8pMOhy6dxtGSCVjZB294qG8eRnrUMhZatWhU4ICGrNqNjD3fBUT8gE0JiCA1eBqWFqlYn qDp7eTokk78UpqVlqtYlmAaDETqB505Kazmc0TUNgrNUHY4ZPAxpMcmb8UjzwQKXoTFqB3vfsXm7 NmdbdQsDOHuNfK/NIexxEGkTHiT+DBqJbHWvD7rgUjLtxA/iGUUqpyW4GzZuqDlySjfTeHNK/7HE qYw2LZn1DsHXmXQ/3WpnDUijx+oE2WCXktgb+p5YZ1KjxkB0l/XTZKYMKW0HTHQs9xaH4cbey2UY tPQ14Qt0wdIrPOIJjlMGnczCMsltdW1YF4c5n9HsbcE0lyFqV21E9QKi/sGNnZXwNRu+Qctdplvb Rv25NLzJrvJj+DE1dnXnANsmA8I+G8P6xISpBEfdxtHSONz7w6FFrtkgHO15kVsbjZa8JgkBlKJZ ThhEtykCgFooh9Wy12wTbDdbxlqwWvhaVSk61Wxi0rEhp1CaAgHyFKPZZAC9sASXFsNWXeKqZYQ8 CC4tlq2mxOVmdEFBpQFke31UHS2YLcnaWj0j6wFQaRltgdPglXYbeG7/SsC0rLa6BJYdUBly3gpS aFsZlgSTUrXbqRcwuHDgTbApHZ5loI0CaB2guYE24RCCkySzuqT1yMEswdcs4Gush4+C+BJ8LQtf 5opNvMgb8SUs1XLbrhJUrvNKRnfy0ZubGO+yK3vXrlseegmclsJ2zcBhJkrKYGFzCEq4363OYYAP 3T+oUdhVrpO7WsxqVSgVyD4iUJnhgYyWALgGoEUAksgMxCSqUunwB3QUpatWvuxu3UKHnSRMJsfl KdtOORdzjj7nBVKU+1LVeL4fK38Eig9ezVatS/+AKPKLKC8Q+OR0rFiRiW6rbbki98yKcgkpJPTW Wl/TIIfM7VCyie2UjNTCWath/3bA116UJtg6fwnydgHEZTt2MCetupjCPSTFo0K+EjydAh44I/DT kplmP3FAq1WzM9PAF7TPTDKjDGu3gLXBeuSzBUc6x7gQqFU1PmetQUDNPHwUs8kE3ti2POMyN8xG Sw5iq2oku9YkTK2lmEKt8iW7QOEKz7JVNaeAfOMdssUrkbvrIzdnwq0amblUMtKIrgs7eCmPHWif aPdNHroEulmAdtnLJk3IVW5Du1HsKOAh5cwXJ7lLkBtxdptmEbslI40Uuzh/u5QxMvECZQwGXpkb 16p2CoD1dQOUVjULhmqGtr3FI2tGHOtg0Z5SdiOKH2T6jw5oifTVagVA1wb0juNgWKqPWjXXAlXU 7ZeMNIJSb5LK3ze2CSKmVNaQxYNblBr2Q0+IlSakVWvMIXTJhADtakgjS42GIfpyyUgjGI22GXml ZKQRjAZipCvraMRWrVMAced0jpHuNTR3q2aEpNElVPUSVIUCGDPVLTosKoFOY8rsh94Rvjit23Kr FgWKUy+WjDTS1oTIvLgWp1y3AOKu1PnXert9OlaSfp3LxgxUNqBHJbPUC7PUTepxI887cmWoqNxT Iltuo4Ckoay/SrEfFYy1rrks5ncJ8qaFXDG5VzLSCG4T29Fbj8ntAghO0/CW5yMAOJ07oCXgnQJ4 nf1SkKQzyjzfHxojyS2X0DQoCZdlQITtBC/HUzfySFFXD7bZxiMNxlpYjKxSvNWDXQagP6a6kzZe 7Fd+WxeLlf38nS+WIDISTNGW2rmXSkYaKSTX+KW1di4reSiQNY7HTft40AAqS7FBEBkH1TovN8vO i6md6GnrRVH3z4q6PUkJypaFshcN+Z2ScUZW29jd52Q5qmLKTpUKeTMXzuq763Y9jBZtFKC+d1Ge bdrKBcD7IYQEflNW+6RwJxBCwtFC5Qq1Bxu8ArnSwkoTgaxweBJQIbc4pV2/G8RDKnenY8rrJVAM nKJuEygCC1EmY3M/mFJEEaiYckgeWzw1fF+s4wkvfKDRuFC9xQoQZVPdXBZTAzHO65qQ7ikV7Y95 sZCIvRxyQMvCvyJnFnqJ8rsEUTCZyXMvq+JAjDVeB8JE3cgos5FCxY7iYzzUufI8157f3KD1hrq0 KScntugdg4oOBYTMu80lTYY3ptir/lKuISi0DVvegbFhY2RjDyu3+eIxWctfxEDTMMJeOoQewIJl Bbh0K7xhPLUqyOVoSQxk1jf0dLk2mpMWkq7jmA42Zr0xA63a4ntkqcoMvq5FCF3TJ3SnlE4OOWVm 282fKzxQR7c4L6VwpeNOs3PJ4oUzFZQjO/EoEuPYIbX6l+TKD4tnap6hNezLwv3CrFKTgpwduW37 6iB60vfnI0r1SmEw3QSLaQTjDJpLGwyitCeRXZbcJ/7a0hJHoT3vlS324hbrSYCXtrQXpSrsFgFi BQW6XQarttQyNkeI2A/kzkt5lwHNfNNOlsBY7Edsfdgf8mF/SPAB9Ifg86TUCpnvAklccgQCypHK jcXO8aWWTPsmkrwjzw/CQCbYZKxEIHm7GWGJp3mXnJYijV9kGH2yM0ogdA+WMDIqD5cwTJVzwgMM YHOZmPnj+RnpvFlVdhMzZUetfPWQa3muzGnX9pcmjKX5TLiyAjnZWsJkGUrYU5Edaze6HbkIPUpk BbS5gZ1WowPGwEbm1hzGNiWivHwlOoQ0bSlXaVLJz0Dkg6YIjKhC2bObDvu6RZGWhTm9XHlpZYYl Zv2G5DYGo5nOktt5oaLVPrP1hdS6dGAMnEQC5p1KVWXSWYsXNLd9MuqlJgC182oO1QMZkh460wlp agTKjdAJ/i2W3wdGqX9ozca5yBokcepONbkyzKD1nWatnvt4YHgp0S9iMoXqcLBhTsgHs4qs5JVQ U0tAxhtqGTTMRJYjzTKCKu1nSYei/1B6hEoAvXAEhZeOJ0pxSj4DZyjdFLNrtLHQB9L9J5Ui/TPw 0k+CAR9qPgd2iq7X3+z1Fxi2QMhDhmBAck3MpmQZIPXJiM+LkmyShJ5MdYEV2muggz7lmnrRqaqe FtsohJFkreDpOAZ2vZJqhjBcEzJ4hTuf30JQbiFSxm2wqMytFAYMj+RrpyoLqkK5p4hbcMRXLm9D uQqyhQLUTryhcVEWNfQC3cB47yRzUFuJ7EnzyVSR36On0YATj4QN7ukkAEBKxwmhxSmT4iRFgrQf ZJPYtQ8JNTEOdFVATAuocdjzyVKSMqehGJmlSI0C0AF4IFQzn1GrIitmmhXYwOYUyPlLYV0b1txa eFBucz5lWKN/O2uN8tKxUPFNMVUgMly1dXElc2vGvQA+xklkmIJolRhxQOV8NZ9eSaS0PQ2DLC2b F7YqGiqrJdGYKJt7FHZlmXwcKsqGkxeqpyfXbQQLQt3YRPAJhZypDCXnciSBNpmRNUuCwAgW8Tjw silsiVuEZwNTcPIrENmOpMY/g6S2FEmu+ra0X5GbgqxZfM0Wei2z63bSmx64eOHt3iKf/H1tpDfN KGJBI/2TpsO2sur9hQf7LPXojCkpeBHKETdGEK5JwfxSlz6cINLOU9MIsNo8MeNbzx9Lco3JDJVu DnE4LYYV8wcX3ij+Cs+oYhOQLKRsmasHK0oLnE21R50rdOn7LtriGWxfEkr3Re/yVu3icnc6Y/42 HHFZXxrOEp0voFkhtZHQ+SuTrVvD7TJnxQhdtl/SAqjRK5w/zc55fr5QqRBddmNXYefzhlwlOmUL 0cdkjcW8sJAxFLKS2y39+mnC08ynzEjRtbQCLppFreAob9u0IzFlpgulHEGVrkB2EJxJlpZnKzIP 1VDuFV16WZsAvYoauQzTm2B2r7BBWh0ezO9oli+kXTFKzGZDviMvFObyipN5RdTKv4XlKwp1cOxz kwZJSue2+l6Nupsm4CD5KcLaA9m7mdDRlw6x8lCH1L45MRZFKaLJDIaSfKQB4VMaiVzvhSw6ITso n44pO1NyQjzokUzLaW+UAuhMv0v7LmPkxa81qA0+isMwPiHsi+VA4paaLVMgIqviKe5lKDOVRLmQ DcWdIJ1xG3R1jky5CNRSJcUgzzVuqH1SaSEhww9fZa3I5h97YSDhw7B0KSTC2NtbOt6lWpuQiD3V eqsEEs7RKOH6OBGfhyorUa4FCS9pFKiCkXKvguiY3IqRiRqh9kWg4yzSv9OpEkl6NokFZVN82r1s dfHSSmoYqNQPx95hzde4apwzQPu7WVyYGyY+IiA1Ks80SbaVMWxL1TgoxN+udTuNYoZ0qtoJ5MnK fJrrlAbJnZZCluQuu+SJwLfefrlGb79Yszy/M8Qe1miy9nszGe5jDji0swnmoULpGTN4aKl6i7bN OpHVvT+yxH3QdYNyyPVtduBJXS31V9a6YhPSeD8IaWyza3mqN3shR9Ehc+bUmQ1KutWyxDlQyVTA btFRvquC2RsIY3iqHbIbtjMqgQ6VEg3ZPoybrDppFnTqjc66ArJ4+oM53Z43clhTSFFcWxKXT2Re Ps1fE1tDDNOzYpjR5RJdnZV0bW4+FGHudunbYYYguMXrkVLGohsPFYXY0ghSJG/WPqbvBUE2+3CU b9hON6E462JT+WU2US5BFmlQnriQ0lEWVzsuEtP1fk+5RqrN3OaHTLUuOJkPoiO0ZTBV7fzdIKJh PqeZ7UWn6m7i7Fws1Qyvmgh684HeQn91wduGdFdqLpwn8wZGz6oLGN4Qbe56MrJ0GpyOq/FI1p+u 0hbsKnd9ng319TZi6VSQpF2ZS00oFwPHT+UHQ9ntS8kV6fRBaEMlbOSCqg28sNu/tvP87t5FM3LC 03E8VA7P+FRI8tXhNp2Yai/ml9FcvptLiG9us8P4NjYvkVbt4choPTAZrW22R8nGYDAj1+mzMw7H dI+S15dmgl3Y++zepYdhUrdeW9Msv8ouB9RwYVMjVZE8akce5VYu7+31LmqBpXT+ujr2YX7Z4VWZ /RKL01D6dpYl/QDTTRbTD28yenVnuRPy6kNyhRRttu7LC/wgRUX7vaUiM0tBseNS5XyLr4pZtNWq 1XqXKCvtbqAVLjMBZYfqGiQDRm5HnRit/NiFazu7F0sdK01SrdVcZR1WkJS/pQdLZLmpNr67mTUo GWAFHxZhjUdHWEmL66uZg31lht2E/bbyQjnLcgymd1AUiG3X62tZ2AdVBqF5pah0IbJQJw9xLE9J MccqilGk1uEuzAEdlK3ymGGFR9K3VTBRp8KY7H3Hm/Rij+TnzoCyM4j1+6eIge9QX4oCuh5Boewc 9LdqtjbpthotyCWR13hw8nbtFBtXFUJlTxQC2oL85w2MkGYeC3D5fJqKjCxJlfuBUOXmHDykSk9/ FlCm1eb/HPfaks7m+0xnm/UKCc8ClqxZVMyf9NbDMnWNw77NCq/nEfmj4qEv5moLGVqR9blOS5u1 6NzlU1cqB9cP9yFOd9mcVNNKTVIov++q+2I25YngQ74AqlYCVbM6N2WR98X4hCNs2VD5y2XpMmrP k4GQ3VO6ob0EfhzEcMiyRFie3JOErOhuoZwnB6u4nbiTXUMa34bVPFfMop1RBLTIBxQO8fCKYHde Edi8f7/JsjQBwUBgSBOIoiYo/AzOqp+5WV5Wmni3uSzAmEgzT1Onsu6woAlpG8JvG6DsL5Pk0M69 bKtY+tDkObJBqqJQMV5gdt/4tNkN2f5z5nFewriPH+95tAySGYFKJf/BiIrl7FcWuPrWUOPO2be0 22e8UvvRXvZLFLv0CzLJSArAopE96/dAFo5d9/eJHjGv8iybzbFMKqxbSlwooZ+mnj+WKtgQvK/K UIdBGvI1fiDpEa8BwTKoP/vjHmYR5L57Rup95b1X8l/NmEjvfo0fZXqkZBeCukplp9AgxPZkATc7 hebvF+Np5VJIPTHjWHK67EegKvTqhrIyqg6/qhq1MUeyhUtVcEAjpoOio03dZjt5qU7MBrpbQxcA 8V8qw9CK8R3yksK3N8DdrIkmMMk3+Ys7QvdDy8IAtbnlSBfi0oaOqBfUEiMrXlRW1H2eZ2gVMCup qkyLaSx7flSLjGkOykZuqYW7jEGUg9EYVCdYf2Rewkrzji39HpNsD6VunER4oWpB+H/2/nW5jSRL EAbzH3vMCv0MYW32rRHdAFIkdUvl1JgxSaqSn+nCFphV3TM7uxYkgmRUggh0BCCKvbsPsSlZ5nPs r3mUeY3vEdbP1Y97eACgpLxUFqtnqkREhF+OHz/3C3vojbMVsgOg+gMPv+dzugC4EK9WVmp8nOJ1 WrFzJ9MQdHgXQbCjXYFuITsaYwLMmAyw+gJXxBkBStKCSnaIS4x3OZsvFzKRVh86IRsNynmwOlgn R39dec9zK+LDTeNoLpQCggBzTWsDPy8GnVNUAh6lXzogjyyUcERfosgnG3SyXY6KkUZEwcscYtWn cXxcod86nMhD+RvOwx0cRzivOQ70VcNplFA0Ch2sAln6CurTjChkmtDGCNNSVEw3h0HMDkPdQyIc ZAKHQpqhusxrfoSPn+HwgTqMR6Gar8NAD00IR4NTQNu6m+/9cv6B5NpwBIqnbkpEcBkIvNduMNhU w2t4zOG9eHjHY1pMysCG0H+x/0rEVA0MzjlOnstBAB1XErcEvzWIhDZPygGKSgFAfgUaqMdSigaD Fc6Kq3x6IaeHUy4Au8QoB0V4MPxg3hTLSTVzAhxv5on56Vn2F4y4y5OhqBjAMBP7XjFJbbkhKpv8 3NHBwq1RAhycxkBAgODRcF0AT/8DzouBsxj/jDSP9hkFpQDme0HIwfDIvAu1rygCQ5AVoMh33Ey2 7WB8hdEk+SybDXfSMxPRTQGgP2qdD5AWOb1J+7TM5Bx1f2jRa8QxxoA78/JcdRy4LBiwVGQ7Dmb/ 8A//iOf5NAl8vuFyFISOHDWMOV95fVYuMN+H6vbA4gwsSW1MbFcc24y+UyJs+Ry5BGyQ/J4Lzvti 2I8l9DQP6U7jx8UgB2BcTRHQmPGr/+d3r45PD/dP9yVtBmgsbF3LZbgP5qT//AIQGGRnS5P2I6HY GJT3tpiVQPau22XZAit5GJDGOQq3A7iyOHD6Qo56GUksDxLs/1mUEpM6N7s9oN1ih2AzdAOZt28i fsZC0o6v+eFnxI9oTocK6Uhqc7551+C7XMgJ93ANQznwuFeyt3ldMq1mX2DBAeYw9dt8uuRkIKzh hBS2Lt7qCYCPjZ4U7+YlRfrhSiblBeq2C10eJqedgcUVoXo7O3c8HgPi3SJX1BeN6of2eg7Rt9Tc jw++cw+2tsavxu6J0T7Ue+/fwVdi3dY+PzHP05OchJOkXuooYdrrHY2/BQK2JX4rE1CdfUsV2BLD HcdfBce/9vM3h+HXb9yHGFuZnOuY50pM0RF7nRrmxfhkyxLtNCS3xlLa7JWUNku8eABvHkiNto0+ OYFPTrh+2kZf9P4Q1I91ws3z46395eIKUmzI6vMcBTbQykG8qeqtrUO3S9Ky1OqL9iAHxsNjB8IS 5+c3pBRIUcPjk/gxfffq6FTRzyrIgJn7x23MNLV7jMUL8Hz/pIXnYpQApRzhvx8gsujq+6qrAyZH ZXJ7vcP9LS6Thcxpv6G8LAeNo8PgyVHjk7YR0oAQ7rXTo62OCKatraPxlr8SgPkpRNza+vbwxcHW t04YZYqow4ujDT49fIUfX5KQMJaEwsPysoTkdobO1hY4k7fW+ZwdSu9ssZ7n/r3L/951/95/tUWm i30wXeiwL/cPtsiKEPoA4ckr92QBibeQODeLPzwYbxmXXGDxpkJR7p3j8CWrTiRN5O6T1/qJL/HT 8eob8yp5sRwhvirnXR+8enFyfKj4FoWsWcQ/GZ++2qL8+GzsGOM5IAc44uZXkKmkMHg9Pj7aWule MFV93bAHx54lMJzDC/Gv1XjrX5e56LaMDXALzB2AP/fPT+ytCO/MP4xfHR4Ez1db8/CL4/CLdVY9 t4g3Lx1ldNdAmflLtwZ3GO4RrBcexUTNPfrzwZaCVIq+HJBO6OjbqvrVH2+k6hrxWa9XQrr7IseS CjWLR+K9A/NQAUoYJETlgAyQDEgapJFDLtgedVHWTkwDOYOSBTT+H3yo7DYyKrEvEmzmgdYN7tTL C54KnEMqwriDmTRZvYSE1ssCNBFSt2lieApCuNu0w2snMhYDH7dBr5xf5WD9JxkXBXA4ngUP7KR3 3KaTdewGqA4GZJqvWygqSrgMOxTsu9dDGY2ilgUgAwMCzfI3c+p0DoOmmPzv5n0/qZagYvzHsnIq 8QcnlHVXLW9VJf8I26GKzVBcA0qNUdpOUJ+xhW2YSGMScNFSYHQc8ByCaeoVqokLydm2IjpEkoO5 lF5BqTR4SbQP1D3QYUGvstbYcUm8toKCAEgMt9YIYdwJPvX5rLit0GcHSU+g5kwBAjbQkX2LKLi5 E1mV/dgFis32TG/pZoN3qmV97sdVoFrlSw0Ebg23kuiBUuYUaxTIx8k0TJ4dP1pUN5SK4PMmE2ag G0mFbK+B8pTd914DoVRPgV46DzWGHrjyTCZsp8LFJ4wK9Tmp5GgR4bWw2qfWbrTTaFq0Tw11kBv7 UeGbljLYAlA7uxNzWSPrteqB6Pl2c3FuFhsLHdl0fOLF7uvZ9BYCfgB8oHC6/bw/rZfFhwHdYmNc JAPTktzH7niBSstquS5GZk0+Z25FKVuqvAxp+bSo1mJY7dWK695SpvQ3pZFgHku8CTBYYWo13FI+ 3mnqeGkQMppZjMCbCnjLthDkeYF0BPOW0+kSXTJEVdme5C5vqi/Dx5BNE/V8d9KZTIgX3IfhyK7C fi87F9bDElMMYhCYpLyzwBQRzS4d9s3xV1Qliklw/73lCUjNgBPngXOdF+qcG+5JVv4KC1S4cnCh T8ndoIaaVPkANTtyNRrCqUZT5sE4rfQMsaAuGKXe4kouuV6mFjBILXGoa+z14nIFdtm0JDGOX0No Bt4aswpJ2wYJ2RO5HHPuwLpGvw0EQx1OwpUnK4vnsQ32RIP3tx3Am2n+tugHdFvHC+2NbCwIDft0 jrNbEQxk8LJg/hn9CDV/sISPjmL4Q35dkVH9uimmbws4dChgkqM3JHWCbfgRdi7c7fYkAuq3OeIB YmOTbS/JLOguwPfFDEnlYlmDa7W6uACWy4D1YmQ/wkwoylVAahlEJmGMbvkWtoELcEueGNXX1ivT JASIoj46bPrt1aM3zeg2VV2S94btlgjVYDGQIYRFLyBu1Wm6uCFQrjQE1a3ocP2KbCmmcialfwD3 bvJbQF1Q8hyqR6ewPcaf++w1AjCXYfU6zKtuwZTLc5MuMIUCCcxDVr0M6HqRl1NHR/sRnHM2PjjI 7q9bDMpA8wWb0IHxaI2Q5eUVSHw3M61zb8yZrJVMpgXdEilw7Gisr9YqsxJvtHOjl2GBpg4AvVk8 ilhWcWfOD5kMb+H2AnncBvfHq8od8o+2Kot6QYp3QwpRnfi04nFDfrLDfXVPZsz/94BsrLpbZH/N 0seOConDYZxZ8nJ4y/+xdNdh6kbFjPylQ1gRGfAr9UYQ3oGUAZF9txkx3ux9ONWHXg8SVZuIX+LE C3bysmunQ7X2UjaWGBNv8i0FzEXOAsNSBqYcz1o9P6hipEI7UWs3PmjttdTowsykuLCA3aHkKCGW Jaf2002qQXYlAYVSDkklXrpQvWgqVsD5p6ESGbP5UdQICj3txKuD3kcgRt1AxSS3NapKgzEZyYAU 8ibkxgekvvsoVEVULHAqnlNwgrttb51G6yhCQ74bqVyUiIgZZc+XNYidwESlchZ4h2tkZRcoHaN5 oV2iR/VjWGo5kasYFLPieoZ158fCp6m+kB+zeOdgwtGs1orlPlULRCSvo+RxbOoRRVW2UNXn0rJk cji/Ep+YFPOSQ+wqVgTjAAbUrI2kN2cIlPhNLclSfQW97pUpG/dGQ1ukRu9JXVyUUK5RYn6wzBEu wR1oUcLZwa1mKd6bNweZ5sTQvV97FBlX0gFaSLNhHVFmenVFkmoEdOnehNECJBDBgjPJpJeisE7s Afs6jAyKO/xbuYKDixN4qRoQf8779KE+UG0HyQu0HUJJyjMSmbIxkcwjDiJAvQA/Kq0qhLer7Q81 lGW7GF2OBlmSczpyPvC+0P7ArgKjqK5SJTAXLGhyNT4zl1EEDKKwbiqgRI0ZYIkaKIJnAsUnQOQB rgiD270EIN7GwJ13OTiEgIU7MWhndyc7dOzNn4IT6KrrgmQ/LCwB1MQOf3x4LMKrHb3PIn8baYH1 OE47mXrW06q7pCXZVPMHhy/UaczDe0NxbL7oEkY9GkexhDqRMYa1pkScIuEbTu2F8bksmcOAUBpw j1fYP9pzo2i48OHiVHfuFmQtYpDx5vsElRybSgGvYQMUiHhLDYOSjW0fLxjJSYiQ0lcKylaBQDY6 cdRgCZI9CGYQ64L1RSu1eOGZcjgEsCUDt1HfHS/dpk7SS2q8IdSFL9G3QjGHWSmMm6RpKqRZ2pr+ nr6osJacvFKzkarfga5KCJwwSY2yfW1BRwyvReM4WAiZB2Gy0/m+F4nHRIoNraMoJgA+2iyHvcDn UHcUgjGZ61sLUEkgm6oY+pA4CYELqYxUrFwkmFsLRkR3G6ioBfsBxXIK5Wf8zbQl9qBoMiehCJEK gqWZFmIJBawHp7SFg+kkgm1R+aW1IYskDkIjvH0j55prVRM2RxFBNoe0X6RIPmHZ2FHY+wzsKOy4 6VC4s4YnXCT20nFk5xqcFa9dQe7mBbibSZ5N2TyxUg8WujUMgJJ30B+IotOT0c7oIQbLlk14q3mV YWlD3entD42EKEkxGIgSmzVLsoosSM7hQcERg8GgoCjw8porUMQMTZAoMaRIF9TrhanqORXuQU3L cICCDLuenBLVbkxpMbHQayD8yGf3JLbrdtW1YbfgajkFm5UIvLjNaD1VGDfVAX73o1sqFqimE0CN XgRIrMl+sZxOvUjt19oo+8X7U/pSsgBgRjYWa4WO4OE6wupG1BsCJAf4brDcRUXCl0F+ET6IqrGv hbFWjJfYFDK1KxUEhWnceoig/UzMcQF4REHTM1M7VRMuF2QH+dR6cM6DamaWmbMGzHJsKcFTyfvD NrpbnIakEhjLQb8yRnuOYgVTj1juH0mdO6k3hrqGNAnY8H7xjOzegRA9KBY+rynYU8ihvp3YQfbq 6BRVapX9BGO6aEwYFhejNo5Exa0nawcj5rhcNKJwIgsYrWownCxwG5hSjKGgLsIaq2AHQ1t20+vK y5FpwzcOU8/dKsFrasJ3U+YKWvC62chbeIsXejhZOs7xTsuC+rBHrf3miNk8L2tigRIRb22/tyz0 +KnEsCtxTUbEd5jaqqxiKkVSLK37+HoACdTFHG8wHvOlOxYUNW6qthXd2vV7PcnzOxWbugeJJilK GXgIB4psVQP60VveCRFbRtphwkor9YGtkRU+RvsqvtPHH3omIWjF6sSlQQ4NEYEekwikCmsZllcW mw6L7snwb1ajHe0jhpike5zE6fD+8ehJzKfQUTAhq8yqe6eZjKg66uWNdkbtReDfg0xgCMFVA0Su Myi4+bbQAPWJW6Xb4RRM9qQmSIX0IIH9AhNOEvMkXVl+YnUkPc5e4orE9ZeeGzkJCBZOYxQV0LvP 1l5HvD0S5zRx6CumLTIktIiNtwk3dG8x7QXEd0y6KKUIPgf5VBdG37esJPQe5eKrPxqzHTco3juW jVE5bjfU97Pqxumzl+pptQJhXArWv5HkbKmy8kNROaTWupVzCjKMyQZz3HoQC3DVrceFYD2Xjuvo 9ElX1rziVhP+VNu9FZ/1Mug44VQZiOYhEKPyAhVII1H25OCYBEVcI9RJWAjf5jO98K0FbbZ1So+n z8n3wdKtRBRBuMC5asEAoxH4yzXGALzvQIjBRcKGfwKkk9AuSshSAz4/pXvN66fpcGcQ3Nh4d7oh Lylb+qLSWJKaO4NgTFc9IxsE27TY4gaYOTwHeXA5y9+69YFUPvBLRwEOXrvAlD/yytEiJIAKuIa7 obdsgMXhK+Fdsg1Wdq4Kb4Mv6hp5DibF2YunoSPmdPQheykpEIZPNvK8JUNPAMNn3sDn3tfXEBNu UMhHKXhWFBMlgk1xeU1GePHd4uu+ecn7WSUv4UwQlnXQaic5SrSYDJCpLoZEGfgmOrB3lVcdkaAS xCp0iilrsOU6b75fhczrZAo11pkXy9kwMdWIfarMcx0BHmaQ6h+2okiRBWtn0npSclNNvphfwsDq Vb2eUnIjWqV06u2GGpvZZvPbRdP/2g4Bk8YvwOrVEZFz9dZhbPnp9VrbRTmgwZok6xxZwsnIxxKm SkscGpDgXIv3BVAQwue2oodYUnw7y+Ful1fVHFg8/M9FnXucTlTzA2pEaSrX+bvy2s2HyR1ZU/6n FhhGl6t6WslhLG5luNTAZNc6wEF3eMzZYdlllXMCCjU9c3/BZYBYxz/RH6siADXzKWQylJ4YyGTE vHweMZ6AUmBaBdAcqF2i7MZbVyK3F8oejmphHk3Iu01I9LXjCWxTecaGmXP+cVr4nintoMNse1wU TvN+xBq0nbo/cFoPFmixGjSOr63NHAEz3avMawP3qEbh9qMDImVt0FE8vbqXYlez5RlphZz4DYBu m4JRegqVaDE+2tTkua1fyT7zlOcMCG7Cx8TL30stvtc7JHN2bk4N4rLmLJewtbtha5ZI5RPi0cKK DJeiz+oCS2WlvgreBdFQTBuGtw0gxzufL4JVwQ9kbDSRcXLqxrPQspiCBQYYLnzKkYP8maqO8wrK dpfstMp8VWuHFZQd/R9YqnBazC5RhD6GGNwp2pJ5yKlTFIAc6DH7YAWRu/kknnSgkbtI1/OFE9Yp 9AjIXVlhC0Pcu5qBUvsPvSrg84DjaRzxQIuZEF71j5DM7Ig7xm9DD0zwk3EasJBDmWRSsliSak7U 8ukQAzr0fHbuhBG/+4cduz8CKJZUZoBIB4Z0zn2FRRj2uriunJxW8MsLPAnfuw2DNvBQ3SdvDS7I KQEXuCryydrlvKnOlg0fxrFKiGzTQvsHZoiiBOib/UyhijjIl9yGr6Q2ctxmwEv1GOl9DCg55eRw R+BqqFhQ+Kh6MEuCWLkec8bBTWnoL7YxY7UMLuXukOf9ZVWx6tN8GHgz5wzdDm66JRR+SqFYVds3 kLthTQHY3XLO0s35+bKGBcXOdREYn7X97ugDNPLkbcpqBt5sDxi9vqQ6Ue80m41w7ujfQvMSaLcI cHTpOVQxgS0k6K0MDrvAvdMhQhI4VMeqhS05RPTsrlkKZrqTb4hrLcTxZC2u2WI5E6TmuDP3fUVx vsBT3E0CFdYeLB8W2OYBAmVDdm8qNDvgzwsJs0dbHJa1B8un2wXjKl51sFO4GyFuvkDHXTKpQfov x+yR8GkHEn4LsK/APCTrZfNSI4U8rst3sY8s9zZbNNENsjAEVKtqlXLcPuRklGUiZPhA0no5Q7jy lNiHF9KPC4ogDqw4JMe7tz2PEA/fonoWGoQGumWouI4raXcDk9jIIf8t+hbIWD57cCwhWAzQLrHi iHoshpwZjnJCFGMG5A6barbuywACSTG8z8mpUyhZHESqSfo+TPKW+3FacQUl7ukt0zm6AmjL18gD sLLoH8AC3BKy5mpJBQMwytHdauCptfCFAQgb+cSxU0gtLTiJS0qCtDRLb23hXHDHEJYQeubwnUZx A/4ZlPYX2NaMo7ueZeBICl2zAh+u2pOhqk/N0MQd0czzc3dzRPxyBwICi4gEy5ngBegGEs/Ksnjh mclux0nug1sWM4Vxi2/wbtKVNh5pdwxTU9tbQh+0UxlfafDxiqseM91Zg4TvQO1YIsUBmgJHIbEf HAMMZs71/OSQVUVHYZ5R/BwZH3MjSWBALZuLpDyzhKYPWL9BA7/TZhaOZ2NpFAqvuIF8NRI1MHRF I9qROudTiAoGPEDFUTx1+CZHfRFBH2QoM0mVbcTQl9BXlWTW22fizDozKQTXZcPPkfqy8QUr8Zjf Sy6Qg10oMBmBlWyWdG5qCCb3YtAAg4HfLUD3moLIeAOnTsYovr7g829FzXHNcLg7bmeXKL5wOIM7 TFBexMuvRc6EWSCs9OCtWLdeXGDLxwFkdRQsbYo55Jx+xLOl6w+AyW9BVp5D3fOdfiYspqHGk2QG iwDtlanaXJVAsanmrN4iIRYNp60nOa5el+cNgHTpvnMnQdxBD1idG4YRQN/LW9KQhrEXNWgqlQdj 4tJTlmdriBDSS4hZOJlHe3mi2DgEuREF91gb4QJLYhNWRg4QGjKIEMe6TQA+IheuoC+Fkt0U+fc+ QjLcFYUWzd3R8uUj1rRs2G5+sZz6PKu5v1TYwa9BzoOeB7cQd4NCLzXLFSguiCTOQ/jvnVgHnZ9A dFSAOVxwCI+EAc0ZS5AOiC6YtqMawXkFchPVX+JAZ6c2A+Ogul5NYtt4k5hcq6iLd05BodwLbKao KogtARcCllLfp6wWhVxibvnNa2gTPHM0Z0S2HGj2pMad08BUw4aUQG8i6w2FGjFNXeVM1vmDQOUV OPPMLYIVIK9KPgtUJwe4Cu4I2bGcjAHppRy2oX6Fy6m74tNA5QVygkbfICxUlhrO4S2QMvCt+JKA oxVA/AMHjBv8T0sn1rtNFWqLuA0HvZQX9DniwRRqrV2g1w2NEAOfmTnWZEdPPmvPkkVFYH7sC++1 GHEifVJHpCAvDIVRRYojst9yyBH4CK2/wjvf2uOWPhYChLb/WOIxuNuDagoG4bmZjsZx1zkikSYy wnGeqXUQqhX26ejh6BEGcy6vC9YSbMQK+hV09IIE2/Hy8pJ8CG7qg4AqnGKGC5F44QdkT9uf2QVJ dA4fp85A+MzfAw0A9gPZBIAtqmADr20kL91D11839QRKAIAKG6rXUr9UMvN4cX7U+wNUWTMVICKn N6VVilrY6kjt4/VlCYqpJExpbIs6IGgJhZ9RFQivPEiXF/Cz75B/UsZpfd4LZwSHcSH3bYqFo2C9 aLvQ0FhZLEh/YAOq5QszFhNUx5aNDtXrsW1mm7TlCYjTbtmc/4Sie9PnNoxo0PkaJJEi29kd7Y4e UlSX8EWrKONlMKFANLxWCIHsEagmkAPgeRqjhhu/QUJPckvg2hso7lFWlhvfYWJQ3V4XFudtsZtg n3WK6iYWg8Q6AhKAgwaf3G54csbzZMCMrDiVWkpneaJmYTw8tJbJ6aLltpU4jzoV1jdqFo5ODZdz d4wXEMyGXE67soP0CYacr0kT8CGy7oDNx1+31uDE1Wo6obwxjOVGJ65TuS7QnCWTln4lyTGorIJU oNPv88BTBoOFY1FoVRwPLuEN7ZlEkl74oO48GYoETiHkCkAcpwtRAgAXptAwuxHa42+/+do8LDlP nZJSS7GW8+Urm1C4PxP3Nwk9dMB0kox2b9Tz7KblOgp+Yh5MDPmXdT4hXBuapXFF9lEsprDKDSB9 n8LtDwONDMpnzC7srZUdOHqeU3A7V8yTMDCvLTkyXgzEGUoyNqq/DQ8LEe64HJjALXFZZ7dFXjfq vMCLZpIYoKz9gjgp2q+8hZKv396m18+H/9ibh/4eKsyq6emkQ7Lw6sOKNdyRLS4im7QDbcKkdbeZ r1cdyQangZDGexxaJQHcoDhgI3X2i9Ap2QNsHwhEYOAJgLjcAE4BxHs9p4X7ctBASMCvyZEVJdZC GkQvIMtmO4WelD8kRW6kHjWa8urlbCU8NkDRnwU7Z93Ymd0dPXnnoDuI6e2tTyN9q2gmKYAkQe0j xZaIGRubye4KQbFvkBIckLXT/TiEr7/x8ShrBsgO+Po8zMKDaKTqGdqIgoxdVC1EyOXqjOGdehaR sU6q1SZahOeeKL8S5IqiaWrBpAWGb+gM/I+O6LmG+QlHkcNlPke/AgwOLv2nXeHAyHbSEbhq1dw0 BBeDGrGcAFlVMWQYA9BbgWW5MZpqrArvgdXEMydAX0xvVV0EZnA+zaHsFrlSMqqMDv/i35+sLkm0 xPhqu4ZJYQqlk75phVxKx6kurDpr6ki7FfHEj5KGcTqscI6SVYcJaf5TMhnmi0QcwwAI7DnnedBS yiYM6BfTZRCOqnnMVBkHgx65hDxBV/WcMpn665FKXIU28KCVDIH3qwukcG5XgAtxPeE95uLWUHCu mUDPgF+GNdF7ve/m4Ezwf2PU8BM6cZizRjciih5weLbhyYG7/2Ilmk2CR1rhEP7wOJk4jxFqURIi p8tg2u9/cLcNCrTK+ufyu4Q3UweFfArCIVgW2MCw4PLPQRhdZCwlF1LxrjhfIj/mvPGprTkUlhQK /QnmA7bpmHrvMIQtQB3bNI1llAOTU9FysEa8aPDCC1/xFNTCM6oUJ5l7DWaBIx768/AaZo6dY8wQ vg5XQaxq0VEhW+CWY7oZGMnQVVgALtY4KtlHeC6gGGNyE02j+mhmoOzH7KsAgfF2RzuE3mKYgnfN PlEPrBB9ncreO8JzNJJ4qw8A8QsfMhF0incf/Q+t36+hdv8TExuabJviVcCD5lsQ9G03I3B1FJrZ bxNfDJrbq4Iu9B+znQfuvwCb0DTNuzOfCIq7qQnM+RQ8EJz1WUmcKReRA8X6LRIzMUb4YoVlHCWj jny1AbRAtpRkQlNkhNcY2puwLEcYIinBJL4yQ4BcsGdrZjJm0ePxDzhr/vUdRzEtBAQAx+NBVizO R+Azapg7TPj2qEEDnHsTe2jQUmsfE0c9/Jh+93qtq6x3nRGIpTk0GYClgWdxqLNEkxm+L1Ztm4zF LlHWaiG3ArbRDpxw+sQQ5Sp7vJpySGjIzHQHas33qNw80NJduTodlLTiDFQnSrH0RAIZgCa/zBPt DLhsf/irrCWVl47YM2G/GvlOAoBmvuYk3iXT9EMPlQ7SMedLuMDFJCaQEDPP7DQkFX5X5m1YRLuO sxJIGDtiTNlP2cOQfoFPd4rR7rPiJh2mF9/AVpeOn7LHMbCTLy+qbnINXcae4ChPMwCBtjZMB0lH 0CFxIWYTeW0bIuQUZIbCt7er2pAh9rdz5nVZTUiY4lwwDEGBZ2d2VAi9k4pd4QRt/M9ZpNJcKpwX 9YiZOlKS11Qzy/um3mVqu3oEE+FlK9NSpEYiKFji6DFDsEmKXxt5l8RmU68rzI/sjNyM6cNrLweT HGFJ+uEf8LYsA+oAZg1y22rhlfZp2PirArAUNcKZGwoUY4xIFTU6v0Y9yioBcYBe0DplRALgXoIj RoSLpWoiVjY5QSzDQcEkqTTI+RDTHB3GDG0bqIqFclRFdhuU6ioRPRh4t/cJ14Y9wySQISzbgfzH 7FFIL8KMntypr9X3YNZsCRA7fbt7kfxAdIBGk2xJ8fH9mi3tAAxdkSz5dC8DT4CLcOGHRAv4ZQm1 BawLzl2qimpGzjwRhh6HO7vZTwPT3oaiAHztFZxHweHef8hxA9gkZdqoRwgNUE2zBGhK0wAAnvtk L+Ojf6iQNufeJseSeVwuuBuUId3GXkFZKo6Fi4HaG2fgTSw0zjKG0+UOI13uR3cFzRkOjChgqXOQ 7A7ZcuDDFSXPL8tUjFOAyPYzFiEUiiis4VMoEkOUISBy6tkTbUK+1InZVe2G36PMpgUkESkGRlgn NFZNaTkYD95WUziJvNEiZieUQIdp+cSTdCVYF0gW2lb2YjSEGwJU+clGScwg7pCEI0YO3oKPH0Ae 5CuLeKnPitptRZ2ksOuw9zMNthhy/X6fxgKbSJBEqbdKsvPQeOu9XNbKA517rX1m1wuDcA1FNMWA XUKyWdeACrzRajYFMU3opWREkQIAGUSYcuNoufseJPlmIHmiUmFPeR4hBJTq+L4o5sR9eLFBHzFf VO/9i90P2faKmsuU8uze29H3kmWRsVzhglWW1VWcIRYepAxfBqlDuQWacQX4Syy8qbBulG5Pvjbn 4WMWZAH6cITeJjrGhOEl236xO8he7PQjA4z/PXFR9FlM9fRBT9gCzJkQa/xR6ycJCSR4q6/d9m49 09GvufJ/4onMPhbrwAmqrV0v7q560Y+W4IAggwNrAiEj1iBak6Q46MrP+z1ws5uaOIDXcXUJh7FY sMJcDsB27HoELJiyRrL/WOaS5mwL6CgNX1lIJE7ngmVCt5ZQ2wulDzbpBtbFH1ijoRo2S45hg2Je jn8DPXR8HxIsOOQJojU0znP/+TENusAK1eFiDscnbvfY4p0jtpBWMVO19k0AqQdq1mgD7wuUHxzL TYY9haUKsXU12PcnbeCBiEqtrXlvWJ9M7dk7UnMpkAWxAwG8j1t3K6fqe25JUoxEFxoVwWZB4KFU ZoSwtkJ7IADlp2LsS8wLfEbRwLz73vFhb3z0AkGySwf6E1nGxHOI4/R6+7PwZyBrXRh2K4ZAVIUu eFcYin1VXl4NCYjgTJenMDEmQ1EsB4kOh6QQH73gvdDB7dEqLSPoKBMV8mdqYUH8EgjtjU4cIZKD aOqCMXs7Mv2KghvnuN60ui24GWW0FDaLaEEystuCJylcSRmcMuAjLJ2ZrEdgAoTD4YMqLCKGg6Bo pwkOnnTIDEERwi5aEmCYph4YcoD0gF6dTVrD1KYaoZc1E4V4YIagBpgUi28KMx7pMRzrhP6jBZUr 8BKUCphCcTocRnT1ruEvCAvP2kX5pLyQVgiytbkg5b1gX54ihV4KsjrC1QByxBXciCgh4M/La8xn uywXFIA+e+bEr5LNSYd4PGp9fJ0dHhwAATga7TzGACUn2ZOHX0bisWEylBTAvOcQYTIxhkqa7eve BUePssnGTXbBNb/WjwgOZjtksBG+l5BNr6TU3GtOoo8fta63/QYRyB4yA8ULqVBuMj55E024OhjV zQ3/YYFZS5rUQPtaRI0a2CAO7wAiPs0qd4cd2LY5bPxt0WfjY4xCxTXQBCJohgMx82uKKYYoaw9k yO2QU3JLpInJhNVh92kZ0zmx0nLXstGd8Ngscx4far2T7vHIR8VnyH0hDyUPNfQeQQ3EwBqPTKL1 o9PnS4jvmAcVztz/g9rzFG1DHRl5MZSiAnPUGh4GWIlZwpD8cpq6vD6tuaoJk+0tRoCO9cJ2EG1A QimxJ5KKbh720RQzBqqmPoPvw6F0RhRxjEdcEWLtDBFx+FzZZ4NKXYN2rSG/K8fEpmntAbzwZUng Mai823i8LO8k0kUEmRIaR1S9gbrs9m09QzoPsJagG9qJMNtT90uf8N9eVynf9hTPQq806T6YTYPj 4fGeY1x+wPfFJV5wOTy23mmVReB0PsxaCHbtw2hm4CGZSDlkzKYMFkcl9WzhbnYaE9NGXdmw8rQw 4QFTh9UbY0PvuvJ04BSmHfJo7fKS6llfeAlGIiqC99HW70MxSMZwsy8asXVuoCysFF0GWuWl8XRH Cnd9BPmVotOrPhomiuI1Ji580QYE3FUMCAbTN3acriQYrYLgWEgnQJdWmdtCFNdaquyr7LTyLMfI Gq0zIhslHlFSkkddRrSqFt9D9haEnJA6AgcjfBS1Cvr+nJrJwdfUOCgQw40FiAfiiAZZfzsu3AZn 3OXcSPDwDDgAiYgK7gSSSPSMFrWe1Tzr/cM/9L65pTWVZACOvuooB0vVN/lwfEtfq7PAkc20bxAm 9LEfBDFg5wGEsrkbZAqSIUDMVokEoNHHl5+Q8U0pdPB0YNXqDFuk2VVU6oDpZLdavw6qfI0lvkjj RRemA7wbnQvAOIZUnH8vlnh39CUvH2Tuol5gy5u3JeZoa5omMwOTch6nV8EFQeHGW6pk+XjqBPcZ FL+6PnNfQYbV8eHXmVZ0mFW2zU+27TYEMu24HwzlYCYsFg/G8Vk8xFFY+paOkNUSOe0YH/y6iNLV MREkwVxELFZXLqBihkN4Yu8wry+LGiA78OcUR80nQ57gGYNshcOsU2vthiohNRopFo2uvg1ptUaO O+4LSFA4gULbClxl7SGzBgqM15atPoPwUVyGjaqITjqqlEvBcHhb4EXg6eyfV1FiBDFZMd9Df56d htTEMPrC2F3Hz9COYQI1VHLyVa2iT+AW5TNu4FNeQMtP4jb+QttuCP7DH6K38igwAoaBYB6HogMv 47G4hLnrw0WtCb/s+FrQwMQJwI6jlkHv/oQCcytWaVzTpAm6UbFY+91nUsK5w0GRQrNJuuAQoI8f n8oBIKZZWw+3gEHLQcgL6fyvIW17whY42K45TZGt2TMC67zIz2p0GcJ4tqj5SMIQiQOXUWMWjlSl aZD1kkywCeWIwjOfYbn+WfJZJkVv4E5FN5nMcE1D1U9tajM3su3iUQVbH3q9mc8RQMZ0q5wpFcMg 03JBb7qzdKpdzK2rUyNB7GVKpumu/C7yVnWxKLBUgyP/kmWlPjbTXw59xvYWUJbDTM9Xut7Zzj01 Fi4CLiEdRGABKwb19uaL5dSkpIUS00i67PHr0YBtc5h6On08n9bwR0Ar3qfliEF2WyxEQHXyQ2Fz 0rT2t29UhHu6kCAysyA9s/0FN5ortaNJJPmK6FAk2M7ZLRWexj0qkiyIW4B8W9Fh5M2Aiv1A/Va6 lf5w8Dl91rqspBQMA/EF7i+gKhfFnQCsJ0skHjMwf01by/QSc3lBZD+YyN+kghkg9tpSK4V2U7yo KJm82xQpxTcEGAupIW/bSN3OqtntNfD/8JKIUYZvulDbzvfZQkPipCnkkqQb8M/rRGhNil4zmfTv lOQBwXRQjmKmOpzjZAvCrwGbNE4v13hDEvu7dhP36oAVH48hXFKDTrsYDGu0Wh/YfO8+oPUdH1I9 ZycYlRM1phdB9wg11Y1VRjacZiIx6Hhd0pyOxQD1lI5P3ALgFe/xI/EH8AhgIMqXFfEc1nDdsTyT MP0igGIEunKGx6wCKAnRdIleFIHsCN0j3ZcOtRYlS+fRFIw8FQts7czxs1tDEEtJXnRCpnp+1+1a IYkjmAiXioRFpIzrsYM9UC1lCy4RhiNQxwFE14bLaAqpUhe0Zcb+sFVFzIxxCuRKa9QMiEeJ+AdV sXRE6rrrxk1hCsDaFHS683oDkRZNyoEcHC/fPIvlWNFqUa5T+bRTmIOFM6O9MB3rkF21zGhskDcR LIuwMwpxJrucVs8eIXFi2sXyHj5xd9AmQG3zcAKj+CodjcmE9sKcvUq0RiW10K41HJ0Zeb5C+CV4 MWmfsd0mcYmVxrWUK6g+WEz4rjI3nmCm6DmDGSW7mvitXPQrYaPH6uS2hvL8EnzK1awLNDT/QAk9 9lML+AbGz0d02JarPUu0xKPLqcac1CDkWdV+uxPfZ9duLY4+wMiEhiwmZFBJewcUsCl1WcxDXh9C 7gNfsoOHwztzY48SirCHFzcNlnzqW3nypyxtEV+9KdIdBEFgwVaQgPXPfXY5fJWEHbvpi1nQoDiF VOeUoxcGcUL+IvyvFkEGk8Xky6q2Ek27RBgGnV60MEkcbcxVU33gCNNskAlEz3iPyax4t/B0CXun UEECJfrMV1AAkMCMn0RA9l0kEGe8GhoALTYQkE9GxP0TKOe1SJVPZ7qjlUbqgjq8GAJKN3AM0eQc EUr+DVw+FYNlpikbYkXqsSPYUiNIFYOIXa4u7Hydf180Iv5hFrFWLPE8S8d6hpa1QWRXG0SUgePv RV5mzZMutdY0IpePColE16i7vTG0g6kBbHna+kqiZFrt4DtDiUxrq5KRyIczuOFDE+HPN5HuvkBk v7Y6s8BKZ9cgClCe6mo+FzxDZ9rx4QvyRf6LQ0X2SjNj6F4dvxCFcrndS/yQjuqwhUyivGN2fArr EQ91Mo5Vdcau7QZYkd6wLlk25F7cLt7N8YjUiJafNdjIgkMXIIRz46MamMR76zfkyS7cosKUsMMT LhcG3AMzHzm/0wREeKYTbk0xqUkcQFNcl+wfFm0evd0P3H+GOw8ekIOIHJ1D/EIzaQy6OA2qwIqQ RBaeOOagnTPD/qLWEOLpa90+Gigu09mlVCrxoG1xotXWuMvtJsNjOaa1b7GBFLovQq+PUrqPHY4d 1urusdY7nLJP4eEFLQwS2g1YYw31j5rEsGXjNLJf5hhfdy5QiTutNFhoYp2yPFjStrECtxu5phYP VwRK4iDvgaG7Vo8GCkENuamtQEu+qmG3GpL2deUm/xIamqBpC7wdxxftVW6z32W777X7iwJkF4/r uMBZ8G2ACzBGCOi+564198WkRY50FZ2zq/CVo+x9KySTL+T6mSUWJyS1m66cNIGwSEBMBtz6iEgn Zwg7BOsOBx4afGLcPuqmbIpBElRkt9/F6NooPsefOyxEAvURkaC8RHNBAcSRU5xlp/yseqvSKjAG 4vbfF7dcQbTUGxVNoNFmNzl54xwzQipS1VQlpgvSLUB3kAk4PJwE8YdJlLQvA/HjHf0zcYuS13CQ mTYiuG+muk+pE0VdNgxNESp6ve+I21RyOBzvMWCS0PrC37x5UWMZ0cInselLhrGI7xpRh5GI+Qky 30A0+QoKBtfuf/YwBMkHZxoJXcfW2fh4yAkD8rMEg4lxghLy6/hTQk8+IkbsKZbPHASfmddRP5kU 7PM+AwmkMSSDvobFhthukjbphilsBfuslCHnvWrp2+gFvO2zNanm4sb/WdSVQDkpI8n+ADS8DJ4J vTm4TL3u5vByaLXEhV8gJuUSsxrVlEWxzBqGhSKIRi1YoF0VVIHdBHEJofcH6lYu3ZvLxpuWACEo lbHWKCJxcA/S8dC0Udvap8Do0N11lTO0uIQksMC2TEpIlHWshTYEsSWpQj7fhqoIeGt9X2rzmkwL 4guUVMDnFCZBOiS27xGVBDufUWGIdkqLpnGUjS/rK+uTw16RPrLNbRbNe7sfOX4yvcSNj2QJuscc zzATczbhpEx3yV+dfHca5OqaxE48oYmZX5Nv71zbA4gY1a5IhrFuq4hdNmxIgm0y2NAbZITwlo3Z vr3bH7UXrnmWuti4cEfvVVRxEeyjWFWL4UDbx8zRrlEyDgyS6r2Y8wXQAGMYFkLDYm/VdUF6Fm9H NaXX353SaXRjy4pko15ve0W4SYOerP4qTPnkse0NaSWc2f51MlYEPq9X8r82CJ+B11AaQNoIpjFU i43jGx+4P6dqs6FSettwKHMIAqD89uxtWS8w/geOLExgoWaDmXWUtZCwvxmQjtlo2JEqCEO/95X6 qWcX2jVXjP0hk7ujVrZBAMDEaQzj49jpOI6wCoaTd3JgrRGCIAQdXfFn997XNp74TUzXbIJMQIsr Tg8qfeAiEwamZbvUFcAvoBHnOjArNF9FK1RRbRBJ3My38RuftF4vrqpLtJCBAUR7g0qRehH7WJf6 12rsNG1g1DOMLiW7SOWL0HN+ABd9yApwPlDHRm5RnUIH3+ZdOonnJgbMGvEJ5k2he/XW4evImI77 lNcAWIEed8jHSy88M6SPz5nT3qCHDxhosGRTEpUD2hbunvbFnm6qKvaWsj0uwYNNW9Q9k223bHgF 1iUg0VstF9At50vDuHHvKa2uBDFmZ7ccREL+flQZtDvxtdMVySdQBO4TMwquDlLhURzkGhLEjop3 OehVg4zaayDlAPYLLlH30xAEekoBG2XflpeA8nzVpPsXsA+09cvkI6w4mt+Gx8Mnw6ulKx10TpA1 Gzjx8iXaH2JQpBcCDafGiAt/Ekgl73KIKzeGdfODdbrt9Y6ox8P6HV47/F+AAeO8Ikc3VUsXiegX 3+uOkztWbBeavdR+0dzKwu34CKtWrN1uvbLXxc+7Y6iniprO2kOlXUaLM+VGuVMDK7CyTLFG7HEU YagpSJyGwoXnPdP+VjlH28l+SyjNvshnCzZ9XHAgDjt2Q4amFLOQhB61Hk8BI486SZw359mmH14w RwZkmhdY9im0bMwewopC7yoKkeelER+UBZaNnuIIWyN3MA3boFOXQ+QvXlGu6AA0Kiy5g8SVyj8b OIWZWS/GJz4Kpo1/X3s7B4kjx2MGGrm/orFBMcUoSAtErukn/I4BI9gc83ifHBlgEAZxcTeFhlbN 1Y5pO1rlWvYSSgiyPAf0Ga8CvZA/NLLThv3dyroCfpRauV3wLASMV27bGJQvDLDo1jxMJS0UbIgT e4c2o/ZysVQQClEyMw3k/bsYOmbREabn/oVOFgOw5VlUh1TymhNqNyU+NgYwVnSx9wVMt8XMG0LV 9RtLXJWU1z4yxS4DWcfH7gY2Snj1piJn5zO9VP6I2B0BvdDMr6P4NZKllr7HKM5FqsaXfI6LqPlo KUMsoiI6KjW9++Q5Kl9iKznFKcJeIQDv2cmwa4o4U8iARd1CuG8pjKnb4CWgUElh7N7vhu3winfB mxRrglhFnXDyWTRYZhtyYfjDlBkJOIbRJhcN6vVAyMCClhkoH6BXo2HlYS/7RktAm/Z5UN/B3ZGc nIAO+Tki/CzxMqVsQncVFCC5lLpvPwZwSX4HFxKGLiY0xLwplpNqht0qaOmonC64bmy+WOToWaPr O8r2wx/EQIwUzlPUsiYtVtyfOsmIWawqZIjGUZttrDYObSanF4I3dpk0o1YzaBl8fDt6+FL3I5F6 Xh3uhhJTZy90eGOczziOiP9On53Nfq3GLyop3qqyUWCI11cPI5jEICEdib43IpGfDPLZRZbiOVaM OcTTDJfrRigbDZtdzsr/oBytcKheYnlAjldvgK6lcd+tLzOMy6Nq9Fp2FpbyYv+VMfP4ScfejKlv 7EZvAFclvQzKMAIHwbY/sP79tDxDYgj2p3Lzd22SlV2UaTxGqbpNvp6zgqKY3C/gOwO2jabqFZjY hxM5QyyD5pIZlkCvYKghjWUKjqVWD3yQpOV5XVJMP0gKixzqqVdvJcpOdNRRhgJQh2hHYGjWwwGD LAn3KTQLpXN/uSaY/3KJXAGgYG5MeJm3mz7K2dQHmCnLmwJYB/z9orwopK8v3gZAAM5MVEWMa2QG qTNPIKX7sTt5J7t0oVPieHHRJlw6rjAJ3tlO5Fs3XqsIJkYmJE2PqDvBOdZSnD/nGuUvzDXacBF0 TnQe1GKFHb8gp6pM3IESTtR1SlfRcPo+eSRX0QFcGYXgunMAe1fRSOPDPIKAkEYMeSSigGUSTcmV 4i121FuzRRKrc38hxZ12F0TFAbZxJKem9ROYCgxV3bDQ0gleAcOgk246SSJK3N5jZnIHOTIIuQ7x NKJ/dNsB0iIYeUEZr7QXa91tAQrjjvE1UKYD7cQz1Hr+huttM52Kei65LUtrABEwyOOPYltyY+5o He+gfrYE3rzRRmS4LJ/vCGVH8YpelXOKi9ROcGwTs1G6gD5XhWOFdOWkZ9NklLmrfO0kBqZkcP0d vb92s9he1yyiiDJBFdrP6NBlQbgGt9ALiOnS7KURpOdzYvOCiyKQkVrbKF2ljAcQ4ctKEJXFB7RR hc+d4vvlHE3POVw4mKyp/HOH6HgnU1BepYULRoGIhzO+B87xwaM75oez2VHEpIwD2lp0qNdz6JNi T82gAxZBwM75wl9ZSx3GA0PK4GEdBuSD0GbRRuu/pFCO7ndOGRkmIFu4q2ls15JBx0oDKAJjgUpJ cpptjoJD/Gn6aokICVdpaveqUm+4nDvfGiO5hEulgMtk5FH2UhrCBvYO6geMywoKfAvmlUE3WJ/4 JrlkUqsasY7S2UzWl+TkkQtVduCTVlHjrzHyC1HnzMHF0Uu0fk9kDfB0u0E1fW/0sE+Aj31BvrcQ XkkwZouMXxeXEBqMAIZyViCVwz+oNDmxfLw5GFXi9uL0tFHGgSOdX8ACa5UhpiJD/LfsAV91CbNj u4LP3ZDbtZDw6pZfy18uOQYwq3mLj8rtZlG+sCxomNQ/QTkWy9dxiVTrANe7xlIddrEVD3EXFKiu IZsigxXI5kvRjQ3W6YLMBS8bOiardoRQGWn1JluQDxakzv7XjjpDN1VwTYzwbZPigIa7U6i+yqn4 8Hy/DvK1uE+m5Oov2vOJ5vp8ml/CNHS7HntHnu/nDlwUyiHyK9Jnsv2ijTxu+zjRY2+bg3DczPb4 5HnfjwJmiAYbNamZyc8AIkK9BH6kVW2n1C0A0sLBo48/gFI47a7RlWjDfJws7YxSGIpeEC7QkEJz Vc2HZ7dDiElxh1U2zzKt+BAuVtU7NnnCUwlnGWgQnTZ2AJCwXTzXys5kcgFUBvqPkg0yJWNVQlbs 6zFJpRkGCieUsDmGmrTQRVnnMExke6/KnqUDUUNCUL8Y6p2UWIdjf8WxLK5aFjFyB3Lbd2pabSM2 uXWruf5cIRvNjh37Sk3j2ZPnJba3vKcg+Axrifv5AdT8OlvrhEIhgs9NwRefn12a6qUguROR8Sc2 cIIn/G+J5odpVc3VAE+cgwtWpkdHf2lBGAZ9p5HpMT5if3EqbOUWAf2p5WbvOqmRAcUNkAgg7oYa vF5AjVNU7njTU0fxppn2Q84tdq4GvOyEQrp5827IXk8ZM1IKgCx3oGU7cLO8hosnPc3opPUltDLi gr7GoWidtMJKKstsNGL4qhkXy3pEQxPnwCt7WSyYdpxPnZCAxxxd3MxETmKzYYSUXQOYnooJmjka sFNe8/n3eidmvknF8iufNxnUz31fPAx0ntIpIa4qW9aoYBmvUtM/wIOTFwkJAhaU1+dXJciyS+wi UiHJXmQv83cw0ksaAYWdBcpcu302REMd7ZVLEVzc6xCPyplHZCAHYDCBxQ9ocBWRadHaUUbWram4 BDuMqBSShbcV6Dpb+exZVRwNA3OJnd7m31lfwAWWcb4qUmFdIuQTjWz5YjDyEqQLbT9xQh2cCCgP s7GIokzQvUuR1nCdT4x5FvpUKSNjm0F0Ea9KR/ncad5m29hL8gWbS3b7YvfttPGOsrGUClwZ6oOG SMnQbshIJ3SfUmSR1mTXItmXsQQQECDqpS4BHVivNddKCm7hK6xE6o4FrAtjbzgkGGle+7qT8Ds1 nkKn1NxgKQtZvazTenlBi+YiHaPWQtOl59csVJP4uKINO4Jw2TGd6Fikp+QPs/+dbXs1x1hb/iXb 6eu6ex1pCbOIMQAFgnPX/oDAZRwdgBVrVTTfqjvMWAAtipsg7NKxd8saQULDG8hovaYwoajdPVvZ 21WCQLyZOVkMe5jC1XoCdtTqLTFKoHoNkxU2+HkU93ViOIcXCN54PsWm8SsYIUtPwC98FoGTZQso jbQo2WnUHpN0M2KUKXyhwaDrdF1i37qCfbbLOZX/Qrf0I3Ju1EBO6X+LCfqnfZoxLRuWKEkJPSuj rBQnTM1Ckic8nQVH5jPmL7Er3pQ8UKdHZux3USJJTG/rwtfvIt8mbmkhfbDM+9CO3nN5Ws1VTqla mMagvnTke6tHn4efX6IH0X4/yr65tcOVjY3Uw5uxvBbaphRoak8iwYMcWL1Z7vjwGeeHYrkejjzk ZoB1O+oh0S8NRVk4HixsaDgjkX3y2toZKXa7CyqpMdjb4gcpgcGL3flz72FCf9olr9qaX8ZHb8wP Idm64aBWbur15ouTBbfIgGzdqkYDSMtB1jieNt0JX2y/RIZZR0BmYjXrCvYekE403f3YIdsRy+4Q p/uv2N6QOsT4qraPK3lUfIIGiNQuiCYwZmlYIFMOMJeq5ADuJuox7APbcEj3oL8CF/xuPhoX/BDM U55mb6qzZbOYecs3P8BWAcC0YRsSKsLR7BXbfmLnDQtMpFiusLRxYJVYumnNKcbhYa9Rz2PWANDG pTU20qYp39kLeBqXSaC7S12hFnU1WZ4XqLo2pqi03eDYp+hydKOaQ1SKjPshpu2mBAH1bSgYYEYB BJlP0o1BdX2NpUBqVpGMN7iwrIvLKTut+fSmGt7kGnuCrdnpxO96XLagUcJ3p24wcoOMJbxDt6nR m48RSlSDlu24mEB2LhXUfSQIlR4as2n1D29aASNy1gX7FcoFB9gJ2/dBIZrTS7wrmZ0ggaFYb40j /NGgegN1XybkZ2vowHBzPrcxmDBkAsxuA38AQsTBMTMFAvi6abD67TWvio7zq1YTj9zqaZLGROca 5MGREdDhVKGVhZLJcKTehSDJvhduwfYESz99sA1h7StZKuSQcSSNz5SaFeCBXpiaZBQjIyElx2Of 0pS0xMEGMq6BKGUz52VBsYx2x4nMJDRe+Jw9lmFaS0o5wsMiEXkCa/ZtmZeEHxVgN8jeDGCd7yVU 60M4axRbBX5qAK+eArYO1dhkE7LmVvUmfLVkPTGf+vxcqyPYIywZBRuUoVO6g6lSo7vDagKFqCMB S21FcDgVRtFiNxv7EBEftHYBpv5SimHtOuk+xV5Q3SF1UWkAQ7DlzvWYqSYCAs/Aol98VFEmeUmO SiLOWEA7FTGpBXSXnFRgYm9JNxobN6/EX8jWneZN3nwsGGznsyXhWGuws6A93cceRziJtX2FGtqR ihmQ2Um3KqO5w6nYZiFzI5NJLZjR2iNSdt7nSPPEj7Hi4TnwWk+0hQ8IVNCSYP1AN3mjUSROGT2t l4WPCXGgA/QNPgguhLsiz/NpU3wNnTTFoh5XVPTut5l3v5HV/h/+oSdN5GEL7zcgGx/CFcAfVFgD sJSpgu1ylCDHifo01oUTXTKguReVD9BLRiIID37SBhYinSUhYMayuWth1h/2HZTjQ7uy4fdB8P/+ 6anPc0uFLaxFjY3RAg/5bnjxHlDpw8ciRq8pbDnLnSRXpTpjwcRkSvM3DGWKzdAKXhy76/WBierO A/eeZ31koRXrqimmhtSj8f3ZSMyIS65RsHGtZREkTqQKiwGSiCZoDOmWvhVBeWELdPnBJffBxAwt KgO8IE+bDl7TLEniyss6HFJzExIjzIOuQcmXhFBJNIGtPCcJjQ6zl1iynm4a1yyG5hngMETeztLJ /o/Hjscjjp6QY8MoeQhyCdvExViZ+hC/OsIY0rr6vpgNFLB8Rk24ur+UmNTcAWf4866pwWhek6h5 UrvU/rZKTmEsyA34WK4tUKwlF5SsZSdbMFy5zkrZ9eauvvmG1Cq5YYwHaIkiyXQWlodkmJpyqZy4 sOJaNbZNKyyIZnHDkZYBCHKjQ57g0t8M2DsUnKGTuP7wh9M7HYAoUEkMP7u1NOUVhvmQGFJQ9EmU BO1DEwB5Viaic9z2pCJQgyx+zqVz4YPS55MCVUhK5rJ0svxT9d9gBENGQzlxwYkLdwVTSHTwlnqz h/tDI9Dz7P2fOVFfG8N+AAKmPwMf+oAy2rKREJpVmwTTvDkZn36lZnVYWOs87BncdbegWtwZQowv HITPOyLMWYkPXEkvnzemZAgCXLOpwNjCQyFTBE4p4EwVepFUAK6uScVhZmRofi/lcD/ceYs/bDar 9ZLC1JLYru3Vl2dD8ux4pYXJzoz4HDlllNM6EcsvlSIm4V+wIy0KwfBGuoHltkuoqHkS3M/cx39j gaq6HX+5YvegGnLtebeJqL6Fw2ec67yc51bW9HgrBJQ1JVTB1zAGJ2JNuGouWy4x5nYhNXDBszlu yM2tafRAM6jusV+imxevJy503ywKgeLri3MeVuabaBoLri52TEkwCzFqwGoEnhqZy/t/scs0SNI0 8nXlM8aONhxgkI/ji7dcChZdYSAJ+deQLvCyy8ZPrDMhsq+bS7Vs2URKKDmJDxGo3zl1K5PayOvJ zJjuATJ7hv0GH7U0e/gG7SnuGjU8lNRmw+4JZ5hQzTfR3pUIA6k25CW1jzw2jj1+L4/xxF6eQbT2 SXLtVPc+YAoh4fjA83FMZXBjCFxJQkM2vbLR6x81APCp32K6E+kKLxGGdUhBvNpWOIZXvBoSp5z4 QlA+L23N8Q00ZkI6TWrUzLHvZC0xltKOciQGDLaUwAX3CX1RKZxthV8h2W/FTdZiwlxpZMKlN/ob igJjy/lNibNXR6ctETiD/iK1MXYe+86tThukbgtcIMTsgCzr8L4RMk1UdYAQtyGZ2ezmgfOBxISC mgwEfABg5kvM0dEiZDZmlWORQlJywSvvUwj1cZHRAhwj8Mjpoe6s2AxaLynOApw4DH8cuzFoOFaA vVU+uDyIRT5K+qqVc07fTbZf9VuVT0tpyPGDvzQn+6ffjo05hXx1r8SgfQeoip4pPxkZmm0XbB+a hEtNRqm9zN8BqF+yoW5hb1jLiBK/r9hogZZKi+QTIEsDt+FsRDK6s0zJyWfcTBCJlxejFsXcjXwB kQbsJBMcVngF0dU21rc09J6zdozsLMw7kJYgHgrpeXBNoZUeWaw6iCZJXiCt2H3G6iwkm0LQWavP CLiQZrdKoRdamxSgOjNhfPJFOfM7gcF0LCeiHWvpVEDGi2oJuRRC0zc/HMV4Ryt8RWGqxB3cCPBh LyhdSg9QJNWonEe+sN/KtuJoxbuu0U1fXZJxXSk340KzUJxeUTQM4Z0Y2MnmTkhzCIe3LefYS8UA EPkoiAlO/q6rxkNMK9hl42VNc34GvoK07WppsBSGIw3++del5lnvUotvA5fkBhN0fokzLij5Pl6T Eammq9ak9BwBs91pm+sb49ndd95t85CZeWNWEE96vEJ20QIQ+86s9AkGzKsinxaTiGyDpllXJAKY 2KAOqTDQF9EOCK4lQzZbMhNxz3VciugnSLm0SLNyytecbYJuY5VIm1jCK2crBAY0xgMBwuvA/MCG 7MwNRiVVZ6syJ10dlLVL54L+0DwhXrqjJfYwAY2RT6Z1YmrsN+fLY8G2Dqg0ZwHJD179382OjNJk 99O6IQkXJnnm10qIjdXHx8TAn4F/gsJufQK38SRr0mYgLslxOSL4deJ7DUltHxAzVkrW+rpnxQev foUi+dc9VH7Fq6hKjnsryvS3YchAJGQ8pfrAISpIY6lz0L5RW4ckOCuqk/9FElK1nmev5fCUiC1k O9RI6cXua6fGv8TCHwU60N+j5+gDJ8fcVTMuG9kiKQIW6VueaZMyhjfEsorWy7Ab6JUKyj0xGKNU ywpaX7EoVQfCkAbRcsA1dtfZ9xR9HMd3t7DBW3bcOj4JznwHG+h8IGKIz70Eh+EZ+PDomx12qdif RqGhwOeYqQFfks02ODv2enTUBAOsXs7Y7a7Zci/sqkV8IcaLp3RrhBH9aI1SRhFugcblJn++/2J8 RPSf3HKe26XWqnk/OXNYva0dJm1ZeKaJ2VLRCxmYXs8BRpgFtFou7Ch77pWwYhGbZDoBr/4mqK55 VVUa2eAeA0yF9B1zVilU4m3Z9fxBYA2W90nhgfb74ese4JaPGVtHQb/unZi3pUtXyx4QkUukTD7K lmmTd6ehvYzOSBzbKxbdePazx7GZGlHlV2CtRxBT/rwyrZBtLpYS/dby6dhU60zrLugSjTtT0Deq AaOqFHyUCgra2XF6UHKZd1lieoXJ7iNYeWIFoJko2UAPTaHrUOPwVqZfsou5kJXAmEGvvlRjvxVI TgaSlkIrJDSfRRJ6wsUo/LnlFuALwDyXEiniG0+lLFp5JtH6a81NH7TJXmNhTdHMQiAryi3MJQV/ eV3UJdW4kjtkbaTbbazaGT3t4xJNJUWbwdjRSrHkWh5/5epsVyz48ctDfvMQ2moVE6B1aBxQS5XI khN/VR9CnzXxpNF5k9ssP6+rhg1CBrKkEdEraIHGAjGhcVLn8046QquEey4y3JoveJKWV49WZ2s8 wwhjctxJBLraDRFGga9Q59Z7NNPwx5XOug2FLIliNd5w+Axn5AJZMUhhA4fGBxjuYsUyvUl5cxsh w+voBQ/vxsRQaG8Qak+4wvLONXQ1Ngq2SYHewekDx49P0n1MxYLxG4MGg17vKGpe6hRFkKGSJ4oF UpT7qXSe5JSOGL5Z+YKENcuAEy22Ztv+5livc64NFdXJDJWwkdKCsw2j4jBPD5+fIkGj7g8gSeR1 jfmpsyoajb2V/6PRgqQl0KK8/z97vfNqTsseF5c+l/Ck4GbdJNYRWCkMHYNWTfp9OZsVCPKRGUwL n3HLyvBl6heiIUH+R2Ib/pgHHDcXDBZY4wNOzKcZvc84B6fEU38Mcp1w20pPW0CqaAhoELbFCkph yV/QPY9Cl8P2N554bHtkINzsqxH98aNHkICJXXQ4xgglVqka7NSqyxJiwmNSRH42hBQuk2X9WbBb HBEvaI59a8L74KDhR8XStz7zQkcF7FNoiaIGhcsxmaBCYzdH/uVUXlD8pcD1muIaI3MxJ9UcvqnI pJRsDS3a8GQhpLHCymPhkT7zcY3p20AB2zZ6Ut5v3RCj9fm3Isx0r+w+euRrGtJF4Cpb7XuQqAmk d8G9TWm7BLcrKE2KwONEjfNCA7bclGpyv9u9kQ54AYcH1rSskaQZgxWp0TLyRTutHuWWh6O9EZXR NNvlQTsHe0O9auKRHooQshNrC7GOsK9yZVXfUTD2WS6hoL8ND0W5Cabz1mGZFJ73BxzgpsYhFY95 JKo0nBDaYhk59teIpOI9PtbGEEXzyiAkLKZ9LEb4Fpcix1M73r/zlCNGqTJZg9Ny1BMrOANNL/Dl gLw8XtVUvO54waUoZKB1y4J4GrO/5PbcOne+AvSqC4oryUyCuz8ZZiSQv44+Cwfba54Po17IGe27 FuHFkihnqcAd5FAhsUBz1AVLaNb3R44Z+BXjSMRsJjyhndn5O1U+OjWPOyseu9nrmuU5kx1aSbEg eQvSszpLEi6wwTNSmtL3pxfxb8D8iRVsB4kzrAH0PYpvXObFQKqfcd0oCu6yTCywF3OMmCTT2HAo +402umYDFfZibLBMMFASbksdLxp5O6q6WB7umXeK+VxOuLJUPlzqyqMJ31RVB7cVGHGahaTqGfOZ pu9VwuPhSV0Msb6mGxBEUe0OWKo1qcDIn6xVBx3CkZID2vFKcrjoUCtXqEQV4tHd13Q/1DPPH/AF olVQPRM5bGUkwXdgV8agf67KRfeHKzWc4zLFcAYwfpuXU6oMvxC517eahJfFd0Fd7AamBSaSm8jD 0djSPDvQ7+njEVs96FjULHxv17z3OS/ADBtcdF4CSngxVna1GBq7fZmw69zlDoHHQq7BotKEzKT/ NbQQfPZbhPO3t9h03a7f7OXq3kj70iG3/KQrF+wivE6/wJ3bu+Od83fJhzGO736jaGl3ZCfFypvg TRJCHao6RQDsHYjpyCZ34OteHg6Lp1lK+wnTqTxqjOGTpengCRBksi1id/0oi5o7h3MmJnHruq6W d+Rwv+QdxAV+Tv72N8fgHn7aZYMVMlkafNLt+zh+ZhRg0jpSrIncgnpg9rK9+Q1ygRbaBZiGzRxK oAPBRrA1WoMVjLne1TP5jtzAFiqB5iExh/G5oK4raQiYiU27kdPnHB8qpadPvNBzWWlGe+I7aFp3 PNM8Pa1qo93ZZRWURV6I3uo0RdolpJa3CY6D5kuHw8vrFCCSMfNvFLnEmn9Cg9v6D+VMzFvcvk6t 2HmLGNPGYOjW5nQvUnd5gSFHbcSXzdN7sEmsGROTfUMSNoHMC9I7fznIFHHvqp8NMtFMd4UMEG25 LUCMKeR1bmrHNYboYtRYxA0w9jQx9sb8QJgBEwYxX7WEL6y8CTRJ+IJpdqeD+JoOEfnXFVJBwTbl oZ1DEO0gw+JHDdTswOVImXCJTIL+6ntR8fmugvS1FPjnHBc2NAgXkZhR+NsEAVpEq4tp6bYLppUa Ug6r5SJFV8SW2jGKAPAsKt1tIp3iLnjIKveSTcyli7mPFdTiUT9msBpOKeDZxr7jxqHU9M6ecxCU A137woWZLU02jEZle+pLbbXbbieeWBvHIv4IZNq/u9EimVfb0mAQuIVZ/8v5wBH9WYHFOdF5xi06 EJ1G2TYXZcMX5d/0rl/kd3P71yE+BZAfQFj3uQmibPoO7rYQw4/Z9go9s0G7HHS8Jy+CBpdE6ZGJ htVU/MthmJhbbTi7r6+C8cmxjNQ3lVaaoN09usd/RBO9GN5lynmOhrz4ZTaQxmUzqJgiJWPNdLl0 +EwlfSjrAoNqtSs9VlocSwNH6hLQbLC09Cc/1wJR6fAuKllb55Fdo9iqBDLb5oWJdSEOoJ/ZANk2 6vRBS6Ji3dlH5CnIw0Tq0Rc/y3+K/yv7v+Zf5F+UX9RfNF8Mvsi+uPiicv/O3H8vvrj6osB/wxu1 +7vE/199MXPvwhsX7r/hrRL/hncK99+jL3ru/15/8d0Xp1+c4H/D3y/cW7Mvvnfvjd03ufv/hfv3 If4r/+LM/f/G/QJvjt2bl+7d/Ispjl/xLPR+8cU5zkfryNwMtfvXufu9MavK8VnxxVv3/2fua9jZ Da703P13xisucEeyS5mjxjng2dz95kfMOvZw4lb1HY5Po2VfTNy/Ltz/FTjWDEcpcUUE3Wv8VnZw gTu4NitocNfw7QTnn7l/DfBfdp3zL5bu70sc+fIO6wzmM/4kDvOElpl841q9tugKcpU7LT+nXV2l ZjI4YVvt11BWRDPi1BG4ya10MWEtGls7UKoc9DzHOWYm3O9tXpd4Q9l5j4IPePd9IAA3u8PY/JmG z2PRod0H0CctKtZMxfWhXSipHVSM0peg5QXG6a/X1YRlu7hCEvOcchaDxKSMxpMo+YozIMmJfstw JhEysQFHZJfXJqimA06kEvozQ31cai4jcZoq0GQ7LSdYUGfHboZGR5g5TRSry2KoBCXM4L8I0GXD qjqVA/SR4lH1M7cCXhQMKkcJstVu9ieWBwlHyctl/KNGhAskTGXSbQlTVRqUMcWH3ErJgcFMd6MF Zp7GnLdE3sapWABc2EBn78UGYk7wFbJRlKHOw1wIBSR+JCzC1itKfbTbH3g8hgnFK4jhfKZATdqa A+ikHj587US6F4JFxeTWpoE867ITRRkwtrATZGzH4MQC0Ti/z/nEaP9rroX/rNeDkt5YlR3K389L wo2vez3MOyK5dVPBmg0ZnYKwjJobTzQW7m9J1zaQDGvNE3XCWxzqxHiqTikGfYIG3QaklEr+fq5y lnLi9vliOPWKFWV8x9iE7YV42f0Qb0bqd4hoqTuUCPS4S1sq1T9hVzfU8QEQhCcVqGLh8ZYCU5BC SK7w0L8dHr+pnCJbdxoXz5HbOfZntqytlxx5vZKpFe9rSBsbMyMJSvwQQmMCLc6XGh89vpofwunC K78YyC/XHn+YNCNMb6lZ1TZRpr68fXxo3Q6+U6uOy4XikDoEFRWxpSwDHqyKsrhgr6bjJEVmvM+x K+4Hzuhj4mYuZthcxZHUgkN5uWQMVE0dx9TIbThSXrO4xDm8Cmx65rtzuvW9P6J6kh9oh7r2YIYN Rg42/f717IOHWntSGBbyQXyd8Iq69CKlmmLwJ8oylLTY2K2PqI5oQd6UFsjpmnNYJ5VveV/OBOYQ yyb/zoU7tqMxIs0qMFZwX+GFRvgQ/T9sDLAiLLBMh2OY/FRIUnNt99YOS9kbPZHmsHfZtN2yAmDw 6bs+LzD0UYM8P2L3KlAqxUncZynvjjkvBGkESB4CkvvUVraPedhsXcpv59KwBMKLwOjX8K8Ahw4L RtbRFP4q514Lpp1XtHOtpXuhld6oVDRdAzSco+k002biDrptCuwPKuGIZ8q9a2zHifjAdCAAEHCu jO77tCAlHMJAXSaxNsG/NoyMQ0A9RU0PA3fanaW51kMiOEqO1Le1IXWjZk1IaA48oeFIvDbp1HlI J5hhiUc3oxRkhOHk6JSfM9ztiXi8FFCnrrearzpOfQ20tKQ4u7ePBREgUYAN8ciA6hgL/qY40NfE LromaQEp+PaXYTdtAP9K/CbyEMUg0uVtjNORZnR3JvXVx0Dql2RSm4IsAQkWkR+GDYL5Ryc3f1PQ 5C1bTwlRx9flgsDUlP+Jyg4bed0Y3yzBljB2v2PFXMxLoIZ1tnKuHHw5G3qFIj8DjwyABzmehqia xhPILbnXoZsMRWq07HCGRG5ZAaz/2m4P4Qjl85iCGW1mlB0BTmGAP0dIgHUir+uSHcfEGDF8GnrC YCw39uzjRlxf9clEhQHigJgYBe0750rkPnZTXkIUL88p6jigmUMQlgGwmfEUoWy7t56lC18voF5o LuRuUjZUUIyNIdp7k2KoG6aa83JeTLF0urfgwOAtaziULruclU3BzpsFlhqbYvElShyDED1oLAbz UcoLGk34MM4K1XLpO1F5A5iONHJ9dzc7Aq8tm5MwAAgFkkgtba5hsGJG9UOh0eYixpAIJSgdGkOo MbsbkRHNgxb6Hk3KxdcSwGtHJRyBFZSLpS4H8NzxCwfiqr51u9ndCzQ+7H+A9+UqysFBKWXiSHeO bU11j1JzOp+8LZtczFKY/wQDXjqSN9/Mx85oExREYG87zaB8bZQdVnh0FUW+FFF2nnT78wIWwOOi zi+pMx0mIZ3pBjHaHgOVZG7AFS76EgeCCD1Fy5RQKOgYg1I4htYjxZmowGyyRHwAAYsWAa1XLCDx YVFX2CyU4RJ2SDHatlprGovXL3YCQgersE93w6egXxfIB6a3qic8hE01hZ2guUJZ/oxJTyW9benW tywBbAouG0E9KHA5ILOTFbbxFKFmOtHdEnrklo0H716YlgsdETkjatO26VH04WkgeiHZI7HrusjB 9n+xnArLa1WLwMyHG467uJXIOOkpvmpVz+7aKHxtp/C1rcKz7hdsGAflTsPGSh/pksqIYdt+TaYu aotioqmI+nJAWkzqpAmo7GXFuk1gi576fOrwBXpJRhOWnGATD0/MDLIg54QsUyeDjjbsna7ZpSZl y1Srw4a8JaqrAAeOABi0LMdjazmuC1SbV6LIgG4AmuATpvex6MjixIB5RxSvSnwBaRtLMzzhRO/R w+w1hvmYpI4oxOEMTOtWSQre9YsVsg8lnGqk7JRovpC5odHNxBJS/+2Ic74aZbruZTiNwGKpTrcX ZGCWcSAUgVl1cT2vamiOPYXaAA4mQbuuBVe/Yx2QJj1H/845NC4kEILlHqslVRqy5Km0pMZiT1YJ SLE8i8RBRAld+DZ9C5XvNUrQZ6/nAffEeEtTSs6UKUoszAPSzMFDkwC4Zm19pe2PEk7FkqQoab26 qFqMNWCoVlNBnm8xxXMyDmbFpi2OPeaYFLfz4P/QTblr72QkGZs2diNshhPuiD9PWfa5KdDMPoMC 027S8+9F1fUd8IiYNJgcW1u5HiUi5WJxFei6GFJQWTMHYlPOeEKM6uDOglZeBp+fOyfDy0aYbkeX I+zeDiRjEwwnAXf85iVlym9T2v3eaOdRX2vogIsCfU6wuiCjnZzPTryD3rw5uoZGO30hAI/IUoQM mBymDGBWFEVrI/nR4xKdr8R6IAVNUzaHKNu4Rie39hl45kTR8uVduXHyI4VB84mjhcZTzOVM4qxg VLjOoE4Ib0k6S9j5hHxN9wlj0bgRD+aLJCDwLfRssSlmUhT4WIr/3DoulNg+zjjmHAaXdiSOZC1u le6xHmnvKIhDYY6uGxy5cEUxnjVlOwxYxgZBcr6sLwv/JjDCIp+QyD6UnZaCG7QEpCIY1Ew3p5Ir 0xdHdvQtab2YWSVyk0AOYABxEkBvWARi3jVusFEE3Dl38o2/VmbnMIJEcpDp5ArjD0C/dHDHs1Oq BNZXhO8jSKsvq4nDchhAIi07POcsQfAXSNDd9nwxQxOciWlBoGndhqoIgdsjl5ybaUZFYXGQCCDy Bd9inwRMI0KAHhsA8Ypsi67gFvKl1xf8fbcJsXQGThjx5nZKE7fKkokT4Jo2KxJ6FQ6F2BeQS7kP nPRDso/TGiE0kTUc94oPZTjmFzlS5K+gT9XUm7KYtIxW0A0CaGTyvje37pLX1UyyOnRphgl66wQR AkKHx6iNOwWjxlhq2MOfDEocY0g1RbSxXC/IkIVTwJhtOS4dAaAh4VR/gQgqShch1Uv7z5n4oSbP chwclFdLcDyyQtv4IHm71wvc/Q4BxAT/3fxLCCmlAXrWCS9vkP0xeJQIy22/lHDiB88JTseHwY8m hDApHDvxYxkOA6C6yUuyz9BjLXCKgebYUBYNHpK5xTdLh0HyZ+V6PwEYacagRfV8QVUknkS0aA/Q LeSqmoK/fAqhoe6g4ScJI3tbkKjsRSDUdObcVM39dZ5zn3tWJoLgLsES2KgpYu4pkuF1OC0JIMDy o/gsraRO45LIUS5yiX0JsTu3SQzgToMbOPed4KI9RdEcVnh5/938A8/JBh//jIu1IO6zOoCC1nU1 UVDNiI3BCbsV9VmoiMLxAsnG3RMnLEUVuhYAWk+6maJiq5eYiifIMm7P0GUanOJxVpE6E7mHMqob l3RxKhSRE+ZA0DcPts0mqeRouNb2WbFSa6kdE7sncSCZdc1uQ/U5zxr6nCggr4SWcsxg0uOuuty5 oZLhKVQUDgQW5TiIj2wrIyTB8HFa6f+Jj9+4dAMi4x25CQriB0+Rl7bwFkyWIvPsWA96kydd1RdU uxYEeTXtBF+OmR42KkM4vkjqFZqpKMBw20TfR6fHPeWMcCimf3Kouls4gHPTju8Ve93en0DT5eGi GuI/PjB37vXeZfHy0KD0/kWy1umHrIf/edfxUbpgKIkoQg++a8BLyRVGd6iZmBF4st0Pks7ScvXG Nbpwf/Ith5h/r9YQvuh6q30iY+R4GwWnNd1htgjnhMRsOk0A9BvxY34w2YABjpgL44bqZ5+yrY/Y lXTq+D77Y8bFVLY5HH8APBOsoAUUmhpAsCGoz/0QEOvwdFLUGO+ruXOpwoQkL7p9xiXGS7Fewy0e j7LtV0HrwLiAL6zphquNVeJObKgtqLkHwM5+ykhHxhKSfa4HlU4IM5APe0HjWZhChiJ5d7Y8h1l8 Sa21R5yZO76c2bxYpl0r9c2QZE3a5MnrvymqxFRIUCpFJqm+ubY7UqMzHr9cirgrdDNaR/aIfIHi uFxUwClI+ZJwFkPYMBj4I6laNPGQiJOHyQc6rr+Ve7gKji0fyzABywQoLU1LQ60FtN8+zESmWLr/ xmQLvCxBX190Avwk1l7a2Q+UV3/K7r+TvGkcGZuQRjobzpbTKWCjiftYN4GxHYFSFr6OgHUbei8T ffA1BALnTmpRLPI97RD5DMt5gcER+zMvHHtFVQ/Ivh+KgrEsbEwKXYIXAAxpsAiX+6/WKHt0D4Fm BzHCOMrHiJXgvEbMzrmOR0C2gjTgBBGLw3FWudPYWsG+MrWjP5b6dWbFkV1DIiH1ekf+K+E0eChi cYMfwrMln5pkIHkN9Dp3z30WIKRnSmRHKEuyAvGZROXxhqLymJkSqzgdyBVttZQekIGHIWRqqxGN K/wp5/tI8XstXf5sYn3F0RoaQEfwiiLDiZx/tCTf+cVnEuN/XmHm2ccJGykGmRI2NkPPNmpuyE3/ rtjVV0l2RWF9vVUWirj73C9moXh2FwvFPN3kQY0UZcKokGzm8GC0p/OuKU4cLmTTBqYJki38Rjfx m7CfrL3cvxEDyl3oZ2Rm2F1lZqDyRR0h3WXSDDHa1A5hrRB4lfmfOOAmgv3uxwv2Hrk45G8NPrWS gKVkTpetjV4wl1CYgMYYSyOKVnx/uTpFIdKaQpbxMbYdD0a5g6046E/iEhSi+JvjE+llMafYedDB KtqajUKxW4kp46CUT9JodjfQaHDLnczHRI7/korM6CM0mSf3mswvrsk8+3tSZTzt/GhO2slCWjj9 d0ZEdyIiigjKFS4AdELtZszrgGTOJrnbF1UR4vwB+5nvWyjZS+VM23QI9+NS/Wpxss0OAP0PZDCJ l5ZLodeBLEI6KTtWwXNLUaQTLYGA8bcL76GPvswxtptgpW59t6fr4roCL3BV10uKcGIAL7HqIsVY YMsh+JQB4Q6YGyEmywpILQnpXKGF3apZOvtF4BXt80wK+xdSqHY6lWh049/g8lHuXkK8rra/TFWq kaDvUlo5bNNmsU4/DgDvc5hpuehj+DJWg4cbz82PdWLOUkChSeP7iVJArBcxBhgQI7SkQYFDyn2K QuSQm5yKDOaU7OMABRFqjvDXkxuYHgL/lzU1mmdSQWjFsKFDFVQamOIvC6jZqkmOEBSpABY+22Tb Bw/wwA52+pnkFkB+hhPSbjRTSANOfT/2JVI74WlKfrkqDWKJQwHu9HV86KRxBDt7exp/sjA5F+TR HYrnrCDPmXu9ILkT376RjD6dldNO2LsVhj84ogd1dPSu2V4Rwqw40FKVRicreUSiRj9ulhfcXQh7 Bcm7ukNNOiCB4Wm271bgZ/XtaZVHYihZbYopUuqGiAXRyNLqj5aDi2BUxtSLyZIyLejGGjQhBnR+ jhWX0L0EHVJhEkDSuCwLogsGwFpiQs3gof4ljil0FbgRYAwt2eRD0XXWc8DjxTV5Ph+LpgwS/6sk fQzw7t/UJReKvPVhRNEYiuqYlPbCByIHeUQ281mig7qX1Xihe4eicFLSEW+zINpg42c07BQJWCBv 46NWx9sghJKFgE3sl1hK6I4jfR67ZnvmqF74XYC8uw7IkpWmN0jb9BljgUahfRaAjMhvlDDl0JI4 D2AbI+Sbon5LNJ/uSoPg0eqsXOgaw2ZRzKea7pA0Q3m1dFeQhZJIAqleXZI+yqCUJoM6EoCBos5k Fhb9zvM5TuA2DhPQTbJTID0gz6LJfG08NylmQg8rTsICjohnmMq83vkKA1mJFn7FAexB/gTXEE2B lQDa/KwQhT3JTrcRjvAGwJcSjQyU5YEV61/44NqdPZC8YZUqYGLGKEc2BrF8LcSvi6HNs9wOaRhc rO56fJyuHH6SiqH1hrCW/ciJCH2MfEc+OV0wW3MAc/eHhCGstaWZnUyoKeRa05I1Qp2ubyX9guCP RFWs1DK80Kd7yTlbmb8ykZgWZqTuIqbtPcCkAg8otwRZeM19rgN9S9QHSTCsi8WypiQHrv+lzAYl lwEDp2z1u3LvzwkLCg+CErsEkYXSpFl4SYfgXLSgDKIXiDjM4Y30zmUFMR+ZJPlMhFIcrInGkv2m 8MJdL5Y9WP1aUduPIZU6OdLJKC2BUyOguTkCNkoPlSvzEER/VQqqCzZi0bPRDopxy7UFpDsqRlMd 2rBCtBSqr7TeXqsUX/QFWG/6opk45IBuowXAtGzQEHYxrTDwCp1lxHKQvacImobgYma6kB5V8VPf ND43M1+YV1Gc01wGLTIJK8bqkofL+VSKr9ei7LHgPKGWX3oII/YnNR5s8I0OaqrABxWAR618bsnI RrK2HZE5B/NUrWAJF9fEbghdAcMzpjbRhEoTUuUptGunp29RBQ7shOn+eAsNCM7wQ5Q1VCzgEgD/ WRibM9dJHSDjAOEHQHfhe0xUFx5CMdbBq8m6yE41Qcpk4TTN60vkqfnMLKT0lY+NMof5+Oyobbiv C0So50BTHWkqJ165I3CUl7OqFpG3lfKDMp6o/cXEwfWN7IkECJXW4A58B4UYcVVzsmzGnCwxgyYV AX3BF0xKuZRl1HZPsWfTuAxMAmg1Wy/lyXg25awjwPtTJ9mxImW9ZhkZFZeoIR3zvTwFrkDkM+jK DSLnX2zsPtLnrjB1sBokS4KxLO0LA4joTA4YrKwytI0VTDUxqTzjtNgXO9j8tXNBLa/0z76gXVwQ sfydLLWwxIIIo43QYgaH2UHhpA9NMaflLL8+Ky+XIAFsS2Ji69bXBRtYFYm4I/vhrfueozr3JW9c sKvfrVgQBUjuRQzR3ggXmBKr2rxBhAG+am6d8s+NL3o9E/qWJAGioiIpGPR6ooGTaKNzAd4mzGw4 P0nRORbA8gUpwq2gfIelX+CuJUYCCoeVX4uJyfR9PHo4gsL/d4Yccc0GE4Wg1yYVoZbCpjR2X2Dk jRYtU4VDV/PbRA0VuFu44pxOCtUGWJYMSQwWts2t99Qye3yqLN6WwpdbmK/YOjrIoiUjI2d70Hjg x5YybI4pTieeFRVIwdplvFFEBkY5tmbGhNVj/EPLOJOqu6ZOIi/T4OS4lvjwLBjEGSdtZtQsm6zs jecgJZO4lge+DbQ2PTnsPw34tbBWLMP1gBqzDbTB4VyBVbBxgr5Y8zygE4YPa2Xo9fLz72fVzbSY XGJFsRJsGJxBP0jr4E8GgJFZ73wKpvH4kBBo1k9HtqpgNyN0LIcbVOGHg+FReW6b7kNxhaTINqkA pYVKp4BI6aQtLEEOACMCosMJCXKKiycwXpKlGjixCHKes9c5YVfELceUHEfW4gINmFjx3OGYQOav ljN3UCxRktQN+3AC9PUcK6iMCyx0EyAmX2Jz/2cVFYcBUGJ5ILx4Pgvu1NhSESMwgdjyTqCqzDzL RSsWo7UNpk2sUslCBXyPoMRnOZf+4E7Ac9+SLDt+ha1SGmqPRBnQAcwGIh6Hxk20ytFVMO73BoyJ XMGR+se/k1ROElrh4N0KDvc9kxSVGz+C2tOwnGcZtCwB9iODv6TBs23edj/7ETAJ9x6dR4TPvt6F tSogifAXZJS9nhmRRiEtFwo8GnDLCOGbCk6EUc9xZ1XLzQxkvKnIprd6ZLQdyPAsiXf3cuhQt0IS cVY4Udydv8wSeRabQhNXKSQBvAJR+ild0BmQNCCMcvIUqiW9uA5J784XVM4Ob9H703pZfHAnpaU7 RruYr6AZuO6lUDki/gMb/WZanX9P2p+tSWbwjayeMc/lmkkz7KAKRR48acHICrTf+ERZN0LKuEx6 0yybujtaVS9gjafViX6Xu1UbEmjcuMSxIDrzbVnV4jrUEjNEtLmUKptavLoEFk0OhqgLuKSgGTsQ qBMKPUnsF08Cym5hLagQmYGeFxPp1YjE2jIQ/QxppJj4YR2ixNIBDuKv4IYDdm0CyNJ6wn/17ecz RR3QV2I/hI4E6LQKJDFElG7cGSJEAluXfdtR7TUkMFUJaRVlDItdY1AthEmkyMwKIuqDaLwwCDJY DtUdtKZYctQUBc14nwaIoyxMm1y5UjTWNlITyEtX1+pAaQt3oUwoC0hQz4+iicqQRzvZ/rm4qAPD C8qsarBTsTTWUYL2WWYlB5EKvsY+0+udJF9AfnIOXAhrykELQ4wR9zgfdvCi+rt3BUe01knpBLra 2zqJY2iyV8pnaMR0E2Sfqp9nByePghk8HSreGhxrDHirqVIcSdp/sfvacfKX4FPiOFizz03Wg29o IAKFBZiYBSav1L4xSK/ll45BMRN5jOB+fEijDXQUZV+8BE+aysPnMCV98LJsrrFDZ2QvlJWWaD8J QOODt16y7TiKwfzIHbElOkw3UJCu2lPy02HX1gbZcjYFxYJPikpCCg8PAlMXV3VBKoaZYahTGKcB +iEoIhCYjogGFdG4UXCpWte6JTcqhFnbTxjQDNPUCny0XfjZxx2+Otnf959gwFJU3Qm1Wzrf7WJ0 OYouAuuH8pOvsyf6d4Ilp8jHBtdDg66kSAjafwpuL7UKgknpW6Conr5P3HpV6z//b9Ym/OtAYuXN VAxOJlVJuJcPcGab4VBe4WK2EguK600zmYhpwDVNVITcIIR0o5s+g7Q3M85zCqvrol40WBC5vm4d pNAl3sTgkpiS2ZBWeNsDwp2soSnwS7hyE+8lUp16eVIz32jHUhyb2HaD7QbQRdTodt0aK9Otuzmv 5kzMyq4I2ZFdth6frv8zLF9PVzGelq2rhuP1Bu2V5zz6wI1EIXAkki5sw8C5xjXT1EoyTg5NmNnc o/ys41rorXAXbHnJmp4tWS30JJktKDqElMjQLV9zu3ZfdLcxy4k2Rgeu3wJPMpG5WBALwxQ65op4 RKvOL6XxpCjTJ5xTklLtdlCqjpj0kFbRS/Gx3BOrvytild1Tqxa1Sl+MdfSqI+Hi75hiBQTrhRet lF4x0saGTYqkq+oVrQnicalVgqzwLmNHjQ0QAnnQ8SN44eUxK0IrDJsGQ8t1IFjRgYGbqzSZ1NsP yXz38fp9KoKubvSwHporWkH8XMu8w8EM8WTK9SdzehVxGbpXxaTrRgWaEljc0LXXdtsNAiaZc4fV tv8RHPU6prifrf5ZoukNNOnaBtzC8jg2DBbOjAq8VhyXiGk51iagmSA8uI8CSBhuvAix8jV/ghj/ YwpIY7iCd/u71V5JqCpKKLBiX5DaO9kp0uWsiCjwi1Xd2Vi9ZB9i8Fa6oKpqqPh5n8kcpfYAGcvE HnADrJOKY+MnvL2kJ3mjk9QVm6Osgkhtf7DwXUdizccebrPZ4fIiuQ85H6g5jfNlDcHW01ubsAAn xHY9ByYGQIQIEne3YLSGodunmlhLf/P7BDH1huBuB8cBOBNn7vQHsfmDAhGCSI8oxIO6UqszrrVv vRe3DmIY2x6P4OTDsYbPcCX+xCwmrweeaJi8QhSnl8gEnn0bV3bb95KNyjsv0E46dqtKpuCgQ9O6 yQlQCIoD9+EBhknYTw8I6Q8IvZOmogHijTgCWvOZcbtegS3okuIwmVyLXkSLDQ81uC+JI8220WAV uUEGCdrO2Z6U3VzTHz4rAkfR5vD9Zz8f0ML9JcKTEigXHXwa9gcSy6OJMIKhayJwmF7Zrh8lJXA1 ji+X5yWIA5xPq7kqSPABhiacjAUilSwl2D+T/BRq/Eid6zERBjNbzky/D/JWn4stGobsyKw9FmHb L0nCFX0xARlDJQUOHsbkBXFukXP6TOKV0PNvvGYTduF5F75EIF+I0FUXeVNFIneheUXv/8I1zdGN ZeMDvurLmbEDtqSgOs7syaJmMHlYPTtOqnE/HR/2JQoO+YBkM7BxHwUve6dyyYsJBh60fvEArAtq 8aPOoGSmNF5N4VdCJxm8uC7u3xE2LKFYAkmSItrI5dNpu7gx6YWe1/WtUFh43G6mJdULwDaAyaIz m+N1PO4T/ql7U84VV+jThhwUc6qBE18C79bc7XJrRsEl6KBV52bSe7t9AL1psNJ9LX5eoCuMM0/6 sa1fXaAhAq6PUP8YF+j41W/YBeoWt86T4F75SBco7BzQyJHGz+gCxfVksCB/jMhf0r4bIlbQzUx0 PVneCayPrhxIY2OxdcEk8s7EVBwZxzwaXOhV3Rp5d4ORd9ePDFCgJmwrzvxv3RWM+HfvCv5oVzAg WvkZXcEwXrcr+BM9wUgJP9ITHFPRDajERp7gJAA/vyc4sfXqIz3BPw8kEhczMmhV5M4a/j16gu99 K79fR/C9H/g36lUZbuQIDiSIyBG8jlYFDq/7uJV7cnVPru4dwZ+VZD2vJFVqfJKF7UrT4e3+Eunb tBm8doToasqlJ7Ck1SbWhGU2MLV2zVm2zK3h1DoyGVWJDhvb62jFwJHzIR547K3CNGy52o4c7pEm djK6DuuOo74lC52vv/rCBhHpElNeziDROTo3KURofGBwDdFUquZyqq0PGEMrSeZRPQhSm3f6tLik gZxGgccKgFH23QwOCwq+wG/XDdqjGkZkOX6T02VthZpJGa9qJOn1u6125NAtmm5elie/Fftv40CK lwSy38Fy7U65oFI5XFxoJt3ciW7aTBSsaHVBi32hba1Nlk6iYSHY1TBjhY2SJVqjlzPfaRp8sctr zZ1Dy/yZg+dNOcHMlEnbduljhpJmSERONUWmXhnYy9GYiwjng1trOWs0GxyMhJ1nBKyww0PP3jE0 dWuTccR3rAlEjWVKtc0X2QGofkzfx1g4Er9FkECbBvqLcF5M53giSF6BFlYzT+NWwoP9pLhz6+i+ ynVkGMOXvPHS1TQvrxl9sGQvW5X3jFUZywWoI/xcFwIaP2fSRtUJ01KeeGEL7JIpG3LDSD4ugk6v 4TPr80oQY+AXXpZN+ZhKGzSzpqq2tWYPfCpa7vcroQU83soDaYLx3LXzzE9umBtKiJF7V0N7wuxp T/jbdrlkNHlb4g6Z8F3qCDPm2fSwA9QSTG3mfIMCw0Rdw2bnycXnSRkXdz7a+KR3P/NJ7/4sJ90q zrPqpDepEP0bPuuO5a8+7f3WccB6WGeFX8jd001Yayr7du7zjWU84LZY8KyW7sxE1E3VK7VN6rs0 KJ0NUVSloVwnucUS3MBc/3HB7MDqB3107tYFlS0gD+mMuYabO8r57KKAt17LbQqntQgfB3+CUNXK VOfiggja02P4Il0aQYUVxwhm7HlxVJ0XZJN13Wlco4jGDFQOalsqMuDWdh5oT+nmCsTDWtYLhy5L HWA1OZD5s/dn4PkEV7/73w/9oEJEjrFgdvAHD7IvN94bLxBVPANlFG1u8RCawqHwhDu2W00x22Z+ NJdeLfgPfyR06UgQmw0P97PDo0MTijKLqlK5fU0qQKIr1Lr8wtD5EeFAes4mw+RjKjPdIDw9G3/Y ycbnksbb4uK2CN1EGZM7F6Fc6JULPOJRDJ0nylybbRppuijjrw4pXRHJCTULody6W83tCNGzM74k KYj0QkGEIdEphxDe/hWOoYa7PgUhLw7p23kw2vnMAkuSd9WGz6VewLW2/MLvnzuVFzzCYJZi89On S0by/cqM8PBrwxkKbquLYju2yrntrClHxVckM7zASlAYQHFRaqDciRROQU54nggQM818R9lpleVv q5JUVqLy5RQqo1cXWOadKs+S8QSK3litFLSKoRa8MSqFXaLakq4RJmormhXvFqQoksSfs53MlAPA JUkcKkwu9pi6EA1hY1AJgbnrwf3WJM+TvwXJM3F9knfu42VUpcGf+c61i0X+Bu/cb+LKrYdU95Vb fW4mDOW3ogN8tlv3UTrAzyd2+Tu9lvNKDPw94/sNXcKP43v3/O5u/G4ti+u8G3+nDCr7G+ZQH3s5 /h4ZE2vXjzq1a/h2de1JqlO8icGc1dTVw91FSX3OjpIue8IBdN+7Gz81iCQeGDTTYJqfFkQsFtHN B9GYMbFVUJXKl8q3eLGb5Rn5ayCVDALxucwb9jQxke+JMPYutIY51FB2VixusCAa9PWqZk1xvsTK eAsDcHVPakckNcDFRrboqIZqWyMfK5Qpp8hUNP3RlvLzq7KA+ALoX+YkH/j1Nvu+KObkHBQjH9bP q5HUiFuckxh8YzHw093ktVsCGpAcFl0V+QQsJrfZoji/mpX/ocZMn/pg4CE5MgKXNSgIaLGb/W/z 2jD5HvATivI/m5rb9NidG1mL5G7iRgHcZhTAoHZpTzpIH+wfmwK7jkIoCO+cP2tjBEYs1DW4W6WC PZzamfZF8Aauxl3eApIw02odsov9VyPMrbKuVnQksA8Z2V8i/Ni77dBtLKyHMmADW+Y1zwwWsuOZ mzwnptZtKkN+ZpkZufst7ekCp0Jze1MqxB55TeURjwt6pX2DAFtvl9lqqW0+B2iqDW7gOXBdSPoA C7yj7HwlgnewIj5ClU9Dh8OQBJlRqh+SHXzc6+09zP7LMYQsAVV2dEQ9425MBFI5KzRnDTKpBJ43 V9XUeKKxjKJbFCD3gIyP0MbOkYMMW9ggJcizC0pdarBge1g++VhCqnIyY4IRltPYbAfEOOOthBQs DEKBZiCTJWTYwEKUMLg9Psr+y53N/bjKX9ja/+WmGImL29jSD4EJM4UhyXlUleCc4rZBHI1wFEto hmHv/lD15mLgoVuGo7hLuBM3nJjnY65UMLpyQucionkMZcRYW0H5W0dr3kLWKT5ma7zdKlbcFLIm 9BQ2Psczwc3jCXgJU3dLUS20ZCHTj7PDAiiIF6CmQD2D8qdEjKPC4WW719DEjzTILktYRe4hGVbl HJjYxdw06QHCXBdcOQKDoQYQaoX51hPp22MXR3jJLgTAOGzJCcpOsjY/SL6UfT5tqtYOTBoAMU4/ jek4gLdMNstXoEFVwa2TNB0wBgqDDwNS3Aq1e1wk1eMUsgRAVySp4LqgLhZARyZ/XTa6vq7+rTSS ZzdVuyqqcfGwZ2ZKoglcCdETGXQoUSvCjHa87MWZiNIYOtwpqpkPuRzFcsadPUjkbg3h1QjIgOWW nNS7r4I0V3r7ZTVZTp26NMx2+pJL61fLLjPMF0p0eG2FBs3o0DuOwzG15L6aTr4rIG102KTe5pvV se8M3gaWxuvKKXy2wCbaswWX/Z9eunNaXF0TQlxVVSNYIMsqG5VjSRKv5oxJeLb2VUpWdXIHuJlv Z+dXdTVzgJPqT3naBac9IvCUMAYYNhnBx8dKpxCCe7YXEiudOFki0wUGb3My82l19O7czQ6JcENH +eQrjjNUWcAjtQQvOtYXdcq1UeTUMJekM2IZgXPdTbd/WWT/kv13h4juXz7s0fJegKGmu8P14Txr 1ixYXlHTwFV52cZF5DzcxoURu1wQjR1KX1/ejsVr7IScxm4ogyE3dtdQimlAKTh/GE+LUuA8Esck w96qYsEEaNiiQA4iBLdR3BDEyU0T0UiMScBBH2ty4NfcWNqxKuAyF8updZvDPCUS+dzHvg0I8IHs OykEQVeSSae1VLW0n8GzcSvEP907o+wbWkswfYuOxovJ77gSb9hye8e5DbcHemw6ZiEXDMNLSlJe 8SMADZ8ASVkaHugQCTpGXecs/cFVwbjb2o9EwoMpMt4Jtho01KLh7gaIO4GPHuvlLBLF0pGo23ow oMv4iwRacZu4kqrV/OAbaAYki4W6JRTwuiSZjjSeJQIisQlj2SnDsQDe0rMQxpG+SqiMj21vpYRn J3W2TQhmuhe04kCH8UqnU67KwAqY+74xRV1XtefDe12iGwwdiG8k8WjoE9K7RPGdmOyPVQzoKKNE mOR47tuCa2l9qpAYIQwzxrgxp4MzSXbpWOK0ZAksWZNSXlDWwc8mZoYcQuuhFJZ6eA3yulryCR6P G2mEATIm3EtVQkk+436j/L6PvolAkapbQwKlRuxzdL4yJtPQKiCMp1j/ZMcj3sPshK8bnDypKh6R OtElKVowjr3BnC7QXNnQWC6k/BS3uhqfhC26KLYPeRLUV2kwMckBilsF0QgVpZCRUYXsl9wjIao6 VZgSUV3rd1rsG5KcqAUuii9A75MNtQDXx+4skZyOBQ05nPsF5FcoN63mKqSl7caaVhUq/UJoi+gq x84Fe2UBA3yrOuOvQOvEs16PGUosTpBKw7aDKwhybOhutcuASXBEQPpsgRhbjCpO1aKGvPAbFxlL KVBnBS/63UJ+jSaLJ8mhtRNN4SQqzVNC2AXnpkj+CLdieIVnFIzNqxilN/25w+B8iTNo7V00Pc82 ZdtuaQVZ2oMUCMny4OU7rANpjyIJ+dDBzoOZKG67Fee1UyeWhckTSHFyMb7BKJC2ci1NxnBbkcCL 96aY5nNgUU7xOPdolxjbDDeIVmpYHiCvsRgaBZ0CVR9n+1zjgdFG+SCqsx1ZHcRXQXoEXQUtIdw/ USbJIJuJmT+gKTMBL61qvb/cJABJwlIHmy+5diCLI/Fm6ehY1WDpWFWtNmnDGVfMli7Z80xyu3TA MS2NETDhtgPEm1EGbdTbxThCWy4euUkAPUZKeTe/oEtYtAZUysvAjvYuS7WoEERYhjcaD29llb6h qTcYfAkLAR0M7WWR5gqqCKBui/o5IAUV967yZhVK9AMoP4u7gwZDKQ1uUSwAcNFxpVehf1gEo2Ft gI5mxcUeKMFRX0jHHR0QwbpbBUF39Ae0rRW9FmWEAzdFyrvfMYnDpz+wmIJi6KS4wBvpnbddonEk NoF4Scbina0EdPXp7tbW1kn237IHuKF/hX8Ff/8R//5j9PyPwfOtf3M///vWK0DjvfT/uFf+6F6x qob6K0M5jvJ3+YqjdeXhwB0sOZVYiHo02qL/leHpPZjlv7pZ+Fnyf7Z2sn9DiRQAW6g7XZWfGIxB aaLg+nndI0gRhx+OJFhEPoa4dPl41NvJ/v2jl4BcIZDUE4L4qLebnayaolMj7tiozHzXne46DPmE ZWy4WeoHGq95s/Xi5TVrhuVKEd9CTAwRgd5oWb2HP/eqClsda0NQPfq5FxVlk2+2rK2tP/R6newx 2OcK5vgRVU9D9qaU2qbRs8xaflqR087NrS52upL3gzu/xfrjHcXsTfbT5klaiLXU+Drwgvr6zlhk cSwGaUpEw1COoTEviRAk9ZHZIzE+6XfIb1YGS+hzoSxhZDajYLX8IQTq5SyxrtjnL66gQdAonbXI r1ndMjAEfSjk11SB0gnD34stgzvv1sW0BFZOzhf+cd5tULqmEbyFhTh9aKbFwqpUog4z192/UVzo sHchIonb63UrUwtjpOggusMvWLB2wESzREsgdqCvJkTd17SL3IbguH4c6ObNA0agcaImaRE/NNnx YQ8N1BA2t23Svnb7vejoe+3b3hNtC46hbLwqMxG3GenSSeeu+NPBk7VhLW01uql8k3hzRMp6cp6A IoA/IN2aHV7NZ81NQQ8pkAaT3GihscvDnY6vBCCI/5CKoxBueKKGaDHQUd0+ug6f9HvEyMid4JaC PyfDcnNai8MTeBVGnBH6rCkmAGmIfdMo3IfMkNOrpPoTbAlbncoyinomSDkncIywq3nartkwZH2u uiTTLBKqYoaKubWyirKS2L7oNIL/mFgLioqU9xHiVxJn9ozA8UCxOgclk27VS4hjeccL++MC14AM iR4IAsLaxMrkafyiiZbDFysyLY999BOZLexJ2DracTAa+vRKLLuMkJPNWBucjdzWtyFGE0BXk2cN MZ3PsUapKYfAlfPpsgHDch2mc5PVnZsSuxEcQOkc4sTyAKE0lKyavS1uGZyhR68pcG78cuIQbAKC E6buDmiJOFnN5vCcwlbVRKKz43JpRTXlqsdvBInvdmWL8nIJltpttlUBV5eKLGWUOCwW4D5ir1xC SYoHJ3dtQBfmuzccIfti/9Wm2aLs07N0wpMPuzPcrhbTwC2KrRjeH07AAylWaC6Vuj+dvthBn0e4 qrX5dB+zqt27rGoXVtXr7Z+ZWDGCIRcAX0NzqZoBHQPHxrNngwYxcarVAsKuuS54d62f48OV0RkD Cvqpk3HTaT8ZEMXzBS8LQGIpIBiRYHo3EEhgRCCY34tl04McAVpS3JvZghpznziF4ryrQzMF2eFv pY9hQdbbGQYAb8XOQub8MBCavSqxU3MXlYSsRsIk1OuZVWSpouAYW7v4lriBhK7Yu1gXEBLbjFac y2ooQzAoOvSXc2RT8J2Bn4U67Lpb3PRHsZEwGSTptHEO2TeIKEpvQXMiEcseL3kqgybh4oZDBgKC +AUbQlLo4a6asc6fcKkM3cvAOzvW5dcSpc3nUP2qxidTvPTi88Fj5qvfg4kUNZ+qu7UI6m/pitph GRNHYjEcj19bvbgBCULkksR0pCYh4/FGfCUuoPugRAi2S37CdoM6IatBhYkZ5WNCQEze5u58mQeA h6NWwQlAVNQLdpMieKTxwjXMjFVWyABsHQ0raSbE3AE7ukJ8Q1kGqHk+yeeA5k7PYSvJOuJr3DDJ bJaPSGXBUKkGtXI3A/7RT/nfWsZomZKVV7gU4klE5c7TV2HsawsL2XFFCX6a/TmflpNczNUqZVJK USf3k2Kq5YxCXSjcT8M7oHHCDBRMDmxD8RgiSZfY3yzVbIPYsDpjFyqoydAoy13k5XTo1Ks5pPM5 8RXz1ujnJZk3iOSJMyxFtNbG5C3dgykRbz8ux8Fi0xVCyDzgz1qbFHczZMXt3KG1ozLkfMNQDLoJ ZVxKsyNpSwKwOHWChH6HDH/SSF2JTn+GCmGcOQY8DZN7gsnqYkjeTfjVujZpGrIt4kOreaTq3uVJ B/QFW+pKEzBA5yJIYLwjMIUj9VM8YbI2acnQwO06uxULnLuGdBo2XFPRy700PGQs8Kc7rS4vASsw eB70VglkxxFIcjVM/VA27dGjgOvFZX8pmW6Rfw9GsYpTaCg8EEnXMD8nFWaUvQbFL0d6zQlZmRRM BrAQ0uGoGm8ppxViqnKNr7IOsxDngLH61Hj0IWrLVQQDhQqxhoVWfyiNgB5XMoHsMXgoljCFiSMD ZJ2gO0AHsU05AHRis+Km3aoNZZoSAoxBfkZCgoYJJtAaPFLNiqbPjB5B3LEehvpypkq1u0s3OUUR +dA9QHu30yVThyV0iawAT/CqQTgrWCVEaWljanJQYyLlfFtM5EHb6EJKDiD6MEaSTrqgc67mlUPM 21FU8xCYJgtspaTm2ShhJgTDJCXYOH1TmMBX4TWX5kKOBcA9qbWDkLSncNKUA+TswimOki3g1nfu +Dq64ykctKJynuSypKj40sQBikRaF6LBO+iv6NNlmmH5xlLe0hxI4xpHCsb68/NljawToKtR5HBz dcWOK8zx16B32AVF0VvIcBQN0h+3xwaw1sSwwXYgiu6HgW6vwbA6yUutIQWzmllEmueLK8DqWiVR VKe1uZOe0WgH3DuFRt9J0g9qMiK4kHPTCVASX4+GyETQp/aIcvcl6OvlXylgNiBg+4yE+gTlmIJ4 Gi/jVEP8Wlw3kBtMleYJhbtah4MJPoG/2DegAIbfDtWypv2xvoFgtmLBdAKIBxGTrio7qEOTYG18 YcgTooMBYZJPNREVrOk8IVLnRq2oyehrELu2necYj2nvOaWOQV4cooEkUAj1icJbRaB7IXFsh0IV 5Q24V0GWs+T1SY1uvxbLqMWCIUy4Kew1rJHo++vYLWapHDdjz9JkqcjLqRUwHVDt1PL73HouxE4S zTCZjOJSWEtG07qSCAClQUzOcGiFkGHHWkQ7N4zciLNknz4Uh0MRTwQ3UHhJGriya2hRME0IB0xm UxUsVAxExsDr5gIqMET0ViKacRKoGDC5s6cm67gTvlADcGALBvUDHKh9ErKBZCwbn+HcZNMdAi+s Z7pL/xYrES7YL0JU6pVbAFZrrb2vZ3SaKCbyh3E/wYVlgEGU5HR88mJHBDK99njNieZUreF37zj8 rtKVcHxPfqU1Hl6WKe+hRYRZjNU98gsf5A3UViLbUZpcx7XuOe+TtUh8xcsGBtljUcJqaa27BiM+ NzSPUwHQnjIDzWw6MrGm9krR3OStjXQZp4n8yRTjT5/eNgSNvgXK2xdIH2holhD6kM6fkUFf+QXD uJNvsEhdNg0Ut3cTjFmmEmx3EHn/evZh1HvjRJzrgnfsKa8//L324e+uOfzdX+PwOZGm+U0iwe7P hgS7H4MEu3dCgt0H2XdNIbw4FTyEEEeboQT58ssqPjrxrwDTmDfdGZY35BAD+SIeJc4QTaW8+IR9 twpVlzjXYuMkjbd5jUEQYfGUVFAOGwnY3R374YFd+a60gb9EM9MKSntBBxnKlIEjwSm2FdpWgLhD GQKcdpFfzzmYUz/DlH96PWWRwFFtFryeKmQUh8H1Xt6M9cxeb6yyw3dhbIhIvocJVbk7+2YAvkcw SDZIAdicILb6aArfLcWB8eK2a0y2pSQXA7aB5QxAQwSCxVMoUYPWa0qtQ+wsG8qPmxX6aNCxQzA/ YyUTnzjKk2SH3t6VEYIlNvYfUBOAlKprOrUA0+modfcayXxN590BBpRe0bsRDUelV1BWJ4mK/MQ8 Eq4FLK4VGts3gmVyU5O6mje0zGD5JhgDn6JkSTqGwJktQyi0UvWgeekdutFeSRf6SSJWfJB2asFk /cAlC8LS1MGX0U4ovQBurSxE/L3k2vLIDGPqSGglhpisFvgLPEOnO4+gn6gSLPAJztnnwNL0Vd5c IYd1eImZz4hd0/L7QhKtcqk74dbmuwexLxU+z8jQEnfo9qHpiR0DVkwqtC/gENX5ed4IWUVDLqtz 57eWMyZRhNx2xHXRxIS7mFZiWwMQ2bUnqYTjiepBidaKCht8LodiHWqK1nRSDvQ5nRJdIpibYtya VZjult5wtvfpVeTeMYNb7GWHExC0hrp2i2E3OQKfYWuIGHdMn2uw5LDdD67aXKvrZA8fiPW4ZScs G6/DFYkUbDHaC/Syg9EuRD5BKLQ0Bq2w3LlDhWJaNtes/g9R/x+EVrazYlrdgN98n4o9kfs5kv/I sscqMyegUwwZ561L6sp8yWTq9OjVKU5bcEkdAmr7rsFLywapmLAVH+OD4tYSMToYeZSNy+tyShXF crvwxATB4iX9ZtXaT/ZPvx23Fh9+Ib5u/FKMEbBMyVNmJPJrW3RuH5JYfD2GFj6Awf0dFGbzQPK5 f/QEXodVyUKw5JnbzNCNcYlUxr9XdaCdd5mdgdfILQea8QzUEoGUGYzGbLtKj4JmK8R9MdcjG78D con9wcObrGBwPG4iRCyAlXE6Q+wRXTQ6OvbNLjDaCo1moePa9KhQKz7yMLQKbCPxfJfD8gdgaTnD 8DBkSGBW4Gja6roQdxtwanK29L3ItiuiOH1O0hcSTu0V5ZStqLAVHQJFU/CH4EPMOSK2WYCqcsls Rdm1nAixyfNpiaZF3qGuHqMQoI4Xheeg6wd+lvVxPQBwnzUYXQbeorShCXBbfJJYJsjapNvvB60t UX9ho5uxRPkGWm7d6Cei8DtfWGpWUaQu7KvOgbm5FSBGOt0OAtQATxutWYp4Na1mlwXH26HzW6vw 9SAKGnijU5rlt4x+K9mEiJT+HdaEgMJCDbs8oW3nt4X7ly7jx4z/Rk3zf2cPBo96oBRmp/rCzoOs UdpPKVjEkdSVxUyfgl8Zg6+dGoilHt3Bl+ca1tPmrvDrktBNQwkZfcDsBOxKfPVoGrNKBlmkwQ6L R+kL7THDMwtjXnaN9VRjOYiX44Z3HAo5Hd4ELBqdX0N4qdNNuGDMjxpSglgA6f0EClTYAYtgPWQM NbZQX6JDYzg9RUtnmYfJ68q7CvHSGuO6VpeB07Eh/nwa4lttZfsxV8nVZp3MIZTRGQTe55vXiqMr XWYmU9HwSCQAlIbosA/LZ3KPPbhIHDTH3oYLjPBAnb2twoAQwGsrMVApr8+vSvAHLmvyf7rLNTNd XHcfgHvanXO83Z+C0xUXdnTKFxo8BS9xPjB7aA3sFUyaIUzALk3CLLpoisnKrGDwEGHcQJNfSKYY WYlLU0EUinlK9jFHDTGtyrnYEMf8ivBn1k4udV6kj85YlYfqU37dokh6kM6EYCRgIqlVaqDyRRva Kw+L4x80M26Hj2xVkEZ0OyWIOzo/UD9vaKF8T4V3+wJt8HIsHlMYN15HR+EX5h4gLfNVYAAfpWIo ntJc6Iibs8ouMJRvMvHlHIUQaiUwx8tzxwIWiWX0oVxNMPbQDg4lTd3HM3KROwnBcQZ4F+Fau6Nc NH3r7PfFx9wawPiY5ch7tNwQ2xDFGLWcDVlBFFkqx9rXJE/YxVpNiXuQguhxQ4lSnD+AiTgaDSvO LZC7QLdrKorXaHjDbrs7jwQPytnGeCChKIh08s5Ghw6XjylwtxOOwOaDQcqGQMg021elIJ6D6NxV mS7CHDhSJLNyZjkQ8xwqmBp6CNJ5EOvVGoMKgSLm0w/X4OMz5US74L1H7H9NOeGVXLEjeNbAjgFl mhsjMYEl5Gy9iUVvrUaLOf10Qoo8G4NQZ6LDTwXOofTrSBJUl28Ctq1v6x1aC/irsFS9EuL2UBCl DLQZrrNb5VnOnzhhaOjb3A5IZ0e5Bw4VQoK8S3T74ISaN6uI2jfAWXOkQcbHyst2jWaIGTRonYE5 Rbi4kV58oWtPe9VJiDFLaEt0LOr8e7I9IX24TX7o/tLELA/xNdvBc9hoOyUaGcpaomGEACLKTSvy aTfxlXkrPZ4f4X2RcFHbqWzlJRFqJHb8diHzdtPLOC1euBQM3xW3zJcP8DpKb0sgLyBfg5g7AVoF 45JP4FIiM9PIS9p+yjSJ8GN9TQTRS8e/nB72tqyrmS1QgooIDuJuK+kD8HO06sRtxzKMFFeFTpTi nQNmxmlXqvt0ET89SdZ8Ej3n7naSHM0Yqy/wQVc8P/OeDiljXc36Xu+//ApHufkJorCAUfswFeFe G/nufIr/JX2Mu3CKT0YPE05Yciq2fyeB2eciY3a8OT9a6SuK/GZ9TmJbSskV9zV+TdhT6hticJwJ CbrnwxH0NQKzEUZfLBdzSPI+fnXy3alTxHEE5X/H49fZ04dP9mDpi+q8AnLs5OlZ0ev5F0Ojhn3y hkL8/CMDDPEONz7FGNaz22d/CFqbMIfO5xiAtt/rvf7uFNeK8zj08HjwAvCA9ribvQm/c2RtWuBd 6TwXeiMKJVNlVhcEMGJOUQOrRw8mmGoxixrARsbm3JbdMSMiBlJs4zMNRqnERL1LSfC5g/QcWz0w tutR/Gs1dpoACJoz4NJSL2IWGvASZPkHSIuag1RXTGKoStABCCaALgIrWOy1U+MwvfhdbkpGHpoU jH322QSlK16dcM4mmI8WyUED2xHb/dPbK4OSWyLgwxTowJsxiJie0Uwx3PUkz/MpmM4kChI5RXGR Q6AsQWO0fjW8kijig0BUQKBDkz1FhH4i8PBqGmudWN56G2YgcTCDtP6sD4TZT24fmbqTWLV+cSUi x/sHDz5k2271OZ7P5dSJdBhGwJ09sM6vo2yzSwsQSgR9v7Oz9tubIv8++PLngPrAx1xHETA8cvpe nt3qVYEx32q2M0Sb7A0chYZd7nQdQ3MFHAvcY1wGCiVyig4EukCGckbTrwPE6DgbOIwIL3jdSifw aTOlmHKp4qjIt8EU7syiKVau1r2ltmamAbSEgtcA5AAgqEexfvnh4X0tU3WRTkObdMMyK9MguFe6 IvX7yCAcjWJt5lQ/YCbJQIJWKdJkKAa7SJh2SwgLjNXwYNjDQxtKqR5ls87cUpczXw5k2eibBoLR BTGBsyFEKcIlAVPtezjoQKGiC4fcDcKF7TpxMiZiSJ1A94g4JF8jx6fh6uxswX/v4n/vbY1lJmWr L/Gjra0H+H/ga3D6GQ+1tbWDv4b7gXd33P+lfm2P8AB/J2Xaj4pvQjnjYKbUezvReygW7Fm+L146 khj2nFz0Td6A1CfhY73eC0eiD4/Gp9kfCX04iQIFjSyRhSgo7kUEPjdGNHiG1UcFy+gYSY/V80Au M4AsBqkxCbI6py3gHM3ybMihYfsOCwXNB9nxIUmG46MX6lfZRS7sfgm7qKWWz3yW+RgKkMno+YyC 55dc+/oIZqRHsG3DCeaYM5qhKoFkh+/qQkoyLCC7bIq54a/GZKM69WLuD1jagGq6WPmjbNRHyjNc tM+1r9vqAB3EVOg7ALXjQ8/6pxWkN7FGix62EkRDEdgSApae8MpPk50Tcfb9xQKCuCbPp/nl9w7j sFc3ERIvH9njlpNMYBuV9StYUvC0125Z4pLc4o7HTLDQEznlKEveaoqkL2xpFBx48tf8HDyHkvrd eGS/qubqDYPMDNbpgBj/0Fg8HMn19MQavwPwyfijniWLv+R6Z9AICiwDco5jOQAfnHOxyfpXYRgH xQ6SGPH+tF5SOPw9RmyOEbs/23oDEno3HCCWs+tI53k+b0AwFjOOT0pxEl9e1r5MXIpw8CpP9CNj m3vhEfVCfHo6ug8jPKF4GxKLPL5UEoAmtaM8gMALt2bK1FLBLOib2Ph9Cs4RCAuFCJ2LGiZhnVym AE7Rq5s5/Y2w5uru5OCb2TZobCW6YMek02GupYac8hscfEzs2DIG+Jn0rTvvers6kxrOYlah7Fm3 /Np0KuTr+GeuQbCvwKZAF7fRs786rkoFB7u1byYAIEqgoU8qfWcSO+9dyuF7iyrTrCFzX96WOaM6 CW2x0Pg/GmxvsTvaeTB6CPGRULmk/z+prcMsuAvmYCdymFFxQLgTexkF38kdoXKjqN5AKXsZstc7 gGZGqhhY+uStKamrnwjSsBdZhLyE6uB29ZwOMbexs0be8Xfkwop7QD8WHKUQUDfQ9c0S84WlsehM 8gtTsgQiWsB5zgkSXQsgtmWogWRSJ05gd/QVJhcTc+Egc6y64S6hz5aUaUos4NFkNtWYanTA6+Ib PQdrLmbLMlNR/gPLNmN5gzR1cKSAvTB1D0JgkhvOpdsjtbvJbzNxFKWWDdt977AZQnmqs3L2AVzn VyWmF+jmEdiRsC6aUJemuwafPN0l3uCttUofchYNWlKzfGkiLhGS3NwnIaqHB9WGvdtg3CsTMw67 gNMfZcprCbR6L6m5BdFnsq28Rwn2AzZE4+aZD/cyn4dBu/QHqGAkA9uQE6k1EjoOqxzwKaGbMp/e 5LcNevNm4Yl1HZQ5pMYrJMg0ZEUUWuAw4iGVF07LVSY7t84vFVMjOsPdYjnejMLh47HA4aCE72H2 J+/ZrwsqHoQukqA7pbEnIAmZebuoyUVDn7OBOtiTv3rkdMPYtA/DmdKsb8y80jRqrcAAbnMNrAOs 1nJQ57lkKvFY0rvg1cl+rETj/bB9edkOg7/bWvUcujkzeigD8aH6IAKnTPQj4luObZSCBmM0qob3 +9Iu7AMfYfsMWsKJtunDJb6AWm3uO3cl6/wQA1GGYjo5OYQi9bYGQ3taOryOI3KfqzsAJR+c/CrH qj18Bt6YsJyR1Z19t50+nZEvRIA6gRUWsfiK8lQUgUX9z61WjIG8YFpCyZUIhB8Dx00WeJhOaQ/b NtHaB3hJ7UvItVouIFYCUJP4DLBWXNAFGvKur5czTgLoe24SiB4kh4rEOFDlR2FnDk3OjOxflZOj DiIf4fYLLO+UrNwkK8AI0mgZyDZvCnja+NUwmmNmF37CeGnh8t4D5oMaeR6xScZWgKQ6Y+xVDGFw fPwtQRyjD/Kg9JUEt8tvlmnCwiCL78ydwVVBZtrralYubP59q/xBq7yBhJDBw/HyTIqTHEo6vGJt Ixc5ZZ2zV1lGZtN9siKTDqrRv/b6kkZNdDmOxh/gOXCRIBg0dnqaL9M1Ezf+fiZn0/rGFqlLAu05 7y9YjleN3P04QpPoG4ztIgmTI6AML2zN+9wzF12vUbg5zZkZgxwXVOI0mq0WOgzoVvL+qTI2gA3I CQ16Ivx4Q6ZYMLzxUoNwV1zhhGm+15sUodJJumRdXFdv6QdSlF55jarvDTnm44kwx4DC6CjvzyHy vgGIfFAfA4sfrZEYOm7b0YGsIuH2YLpXh9mM5jQI3ZKXpsECO6onhWOFd8bkvzG+3eUuMDP+egVy jWI0Gu4wSt8Fk7K7Y9JkU0yiqlocqsFBrJXI4i99ygosATrXkW5cNrS7J6NH3sEiwcoNo4DPFgC6 lw5sJgIdqHSUwrHLDn4VC/x4GJBJySa3qZVCNA6US+I6eDkWobYmCZjlfIpReTugOj611GnSJum0 kpUUDAIEGilxl0Ot6aIum+ECvIR8Vt6Q9L27SPizH9LEsNCPQ5zo2Bdc8XDWOSlagSqH3lBWDQ6r NSIX4bLtaH7hENF3OUMJpbbxZHCIJFcDWgWlw9aAgssAP+PGBo0P8pDrmxzACSpDDcHyo22PXx0e PO+bHNqysYTEF6rFJdfCX1VYgJkpMNZAFoE1UD8ov+Hw8wrDCMhIgL5bWfQI4hiHmMPJ5g2txRWL D0fjH9390jVui2DcLlLorbmidZPVz9u3MXrdDf2NHkzjsYaUJv8DFepDEyNa4ulC0FgUPUGmvAWI Rtte+wDSl1DG+zjSVCUq02m34XyjIAPYyfTGpLff0pMDN9yi4jD8ZRgpfyJONfCgcRcPUExYAARx HGufhNWwSDZIWhTAUEgGTNMwM2+6XvfNhFk6tJWmZ17JOR6z1LMwlhd35m9JcgTsKM3r1lxpSvNn Qe/i3BZUytNmWtYXs7EU/SRFxFQ6HwQFxuHUT8L6jQLLPlNf6r5EB/K2YGYQVrd+6uTZl61atr73 Gey0yTCnidMYzsAa42T6Xk8pl0WW7WJ0OWqlcwivl5OHvOm6atBeJ6NE40NtZVPZNyztz/keaP8X Bd9tckYWMfiZ5cl49LKhc73A6lcA/2KituU3GkchNteQwXRcDsc/m+KajWei9oKlU+hGvAiYrxVs mmhQszfa5RmlLHLheM05oixEn8OQpKzR4TFrfDXeP7GdRZhu6wVmwnHioFC+kzW29l6IVUiCCxdM qJPWPY5MiY/wdVDQHUuusV2IGEdnxoTY68uFN+dYvUP7L2kcSiLXJMgWkXwxBgIkE3sjsUV+Q4ez bVpyo7Le7oOnli7TGRzezvJrd2P3sccsEOdBEHjuPxgQAWBUdbNhvDOEAvALfSaAgeqcN1Jl0riR zCo8++ejjS+MZU8CWWROJ4fcAL5xwKR6Pa9O9kfZNmIdF9WENxeQW7JAw1ajrKUj54VJJLLQBcVK YSeivjY53Mt+9HJPhwTZ671yrHvrz2DB3TrEq4HBRVtbL/N3cMgc+PN4D35A876m0Rmqwu4hav8r 2Q5KNHCwk3xxxYPtPNj1w1FjAx7ApySaFAWw92xtOcQYuiu39fxoC6WofWr+BfgSBupUjERPH+wO d4GYa69s+EZjuZGNogXfBtKLEKTVZNVYJW5LEUxGbkltZeHk0O0O/rOzg8sMl3YiQs2x8QkGLZPN BChE1diwl6iK29WXp28cQ3zyJDm3KCpbD2hq2G7Dv6mvIkVXwuLFW1uqx72sJsvpstna/X/s7W5R 5xi240ZNwZq5E1Y0QAjeCE0eW1tvHL91lOGFbTSztfPwq11ca8Njv6AK01yUJoH2jZZgcqopIpr7 qsaxHQS2tqK80K3HD7Zead8yLrlGBDaP65gm0lO78m7nNquMEo8BHcZOqqmmYDp5SS40d74OHXCH DKgziTdYVOJnu81K+BCS508xd949Ii9yxqNlp1pBzkbPq4Ajwt3W1v+JpYS3dh/9HzipE61B8OT6 LVxnWB2LUnCYCX+YvKgpJyQ2Ot2+wErEuArJrrPUr/Lpj27FPBcYEmDtsLY//AH8GKoUXUVugIVx ybxiw8UicphoDnrtHQHIEa0DDtDe+BRQbGYa68u/Vmr/wBoWmqOCgZGzci4hGjIQDKr2gkAN4RJV 4W48I0Q5SObHuURwKNDSUWoYnixOqtY3BdfiSPAqLI4xxyrZ5FgoQmeGym65j/abkySChNlUlOBl D2ndHI8H2EEV0KnllGeIdhYOpPUyjw+RzZOiHencHHl6CjFQPiJC+qeRCAYB6o2/LepWN/y4gwvH OMLmosagkYnDzbPLEmqgh0BatU45Sm33lkM+g7Zw+4nCLwMHV61ZdubnAqHs4MOlfcLDJGGoFS+y FsCwkgVYUI4Pj+1awD7lCNDECKjwhlhX4vuj0TBx3SWCM5KfAjoTwqN6OSXTCbLdvYdPv3TCrQrV OD0vCjmspoPxSS3JEwfY9FfxXiFVToSsFsbU82+jnV2nrT0fPf5qkB2Ndh7vka0P/vnQYofDGWKU jQfPoSP9P6Hug7IGln1WKb0LYvBRAmJ659fsV4v906EHR67UpnGfvwRrGGYmuD9YgTAlgDfFBTx9 P57iEqrKEOiNVjcE9U6TBTHw5De2FBC3tU1w6lvhs4U7Dko0NRCZ4HOGiqXc+AXxosI6NM3OSZqm 1zenAyOsA80VjEha5UuY0sHKxqeGkIS+x1YU+gvVUcfQ3JFxII1PZXoukpXD/sODA6Gze19lO7t7 A41KCUjCv438d4jHeBsjSr33JMvhPwMpSg9D8S/uIPHPbzLuIznq/SOOiHLToWMwqrLBxOysPnx1 fJAdcpFvCpprTXnY92uWp/+ebduOCXNMIsciK0BAnXQmXTPsuZgZ+7xdn8jkN02Laa2j75SXAHQ3 HD2kNnvxRzMtG4UncXxwKIM9fJI5gfxRdvAgfRiAM8Tn3G0EE9OMrsF/py0gzj2mDC69fEAKvNcE fjGzMBMBDLxdYFlEbLG+/f6fPxgEkx2a6NyIP7wZZGOgT6d4nxrJfV/czqUVZ3s3RB9W2L4AYDVW vRdxS87Ej8A1ziromlDKTEhvoKTR09FubBMz2jxLEOwiEGsLHZOEQnrSYrz+1YySY5NddDHLAQJt zm134NMr44uR7kOCAUEwhWlrapLx0dYd2ySZxWiPCOIqnJu2EP9U1I5Uwz7V+tMy34IZcNcJ0G+8 qeZIZvzJxyq5nwvV/7m5k2YcwnFmHPqicbZiuGlHVt1whAfPY/1iGQo/0mMqI0dbx3tIkE2UD5Ef rqrjPTNWchgwub7RW+bhPzF0XhctQbyOSoOzCs4RFAcsmlJiKS9ZHEYEcjrYNRdhpDg3uwAOPKFi iOicRX+lkclCmb7pWJcJ/FxYbDPtMfzLaBA7IKv79ndzLpVNIASpyUSEB6gLnCk3dcJhJjWzWCXQ C9p8OgwUPkDCWXOKM2xlYuOm4OujcWbrVyZqgx+N/XlxXa1Wwa8B2esRaBKstdZfljdNdV6iDRfP m0vWlupJ8oBHHScoLTmJwxF91XStRW4CRKFIEGA50B7gHT4gBOy1ftAe/IdtZg8dUT7yQkNbxjL3 3t1N/pEkla2XnJkKGsMWEmV+YWuLpIEtURO2/s39ROzd//YN/nbof/h3+GHLC/RbR/RP5p5K9hsm WYjR8N4WMyPgRlte4t3yUtUf/7tKhn98IP95bv6ztfXPfiFvBuPBKWrwWkLXwxmJPUQdc0X8tTig mEWwLKQnVfoaHTqxrG9bSISzawvCIckDXNoUl5HdDRfPoBIkORBu4k2mkJEI+i4HJcGHykFAZ+Zi 6KH9Cpt4xT4xuq70TYJjR5TnHKvpBABz4hkJcxaA2ftjc7k+IOyU3dLIqNq+/26GPcI/9DGIBAip r4HNFV4xMlbBP+vqgUeA9clK0YIcprz/bv5BT/H4MC6d/+roNMxsEOD4kuqQ18TMxe1lCJuh4Mvw wBbtqJ/1JNvg2tcQJYTm52BcqtfQkzNgDieTwim43UfbxgZhVXQcAxoodSDyvpyLQ7SV8B6tgnd7 Ug+8eN4FNpuhr1pYqCnodCD+ElM3ns0XseEa4LA71tHq+skWUL8oLa5StLMe4NKKdpdcggziz629 iFBdZu4XeqOTbhsSneBlTAHcfkHdfyC4gaImbqGs6JJOnhfJUhcuji5HsMTARsNcDHga7jMbc0h6 RJoSe6KA4IIiRDvaqpYNV2yl7ocYXZV0KeAK3VWg8l0rw8+pS6rSwUFPGupFiNRxheTt1FFGtwgg 8lAhksahSOLGxamycxK8SXIdSBbRC+rYJ50VWqxCT4xDrlBoDTGwekmcQKNJC5WxBMoN5oD+Y48J Got0jQFbr3cjpxe5E1iwI1yKnuks23XRb7hZXKsFh1BXXtso68lKfQKPBKMUXMwhvIDeWgJfHjA2 bYTRC8Vo+PQFpjPIANBmvf05GiJIfM6h3vsl57Z3ZlX6guIezYnCT9ioJ9VDeBaulpJfQ40V+M18 bJJq21PxLugOpeNK2CBCRCWEok27qlXoMFcnc+xNy8REHxgpH6VXEy8/J9WHhAg3ZzmFcU/2D7nS hPSlOffNwPP6rHRv1rcEmgmbR2ygGdglxm4/5iuDRBRElE2L2SWVu9ail9f5O3QHDiGQB0fd6Wd9 dpjIw5LdBOxEri4cu3Z6CXisv8GWDe6lntZHnl2+2Ak8j8Gj3fCRekCg9jsgk63rHUhdmImEEYRn hVqROHRf3JU+QMQ4LDlAB6HMvmUGBDV4l13S9sUhZNsYI4Jh41fsUqG1DeOQLiMQVdyHjvVsqIFY KwDPAGjohh340DxGHtw4uq6wvCKaYl65fwiiAo2zNcYXFNWAAxO/M/XmaGd903v1zIeq+c4QjyXB Qb1eoheTkbuODwYeqcrcQoXA2sFnIo1GJJ4OBaw014bHqZ8DJSgiPUHRSwillRDjEG/xzwABbQws hsByPG5+Vr2VVo+likiApIOQXdLOoCE2TKcatgYQWmcjgdFtXdobmELnkhlS6lfISbmss45LNjD0 l0toXlVrvoeXiaqQxgr4Q2tWZ7wL5oaaF/1uwR4ktr8At30wSQsfvLSqOGPWxqUQFydOQ3T6oy9h ZfgDdJWfLafTVFQ4h4Lhj/tLeL4Qk+exTf2yio4l9ZoSYoRMB5VoqFPuA/BelkmSdURuu7bEhvM8 HBOhAcLjH6Sk0KPsx8zXU0zDi2RZ3E6vV47R/CEsmnxdL3ZfOzL5spr4B7j85/DN1hZHNWwNh1sa wglkdXunLw93t6gchvzJL+zaF0iO2rIxErvZ9p575Q89x0OA80qOsuc7wOY44Yw8u8QMS6j2SPTX t//IF8J4JGAF/s1MUlLvwfBY21iDq4IlOiXSampkckhU0uRb8vKIjuJcPyo3xEjZnB1eJogXEnml NHt/9AcQdh8Z20SnuIsvjnZwXm4NgbstGggPi8wVHbJwVzpJakxvHhBRIMju5BQ1T6s3EqERNyJD ic+4MOkk+MZh9oIAHOSDGJtpQKwDlD8e/9Bo3Bst5/iQRhuYo2bJipfAQjGYhA4R5emDl2VD5gwy E2vr9QR16rrGTJjYtclvcZacvNQw/QKJoZOApc8vOrDAEiM2+CSVG8ZkTqnkaviE9Oi542HA4dvw eW9WpPXckivBhQz9SrwGnqKn8fl74kpwMsg79qUKkrTU58pL6LoGx6VmtmHtbmy6NeioIAtLY3HU 4R807KCzP6/mXiZE1knueKgF7O7dxAF4ZFatB6jL/wyr1+P1TDDI5cp8Qgwb4LoPevQhSAoLRgXr a87DzuUSxE4RpCkixM71FvBrG90Vz9sq23AvplajLLiopUdxU3+p1/tHph6NWU60MTpv/fzCRNlx qlwJbRq7povsoyaPnfcxjDeaFFw+/syEj2g4ooR+umVLqnmXxlsa8p8wT4nlDLE0Ub+qwASuhBXK uBoYbyhrQQO9GZTlBMptxCZkBXZrdNHtqEXVLKwsh5FM19cVxRLjcQAl5UqlcK4s/O+7rzQCJRbh yeZQkujJiH+m5Suqi7SWgjls29C8ar5ghdknxaS+KFGpH5qMjpXVjfBSgUQ3tCKd4cB9DXyUhFR2 nTiZJQ2lxMZRsqPduzEwJiAJfqADQQG1AJev8/r7aOxcC65lsHbJM4nsw+hTnkDAL2AO1SbqlILm oRSE+ZKMSPumUpuNWwsYoOKl0ismTxGiM7KSNB1gjheGSGzImQTgthZ0sGKUALKgpRpafgSqQwCd bb0AIlH68WY+Tm5KYb4nQ6skA/vpUL/tEqDAgs42B8QIxCjDrXO7trooVlzLUku5YBk5NbuItlBx c8R0nb8S7yqpRNn7FzsWj8WTEGCtFcM4gDDkv6SUbTbdrp1uKPPJTenS0DQNKijrM/iYdT4eqWP9 sdNghBJR0ji9QpBnIglI73SOQEUEHXBfr/B3TX5ZbG1tzcA2B9qfjIlqnlUet76bZ9sP+9kL9+yR GwL561agPm69KTCjeftJP9v+CxbMJkD2t8ATmG0/bv0eKpcdc5zGyJ8weCdklhGleltSyLW/Ysfu d/MPI+9lRJjA2+95cR/aA5F4YeTspP/zu3n/A98l942Xt7VIuT+IlLsFJCP1t7B50BF+cRlekXuL 3Oiy8f4Kdx6sG2qpGNtIBCPauncaistOAbG/0tWb2qyxf/oY7xqbQaTiD7gf3qi3n90AphhwJAAJ lgj8zy92e1OK8WaX94nwk1m1AUsZdPAU72SgSZFU/uNdaaVsvw1/f0kavRuxHSDhx3fYCcEXt/22 kOvOOuQrn0Dbk+u981pbS5QnwxZKOyqLrFp2oChOUU5CjZ8oNd792ahxZIZ72FdDXZtOPyYa+kRp KNHfpx10uf17SNdlyN3X2fZX3R91EfmQV1haj4M6IDzoHnTNBn4h5tB6OUA6xUt/lCu4yWcdjYD5 WcdMjnbP8H5uhpdYV2tBux82ek2xYmtLexk8NSQK5fefg055F4FMBXQqpE8iJD7amH6sER4NkXrC ROrpxxCjO3z8myI6H0kcElOuH3J3Q8Hs17o3f7ekavcDZQR/rBwMX91RoH3qto3d4qAoxFu9Cnov 2oat2G9iqsDxNGguQXxDWQ5jDcFyVHjHLswNBk7MkjgXR/4KuzZXJNfgJmNmUYyzAGv3sUjZ7kQv gF54Re0niRYi4XRCIPh/3WL4JNm4Y1KlfIBYuCq9BK2grW2IzUdMnqVf0I13eC3FmlY2KbtvX70h fG4ePlDjz733awGIp6cZf2jMUW/7Emadx9/3dCUeqA1iHa8buDKsBw+YuqVH8SEbBN3PmPwj4T7W eBymb1RQHqaYXlDDsBgbSkrZ0xCfJ+iQP4/BxzxGonJU70luZVFpiORaVFLcsaEWK8ICKR6zNZ4W ENHCHe6gIWqqO4gQT4331SzPqHjGYgqFzSXqqYuqEAO3MdM3vAKt6h45rAjSPivrQkvYM4QwCgzl JqHUIYbfMVCeA9lTiito+qvoJTg3dYfhEs6r+W04GIp5aph9ffFKA4vcIurSWtjXGKsHPQ0avqLc Kq27Ab8FclKQfEUDWUM+b74jBpkQtDVmfMHtgOxHe5y9pDK7icgNgUgpMb1Kmr4virnj2LwpCsna 9gC0m+0r2nSMfkvoHyw8gFYccmte4F7dwPS4ASWjXgKaciyL4YmSd8pmC8Pp4e5cFRDOgeDCATl3 LUZfTFiDqLVWyhpnb9wJv/FE9rJEXSqMnYFGYmH1QYlx59O5ofbg3oeMzbintwCHpqjfltB8pGmW 10SNtMpj2fj8Ojir1ALwplvfFWfdPkV6J6UXyc1FheqaTPPgu8pIdlaRbPoEcywuwoyBN6ArdTto pLQeiGDuV/AIYUZ2MjIh2A6jUX7WUJ7b+zasPmjFPbfdR6NH4U6PZ7a0yVPsARemIN9h18iCUOJS 2Juao9618dUKYxpE2fzsBjV0PqSVVlAJQ4Mg64pPVj1IqbPt39vq7NPY5rb5YN1q7p0Gjbb06+u/ q7RWf+7dKvHPNOxHa9obDA7D7qcM6fcq9y+icnfo2k+xA9n4zwe+pD94w4mJQWGC76j6gHKgZO3D c0MqTY1nN6zx9QQ9A+ISQhpZ1lhSTiy8RWbXEmm74O2FqadYSQ4GZwxQNV+SQiuMRs/runREAYbA AgGtPlELjrBW7R9FogPY5BuQ4aHoJGvv3J3WV/g7LIHrYL3SqmZsRT7mGTxNQrlA1B/azYWju5Oo YUmjDHu/wGtSSTNHFuPLYGAGHhxqEvhoOMV8ri5YcNaZiJAgPXhcfnWyLynurBxD3ZFiEtY6S6zx cN+vTz4L0c6iQY5RhqBJqkpW2NOR5huRpjMS1N2V2qA5lCpRvYxfg4y+bLLiBbyJ2vTKiNdEU84x pUWr2comMkT5ReW/xEI7CE+Iu6pBOnqLte6ui8VVJXUHbdWrzmA3GLejtBw84qQiAmspdfLswUvl j65KehRlPUtJlVJsxmYxqF/3GR42JgOVWEL0XGLX7r7Grmp+WMZgsb4cYHw7OOBtOtVRiNBzfLyW M0+VmMUgtePDY5uw5d4t66i4DqNzVdcgXuGzaBtnt1r9a8YZb4fHtlb6e1/Q4UOmzcyB1ERpylBd H+Ngs8YhZF6XFRE3ZAJzhzIlaZ2m2JhomLAuXIg00aXKICAba9BkWC2FAKk1B+1CD8cn0UKZxEoF psS6uYaGToY2T70IeOGn0yWI+aIeatUttxJaLa5kkElxYDWwQNUoNKciRiAu0gcBCmqZS3fKkKFx jXc/KF8Ng3HJXQQGZFAAu5fwdn4T0v6m0z5WFTaLOEl2J6fSHLII+pTLdQvuQZEweWE+zWfI8wk0 GRVsIY0H6XZUYBjG6KzWJ6VR2cx2LL06LpyEpEmBtAokXG7JGgaLKN24GSfIYH14h18qF6IjiYnq wW1a0xv7WM4Eq6iqyB1xKtNiyVSYQvq/uRfLGqc+KyjbnFFuVtAp5xO4Aw3l4pVNBFFRUaeopWP8 Zo7lv93HKaMgx8SMX+2/OUKJ7G1eTimvk/Zny1Drph3Ar9EO8Lb6no1ktr0PDubL0yy0ACwfN6T0 RDXLAmJpomrxN6CXMbFsV/YcpOA8+Kh6n+lTJ9lCFpesidiqprmo5EW96w5podyalAqRyqkeMlER kc77UTa8akqSCu8qJhh+Wr1Asms/JeuVF4Gy0ku6nKBYt+oK8e1iqkWsl9NKdFb/FSdJjU/3T48P IlGrahbbjbfvmXUIfQhSUyl/VxhHMGAr2RTH11pYdmRzeeEEVUhi/r+Qev3otUBMbpZzPDfmivFW bL1BvEbb6MWdQsQWWssw7Zml0mjZIhfuZVQvAieBdTTZ9pRtFqmI8r7vidcpN4GQv0qYHFDCaRcK Rt6kXs/J++fUiOrwhyZR1nIgHW9zuEFEOSUYYkXdXUInKoSvV88KWV0rFF8EYLi6eXIoDScKdl3w T4VtuymdIw+gSCBM+waE36aAsu/0G8Dl0NeWbG9VhjrH13H0Faup6lWpCtYcIKSJEnJMuUVOrO6C HuRS0E0E/Hn/zx8wp8E9A38T+7hSu2BB31QIjlXgdGXhbT5pzyGDDGBNc5cMAU+NmPN4dc2mBdBu 3bdtJo1SbiU3d0D+GKHNidmJlrEkvzlO2UZBHigyTx/JTKBFmb2hHiUfDSIc5OpU1oDDFRSCtrcJ EX7mmwrni+S1Q5ESK82Z9sOJ41aLVDWF/aNHwt3O63mCuwJRemi8fTxElLx1NwwNIDKrAE/p7kA5 Ly9vqNnhkLNigcCJyOGWNGY1NzP6L15ZWI0AupqDPFPFpIrXRBYuuB7124KcRKBZw8bAzkV1aCZ0 3DAqSKbQw2Tge1DBAqh7Ift3rC/RfQZpRN6fhRVEQtOCF+yVy7cWqhmgjEUOgQtjRBvA1Smu52hB K4SREWFCC4lehzY26NnqcYRj3+VESJr4KkonH6hqHxg0GepQxIUfg00IIERF66hAX6smjFtGOZkW plCQ25zPkF17lgN4hdrj2prQBjCRhwj8hpIGL2vGJButqI8Z+qbf9Fl+Vk4hP0/pn24cS0hwCRG8 HQspdwG+PTouBIfgAgdB80UkW5sc9gWlM2rP4DVNijJbhtT71CJKI/lgJM1w3yxTd1CJBYnK+qex pfr6HYja751ADj85HREoDpS1GqMG7DV/ZgglmYFFNJspEWH36nm8+yYgnC1KTLQoiobhLLt8EUoD Uy00s+BtKUXLIacc50PVGqeXYq2zUMlRXsNNy5XRTLEaYbAQQ6RhC91UOcgNaz0FFRPMfGCPnwG6 5WibdzOcUjlaJt13/XCAdgBzOsTG9ZTFAwzgqOq8LsFuOzN0fwa2gfDMUB2eFJEFl+uB34XSEPBp VJZSAgle+yihOi31eNXPm2CK26QtUJ1pRqmOS0JVJyN0XKSbVDD53h8wvmJy7OxWXUCLEBAbAgCu OKu70zjopLKe+2CJoHvMpzkE9PkcF/rbHfD754jgH0hQt3FbpA9RCEXhMP87qqYjNDXOC0djB0+Z sKJTnvgC8rC5oXTK0Js4oX2uOcLY8nGQ6/l6sMHG0ltBVhiCF5ZPihmeuI9asqJkBXVNgLgwHMjs l9iSMM1HD7ietaZ8sv0in5kK3uCXc0dEvXEiWocUDW3CQqigwFVE0aQqTBHgBFzJDHmCb6Gw0KJs 67ALRuDRmNbGglDgQEABbUHGUgdF1nz3RPnSVunS0dlN6LX2Bo8Pc8S1RQYKRNj9kthNDm43vv1D J687WIYi1Rm1T4V4fAAsUjg69y5toCUq8MzMqJjWM+E3ZQWV+st5VxeWW6GvFH/03TtH2fbxggyB JCYQrby5qqZ25nORSKTHPMfikKiHCegxYwefnjc8gzFYB6ENfJ2hzZftvaN+dspOLBZP/ey4r9iK jaINmTO9CSXyn/BI5IRQ861RM+MT6PU8a42gP9L1KZjDk4GVsH4aiBotp6lvw8ht4PlKsFvPzsiW pcgTQC1wMHf4NFhGhJp4Z1YjJ5inaZn7SIG/CSySRWNstjwHqJsW6bzmGkgmDgTfiEsUek+gWGC8 lAej/yQ3vARgfjN6N1CRlCuf2bPEl/ZhWwe0xppv8MIeCwzrXnGDBQgy8yQggSb0JX3nhoYIZXdh 0Xvpq1pHvsO6INcxq2lGfj7lFnVOKEFjzLzGAIlC/bZBKD/1TcPYJzbrbFMNOYZdbCTCyO2IWOD6 mUwyMFSvCatGkfVeNUYSKtm/u/DXj+mhdwiuxqJYrFiwy57KAAArcmyt7DA9l5FVq8KsU/gfqBTa 8jW7YRpdIIFIFs6rDXRiMFlTmz9cmpSizG0nA5r3xvNpb4I12Ex0VfkSzMWm6AUhAMOZOLRtuB25 fc80RsBacM8KHz6DjVYAdogWlzmIIDiUxGSlDO6tFrEsh9PuwJIgpaz8ScEubuqSQxWpuCiJ59Nb Yp9kY8T7FmMiSqUqPwAvpkGp5ovWf9OqpXBTzHA+NQWDURMHEajvFBaNdee5OY8/L6OCs1zVZz7/ 0IbsYH3lKunRh/gcChoBHDMCAJI7uNtv8ylqLVWy+wrhJuRsgCvWeJ6D3t26iMDuBdQwNSYZxKBR /XOwC/s1DRjlHOzRXXROBUWCMtILdZCF/bOMs8r7jYUo6ToTln9f4s/NTCjLNM+Lp23ui+cr5fdC CWEUhWZj6D/Ukm53m0GXggdAhD+AGWj2Ygd/3D1Amn1ghPC3GpNOGMcXyqcYYYx+VLkThLEK+rnk JWp/7DgqawnB6dxLRzmnUMgchR9ziSmzia4Un3gYRPlHdHxSXUAF8iW1G+VSWb3eP6wJ+dGacTnZ Ktw6/mu3FwV8aoPghP9btlhCfAP0z24qNvSsDTLKjf07oczBNND5sMEWgEAm3TtH9hVqoPs9Wvkc FL8HC33xjh2FFxAqL45GaqjbcMxa12RoREdPes7tKma5NONljoRjc/ATuXgwjALS1RBWplpwDD5u 6kvVdy5Wv1RycKMswp33P6hyaRypWngemU8qTtD70Us0KaXCqwgXKT0h22ZOGbas7Wfvjc5VIcOH sFCOCGXjAxgEYpN8GS46seWAmbmtVJdU+289LL/P/sVtdeqogpvmnOr0IjPs+uJ7EkEIqKxQ8gB/ 9Pg1jBFs/ZhSkpPG7OGYGQz6QDqAgXDaZK2YCyKltl16Y3OivJxA1aa7OrZrZ2skFtu+NHXUmhge 9w3lgmgDQBO3klX3tYHoMrIm7HBwlI+CgxUPKddC+ZVa8MRMnRJjbBaoyNjkoxILsQrkhOe2Gjw+ bCgk+zW2a4H9UoFUSB6dBX0a+DaZD4SEjnZM4DKmqJXYzAhb57DnwB1SINlhUpnjqHAzQNS6DWN8 QTyIeqFI7htcE7eibalvyW77Vrwn6Q0ctBCkN5KFsEULh4yrx3IPYIlBaMODSCBsxMclYFpv5Y8u +YnccXbM4YU9BCTdJlMEBjpZT+w2iGsZSTkpjOCSet4fHDhgg+WrXiqmLXSjBtRnp2/MJOcLSL1J Cfw+NVd+SQXnRJKIzZraT1FGDpUHkCE7JAEsWF+2jdYUXhryF9pH39O+xKEo12NRhVfOXHQ1VvTZ 0MDkKKBEdFVtX0kl4nltqbDJu4bK4rjpO9ExgmWBkWWkb5Xi33BgdIw7Zy2BA9i08ZK5Zaiy3wTe QL3Su+ZIMO0Br/Rf2soG7sTgJ91sMM1OoAlI5O9jP99A7mWgtHB6BVxgynrIXsbR5Rz395mvb6ei 2Hl9mcbGd027NgMm2hvshN8wmkILGx523Yr3yTuh0kJSxtD1Ja5K0WxyJdrSgMiG8jvJhpjBnfs4 NIzHdVdjJVnKDTFwsoehERaIsAdrK7CtBTYgWeiTTlREWJek+cGQGwpO4eF999UEcQoNJf6O+uzt ajlT3ziLEO6vtruhaCzPzmfxVeV5wVBFobSUc/VAr+ye4nFCOtfj7NEwWIJ0XeQZbqKd6CELsVen S7M49tdRARuEFyYQPykmM95/6BaTNcyWBQD+znYV8ahFWjgQZYy3XtY1Udn3Buof+rGmihSD7v8m Ln0JlDoIwh9TX4on39wObS0e3Y8VaL1SwfDw17eOJ5uRBERdLRTgdsW0ADe0rY2hW691IoXy0hXg CGQYE8HWJuFyIDbSiC+cCGbk2F3FtpQgdwlehT/P1oIRELNKyK7haRiQ9POcWLc21X1in3RYSmke GgjI3Gb5Rk6QFQXBgyZcWaAPATti+8unY1Ixjkhl+QBwpJEpHzwmSF03ok09Iq7J1h341RGRaYEx 4jqZj6trLfc3jp8tzNAQOXGrBohasngqwXNrueaBA+xBLKKHM/OiLL4CtnXi7M99gz5+YauxYCOR 5tNgOgNRa7PFevHtLhc9peIcY55OSZZvz3I7EVjkO4uyntt2C2scfOAFJ9p22bQ3+WlQ7BIWZ5P1 YFXC9wjCVgBw6IBsva99CVqoEkoGqOzgQO4n8Cm3smg32esQqxTQNtN07SLWso4n3TSCjC5Tchdm 4FQMBeCisYGGjI9JYiPQepwhBb8zsLxVFoHTlWncCaMuZIiMf7DNNhQMEWGfEnE86pbmdvYw+6au 8sk5OOkClxhUB9nxW3aAPtMXgwgZupOth3bfVaelOdjzuja+B9X1NdouG+naKs4QpScv9l+Ztpe+ 9E6r3Bh2orwRfYCrscGPaGiz+gMyGsw/j4tdYXApacgwh2m/FvrdYiMtgPYxOh3rBZnKZuJZUv/X kfi/EI/PydkWsLjGJsmNssOKsiOXdB6HBSw/b+XpsSmimHLIIl+ukRg4xc0VdUL931C8pXDbgs4o MoctlsF3U/KHJn76MnHs8fTtOJkksjjmMyLM3E2ire1SO03W+UO/WRuR2fBmN8TZM2Ib1xh8xDDB u9TJPhyt6inSxOOhsi0f2MFH6QSesd+Hrp4tN1Gpc4P+YbXz7hXsbrKC5hNWIN0SoiUA9N3J0nSz EMa2kZbW9sDb317UDw1WJLSFtupBJsOe1CWINlQxnBY73K+Dfhbz6VKdnlGrwOn+q0A27ZCDkz3k X8xShwhVT2LrTdwN3N0rKDDTp3tR2pqNAZQIoGd/E91qyQInj4Ds6YWR7bBd7qMb2PbgiP3Iu58w 8n3/299c/9tHu61s5EU1r6bV5a3mPwMAcJDq/Jxq5GHiA0X0ztA/O4OLArcI341CaeH3pri8RkkL 9+zDr9tgQZ10ECcQXZfNMBQFKg6MZUulezd4juWNICgZz8IbRxddPbbckE0BsQaLIlzxVU7dr7Mp VHBIHyQnU7+tptAsHWlryR2czFiCEQ2UiOjAianDK0RTmKwWmQzQn4B/0cXTiQ6Vs2UhUUxIammY 9kwj7tHr4LKgfCgnzONXlePqsGG4IVZH4HCDhnW762FDVVmU22zGpVMMWlgbhUXb2EaRvp0Q8mLn eCwRYqCNkLiXiXtNLRqn0AuMJrXvwT09MqFQa+ezm2FRgVwyEsfjy0au2Lfw3EA4SYohNlYdnSiO n4747u9vwhmT434Y9eV8qBlZerE0zUohxTghYI0ivKsDx+uAEHeXX0oTMSPFnAcNp7vEqragmJCo NkOZ3Y1R5pNPNQ01OcCNRJukfBocYPrs0iIjS4gCTVEJUTxnIw0VyxG1MBsr/WtL71laRmqMkaHz KAp/f3FIORmR+EUGWgN6K97YldVaaR1a7ekmLMh1vRIswq4gEx24bs+iLo1UttqgibFXrX4D/Yvv exf/vL2L7968+OLn7V1s1qNhqJus49M6F/+tNi7+jXcuHsati3/pzsXDn7N1MVOO5tfrWxzTg8Gn Hli7bfFDLCH5xjOIaaSstxlIQlreSHhlYTlY/WrqdcBogxF1Ih/UtjfsYLPC94pjyrUEzz6h4yxV EtDugHCQ5P9rdZz13SMo0BMOKYjyzFb3Ce5HUKupwDWCQ1Wh1snXiV5+rKvdd7bdsLOt3F2SShEv KRK4VQzC0ILwTKQ/wr7+mpK0gWl1aUtyT/fsPY1NX133dPfu93S3fU9TuxvcdXsduoRs72F2FHfn gDYP7HlLWI+zbSFF3hTYz0pP5ntIHDqcU97ju1hZUwlJRa8XHmyyTHBwTV7uH0izC4Gtv1gIut5K sDlZNxhvVeMMHS0Fei8Uddipo6PmbCL4zfa8cFoCG9ht+xG8xfZq8cMhPY1rf72lRvCeB+rhP8pe mQh6bO/BD5xygyiQdCCsRQHuBZRCgDeURIBHW0vJIn/EAX6sO/ryLqf/tU5rJCRUAuNEglZHeVqn E5qXkBcL6bpZM3fvCkj9MqXtxwCWZNIWJeeBaESYthCsSKpjtPuLJdxie1H0IbWF6aQEXQ4TMuDO xIxPsoiwGjrx/iDZwCaJngNawTC4VV0ouynGEtK0u94YbGiNAujQdKEDZEhY2ClJjXxHIgBZq/57 24TqAzBILqjiIEjJ5uriAVFiORPxX23PprygxJfwSo0csP0GL9Xiphre5B4rszees9tcAC7KknT4 qZNPNBOdH+CAN/1NRslpPn1Vcuqha1hQJGmGXv3URCFV822KFHxurAjAAE/qZOcOmCWllV2Pu8lp dBuDdoDGULWg60Ak7MMmc6Z5qB7d3fp82O4Khk2w3ADi1UfvZvfD4De1HWn68dGnI9+j83GTNkq+ gYZnck7VCm46N61SJ8/m3atQJeokpIaBnFow/oxNrFJ3cPTz9rJafwZxKys6hD1aVkqcsJIDzurX /kpyy5VgOQriwwZYfmBfqNvWKwhXEAvrR9GiiLZ/7JahEnBKXmjLCljeewYLhbJB6M8I5JKUFGXU gaCy5B1llOD36m6BFr0eyujg1G4W2TR7F0Ql0UsaHQJ17h1huiajST5Dx7G5aVo0AQcToSJeYZAT 11AzBEYENknk1xW6EDT3KjFq399BxPVJG9NVAw0lNfKgq+OrtdrSlNcjCxHXj83ZeFBMvOaRtNIC ZKYTM6UU0KaVRkrDnfDSB7oaOkUBajCoSWw/nvnmO77tTdk0S5zJxFNj+RCp8uBVGixUmRatqRjm Q6d2snG+aVgstiQMMqnURSq7VS9g2hhWXjPqTW8zrkh6exefCDnJfKEfDrR0MFoVNNa1tsAAsNkY Qaeljk0aU4xxTkBJzALLpbR9f+jqibOUWlOZKQh2Emy0wyGKlJs5zecQM+7L0E3hnUV0kuF4zKnQ k03tjVj+lQ2E8ijcl2e9XhQryXGSdPd4GTv9eCFOaSqrSXkezG9XN8pY6g84KsxNzPgYZqVHL6k6 dImBmuFqKIcxXxcPurAywOTNcTAG6ctYEkhUPpTQwnlaS1XXlLfvLbRWhhcquvZBqxi2AcsZy6Sx NliCEOYMdjhMhCosMCN54m4/RvlQPdJ8Xk6mjhz2elVNCjc4nYqZbwQzczfRHxCOYTUUorMUG+SJ czwI1AErq2UTn3RCyYFsYliJx7IrDDOFHWFyKiUA+Frj51gcD6K/AQBwswCl1hy4EljUoOHOxbWF MVSMaguH+nWApRoK2RWeBB/CenCdcE7N7ez8qq5mZSM84gqOWIp+Ip5I1JzbUrHgW24lMAu9KObK lNjkkKoK25np/AopNCM2awA10iqQaRuhXQwM2BVHHGmeyn21y4yR8WkL2/K3A8VfYatQUVqdWDEd QzAnpvWCNl6a/G1VYvBnjW1KQz1/9QgkHIADhmg6SMEUUXqG0ZEZl4RixyleFMEoakZlnVxV4MZq Ob9jX13Z8moHwoVtxrXWXx3HEnunT1DS3x14yiHqFu59xwiTKCa2a0t50puM0GAx/BEiyerQeRI3 1t9vto9ht3Yj96VxeJYF5YTR46U3lyM+Z0uHlJxbLaMao5U1bp05cep70hEhMHJ7XBTZk9HO6Cke 61V1g2oDe+5gL+pWg6ih0ytuEIc+GBIb4dBvqg32jSQHNV9cOSSbcdFi+FbQew3sxLbgP9ldRyUo fg89kVNui9Wwu3JtqGExFVfd5mscfWJ4nECrIzzuo2PgUntZC7yNI8WG6VAxmhQpbwxFJGQbr0Tq 0rHLN7mahVbehXr9eElNNyKyZCU+BCO7LWPVzTLZhmsaYKEkGuAT1su5G8ZIIabFmv2ZeqJ2cM8F auMsx5sirQgV5qxAQQgbxZRbU8LYdwTONHssMAByHV0SbBrPrxsRbTbdcMAivP4JJhkcYscPYL8f 0vc2187p2OgA5QxSFEhAG+Al3vEUVgU2+Gy3P3mFedIORHZKxXJSzeAeYNi9r8RbiIu0Kx/NjX2i ZTe7xkMNWiODVHy9AxXdLrGYaz9Ro2wXvUE2dw4U77vlz0nVqLvRmk+6Bbub34LdX+oWrN/wuluw +/lvwUan8Cm3wFsuQrxNoHb8ygaovW7561GbIhLSGkMHMTO5SutEuxTsxO/qrgukMmWEYIiryRWe WqxIJHR+KVdrszW1Ejq3N87oxHywWSEddxNmdlhKqPC1yMFDJ2YyNWjQAOnUV+mwkFKVaP4fKAc4 dAqZar+0AtgDtrc+Fge72t2g5whdEJaGbP20IL5QAUSWiwtKB4uNU6Vv3OfOZBAiKOu4XGOACypK OfRp8TbHwkh+/rIhg0Y3nTO2W6yD2Hzd/QUfNCsSQNVM97fA5dE30QtI+QrYJFjVtWkYFjIPikMD KbQcAFuk+AlIILVEtY81fVfuiRFPMiYdw9hPX0m6BTDjpDifAm0vF00xvWBhL1+pePAYFZUuR1lN feyYF/lLb3Obi9AXXCUg6RJRyR+sJ5PiglIR5M5R2A76aExeor8OsFOkLcgni7p2e3MoCnUvEc/x xiAE16tsrPORgeQw1NGt0WSFySzpqAzsDMHgscvSzJJti+XBCuBTIIL9yO/nyYhec78g0Q9EX4CX 16uQ7ntatbF8n1FwcaEV68MaeQOxKxguBynQi4qdAi12QAtiJqg2Wln3NC/RSiZF/99ib7EqmkLi zo3RMjbDrd1wi2cMDNSC+zdZOc6gfcApdNAKEP/3hfIB66f1xSCyY18A9G7VIFAwzViuFXn8aByK s75oBocUCgsRu5RkslZ1JAcbXEY0lQRYPBsw38BbyHHFr1HOYPc3lc8LZanngsO8K6pfNae6km7M s7qcXBZ9kZMB9FTIWu7FthPV+2vdCZXWrIBvVkr3ZlcOh9xH598jwH2ycqn979jyDT47lWRj/OaU akg8zdF46othFVJaNdSHtNVKzq2fQ2V7ZZ1thkqKQpOnoX3Aq/QOa3ZDv0346RqwH0f9czPT7s8h lQbKxSgJWMFCiWBtShY/LKYO8A5f3O3AwAy3Akev1IL8gLhG5BfaFugCUoD5OfMeAJodDSLcKigF FGOkUu8NngcVNusjMdqGubmWer+L6V3lk4w7o1xXISXf7FB6PXJJwN8F9LN4U4AFnyNmQualAQqs Sh0fmhgOdd8DV8F0r4t2UarI+WgZW6+3Hbkd/wWP+Ih+euPW3xdnYOxcA18X7UBMBcR1EM4oiJc+ xEFPkCsEA+v3d9lWMPCxLdwE2Lp/iJKzuw0F3QlkO1FICOX5X3CWyq10EYHzPS9IEMfmTcqI3EZR bBB9MLnNTHtIaDjUq6NTJCsFMlSmham7yznv4+XlZdEAvrkrcxBcGQK6ChkG9sM3eOOoqGt8R9yE 123vKflWwtgqfCmYU0rxJHfr7uebAjt/a3UkLSG00HU0iWGHNO6dt+ykxtxNf2RvO/HAJzYNQdPX f/I4734uPA6RXC40q4ClAuwMxyA+dpWKDJL4CW31UcYBWhTWAe9jjrd4G0bcBS/1nU/+gUiA1qck 7HCZ1Ti+ieHoq0XYhk0D5YcylMoquW1LZMaU8guBdxCiNLjRpKzfdlwNY5eCBubcSzQNE+A5QWtq YIrJdUWRWavDfIZx2CNH+VQc2mdDbk7taEBqc/aHigASyPWJaMMw4nMi8OHjJjZjzhyLZrUEe4f7 SpA49jDq23g09kfXFZoFIefY19f0PVgbuxSXpbMxftEZ+H4IEtc0GWWaYRkeDPY4jr53aNxUZGDl isJ+FXVhBk3WSgeeQI2TB5vtzMebzdj+gUpzZBVNhINJXKWdnc0gdTHEwJR88+CwGMBYOASAO6Fo +HUQJhr3NF2BDOvI5LMFN0p2vKXOuXne8XjoTsNhxKI6r6ZYXb2CABZMtaJyZKBrQ8iFdBdHL1H8 mZTzq2wlM1O7z8mzWpUI6T7WouVQDrxVXq7Js0uH+OmBKJ5ParIgJezOCjsrkemAmAh2OGyz9fTB rl0X3YFmOafI/YdP3UfkQ1b/7yDxK9kb6PjXz4/XHxWWr9y5OQHGYx3gyagn//nK6QxQ72dZk23Z HXc1YeXpBMP6SOrBNiZqcPTZ2mRnU38dHvTwUE76R3dk2upRzs5N/o9fjXYysmlP/ZT1cgrpTK+x nhP6CXAKFKqwxrpD1QaqBcLLSGV20DmOZdBzhBAqSKPsm1IGICU1GIK+BFL+dMCVkADWOyruoZkK NAxoXAzmRHjMlqB5ibDSIqy1E26lMzUgfXG+RAsSFaXCiZdstXD6JQuEOS+GCAbVmKKFci15Ca69 rqKVSJzEc6pexlGEb7Svu8O5BhI9b7M3fZw8shj/p7sGREZKCnaFfXAypGaNqn0SuAIiy58puQcG pIviYAudO6/zKfS2mkpYhFRVw23P2FYAl8+Jw033+F+Ndp2Y4xFPbp7Ts0AGkmvR673iBy/CB9l2 2A1yABIu2ITCZGXYtgRnSI8WghKiIC6VRcU4L2mOPXmw4Za7cvWtR1rfqwsx/nXW+0PvFG/ezoPs x2y/dso0KGvLOp96sohkbSkRzyky0eu9bN1yXvzWN3TLtw7xOmL00dbWPieObz3YGT59MDzYHT54 AP9v5+HW6UqaAc1kplk6Saf5QAPvpgZ+tGZgGjcdckHj2if8YOvBVzD47jc8y4N1s9A0yTno6jn9 RuqJ4qROoO6aax2ocCoQyFfM4IjqH57uPXz6pTut0e7XiD4Q6VQXRvrFTo4oPlObYZS6mTy4AaXy OFmAnNS7qPlqMPpJzTskzvy0xCpib4tbwkUggTTvQsp/6T74mlaauMZ1lJACZ5dQnUYDuViUNTaq 7ssAdylwSiFmKzCCxrpQVtFXiEZjEl1C1Tpa1I9opC8SsP/8uC+LUg5YqO0GG7DSN4YMeimKiqab 8ZviuhzSB6CagaqMZQncH/5REwPTLJ2fbDKw3Qt/BvFkbOJ7CDyH+vItm2C2L/ee7OzuPbSzgvx6 BUJbqX2RnziivbX1qhrBfMRQt7b2tp5s7Wy5/7cL/7O39RD+x7ES+iIbKnHU82TTqiPQewGBDttY 9nrh39k2drUGewePaPI3dNExiSXc8+RUFB0TkbfgyEPbWRyPm2WaYzZQsm6NGTqvvzw+OiDquu2E RkjOvyDJTB8MH2eH/3r4DfmY+Pev9nYeCh9iuT7Ip6RDefh0GIlp9lBAW+U2c7Do8p1KBfHe3185 SDND9YQAL90H+DaQDlssBxe88+DB3lejDG9YsNQ2IHi/iTOJ1wymu4Ws2gR4PsRtywx4LO5MuP7Q 27wukQFytU4oxYqckt/A+xe/hDGUTogpIfMXG8hRy09PLfTruwBvJKUyIbcrQzOiIrenEbAZJiNM 0cJh5GEKBdLSIn9gSRBfcoG1gBmkn4cUT+7AyPoS/lNEcKCqz3zwJLp4xrB5999oc4K3fPBg13Pt w3pCHVQ7h9iJfAlm6OTvO9mBNI3VtoqvUI5tws83em0nO4ELD9WdVg62+q1TDIBosSM8E9ufkdsz wiE8ypIQvvLgOZUsjtJqq2cdYaeBXqoVohebFsskXjlf1kOI4SCE8tNfpN3hK2aFgjLay7wEWwCn NJApSAMco0GH3vSfL7xz/VQrKkMWTFBRGeMGnCKEruUFlOn9nlRFrkinCcfJ6shhUWS+Y6urFK8s gLwNfdcxnxU63cQc0dolfKtQsTEcloA61zB0VQOv5B0cU3Q8/fZnh3Nu91/qV8eH2RFU1YVf4QWt xQd/vMH/A2hAFL35Hh+yGgf/Thcesm99adO84YEWPjFTblnLoOP7W/4g4C+3FI6Ix+2h89h/nf1L Bgvcf3O8/82Lo+zF0as/nX6bPT8+enE41p9R4L0DHLOfHIakdKIMj4qMFrtYNjMEtlOmXmhlbSKu 7xyGXRU5CEzgHMVDdcrqqhNxo+y49eoWf4oGVee5+ztUKpFtgV4pKWB0IdW8Qdtnkdw64LE5d0U2 aFm60iAqm/EMbf+sKKuThOK2n4KN43y6bMq3RZyZYVeLkg8ktKCPCF4g1kochczFpP5LxWOqewc8 /zHzKB2v/enuo0fy5XWRY09sSEPxn5AoCzPw131qP0D05a23IJTTaXHJxb18yJG3TMntyLZBBgZL zZUDshONH/Xh9B4pT39Idp7HAye8IqRweLkf4WoXkpgQGUQedBhDFI0IYWRQhy9Ji0pigI7SYT+Z foGRfYJS+RYq+zo8wqqr7q0BhfvVoXk+8AGwb9d01wRPyTUkzAkBDcv8r0LVu6PprjuONp4CjCKs 7Nw+m0QRBzpQFqKfqAbscs6gJt7joFNeYMwgsA9TYaguClL4fAwiZzuD9YW+UVss+s1NcbS9uDCa L7028jgREGKHLi9jtfUxKnPgvWUr3elmKOTUvxfVDWuEZ9Sfg24EAryvQHbnArYmnYA2AOG5XlUg 2RPNECeHptAcT+su6w4SQw7DdZDo9Xb1FypyAiR6NiHHuMaCd7mNk20wKEHG4zcLFHxEUCp9KWXm 0CGHs8LbMp27fVAswS13z+24M81ws4V2Tovj+mnDsf0SiAw9AtUiT6WJINAD7PAqF8W1Y8AzZQFI 1bIf8SsfgwV30aZWJvbR6wUOwB8Df2DNQQfItTxhSY1ipLQfnb6PyDI17JHkz4FntsyacC5ixOZa aCWJH4FOO+r8MRfgm5AFPHGDaRIfbIb0/83zMUbZt5C1V1tL+xX98onjfhfZu0fcmgRONGcqC96z quHb6I94e+fHp9ptpPKBYJtN7du1KLFgr4dE6zkV5S47OajmpbCZzb/zVVzAYZAUGh0kQssjeI+e tcXyg9eHRyiQ4scoJe+/+O5I/t5yXAic/JOCnTzquKY7l7PDh1za1SXmWLconlvlgXaIlY7HNCgp 3BHj5ntJJrxUwVO5IimY9nrvMtgVShPvBCpuyGrhONU0EEGJeiOgRu5d3Hr2YxtKYq3z2oVdcfx4 q7d190/CHwIJ3H7oCcIoBBs6QDyTRxNdOxxNq8rB+6ceyF0KLkKZo6k47sqGi2lNnE06LPikpEZz kbDbUNh/KOg3bJKiQnrfGEc5lm7qo0GubDjdgSke6L7zOcQh2AAVMAX1Tm8qb/xRZBT0fLYSfjU3 aBFh3hgNPfY9vgP2GaVqBRoaM+/WY0Kz+Cfzd7Yty2MlAdZkFiyvxcfPW9VgwtWoJKCIrYzWgOdh 8uSTYDJMgCRXX525ahYKve1oaf3gsb2z5vdNv2r/6DbmtxSbh1cAum6YjenxxStwI6+C8trx2awW j2G1EqMeqldg1eHDnHQ/g5XwyG6yx55aneRknP6R7imbskA/oJ490Q3lxjvi0p/n2nyhy6JlSf/T 0V0wbZtLLIN01Mdh+A7KEGyXR00qaF0GVLi7/MNPmU2PAoCaoOeoLgMvSyxsBFvesd/ZT9nOA7O1 n/xpUqzFj6AcRpTkpwRDa9eZQBYV/oyxCNb8lCpP8ROEfmiOApk7L0oTPieupGi/JCqf53UNElC1 XJAZNlaEI6L8wM335mh89ObPR4eoRh1AQNgCKuZI3YveLgLBvLfrFIefvLWMY2acEPoWUDpal1Pj r6pJ61gRFhBR6svicDRvYBqIN+n2jnGA7WWSmYFkIbFw4VUjK3Xuey7INTB1SFI1PTB0kkkmO6rB 2P5Ytalf3di+a43tv6CtvaPMwyam9s9iZF9rSo87/t2b0n9+U/pdDOk/fg5D+r0R/e/SiP5YjeiP f0Yj+ujTrei/RTP6vRX96pOs6PuToQBPsPCJhSLoyylcSpLrv2mD+49qQRCDu/yyocF9/LdicBdT 5ecwuD+NDe67mxvcd9Hg/tH29vFnsbfLKL8De/v6knAfZ29fP+7PZm9fX7bnTvb29TtJ29vXfRfY 24fZ3Szuvd+10b35mza6/6+27c6L15bbB2b3/xVa5FuGdyKdXwVmLr4k+UyER+ydzswhyYWB13Nk 5K9qzO9oh/EZjPm798Z8Rsx7Y/69Mf9vy5j/i1vzf8/m/A3t+T+DQf9/JStO/15N+q3d/s0a9Z9k mmMwD3MMOuz6USmzLhFhVs3advYB57rbamwZ1/rwph3flYhlQnflGzX0l2StFzhntkl10IvJd/ao 6sxX3UxK82qvn39ee/1nDIrfwMq/O9oDInVv5o/M/HG5s62NzPq/fID8vV3/d27X/6nDsv9EdL3H D+4t+/eW/V/asi+wu7fWd/r4/2bC4z/RWP/7CWmPmT7QPGYKy1n5H0vcpFp/8V75w8ukQDz8xLdT 6vamrZb3wdPRIRoz7p3suPCf36Mt997McW/m+BnMHF12jntDR2ToeKqcD/lh066IEFdjBqj7Yjfg H0ywzpT9g1g/1GDPL/FblvYd6GFlQELooONWi+mVGMUGCTL+LnA2fheHTd4AkjBzNFiX2VdC53Xa iriiMybkCuQyfDuhrLiHjL+kvwvLQxQiKEWS3aFcFAu2L7wYn8Shgu7XqKzF1kPH2K+K8++b5TUa Jbb2T0/h08NvXr/YchK7LvE3FmJYfqwp4qd7U8Tfdojh089hI8g2NxJITNkvYyUwmeAfYyYw/7m3 GIjFIKWr2Vu/ga6GdoeYyrrRXimIpC011zUG6mu6GFJtYyesEFVOaq7wA6m2wmoDFividiN1VW0f hYS+ljRCn9g2JsjO3HqYFbi/ehF7cOvUsl0eG9w3Tk1jruFe0X9WF4G4AGPjZfAa+wJK505G/hNQ Xqvr+ZJv7CRsprU32gGd4eRLx5W+ZK70JXMl93PGEWkDQ8xQK6YeAlwSGnqxtKwBfB0VoVBAkCYf 2ZuC6vPNWbyTws2gSpyeOk0GLaBPhg914oFOPNhsZrfx/2++WOTnV8XkB4AL0Um4adxu8BkoB7C/ h25CGO6QKsJnLwsnMZ7L00f6FNpHhM8e87Ojd3PH/oro6RN5Wtfu8tCzEaIowJmBC/aefX/RHhhQ zyo84kMpFf/6bVFPq5wrIZrbuROIhwyc4FMHDfkaimw72gWPuWJj2WDtM+xVXUaufifyQssEKNOG HEEapDmAnudTKO/nQI48Gn+TCuXgQWSuAmsxjitvLmE8Izio+U+3gh+K0pQ64R+z1ys5/rsMrIff zXAf+Cv8BubA7Qx5KWx6B7bdV6m7w4yxmxgIDm5bxvHLN8MlNYMRs49fyVgEx95lLELhgZk5ai/c uIkP0t1RLN39ywYDZs/d3YHm2XEfxIUxoRD7zqc3+S1wCO3gUc70KiCuwz+YzvqKyiwjFW+Rk9tv c3NNYAkofPkxkGPw1BRKxswJbsyK2BiIsXOb8vVogwfkeR4FJqLuJUZQsQaguxrdvMUt+/2Y3Lrd 6YyW1LWUIQEWpxX+dzwSkJj4uFFKAlNdjCyAABZPfk5EEbfhDssvcKGvr8FPoG0bPCIJWadOQ6tv h1v2t9UN4BwVUiWsA/GppoBTkaT88AgG2nqgedQFdtOaBOi5a9Fz1xgcH+3sDncefrW7QaBql/fD XAu1hzTQQnHzQFCOpl19sAogVB+uVobEmUNj6MyBLE+I062hBlI7+bYTj1YOIGeNbRBgA7A3J1+s /iiYKoIEVb83sDBHuxuannck8P6a2v0g2mwfH9L1/pdHgbm5zev+XNbY9ez5NL8EMvJg6/jLo61Q WMOoEP7di2n+11BAM78b0Qx+1ejFdhIo0LRfYeodJI0WBhTY9E1VTYt8hhZV1fJ2BnQdQ2shGjuR MqDVznQfzkH+ww4HII6zXdI34xtl20nBiG2J2U21dLozs11qS8nkAK0dGIcA1wt5l2BXH6l2CEOJ jQo0em7QBHZobFHAdnTcDWeIT6E968QEJHMGjZAlzUur2YYxYsE8fGGb+zG4Y+lHsOPJQQ610oJ0 KvKLfv/gQ8t6RCbsKQ/C+/Y40rFreOFOe5Zelk6gnlQF9QRixYse8GilMCEQxUD4fT/+gFgD/2XE blYgrnWRy5m3SPzaAAyvUxKEBb9yD8ROIBrakwYhvnAPwC4AKrN01JpUlBTj90RvYN0yYtFF+1Xj XT9x0Ctkih0OWLUVXZxpqynq7hdPUtvzwMMTLAJepdrmnsOwX5ex4G514w4JmIgQua+YjsZr0Zcc b6I6GqIpsq9w85kcxNNyyo+2yZ7fZxbL6R8h2I0LEssmvlWLHNNGIp6TkKu3hV6d2lF16i8EUU9w auiSqd0RQjuQ12huNX48ap02Ib8m4CmgCSR8eWEMhkVxDq6ilb72Qunr4SAlfon09RsXvUjs6nr0 OcQIaupx0SJqQ1YZNhQofibaU352EaJrv7zdj6LiMNYdKHkvQcl/Qfh9ugTxG4Bhihv+QjDMPl2C WAXA3z38YvkBnEDWUZXiaaPfdIzVrxpkNfzNRVn9vYdZfaUGhnSYVdyQpjPM6u6hVUhQ+FsfMNIV ZRUvJLr0m0VZrUgq64i2QouLo4B4ncSoPefGhkkp8w7xV/fhV7/d8Kv73K/7gKtWwNXuA3Xh7N5n fgWsbcOYrk8L6bqP45I4LkLCvU1Kut2HfN2HfP1thnwRkj8kJAeFsQvF72PD7mPDfvnYMEJPaU2U 1FIGmUCnkew+MPnetZTc7yekTP3V+0GAt3KiBKQHwCgNv1CipWOxU3xgut6bKfN2/Bqw4d9xtNoJ 6qe/tUg1+s/vKEFUsM94xFYYGCACCiWdDV8XK5mJ8OhCWGC0Rbu8j4Z+oPDprbJF6+a0Wb2RWoEu nOuFdwLA/sG3R4eD+2uSuCbdVX+y9SGMcZmg2DX6C4UwdoNFWN7jv7Xwxb0V4YvwHAMY9fWHoVNW 3K+GljErovt8Z0LQvtl/V9GTK67d+sjJ+ON1QZOd7wcTRHu/j5f8Zaa+j5fs8LnSv2Nf63285H28 5H285Fog3sdLfr54ScfhNgmYhDk6YhXR7XFlhJMfGm/47QpJfPDZIiM3qfD/eSIj1/YgcCpjS/L5 sdO7bHbc1gT+voIkHwUtHU8TJgeSr9jksELc+jllHDEU8CEb40TwYGs7+WL2Zba7HZo3Pm2gv9F4 S65shR6Mihy6KyO0MGoj/Ggn+qJ497lFld9BTOEvBOf7+M1fENZ/52GevxCY01SX4c1sqQRX6HU5 ZKmkEmeO+LaIxY+yfcPH7IIxLoblAATUdb44v4JfHWghMqhJLQUllk55wjHiCgx1bTfzzugxn3DX BtzI1WSitjmebO5mKDBCEzVhjs2AICrvLOcBSCSB6BWs297DzfoZwLJYWaSIgjMYIVlIiPxLQaMd N2VHvGCH/dkJUkuo09osqgpNZGhDjGHoSQ6NA/ILWy5PJbgH7gQvtCkg+GVReMvnKqPqx0YL/y02 kv7txQrfN57YKFB454E61yFiZVqAGToMjmkocPj3F9WaiCUiu6kDrWOAL5LhrZAakH5y36I4uw9n /U2Esz5Ul96T33g46zDD/9xHtea/56jWzxCquqYmfsrWtY0iHd42X3++LxkbMDTOHAWHNixWWR7A M/IfSFfBTAl/sxxYQwiVO723GBcrNeoPhKN2zOF5SWsGtFh+8gS/UjjawfjVRvFoo3UhZwAAhy81 mBp/XJNTTiKi1RoaCTHrNLAG3uIGbxTcWaf1NOcF3UG3BDiRehL6i7/62HgpByfQJlCjcbsreHfh SbSO4i4JOPDrmiQcsEd+7iH/V5aMJU/8SFtHVVexvxU0Dk8WldIid/IAqluHSRdF3ejH7dDucZEK 7cYPUtHd5AMmaYXeAzSSY2kkvHMtcmTbsmqZF8UFvxv3oloT8qiPC77b/wSd8XetMt5rjL8djbH3 j05n3FFjzL3OeK8z3uuMvwed8ZHqjE9/Rp3xPgPy19QVOzD2t5cA+dUvlAB5r1V+zAR3VCt/83rl 4jelV95FrbybVvl3p1S2LrTchnvF8l6xvFcsf2uuyF11RWI4fz691yp/Ff3wXj28Vw9j9fCxyOZP 7nuj3/sS/358ic2na33Zr9eW+l5fitxwwX/utad77elee7rXnn4Pbjn+j9Oi9jKfK32vRf16WtS9 GnWvRrXUqCf3Gs5dUejvswbok53foAvsMyhDv2KRvHtt6N579Der/yAa3as/rbYXLWX+XhP6e9eE /rDzQESWYva2rKsZyCw9h1U72Z88j/orCERQfS8DCgDlOP4Ck51IM4xIHANG0kBRBdg3fEDVr3E5 uM6a1pNNIKaizjTnlUaHz0B0eVtOQIRouBwV5SmfV9dAambnTlZEdkS4YSYEWOE9lUHr/MLd0mxS wr7PlggUrA4s9WEc8/jeSWJ/wYXR8mBXjtLn9aWlQnZe398DZ4RCHuc5yDMVVycGwLlvzpxcLOsA IDUNodKkXFL5Ok87G2bAJBZQsxGHIDOmT+5azGunr8444RzveHUOhSndF1SWzlGUsppAUjiCkvKV PfRhQUSP/Xpba3PvwMzCXK/yt0X2nlDgA9DPuposz4s2jtobmk8vHe1aXEHNl4PXr8an+69Oe/8n odEfnZz6dW/7n/Hg3IIdLV44aVmwrD1shw7Jw/1zP9ImnZ5QTemY/+gI5AOdi3Cx9o/d+A7o/+wU mJM3rw+ODr97c5S9cWdSXW87gTN7hnfOYWhf/8VjlQ2Vj54skQRNndBUA0J/5xiCI+ggDAm2FZNe jUOqzP7GCbvIER2CPsj+q/v7v4J8G63jL3m5+M7d4uk2LNsvJbGAm7zkAubNvDgHEjsxSHvdCJqB OOxgOIu3zCLcqZtn2281MZF8DlNxPVQEKgEyGLR3iGdIZ1RMYOx6Gwp4w7+QXh7PxlQx/1lPgGsw dZ9qsD4DywLN3v8anQO9YJCBaAbwy0uH+cBfBggR+KVnDm4GpQz8TXiWwQtuzG+O/nT8Khw1e/bH LL3W7J8Box70vsw8ln3dS6yhNYT7khH2yx4gZebAe0CF72UP2bxyNxCw+K+C2r2/fHvspP96OUMh 7PA1L9d9/BxD4Lh2fga7sxcdj8V9T7gXraznkTxet4OyAK+9hWF7tDZc/xjikxNBZUC5iDMRfOyC +cDdkmMk+Lrn70I4mVvs0atDgCSIiFU1h8/9LwkURMw/vVoyDgN9e5/C1G8LR8ngnwMnjc4m+OfQ UcX+1x+gzr+7C+/1lQ/AbhwjdRST2IqS1Zz29F6HcCN8YPGGQQB0dJEZClE7fo0sUFT7J4NHeIFh BpZtGyi/C+bKeVXOPNdToiv8r/ePgQzyvn18uHb6GZkaqKtMdcuZ4//Z1EF1lIWlKWbFTQvV3DBQ QaS8ZgUY6/RGnAe+xbBK2efATQ38NkON7kYEGPMVQ/Aqh5rK7rEkUYh9Auc2FF3F/SnUrCBFsTYV NB88cIRqlCreW636Cj9KzccKgVxg2RjBCnhsMc3nDhsArtzxy+HOWUF2Pad8Y0F5YXSBtIjcaiRM krk68OmhMGr62e+ZsaiSsnFDRauIOWAs64DqeCyJZYXiUX5eO1LkNJzrcgqlyQDoIBnioTjVzQmI u4YCqqDXkCmQ/m0mdCtw81AdGOmTYqSL3ILUvTKrzEn8/3YyLBGybtzruwyJJwrb2HPbwHLJsL0G RdwrMEIUHm2Px6+zrx493OUidB1y+Hyanzud5LyoUaasE6OidOjHa1UrFymQJLRLwMjbCll3BdWh YCKnCd6GY2PbNxWVHGhRxQTt+XyaRzMiNjVFOIATdekuHY8ZgLR7ImEHbsDyclm31Vmpk47bQ8Ol 02fohJdnM0e8qvp7Y1AUjQjaDiAcybqGBk343dsR3QhH429Ju4iHPicjWvM1fhOLrcfms7PayeDn QG30GyCj7e+AtgaT21GQwA4X1ZAorQwFulMAsmKG0icM/h4wNThXLqj7gSokD92eFyUhkAGVqauP ylXDFgpZDdZqcvzJndu5uAVM702watiu3W28GiTqHj0c7Y32SElwAqMjJ8ARb7H6swPcK14ZWEsX 7vTKhduiUptzwEq0+sLnr45O6QooKiqaY2AHHrlTjUvgM1As6xowednknvr53TSALMWsWdakCoEd EoA6bsSKgLh03RTTt+ywoeJdxEwqhz/cQocIH5RUTG2GSMDDzUjA04dP9no9LhKFZvNWDwF/JSI4 70LxGLSbCiU1FyJ1VAvhhQ7D+LaSJ0akenP05iL6lTqdCJQMdzqvwPLtluuEhuuz6W0ffrspwGra dM3vhxxlYxgGIM/eCWBgF2CFZVKDnFN0XLMqOJTU0CFhtKD9Q29nR6wR1+pAcT+qMWJKty44Gt5C nQ/ZJ3k8/hGAJiYdDx0udHbt9PeFtngBG0Dt1FZwZyDCtDw4jLtMTZXhq4OHuRFbW7zTqMNcQ8f6 p8OXr8GuzlJOoPI6iHx5fHTgxI6dx4+GD0e0ecf9adJJVp391dEAXH6+YC2TBihpp4xpRHfRTBCO SQJl9ODJ3h4LVWwXwd1dOSER9O/b9TtrwOO3hAqoiN2FoyKwHWQfRfYUeLgTKd9lRzJBiNF2A77t BkhURkBzTKOq3caE50X7QmsJsUtH+ouGZfWc4K0g8VOBjMZeyYtqOcNLCQYGINRIfIPhkQYD3k/L cynpBqdpxnNr4l0Ouh95Isqu0H/4hz/8YTh0mL5LK/Vf9ehndwWcsuhQN37e6AvulW8KJ/uUVDAX GO/0FvW217MD9NgNv8m+Ofp2/8/Hr79706NqModHz49fHR1m++Pen8VOiF+CdFWUSE+ZTs3FzX7t SK3DVelJBIBtwOhYgWBADOScPIQILx3ubZmTSPHmaP/0KHstt5hkXJJ9/XFwqyUiOPmFQ7mRU9Yd GSwWcDSoprU3ZPaDt9bfDxEa6f6qoC5alshtaF/TXgotSqNAoG67DAqtHWgE+GByoB+yH2LUN/yu w3SWG9JD47Wa+YUQVoUCuXUcw9NZAY3NcsdfHSmbNzAlMlNW4eAig+7BlhsGBF25mxync2u5BGHE 62Sh/9jvDD7grbEcERkiRJuBmb165JbakLyAT71Ej4vC46YD4PbBAJSaNd3cKpBVbXVOdlJjoxoH uGm+UBWqlr5veGuNUwpn1AtpGbT+uBAhIme7smOm1XmJREiJwFneOBrdwhjUWTzALA5/W00nG6Fy Fv/nF8Xte+RejdxdiA0qZ74Q6wZ83r4W+qFdF3vHrJor6B6gd1NVM2x29JtDcAQAVED/C2DAYdmA djS5E7kmTRSCQSgiB+d6c3TyYv/gyCwiNqYBn10YxCPuxCgvC/G8hwSYRYGNJN3sxfUcS7mKgTJP TNkx+NEsGpsrr9JOLvJy6kEp8R8eir52/J/LasqYz5IllS1m9ocRKC+cGgUU5C4QZQPFFD5FLacB V9o/yZD/hLITLWwaW3woaGMKrbsWZP+CT5yONacIn5LH9VcqklXLhlVkkrrLhUjjIJOx0duNxOYw GIBnE4QG4xklfU/wEEkDBs19iAOLrhfOi7Sf9ZVVsivimepZdKUX/nrYJa7CjGoW08YYVyaMgdpN ik4hBW43b74SLA5z/El0wYimZrkYKHUOSgweiI90W0DZZZDZ2G4deq11M0AXmLQOMveLhxHLbJOC BhHpHxFb44P+CYTdfwoHlw2I9zXf+BbChWpURC280Z0AzdiGAoI8NYOrQfk6nyCIZel+/4MOivM5 77PK7rsi3iu0nQjPFiEunLx/evrm+JvvTo/cRf/L8em3/ods/O+vTvf/zWkrx+PRvv3oa/fuy/3T g2+Pxtnz12+yo3/9bv/F8em/D7Lxd9+M3eev/jSGd5SIZMGcq8gLEEwbVQkbzzNr20IbCbBjKZiN vBlMEWFp6a9hBW+O/nQ8Pj16Q2P/v3AreVWG68m2v3ra//84uIUhDs/dWSzh4loQHR69Of6zG+35 m9cvs396U5yPsn8bPdndy/7fsVb3T89m1ewvdT6fuwtz4LTABbi1AqAkp1upTmU4EAIlDMfgr1kY W7n19Ca3d3aeIBDYcEgGrVM0zm2II6/4zLrQY9WqErNuP6VTUWzeE2zW4FeHzakbcbL/Zv/lkZvF TXjw+tXp0b+dZuOTo4Pj58cHw6M3b16/+Vp2Eqx/OZ2GJ5QYPDieBHMsovvI3m2SIS74lBCpUyIA szlHbJzYdlViBDNa3PSlhqqqq/QNXg9S2Qd4E4p3OVD9LnFCOIUfMGfpedB5YdxSyiTl2d55QChT LdRU9UZiTfa5Sc3t/5+9f42NJUsTxDDOamc5pa3w2p4d27srCbFlG0j2JLOYD77unZ42L8l7K3v5 GiZvdfeMeuFgZpCMrmRGdkbmvZfdKslrrWxYlmBPVaEGNvzPj9Ua9i+9LPuHYQM2/MeQLT/gBQQD /mUBsjWjhSFAXq3s73VeESciM3nJW1Xdl915i8w4cR7f+c73Ot/Dux2Hnx6eXKx3T56ferfiCKt5 glyF0sgsyW7iwUmEN7325lSPWklkcJu4YGhOoBhFt4ZD6QWQR7LxMibTJwrxyrG1GnJzoAMHrwBE VebwPqBT75YDS7WYCyI9DedqDEGgfKEBEosvXndXa7YKS7Z8sO+zauv18oVbjeau3WFCyrmJQjeO PU7jojDEb/pxPFgGIexl15rtKrDEbwuYeDHQ+FhQDjhSANyBkY5csAuSdbufLIcj7nprrd0CRNhZ vju4DzDUu+VwUC3mg0D77KfalXfxZepF1Jqdwgq9CHaP1fr6KV+5r/VcKCgPhciN93Ciioz7/zKI 4AVCrbVTgJZUOcWiJPus0NwDVIVOyuFUaDpfWzaxUsDhpzdihGSfS+QjIufHRTdXFPnR6I3cFpj7 IB7G/DsKEKq+K9VjUVY5EKN0+KHvurix+BYUIVtrblbB/y3oty07zoX7AjScJLHc5SyLleq4VtSR FoekSXyLDkrxSKPyK4E41na6FxwNqd8qEjYa/J6ETd6tIGzSYj5hywdcCKWT750Yo9gZYgnyp5Za axYJvIrOu88x5lcrkIgbzAXCK5mD3CPqWBC5tGKPAIbIEnggndZaRT5vSlzaCMlwuj9Zs3rtzaNr 82cwF2riRWKZK7QfWnUJT9JAZpm+BVgWsgtAr9YqMtpT8akni+r9oezpphzMnsZvA1fVnUBwcZD5 1l5rMXmfSEgs6lwPp0zbvRaWfE8dmm+ELRWavS0iVuTUiKQY85kdzybjFKM8qyHlQKDW2i6gDkh7 n3Do+H0QBuNlehQuY4HIxRM9QB5UOdyQAPb7CKF6CBSrfvo01KYWNBuKVQG9gaP+Z6Ajk/056t+w YZf15RIHk+12W3eF/gNRhjZymIPqy+mqf3TSy+nhQYBf4hv4bn/9DKC8/zf2Xhw6COW06YoXxt4w mtyeWKusFhP4NfHbTm9vZyP1GnXkwMvn89JSXr+kGsJqdEV7O25F31Oyee5JEIwPXmJOg2gyeBK8 0OIfGYCiEbtaDaJphDKzGPixLVr4uyMUtNn3Y8p1tY09zNLU0Q3U3hE2PLPVQ5s2ulq0WdzaYXkG WyGS3IdCGsejk5QB4zdng9RjD9GL4Rt2Ew6JMsjsct1EvsPMyT8vQQ6C5MA7vAnV5FKUJMfRZcFH V9Ewiz+S1AOj1Im9XAO5J+RLS0ZOnL52NrPjqViOl30nV33l8j1MPkOPdcIKvq/CkPFh7+yoeQCb i1EQigwXsIA2q8l3fUoQ49GZ+Gda4j9lZ1OMZsApAalTv+LXpyM7lI0WQda+h9xFtYh1m5mYfaKr ObkSj9h1WM0Qv9O6sKFhgn50+TxO2BWZ5C7N7R5u8nr4X3HEs9yhiB140bAcsIojn03SyyH60ubA BSTuEi3L6/t0KZZf/MnRcWMit3J709PJSRwh+9uPgCOAbqYDEpjE9PAOE1W2fDdfHEc/SydfYIFX 2BJOqzP1Em4pjFrsUl8UfkQBsnh36Nw2amUc41NEalBpESYOqbW97STsgbbljeX1fTWbUA/We/Mx VVIW9PmSs2+8Y3jHja803SpprcTZ0XW1pZk0wzQFgE+giIoSejBJx+N48ByYGlpZChTISjjD70WO LSbKEGmZ6VlCu50pg7rhUDLigsqx2TXq4PWd84V17SoxsyY/g9csNKCLAkBz2yAZS2yNmoxjrHxA +mFbcH8dSAi/kthWK0yawZdPuCQH0MlIkMfdMZ30ZcBIqKQoXIhlDbvGGy72EI7c3Q1nGLgnLn2J dfM+iZORDl5BxzHXgEjgYkcF8s6gPde6Fc1GwcYZDnkYTo5IoWLKHHAlS1CZbAh3Mwu6fDWgV7VW oMRVp/LtCXI5Pe7bQTink/1ZNsV4PfqTap7nqPL6rxdZXn8ouly1vzZ1Rn/B2RheBAnoIMbI9Nij HYS6Wb4QNx4neY3OHQXDFLDNN8rjYhmNh3xpcS6fjH7tuXyS5fHI3rlMb53BH/FCukgP6RpSWKVK e8N5cHzapvJeSjLtt0R+WxSpQUhQzJwTUVKcUIcSmqugXOMC/i0yy8fFRxuNzkQz99G7tyJ367+G CCpbm1XvrUHY5OA5jsNeAcdJBoP3bzwUT4ibNkAIUAfJ1VVM2SIYmCgo5FIQstAU6cs0I/14gsiU oiyjYLorzoCEzL93+vJ8/xC/jCYPITZqZwiRLCr0UVw54v0UpjW8+/XQTr2o8Q6FofW50tB7HVUR h4Vog3dDY1c5Lap2D0MUfD0rf5X70YaSBKBEKLRjSBmhWF+OUnhV3vdUw0c1fKD6BojHe9qRox3r b0k8qvbVoSHpa7zVOptNrmMPyaCEqXTN1E/Hd4TlgoVfwOJfs0hr0xSiERRKYd/44+yp1RivCSnZ xYguKkdxOsvsSAO8bpQIC7540aPpjJIW9lqT/9YLwO8VNA+aWhtokDJ8Wg8+UBk3gcxBi2cz5FG9 5Bex4W8fFLBVleJCpIQlK4elPI5qUxqlFbTCAhnjDBe059B0ZhHmnrbcpzYfwaae+dkTkjB8RdGr hpX9mejeisur6K3l7U2y0snCZZdRWLBTAIeDNGZrI/MGglc/fXh4SRglriKW1BQ4Fq5Sbu4fRp0w /ggWPXgcnv/lc+T0X71jTl8glnNO1P0oqENCJeVaJcNPpmUMf0FS+iWR0q+g/QPQ0i+Fln5VSku/ QWK6NDWds8MO4/9g2Du7SNMjpIEXKWztOLqGFXvoqtfeNVYvKMMWOT2UUVb0zEDb6zMgsZ/RkecY NMnj9C7OPOLdr92Z9+/xOzrp5aL9wicdZfulTrrigr/iJ71kX62bEZ+nFw5c7uj14eKeXtiRLGCe u9fmfdy9YAGZYwLtfZaMvQ4/5Yb2JDM2eQacXbMgLugSxQHLj4mVP54SrFun5AFwqIg71nh4K3RP Ybu4QlvmfhoEOkhVMp0on+4Xhxd1/ibp0Xq7J92L7t6RpK+nCN+9i+7pSXj+8ugw9Gc8Mp1kypfd fCX2prNoetMbD5NpFkis5zq6gq4DUu69PLoI5L8yrlwF595cP4ivotlwGkDv69KLGgXT3s1uATsu rMSDZLsCRFh8yMpuqsbnucKLKqf7fUav6GT+2p+pbIwPBIR5/VXMaH2d0tk+YaRNjGcsiQZwTKRQ S1anHAev09lQEkRc6syZA0x+ZdxubrnkTWQlnZROeEiVtbZ3crb0gj3vli9u7towHgZdhN9qbdIJ jViuey28wvIuyhfqcVVZApML76qBkDSEewcHMNjx6ae583Pf0TzReovQirc5qxWdVIw9Br542KNE 1edAPBceLvde1QhcZu8+56D4asU4r9lrFTNrLTyA9U5Fz4NzbKxzf0/83X/o6T//ZsUgyp3YMCrX Ocp87/c0MM+HPt/RzOGAlstLXHBqsmaw0JWxxW09XN88dQxwFp8vuXsqcOwyAzM0fCojzFdKTeMS uVY1MFk0XpyfvjwTMWVOUhERcbLAu0d+5/IsqN6PYKFd8AixmW1wz/z3+XFWebMHTCO/7mZh3a3w Sdjc3W199IR87wLBZILiyekFhiKRxFYAYVVXHsWrLPTem5xhbsz2vFizOXkzvFHv3ohRf2SS860f FQugL0G5vLYk0jvB3xtqhAlDchE8taadzQWDjHQIbu8+kUH0dssJDfLEBnGr71JwkESItIoRItdF hfGo9d2IEFn3oL/RDN9HiHxrI0QKaPiYN5OTYoDI+vsIkeW9b/S4ngARvaG+ABEgf09d0aRXFHvc 26576WNuF1UiaysvsnqRMnsgmepDf+/3kVBa70BCmSdTaMK1EKPWDLXWcjl1W3HoXF0CH8smEl7F ts9UL+fUyTz+XWi+vpj5d1FGbp+sxzH+hpIlzsCvkFelwNojJ9NIWOMQmFhHr+N5V9fv+W1ZwxlK AktJmK5Tx6i6hmUJBdTduScbn2ro5DRWszTBw7l8ar6LLmcDjAG4hPkWk9DkXd886VUsWlp0grM4 XPmWfFPW8nJuUGE1n8TDCFcYckVHFD44Jzc/QKjyyaRkzE7aoNtZRjyNXJkw48HSdvhyGC7CWJTm LS8r5SdZ3hRW7KGCr5hZ75WYQEwLk1zkqFVML+J9xQOKaga1MIeqGKKM19xbvatOszUnCdRCLKfI DGptm/cI58nlOr0X33Fr685jO/nW698xDZLm4c306uE1fk9qrCxC1B7jat0NSPziqM7qpLRRJ3HU QypkaqBfM4XMu6GP6yr63q/5MR1GS3Ixa7ZZwjPRbC/Xk1NdhPzDxa88+I0K9ogDsEEyVv0vzo9V /17+GxSuwUpg8DAKnb/zx9XKFHVaiAMW2FKt4zDARpNZoLKV5ijxvVghK3pVDNHFOK6AVkC4B8M3 7v/R8W0JJbi4K5v2rnTCPZ1PH884QVtpPINBrOp9FVJoBYF742YnVq/Mvm+/Res49qffh4Xvnx6f 7Z0D8p7w390TWG7vcB/x/Kkr7TiTmZtNE3DeKIxA12npvuQONh9CUqsdxZ1wdUvgIGqYZL7MgE9L d41y2bvJHZqSxt9DvRYGtX5jDphtsOYB7wFzfj5zoU3sTuWVJunPpOAKNcrTLclN3P+MNoUej6e2 deCod1bnsLQTcmrN5gO0ALpaU/J1+/jO0oAthasHavnBKjMlGrDloBapyqxTDThEzVIQ6ebTt8XN ArAAlHwNtti9twPbty89YUN3kfErkfREuyhi5RZWcRaK7WdhSCds0XIbgPPDKnguBLFai1HV4990 f2hSLaoKenB6jr2dvMjB2OdjVaksqomqe7tr7WaDYN6X7kK15JDXnDHSAqJG89KspiPH40r81Z+K JDbJVUGsRG8fgGs7Anuf98jj4bJ3vEpSYXB33yRT6Z2FerJiP7NxsxIWvgWr3MZ+8enR6KZ/uMX4 zTKEs/VYhLMEXkA62xY8H53BLyFH+Wf0bli8ZxsWAa+PybPmkXcoe+dks+DRNg+OSZ5uIqBc2il1 KDKleA8sOtljsni0d1IghG4pzWqw5sGmUryXOZ89Hj0sGXFBimi4uT8HRwX7rgBPGRRUymlxxV/0 EHep+aIkkTufi0dTnIEy2XjIlm2PU82ceqXk8oyoQzFFqjCx5KjWlqQ5gGJAyB2sctlcFC7q6tpc Pi8AHhlkfmUA29VISc8DGbF6VWodNSkypu71H3ddrXuvq7XoumQdqjBJiWPs4511/4BLH/UhesgX XH3ud9RLYFBrbWgQeRw4HhdExQGXB1HrYUHkgUGtzad+jvf044GqeuClQTZnHfeD3ZxOa62mDcNv k7nNFyFSxZN4s/XsLTmR/UHKuNTeNBzGqN9huA2zK3XNT8FsibrlVyn7TLRhbkh2ssSysfGbBHpQ F0sxXWb4fJ4X2ruc1W5DNsyT5mjRHfNOpXzjSiRPb1BN1Q4VAYhWH7QBO3tmSuKajetl1LZBkVVy eTgc0vfqogm7oo27iV5ZxbR5R9XVnN2pJYxcheru1tTGSNR8QOjHFxtG3i2rrE0A0hUueqGnCuSc DfdsqlxxzIm5eEwqVzVwJZWjDtnuXZFpSq7h552FqlmAOrZjQ+nIF3T1zlWzymjNKrjJ+SyqasYZ AW0n2mggBYDuY5iqBFhtywaqCbNdltCYN+8NRCvGdxHIGRIzhhd1Bm0ixE7J7Qz7REvM1VXSV3B+ ZyfdAqm48pS6Zy0L82IP94a9x1dsuT1QPnT2cgyzvIy15yW77LC3rPg6Ia4r5YlsMZmF5+Qyc4RF 79H5/aF2xQN8VdRowcjnd09qFozIrigkdcxdeOxDVkdkSUPS47eNh7VeDLs5JBeZbbyP32xsrUkG OFqa5W0fjUnxRzGA9nI4I76LDir9NJpkseSQaW6Et9n9iNuCu1VzNvdbwjyqwocrj1/ZPmazfh/4 JppLXXMfbah27CGpCb7qHhijdO9twF/CW+RqrzqhwjcI9oXOz0KAn8TrziEiVwDOVPKWcPVjM9sI KxKyLcpKTkvCd5cHa0V6gXn2JqU1ZJRKzrmrz5QhP9MDWFcpeanosXh5BaBru4WtaH2btqL1EFvR +nZuRQ7QtRYLs07Q++NpTfYw5aE2XjuQ9ep9LWbOIlUtz2LyhndOXT35I+7HymKOqDnj/sLcHT/f 692HtHpgJDXHS0IgvmEjmX9Wc+9u0CSlHdRQHvOZmuSRYzTjg6yNLnY0VdS/IXkOzjycjnU7JAtw sB8N+7MhEQVJJR4nE4eWr1WjdAn8Vc37ReNPFt0vxy11gduTBccv7kyexppK0jrcw/ZTqSrErS1b 2QJ+A4sCrNbecAHsidZ5PDJaMerS9nVfXyGHr92PylaBpNZm8TaXlufdU9xcWqB5LL7g2KKCKbPZ NawLUfCwFzqRDqLYJVjTVvwGKFQGNLqkn+i0BPnX5sA2B7eauLP4Mto8Hvp5Rlsa7Yp9jO/N132r V/XRdWa9xyJxaoC53AWrygjW2Hnc68qeDgAYDdjaQ1FGqZ2O44vMuRWoxdkaNsTYEWp1wsG2IUfb hhRumyHaJs59gUTuxpPkldZzIytdtQ6KwosAmeYtOk1O5hiiNZhBgWXWozIlLgr3T7n98mdZBpp7 hmOpd+w4Z4wIDCgrTUFSjyYEflO3OEH/REyXydDCkwoQn3NBpVYuyWqs5F3vnM7ZicOq4LN3q+4k cCCEwSAeRndIvaQLcXC4jK8wZWiMsMNvT0f84F5ipQ2ZWrOon5fkxrKB6MDwS4Fh6AXiV09DP2Xz K4H+wStMheZeZ25acb7bKS2yntfZ/FOp/eAHaz8FiJE3hC9F2Fw43RdMznhmQAUbH4Jp2JTMdQGI +N8EKPwAEedDCavZ9JedR+ImuSHD49NcxfmQq82ryJxNKTffJ8KkX5O+ANz8BT4sVpa3wZRr910M /1XErPdZ/LoY9WvSoE+x3F+CSmKSxaEK/pWUDlMVx3oVJcOMnYInlChKMTkZRac517MBpiem79sx rBA0KR12yg0UseVQX6VEmbAgjEt+wKhh4VK/bkHDFhY8ZqiwDKNo3PvA4LcKDNYHkjopBgbzCUex UgH8sU746xRQjW0a6JtCSHxDqbmgj7u8v0tC9b5vU0kpt3d+uIeJb88Pez2Qe/h0qiQzulSjEA7n 3EcPUhXFtawUaqYV0gj8OtZMs5HofS6BX3WSwXgAgozK2DSHbojzehSOgH2YNE+ULoR7qsPyuXwG KaRDELXwN+XLkDWUEbD8sCdZAd8MZAbzMkSVZQOxcLyw6odC9MWSGD5MDsNfdwTPb2JSxO6SgsIL Zrx5X1D4V5jNfdMFhd/zu4XJwWLsbm49YaIIVV62b0cYvK7Nb1dUeO/H3eOXx3mp+TGIhX/2FZRj /deYdFT6er+nIN9VCjIn/sBOwvVhoA2ykipq+vaFo5Le/IofB8V0R+5rleU+5NlxPJ0k/YUHGNhv 6f7PDs+PuxcXhwfctMdtnRHWz5QfeslshtHdknPhmq3RMDcZX/eHb8bxKIsfcQA8co/Vffxmijda wwPyCF+4f/e1iv6lJEB3pFWgfGLtEv3RNPDJ3y4276ej6SQd4oV5D89c6dNzxfIeoUaLuaK8V1UV P5wCP3QCD0wCDyTy36n1lyUHoIW8i8Im8UOUNlm8Nol9Uey7K8JMbJ4rGona0Xc8UjKkUDrMf8+j Wi1y16PaLpxkfMHrnsdPMy4FL4fR6KhpHKCK7k8lGcexc9u1QWUQj4eA38B9p1k8xNtRFP+gb7IT X8ZKvjraOwmPmgtkHyKGrMvkIr8uS0XusQktlzjcTGa9DAoVFqMF4Vgu/n0n0oTDC5m6wH2AVOAL Am2RvODDZvHts0mSojC6MHes6qSS1UuZRVC3rMITlSuzGy4KhYfhWIsON5+nvEV28PnjL0zzLXIt UUya7qtCFGkymq5P03X6pZL4n00v0rNpVXLTMBxPz6bOhi86Vd255D3T8+zwPPt4kOMMs8Ek2Q26 IoW3JAeGupRv5eQP9vahh0O7A5Yju+r1BVjaIp1UMrUzJAcwU2ITrzhlFRCCRRZ3TUqPBL39Ip6k ZL1AvYhJpboJBCpGCimmUT0+JR9CSYPD6Vj9JKKfX5ejjOjlLUwtCv3l4VQhXRenonWdb3Yijlb0 DU/F6E/vZiKLnuOFzpkEPukzvslnHD3oAOerjnGPmlTToHQ2vU7ppmg47H56fOqHiwPkEuIl0B/F yfXNJQjmvZOzPRHb53a6KMD0ilTIo4bKlvhdiU9/FVh89fsKUkDrW2XCaD2uCaP12CaM1qOaMDji 5qiFUXDH6WDxymD5F9/mLJsiVs22i5rbLmpWKI/Yjpq1ltEdc298BzVII762vhkNsvVt1SDtuawv oUEuAMf3GmRegywB2rqrPC2gQnqCv5ZXISs6qSS1XhWyEh9yKuQCuPNQKuRSYz64HklvP44yWaTi Evtq2MKOsAVhAv5SU47gslglqYoX3heTeutiUpUeY+/LSM3x+HxfRupXyzPufmWkRIh6vLo+eojz RyntE77bUlIVIzz8dV2BJypatSjnK1Ywam66jG/XLmJ0paJbTZyVYiAcYYX4yghH7NJf3GhBi9zC caWfpGN+dfnoyQWnUh1ZqY+oE0Su6aMCmlgblP1TU5jZSNtHofXBnvafTublSV0UkLVNqXayiP3x GwJ7cSIPBHQMcn1UkHtAWNts+wHuM25+IwD3TeRBAE4dPybAvSCsbW6WANxr2P5mQO6dysMAnbt+ VLD7AVnbZEWpzHHo8VJUlIy4YJoKE+LB89y38qEsXtCnZNG1DqeOKZFrFsa+R6hBUzKlxdKj3L8I jSqsMgeeJfCqNaVISoksujRAS+Hph9ZS9eWMFuUCq6RKki458yBFkcoABBBkAul6Ai4MuGdpCmpQ eeqOHNxy/oZV4OpehRfnLw/rdN+L108gz4KaMyxkX8Vb4AThAa0kWQci1gjarXOCXJY5CZh5C3A1 1HJAqXWkJI/f1fHxSJp/wAUpWtd5OVT6+nIUrWTJtQ5f4CU9v3/mI4LEP+KCMOnzm7k6ojnkmFdo x7/kWqfjA0mvIF08Jjh68wSIElCQp8bbgIGWWeu0NQi+wUJg7vBzafM4niQpkFjJqKjorzJ6RsMs 1TR76mnvpPrCbF3K2lbI86UdopcvE5YDaa3D1Nt2OVuUdOs3FiXe1iBzM17hfRxGGw3xSs8yNdE9 Xcz5AKov6xrhj27iSRxa+ftwG9DMFr1GPyAx7DJLrakgYs5oj63GmIyun2DuENgIMZstNjZfOsJW rdXDXGWMG9l9HpbTRb1OZ8MBX1yl49QpsKJvGtlii28CLiBIRppVkeHEvvlEwIlrE5ZgSfvTeCot ZAdMRrGFeZmNIrUOeZx96AQlvAvdxxlwLhLFXpXRXjMBQe2p1Cyw7dXQnPzGyN7Pd4qczWKAli2p m0IdyiiCO9rHbB5MbfjV2lLEy40leUdwtYecD9kSvfDbBVsHirW2lH5zw5LeDXRdh6B5nKTMoDcf uvNA4i691t7UINHGpncDEGvAucjmN7V9q1DNhl+tvaWhWnHbviiYHcv7Qly2athFUk0KS1mc1Rb9 YrpXddoTTNEziaNMNXD5MHLY6DOLu06Ab76KQAJckL0iw8QKDMhlxQWINxw0udmEsrQxt6XdlwwK p/sXhxdh74Lwcu6+VuxgrbMrG13uo7HwNpd3cZ/jVeE0UkV89Kxx70AiSm9xcxZHhHngrIBTraMq c74LSdQM8gCS6Dy3sceUROe6rP0qSqIWitS2O4I274Krf5jDokdl662F2Xpu7bWtHQ2Td8vWW4/G 1lvfBFt34Ffb2tVQ/SbYeuWw92Lry7u7/oqw9eodrG2LVNx618pt69GU22/m+DjK7XZTQfWdK7et R1VuvyHYusrtthS3rnAX/mZE0Sr/5bcRRecRr3nwqxJFt9n8vHAg7eOZ5RedwoK2+sXi5O91Zb0w sGqbGxq6C/mYPy50F5nCMtCdy1TvDd2FgFXbVhVm3ZimhQ//kheyhdipKuL6I+TmF5NZXNeEMLMo odIIEscdIIWebWr7tB5WlDt7u2KlOZjVttm9LR8duTAwj1DTgdmh3jYjX5mT6La8wlwOtvlhK2E7 iSlDXD/WDt9cQkfP2QIp/Krdd1zv5VD8lnX4Zpi+ivMK4AV5EGCfePcH8AVBLbpNgTyzuzK0Hl1n dZwERn+qeu44LOq1onaiIxBehvHDOSpfYQdqzZZUUXICUB/NYuAMs4S0rcQFYz4YzCYsGtsX4iha A/8X4UEXsRnF1+k0oddqEs6mrAPYuZMPF6AbjcJD0LZZGq+HqWntjkYDoLRxF09VEdOr2RDOGebK H8Yw3q+QucDFkNomy6G+bFKPx2k8oy3IVM7lTcuxbDnW4VtorcOEjbLILXlmMBZw0VOD/c81i9Ak 3OMiNMYgH1a1JkYgsRgm4tM4jCNCcNXrRtjT0RnwDrMUeDRYxz6qwUWzqbWd4N0tC/gUGINs6RLB ik3Cfam1LSd0ejNJZ9c37gldVxNFBhBeJlxtETAZO7CcJ+GkAmUeyaG/vDPhUOlYCv7SwYbO7Td1 /+s8P3KhHOWGcsYRUGEnr5IIdR6qLaZOotWNHjj8OggMyTneO9l7AdA7ffbDw/2LcP9or9cLSg5N VfjBNB3Thux/ApwbdPjz7h9CB89+Yq2tJMRNNyDnSJaA5pBmwINj2cDTS45PsoLa1NQy058TBFES vybemorxutMySGyrhx8dpK9HH3linjRiO7R9EBNRprgj2MyhFYxLx0H3k4z6wxkGSojlxfFBHWDl msSO80FJh9rVbrGE1TSd3K2ZCXc5Q8oofq0jNT6l2ZdFIZVF+ui1dO2Mezk44YMQsPEkncZPmL7D /09OLwwCIqOgbHj0vjfFxD1SYga+rBV0CijsufRpd3Dv4QhK9w7YsdDzKZqG0Sq9f3py0MWeYDJy WKTPpLdnH6Tzw97hyUXYfR58VCJCdHvEswkvfABJvO6jdVQsvUbECSpFnidrH9VNFoRuySxpFpKf 58ih9cgxcDomkQI5clqrQN/YS5BfS+n9LdB7A4Cak0tkq9GkPvRjCTNSnMo8yHOEHMDLs4voLl5m 2LF1MuxUh6dXJ1oYN01uLJevuTmj3BnVmrvuQluhjlC+55LLtrEi6ZUYW3Krq1xGySg10QT0etoO kzXBZeXz97BpUCLDZ104VCcvcE69l89Oz+GPPRCKbI5ndbp3coDN6OvDHh9x6IV4We/lGdAGEJSc dz8yJ3y73f7oiRrc01NOLrMoak7kKkoEczkiQeuZyAmKvZXICxiBmGKwKKpvdyigGPFA0MQsanNn 18gvt1Ef9MK48TRP/ruDCp/F0aV9RvX2SGa2SvHnV2gLzarmSNPL7ibsX0Hgq9ih/fNDhB6FzZ4f PoetOtk/XBeAKDu3NnEcHB4dIqxPjn6y3n2+fnK6DlzqYg9nK+/0ltx3e3vdpHdbjY4dTzqXYtki yaIK0AtQ8UDt7U1RgS9Vgeq473wN1Svb2DklX0HKozFEy05YOu0OYNkgi2JAuFA0TQaJ9+nWs1EC ug/bZDLOr4BSYmqikxAHKIICzTe22i6AJnuEksGikQXIKsypi6qFg4mXhAgBLHRPjHhrZm7Utjrb j14n2vnBZHdQVRfcoqrZjIqtRlNpzwuXLAq84kRDLVPmKuVXPQSNEH8XYH+0B6TtIylwIFc2CJc9 RfFs6IEobuoU+WBBEUtSvMiGHxnYaN6YlMJsKWVRYGNNZMYnFe6Vtl5Waq42Ste2cwTSEzRXgel7 zmssYS6g7rujzVX8SY4tHNUFFykBcds77jpZlFp6nfTaolYNd7C5xsBZZslQekRCIHMKlDSr/KxU Ug1NvXPejWQNYSQs6aNV1kdr8T6aRFc8PV3CSXXa+K5CJ2y3gfewip/NfmoyTObtQ0VEEN3CAzCO EolEKigR8wzHOcSo7bDhq1TCXhhz7A6qeMFyUZRl85rP9pUpnrEMugl1Pwg626Tv09J09VMJW5kH 1jL41XbYH8vRT+5tV71n4M6NEw9TATkJnOHK1ZoHmtMwGw+I++ShMyfc1Fl8bYfdSXwazzdxI++Z RyUJ09figEXWtdAoD6t7uoyGyZXpRNkXKkwJi3sveTv2WiLm3B94Nq62w9esPhvUwrtqvbMo6/GN N5fP0iWc3LMpPmR2kiUXE1NWerWKDd7idtULqtr2bg6OyrS2OBTVGw9HhYuzqTwhz9McTRVhUHeT PcHK4oY8iw1X9V7YEzxBvg7TSyWuK3rEpS8K1S11T19kmqCHOE1zPVgxOxac9ZVcLVvLcxDTzRw+ 4dnX2k7bt+UXy1xFnRTfXf4E6VcrN/cjPEH2FVX+5PBN5dWT8OXos1H6elR37mA921i0lOrvW77v P1oKxATH2g6ZxEQ33g4/ZV+ACn1YvAWMQOq93glL2fe9bnjyg1abDEcgFqaTzw5BY5reXSTToW0y FS86MiGWwwsNvoWV1lq2IWG70SwxH75aGojrlFF+YTtUYWZvb46iCcy3RRVBmzs13pXNF0qdG0i0 2eN9UzTGq0bkKmgOmPBFQzajcOiJwJK8DVBB5jT86FyFTL9VvrVkMPJvQK3tbnDLYymav7m3y/mr nkXTm/s6rN7OjyfYTzOi0sMYrfZ9/AuoxxgGRXI9TcNBjF5HbCZBaT28jNibipbrhiJUExhZeG3H uTbYQfFLj+C5FefL1tOwP4wyMiONYnQlsu+36T41fpNkU0ENvLrBPKAyR92/SHSoJFrfkpaDQ6lR dB6ZAeDSK8Unk2kjCGxwvAvSZo1XTdWcEBJEGtpZQ9ic56ez6Xg2tcxQTkMdq+DtRj+t6iS2vYo9 3TjPKzsyrt++bsxTbycE02oybm+oe8B3Pcd7UIGrcyC86IEvvPlw8mj1DOcaoHK2X+B4QGfPMY8s EWGRxddygHEsp6AWTKgMi7KdAlN8HU2Irg/ifoK5dDIhMbOxl8hoPmrtRTXhmbMxtV2+sPWfoPvQ 6TIzZymh9g69LN1WRHumkwTnAOdS8yVgpoFR290QUFVQgW8FopfP71uM5lYc2z2QvGJLarvt/L69 FYIvj9+FcR8Cuy14LYfbRSjUdll6r+Qo3wLMrprftxaznRCzpTG7cktqu9v5fXunmO0Z9+0x24HX Mpjtg0Jtl02Mc0SubwNuV87w24vdbpjf8vhdvTG13c3i/r1bHPeN/ABY7sJtKTz3wqK269TEaG44 qqVzs25L7XntcCG1zp4qPqxS3Ljf+xilltNfZP41hoIFh7wpyrPqJU1MxVG/aRtTqS2nZKmul2az 6eAKGToqMIUsBg+OJ9jrPE9PomFnk/gqeUMIsjh20JzdSqTwTxVm0HzujRd8d/yusMKBTEH6LC7p 22dz9ALetSk3WxY/UxdxywWSTNT76tJPecQlUssH38/Hlpi31KjFABN8DwfgfvgYwdJh5CkVR3PK 46A5LRqRlxa+pxtpJ88aezbxRVKCdxmSQbfQdM0OYyld3SNGszRCDAJzx30npsHCYkvCWwonKr29 TTmMIMEiVcOYrIvP6iUtnaiYpz6ylJ9JLjzDOplvGVdxy7FxeK7esifHvvEN1+O09NGHr2bpiEqP 0P1jVuJ0wE2bvnApTv1KZfca7g/fuQP3R+jewP3hO1+MMFnhVDryisnD/uLl9KL+NHkFLxdG9rYe xKo9ixL3jXxiXqlI4HKrplcV1VzqVTveCt9jgaA84kpxH3R0KQYz6fwwFlFEOeUj9dpHGhOnEwDb Qe9sqU7USx9VCpgFzue60zfh/1j8g7koORDpUoT55ZWLvZnx9OF7nYWq6eb6r7VyslSjBTOjVYaw THteNrx8HNVuMT9RhZgU6iJ/3abTnCtVgoGZ6K5BPjmXd6p/pShfJtPMuOrEV1eY3epVHJ709s5M J5IIgzpofqHrsyHsjqPsM7r0tCLnue9bFWyKzZhFN/yxl6qfhSmNeqGCzphBl+qVX1m6urKzr7VW O4cN7bwmNFdUXlwtKpySdxkgVJTOcvrR3IU6OP5hHsnfUluSm1W1HlYr+rEEjEgjinYQhWpI2lS3 ZwdR69A8HWPRF+JOSkhBaTo+zSQ3APdwNRtyTEkywvFYYbEKd5DakRnHOVulcgLXUO+rUlcq/NxI C5yPdDU2By6i6vyq4+di4WzfKgS9pdxA87GzOqKuCLJvJrBuESSs8fWDRWl9EXZFIFS6Vyxs936L dH8LJ2WVLKSepKzadqJYudSghWWN2YZn0iLtm+SYYS5lDoZlkNhIsXkAIwqbwf6MOUidXJX3RheC Bqw+HGGTgaTQ4XCpU87kCw0oVSaKIFkfxosp50N/SBFkO412YxP2SxVEn0afxaN5aWTdjart7ha9 K5Zy0jWvlO5h1c7N88wNuzqFGNAAMZgV9hM5BdJ1zB0Bm6oKMi0BCXaobW4UbuLfDS6/VT7dX1E8 vrA1oMdMs2nvNqBAwYnm0c+DM9K9ToOFE/c8C+5qAQyd/M39uzgJ1nBzT4InNe77k/B2J8HebUCB gtPNI5+E3Ej3OAkOTtzrJORXC2DweGi8k7Pw9umM35+HtzwPbvrl5kaziAqPfSbyY93nVLi4cb9z UVgzgIOVXds6uTAgzDuLQsIaZu5pmN6NbcOpBAzEt+NhescoEmX9eIL2AoKQk8GUM2xkNyrtJamI 0NByNzqhGn46lrh4DMRaR6h6lWK0A75GSJvlLbp4RAaYtS0ePAHsHMVP6DU1d0TZGUXmm5ygJjyN Zo47eitmXFBNR9F0ZgqOZLNL8coIa3HjuhFG4TgFBFifpuv0izqraw1tleUZqBhB04F9wcydO8Zf QzJwTSYXbUOZ97oHXe5aTTu+hRNvpbKDBj5vftuY2nCgEw2vMW735lYNkZkNtSvo9vspb52YVPm+ m8hVPOqn9GgyG/LudHunO+3OzsewspZYoqhDZfpFJxQ9bj8a2VjST0c/m424EdkdypAjtszGPwbN u1kPnze2duvhYaO51a7T1PDXjlo4ThH2go1XmYbpQe/sSbg3HNJVewQtrqDzuoJiGaDRqO4BtAXj ykU7wNZ9FzEl71yAuS7jCf5NmxcO02tMMkWGKIWv2iausYngaE01yc+VssdNnTXLDGMrjraAUcjl xkDXBkwT1OjiwQPf4ETlwL2ZhjfpeP4S58TK2gcfKOi211z4LtMV+axVFdR14axF57l+F01eVLA1 xZzEaKEcRkVb6QNlMiqsJvm2JzTywVGbqelIcB7vghF8uaxHRYg/Xu4jzzGpAd2kI6SpxqIH50Q6 WVT80Ddm1afjGWzpLc6DwNDk60GRR9UOjtMsYaFXiLG5NfTQYt4sPjma0jJZtwhroqIiNd3jXADU vaHgxPqSCToAQxtjP9fgw1M0TK7xqGmqa16YhrW959019RYR0T1Fhrt5+g0H3m5BOApvDpIrymI/ laI+XAEIBa7JlNNh45+YTQiPOTOIIeappJXTrFDox+zpsP7YZijuaquxSc8TcKilcUho/6JY1NOv LINHckdajUkoIshGi7LG1xOUwJ0LRcdUZjoaWawSb7k8IgdBzeY9RnhoGIFMYZzk8E9IxL1lOla4 nZYJWkCTsgKvoklCg/PckTEzsct8TLkS9xmHKyQoOEB8MqZIqZHWTKplnhyP15mNUcSejy/yFmBM W2OMEX+XQRr9VhXPXi5Cw5nMPCbObMbedY6rZmiOB7NQsnqJ1sNQBBkadcqUSTHnvLOVJiBG/ZuY ZQL1RFkarlxGqukGQL0K5Aa8IC7RbcWHdFnVhqYnzfA2HaDUHgT40i9/RopNkqXrfdBipsodfX0Y 3cWTWrOt4kuQi9U21qhQeq25Bqdo1DymnmqttXDj84CARY4/vfDJk+8DLF90T4L19fViYArrbkLQ kfNaj8YKT2FOMKskkMu+7sHhCXpHHZ5T7788OTpujIZqOp8HsF5Yfklj7grtKKMB7EyPbTr9Q9Dj RxQDAyv7PLid24Hc4XGK9H0K4McY62A8902VMhiDGQKQG+a3V3nM8X48oNvJ6jdQLFDpTfGOMojm vmJoIPrRB9H14m+8ACFoTM5RQdSf/xqz0touLmX+SqzU8ojC8BKgkSe8CVHHaWwlYF/P4jLUYVQR w17/bJLC2brNaCMxUOI4yehQls0yI11dNyPUEdnvIj1804/jwXH0Jrmd3fao1EI/lqoV3v4C6m+B 1wnLoxlS7ams93mUDNFsUTFRX3t0wg9AuZ/MxsBXjnpn2UGMkg0QrPKevO0JZsnBc8yxdESSyQLA 87anc7FgrawKQC7YA52pYe8M2kbTCOPfTl/Fk2EaVUHA255OGj5pLdlToT0dQZZXhIAfTFJQtQfP ge9T8El5h1Wv0Rm9ZYzCvzV3WGCrql6jw5y+HgE+nM0mZbtC3Vit+DhT4V7ESEnAhBnsq/aWeil/ qdbEs5Ev6HJX0VehLcgnyEScE9f7LBlX9FFsjOzy8wD2E3lK77P4dcXbVqtaE5GfHUrajSZyafgX DbJsAmAbaBDIFohERTy2e8Emilqv+4eHtY1Go7m1sbaG5SJ6yS9iI6tF4e1sOE1Ap0ap4iqdTeqY ba3PtlEdpqLjRUke4ZpUWXybrJMmkwUaXOwgjVM4PHl5fHi+d3F48MtQVVP6BfAgIIv1cAYggf9c Ad0BYtGCXweAC0Q1dFeUgDTf02wk5l3qhhyQmtQV+yJRV/wtAKjFHRokpYlR3VMbOs1GowXACRxs pqYgJYanz0PrQSDl3hjKp6dHh3sngSmW5O2/1WjsQvdWOaACgHSmfloWEvyzKS0Lb3iSfndEC+M/ TmdTWBdAbI9ooyIXfsinV1fUZTqi7l6jvQ/2AHHaooY9OWP5tyfURIBNxWbhdzxSjqmMXntxvnf2 SXef1x3ouzp6hoL2i8NzREMgHHg8+eFa0D1gap9vtgOPSlN4Oo1h85qtbWje8wKWcYFEwbr2V6Pl +0vNUQf7x92z9WbjGUD12BbsuoMAyFXFNgO5WQus+5jCdPBKgoEptwM0L2PRR5HZqJOEvsceUpsH V2uzs6YaYpRwDzqfZnk4tVu60adu3q+k2CU2djZLPaSGW218aGKtnYfNjVY7sG63itSAb8kEEPIH otWJfU5RkFdfBJ4EhoV+Z5xPkLsdDbglATgp4BITimYRyeho+aqd0mE7wdsjmtzLo6NAYYXWUQgv 8pQ9OEUaaR0VC3OC00lynbAhAFDr2QzNOUSh7e3YbCJudXZhS8raa57tnQIz2zmv1n7wA1hhMS7f IoT+MxMoScUKoCsSIt4XRYBwt89ATQKVcuA/TgqtVStnIurLwELBIqUxD9eCc66+nZ+WnXn48M04 mQixA9W7/1k2u6WKzIRDcHJ/FN3tp6MR2ViADhEOoUFNlZwj3BFzrNNjBxsy+Vf5YUHSrDu8fgv+ dtSHbfhC5CxdbqaIlhlrBtDhjqf9oToGptku7sIkHV2bk8Syl2VK0efP+i5wTC32ZuQbVcshxGot y51EN4S5N7/44pk2ROs2Dn3AFpzOtVuCQsgbcDReaVkrYjemkbs0+TL4lHeKnrmsriip5nFMipEx XvFFB+E/uVvYhHNDy3qYq5mWzILeWAVVapEP0e5QlSRFEwzjeXcEA5CfuAKZ278qVwnAJlSC7nRL zr6N7X65UW9ufO56sno7bG0EJdGfed6T4/uDc7QxfRIPhyknHfdP4vNAsYcDuqnVzUTyooYX5y8P g2SB7tqgkHkovq6u7VvhVqeyRHjZO6J32TxbNy1y8l8q/c4qC+xb6fO9o96hV2XzzqOtmhqRwL+L qh2whRd83waoXoUfrfquVh2LokTZIMbvRjXICQldEQyCW1AYbDIGE7uYRKPsNsmyOVNbb9fbsNHS w8IrAuzYsN9adLiN+ubn3qTmDl2zydZG4A8Lzp1Um1s3HX7tfWES9+PkVew0dPpo3bMPUq6j4VyC 0ULlnZmybuAw+F+aBlmhhToHqKDiFQoave7Qsh6MUyB0fLTP4fiV7MEGavmG7/pxdutz95LBt0Vx JnMVQQU78I+5BWMGhycHwYcfNluYEJwuEEFzDigW1PqCzJFalXYvsAMO2slml+Knp9wKpebzYr3Q NXchjMu+iW6EfCWO2QISvhnMdVHVPZsLxNOPL6y0I5Yyl1LLRhCcnF4chtstGm7R6ZMb3SAm95GR vkjNv23dmjvXtbm5ar/MZGTBFcNgYXa4N7A7PdKknREm8c9nCTPPTLWDlmclU7ZfJTdMfBQEe+aF rvuCjRA99UJYOwNBYs3YY3Q9aZw9IORYLpaj0R16cia3BAl7cInFcwcjD5wkUxSV6Q0OS9ccTwi8 OLIZGLZmMOvzuOzhRb3ri+sJCDGvIpgxvQat2e0Lm++BSPwm3NPQBellDnw5HQkM3O2h+Uq5RdAC Eafs96qXYkEuGtNdWHr1hMSj/mxIlA/9uBIqHyDUndN00QnBzun2zbkvtf3btqmasXLEEYlIeX86 qIYtW0+DYDZNQCbD11HgkYKyxaQwJhn+8I59Y2AXgfQyxPGXEV8ObJAECIATv5VhchVj+ZXf38Bj I2a54qQ38UqVTDZCHzAvWVZst03db1PAWhDk7v8n6eUsm46QdbFCVHx/B8bhyhazvoD7ysolJ8ap 4nu78F5yFdZwdIJBcrXGZXjOlDk3PI+pkBHRR3EyrhfmqKNSPZNrbjzNNwcRJRpns6HQTfOyXGxb kwckx0Lv+W47KJ8/RbDl+x7E1X1P4nXisOU9dwiFgCkm17TZHMt+Cxo5/YXgMVfMubebjU2zl03o RnynCGmoJDz6eYnPuI2QUaYOJ3knbNP6YHeoNDK+XcDeYw7utK0Eucm00WDt22KfLxU6s5gdDisG 9r5dHLnlrl6buPGKqti+47amRhQZOxB3mcIbm543xCMo7fdnk0kslFkqzxc62HI7kKOvjA7F9rSf glCCbC+p1FIZKsErra/pP9sWPNH9bQKcW5/viN1ccPCpJfHydiHVI+poKgaLESOsJcSS1jzDbtLi 3Lli/5oUpOoejKY+mE2cPdT97BL+CAmTfqIxvDOeUK2PBagMnyarYbd3Gu50tttUksp3rptygvD3 dmEZIiBXHV+cs0UVAJQEQY3deX/xPECfBOpVnIhy1qS/yw7bDq2yclBad2tjpzBcEPQ+3Q9j25CQ 77yN5MTKZjmKp+vks0uOIMbVsfgewqLr90LNnfgcHXf4Ks+gFX4tISxbDep1ngEkvCZLC/JtOF1k ally0E340FC89Wiri4mLwthwUl22NLe39pwtKj9jQUBXcVk8G6SjdFDN8drMjhc75WWHt3otcKq+ xn+Z2+Bv2wu8s9nIywnE2oBU9qfkkTghDENhrng4RYZHmQHw7VVC32sRKh69SibpSBSDgvSqFACQ BYJLUopUxD1mvsN5F71ytTtLpsJJQhNK1WyyLx3O1Wo4ickVs2+c5EbMvIBiTOM3khdHiZAcdKXp qBZjNUY0wtMpOhVLoEuxAdZrc8eMwvPDP3jZRd8vSdAmMxaF6sXB8anlYsXH0/UEcYjyxHK3jgdP eJNz7bmMllBEBO6VRGxQ9AePnxFybTM/2qgrVGt+Lb906kjEGu2v8d9OXeNVC0kIjrnnjtm1xQK7 jBdgjtmnLNxtbH4NbKRtNJP2IppJMJRCfG+vnaBLaWi6k12UDvjl3PiwEppri6CQkFcgS8MeTQfk K758ujPUGXYNiIgq+Yfl6QuidyMnHarCg37xaNvf2CJI9J6WFhahacVRdp4WJHsVzghAUIP+iK0y olUV6dduo6X3urPEXrcedq9bj7LXWTw1ktB0ikxoEF4No2vfFrd8u9Yq2eJdf+MH3mKiwPP2uLXA HrcbAraDu1F06+6wbD/KLOc5ca3c2rM3ujO2KUXArFXq7bDIoY/VsAyop9DKC+nvYgZtRqapZVTM MHUrjoD0USSAqdOr5szlBiBb9jY9GyK/a627gVmmOYv8O117y7d2Pa02cu28cv9OkKJyWp3wjM+E Zw4XFfRGWqKhOMobZcdWj/1JAu+DqHNJYcsUo5DlKBHmh7qDr66h4yGCBbaVY5oGMfQy0Oot08en VCt25K25iUmh+dVplKHFKAtfxxhSOb1Js5hDl0i9vI6naOGkG1wOJddWCDjqt3FMi8rMAgBkh0h9 fKP6DdYkhN4BSRoR9MnWKmKM3F4pK5ter6fzDGPLMDQVNAmATiOsofTnr0kpu3EbwyEr6YsBibac p0RR/UUspSMJCkSjQHo1t0PCs6pGMJYOe22shfsIJQkBBJIQnjRc4Bhkt5ToCduPcso0YFyYxXCa BhZmo/28BLcVQs0cChlQyLl3M69nEVCuaRx7XgMVgLLUGXQCDFLPTrRFJ2xvyByBItbOdePvh/tn L+uwabfp5K4eXtLtV1YP42kfgARSMorWpGuiEDBOh+n1ncB8krzC0P8rY2Uexa9J00L9SjNFXgJM D0V/2Qskp9E1L5Hk12hqXuZcErEgpXSjk4iBdIGkJRlRLVVeUj1MJnJhgExPWlr7RjYXRDi9cWg3 od2zt6w1d8sGOdK+8KblX/Rum7oBMSkuJhQliVpLdrOmFr6pdrLOmk9+ezi7hrV8oZEKtRGL1Un2 1rimUDqOah4mPDV8H2PpSMjDb64pMUSdiBcJRiz+ZTHGG0zj4V1jzYJsmySSMdtcR47SBLuF+4BM BwMZAKV8RO61SqMgS7X1Z2WSEv25zolFxBRAw+Fu15klSezwNHwd0RVCmBH3qgvUsgQtptEoTmcZ soXZSEfMFraQLyeycTpSQpqlRiP2gDYCp+2T9DVaUOoK+V1sIcSelCwbuGZ6yzdjk/Q2oSBmSWJy Gw0k1vd1dIdd6wC2zH0BVVlsTGR8MIkodSbbdilmjuYk0Bwp/qesGfrUFeeWz0rBQvQQoJOM+mhy FtbaIN0ih6KSFsNQBWkgOTjpUqgagQt0uRH0EFZXjpxzTb4HMlo0BFBlCnhhLRpexoAIKZcaFRDI FNbIfm3oFV41yY0jTWP9lkA4G+VW1iCSmaoAt6vZhKnYTUQRixMM78Yeza1DfBO9Ssj5nMK4g1GM yBVNqMKp0nFzMg77wePeTGATkz6O2v1E/8VpF+QvSeuBBRsALa/oMtmYVn1nzTG3Ao7f0NJL0MCs PLQXPp6Q/T+8hq0B8g2nyWrIaYAyiVtHsyjWmBgyH5g7o0lMRIdiwEleuk7JhZ6SLsnBdSeDqYti NEVRklA4pimlAUUpDn2n2A/ymG9K0ENgHS0WXAo9UwGMA44ggV+nr2O6skTLXTIpk00aIWB9BMzU 5iMs0yCzS80AuCDpvcH8RFktLR6rWzNZnqRwEojMsv6CW0uCtogzMVXvJTv7106CFiLmzY+1z9g6 O3bwPVV4tHdCDSKTGMkdrFUbfez6m62Fvxu26pJadaSENiNaeqmacFMYDk5hBhKeorGvU4wR70eZ TroU3xGAkLhrw46nyzWUkHufKDVv2WNg1bq3cI3NcTd0STgkayaAAEsOW+wLvseIDdhuCY9WO1WH lkxN/Z3bmQw8p0QfEqbr1NiQS3KU1yzOUIES7BHIZKVIYeENbr+z582PxQno0Np2ikZhOzCKIhy3 2ghPFQ7BPC6j/mfXQE2RS5LcnMfckbfjUkwyYLQRSOXxMZwhHMzI33ws9wBVaxt9zE5W69rLKoyA HXBSWuQLkVyHEkAvgTUA/gG2IosAEeoE87xrHRQIPF4Nj+PoMw183gzuKUOeAbvHvmSKsNxijoub 5PpGXdgglULhCYVhukDunZytlSA1ocUlshPbtpGMxNKNS5TkITmtAZRYpr5CeeogaWC7Ce3TKHWo 1jS1JS8twcKqUHEmS9MA8cuWdUgtmF1mXD9oSCI/HD4SAGEQOBsqW76gK6ARvHkdi7nRZcd6oSyz 4HwRMpfwz+tkgPkCXKFyDPOY6JdA1JsScT0d+ZJWMaLRtuXPjkNPDTBB1Yi15Z1UCfIvwEngN2ID kD26EqZNOBvxkC7WCsrpY+JWCsAeLfHCPmLqBTVHTEUleTYMniPIiaY7hwQNsBsbGx97/E3XfR6g 9fCG91bwZgzELSGMMMnxFEILI6XZw3zgXKR0gmdjnMjo/tyiToSbUnzIueQ0Mz6ZwcT5Cd6qK2wL VRBgXL+Q5asJEiACD5JyPO1Iw+siC16JHIiQVq5KmZJN5QSLbkX6mwBK+4XDHPC00Wuoak9ZmC/M pRnmN2a9whPYMj8wRqKpSU8UCYmNanminOq7UcLV2hVn/3KF2jVGSu2jyPtRtJT0JaGIqMEYy6OO hBjwJWudcrleL3oo63wzuIrZBNBM/EHd20PoZndDmzRU9jSSJfD+8MLBKm0EETAx2o1CImAuQ6iN miDQjFrh747i8OM3ax/jKIKuzSK+6vstD97WsRtfc78EA83jUo4Xdg9YFn+TPzAHIiAIBK4UB6AT L3YZWL/2Tm0zA7mGk5BpOS9ijGjaQEJMAD2D8qqprXY2GPfySRB0AFlxegGQk1LLIPaLVjpsXWb1 gyliQGd44XA6BjkI7EprnY00tcNrdEwegsQ6ziuJRJYVjhOBLwo+mOuOhFDKaNjs4MHL2/TYYROI ZXh8Oc7C/d7x3sf7B/jaGmkZY0oT1KesXYrhqBkK9S6o09DvNbpdIjN8lSZsMWevADFaqBR5QihE 7VMXaVoYzVAaZRsEiswgQMkQ6BFk9eFwYmB0rHUMk8+wE+iWXLcaZIMpp6XKfU4blOkXBe+8Os7b p6nwz2cpQkTERpfsKrXWkiR9RgNDOoi2UBv6okQV5xlwiiMrRU86WkefGKHAEYowGB8H794xDSER H/7TJG3Cse5e5OebAeVM0ECo7TLxtFFhFXTuNYUlKeUnz5+7Smq3mRHZRmJlI/XBjgL7xNRPh8Da GUXnJx5Jd3RnybrGuAq6tdxRxBRHZwQPbXEqOIjjFTIpksIb2GWUZoSqCGI6ch3sBRhLmu/dYlK1 AitiWw+6b6i0d3yEtCySV6pVfr4ovE6VkYFOJZkHaBeUGkivGsEhE/hmwtC51gdj7iDOkgkNSnZl pZ6zqCwjr4ldhuybSgcLWGpguT4LbEO0lp5H5PeT2Saeop88Hv9phOnvUO9iO2De2JGwOj9EJ1jc cTiGMXPPDPRNmj5nT8NmZMYtjEvi0jASC5BokUKJ7ItR7pnLed4JTdbZ3PghnsYZXbvE1i4lWZ8y QzUwfgAlIUo7qMziZjdkETrHJvVJ64tH2WziWAyGyLM+i40JUN/lZhjpPuYYNjInZajXvVL06jYd AIdmOUJsNcUQgyTzH2JeEzJt23UzmWhlRmDkMiotSRuOVatkRcJ6TMJKPD7EVqIsrtN8xorbUJ96 K1E9oAEcD0GyMfMtWE0ScAkxc5rlSdSA31mzDRnK5EFd6kOhTKkFwVKAzmPnWYXYXpnR0GmP3yRo UQ+ULENuLhOCs04El2cami7i6h3ZIMew6rTR6EOJ1id9s2ir8Vfm2ogXLck94CSSdsgwoLVTwxOL JKDCS0YiTT5Tx0RjvUDHhO3Gaj6DUNItKyWLPEtZ4+MtA81gACAoWBRtKcom22qLi8C2b8Q6oa1y BEEP0wL3E9QCxksdVsf5Umk8dHRpuxIyMnwWx2PMCibeAwaRr5T3DZn37sZwWn9EMrk6yJk+mMqw XjennQl9xE48zulQ3emrLl57qxDCtlD81ZIBbYvFdKUPE942Z7D1e0e7bXqj3RZbW7JQ7Nu4JAyt PNqtybtogt2s7ayQzfrV/mpVDnCJIo+c8BdE+FjqElzTZSD9DWuhm0n8K4Nt25OwtvTKWTMybCUf oxiGzc3JoqsrGO6Czs0LWGP11FhUivxDkdFmwGBWm166lMrASGfG1u5bqk8uLx2yMh2hZUZUxcBs P2pSo8pXGBZQ0Nk6z4JYuSVLiW+uzMTt2fI3ymOPvINV6pOBvRvsgaaoN7EixzsaVsIhgy/uuy82 Qs3dFdwMPI1436Vq2mlPCnUXcZeDPIuAymXbBAcu1op8cdymxUaiVpb3WAic8LbV1qVXHIg/Z0kl e9bxnSDLt/XbtKHOMXPLHXrXtjOPcGnOaqx4LuiqlFmbTxCDx+vO7A4avYHtntC1gMnQ69ZHcKj3 /n734iKUAsutjV1dXnlnp7VJ6xyEhaysmG0Vs65eRlnSP5TeMbuInG60/GaUT0qkYGL07t4xYrqJ V6Vwh9qljHc0FueuVpnvbS7oOTOO1HSbYbGW8t0ogjUeGgY0VvEJ7NNiTRslbnRWBF6XsbJhe6Xc Z5FtSV7PLHyB+G+H5rIH6TFHS1Pbenjcdf88df7EFR2fW18ps+YygAP2OI37NyOxFPKRQPulAEH1 ncM+OsCAGi8a+P9ugybzQ7ahT9g6Q8eJra74t6I7KL28ke9pFxK25NL+UH5yvvgZkofOOLrWVBKV arzyuYmBLEwyOWW2EFdUO3XZA9mrpRFL+5fh1fH4zmW8tInO1s5ub9ENpXaMYfpjCj6yABa+QJHa LphRyoGVt5ik9gbUEIdTa7+dkxlldtlWISFA+2AmKDcxbjFKMSZZCLQ83jzBOn1cNqoU6tJfNqfD p8FN9AqIMnqIOPkMfG7liQoJU4dS3sBR0T5POnP34uW6Jo3brU6u8vzWUwlWjqXLKy1sO45EXBxC H4qrO1N9SyOdxmoHAIoi4MjKyU80gdIdfyfYXOCJVrCRnxu25svKvNRcEpNpavUtnooei6eYYe3X EJzWtBbTIoxEwIE1iiHPV9aM/HN8qrfTFryOT/USW/4ltu6/xNbDLXGhFTYKyxO50veI5FL1oCgv WvAqyp7wWvDhhx9Kso/ATQMSBLUTPnOv4rUg+HCvQXdglFMER/achVKVds6ZKIEpOjU3NzZ3duli nSirE3wHlKXi4jE3h3qeVxDUDTE+u0+OFw0surMxhDGfUIUNJfStkuHyJoNRSH61SJhI7WPzYMa2 RRkVYKwuRcfRZTIUSy/sL+ef0iqQ3gdDtfV46hqZBuAQCLxktO5eMZbFTtkAfwMrEamyuMXppM77 QrkO1odJRkavSYzJZxjzkuwz7PhKcpjnKWJchgGqVH1KWRWvb6ZP1TQc4h71iURPwj9BnBin05hv BO3vrzxQl3kP8J5kSCR1oLV4Yf02oEv6oP0Z6NtLtSTAhlvoCKV45oJ0RYi6qnLiZblDFlQCAReT 9PJhSwqrVd9VrNRMxlh4adfUVR3b7HHBd2KhiyeYGQCfi5DDIk4OfWsj5TGmHM6dVxHN+HIPje8q gGBQtzFCv0Ct0ytYFrYGaRU2Zao0LvRnvh3DoHRmAThfZGsEFYv4TOEcxYyUuCazaHN9YV/wYHMA znWEcou6/MMSiBnZcnEry7I0FQHdCPaAA+1dXk7iV0nEhxJRlEQL2KTs7vYyHSIj0na8WbZOuBMP zNPj8INbxAA4XHfBafiByi8XnDZ+b/T75m++7NVmkStXkZYZXlP9hvRKU4lhdBkPhwb3yJoM55/8 3LF/y97cCH4cfgDAugG0gCkGX4cf4LWMoZxBv/F7Y5iSvpDAawUjM9VzYf/62gJeAiC0AfFLpEWF kqj76RNAkMOkHi/ELZ9ftgo65rgYkjr2HLNF+hyB/pM81VcJgIUa4A5qBtET/eFP5BbSurokCV+V Vx3YEnGJ+KqlVrw/XEZ2xWWR3bxiVcQ9qAzROg+vWcwoSuiGUmk+0zS04j/5vtSUVYsMBuHa4CWU MRLxBh9lr1FJnOrLS2sEakNmRYaTrWwxYwCafou5uwCws1sgU3FC5AXrquGS0eDFJAT9YWgophVS wZZKpWGSEHLTuknRX6U2y7gO1E+QZk/Ck3SNbdR3WAFJFF3lbkVeYVjtB13cMNMrLJLTM+TdYNE8 MZFbMF4Xu09h9JCyRfIMMp0PjMsI6YvQSGBFzj0YQ/KEbnR1Hjb1ugEYrp6d3ShMMiG5xjH4Iekb 8QOtaCrwMt4zaJ8yXvF9K3+l9jhzdk5G5rnGA34PRN+J/zUzKIJQ/aHxAd3PJjoGwr044tUoKzb8 cpkOtPJeZhO/oDFV5jSeEVIrpDG8RCKpmjrjGH+i5UfLMKTpaz1U1DRkCq/J2J+wPYORljunWzwl w8l+PgGwxiGSpQ5Abpi+Zi8fdYTxZjMaZqnuiPj2pRUrM7WfmStSTTMwJfU0Rq+njEmMnJK9gZ6q lT8jgN4xNTTfBloP6HJxFIoPZZ3PORwucozxDGvom31uI93U3E0pC5HhLHu/l/w+LvPH+F8Twygp qPoTOBLrCltIHBKXSOVDi68h/RqhA1R0e5lczzCKIHHpshamcZfZ2U3IhpJn155YZ3eUqqqOQjSI 56Ts+CUkknecICSktkKyt6VknKp/Q6hP747UtWqwlPaxgA6hrjG35EJ5nrMHZ9Hpp7pyHnRmwolS dsOpG9dLgoPc2StHZGNsIuVWrEvGr9Jyo3d43I0IakK/0yvBN5yRO4czMowJf3rFpJwIMvoBxpoP uiv9InPn4Qj1FL0ocTlEFD6LVVKMTPHf/hAzsEwctNBDWceLRZOWjQXW4yDostf3VSmaDMlBzwDG ogve4wkkUhXnxfyC4ndIgvQYnb/siZIHhHh6oQCnX8a1vhlzSSj2C4JTjDV+fj5DwzsoAsr7U+Yl MQqR0SAvOdsEzBMxR2vYyr0PTwahgw0sOBARtgOYoxDALCeE5sPESK4U15go+0EU1hj71go2HJ4E ogD74vOVZ8z0CisuxqzQWHmlWC7PYWgQnDssLPFsmb0FcgJIroClUx1k3I3RnZJWhL85chEDUN4V MyedOD2cn34H8oNo1rba5LCMek77gNU0YaCGN1THWW2vxi/a2NdJxvoOz1cJE1ISU3gkaZpaCVA8 thZdTWP2sNRsM7NsDux8MljjbSA/PpwBwhyUh2lmC8hKZrZUhwaIbnjo1jH0lh2jMzv85Yo8KQXA PeHsIqMwiUzEzVg10Pz4NeafoK/J39H0nSgXQLc/xy1tAKQoR8Ishck+tQqYZTtqS9kkUFhq6URk n1gdN5dpxuYGEkSxeGLBR1Zg4QfMoeGzfV7pGzOYqdveWVLC0Vu0hdpt1jbgKUud5jvb4Z6Re9kR WbOtLJnOeHzFMQbsq8jckHB0EFMM9yRW4tqlcg4iv0cJbGejoiFfqUQX0jBOpJck3sB535p61oUb ARbi9i0ZkFFdnrD93FACPK5sB82pXlpEtu1q/fyrKm9LpFUlsyFTI8r+SZmsap3IPxHASWaDxI5r mY3TkZaA0wlvHmAMitxizdF6mr4uJ5WJ3sSZqIx1+jIdJ2q9SxEDt0QIIiXF2cNNlZCmJohzHVIc mgMVg2d1lWVGmXEEGLrmOHVHyKjC8btGOS2AmmGsqQwZjOxGbHnRxITHEloSZRai4jUhoUJLZH0l YFlKsgVNdtOQE0l2FmMBQRgqOwqZ3Ei+kkQTSPjQf3SElgKtm3GoJvZlukHaHk0yHbAVRzqEj6ZU V5a70LqYwyllWPMOKT8F+07EEdPHsNBPFb/8EjTicE+bfr7SVDMT2xpdtCv47Bfgq3mu8AqWrYu7 oNU3IjB9snmh2tB4gb+JhsB2qkgZrkxBb1Z78VWm0sqypbXmzN58gR/5miCbIvu1wDIeaVAaZSdH s4m46rGNQzMMzvNdfhLYnqYBY18P00sboTPP3MS7dY+VHxs3XEg+CT6AjURr3RRP0e9lzd8P4yEs 6fey1u8HgcB1LHBlyyu5bWv9FsQOwvo1ZkrUA/wSYAeE8cp+g74r6siqva8d10/rZMAk4vLjtVAB jbf9y6+/oqhHLBBDomnZOigH9e+Nm/510G/UoKUbwNd/ZL5v/37YaDR+Gsg74Si0Vo99TfsNWo0G QWaWqx961wgrwmUEcjtmP7Rvm0jeYhJ2jYrMSNEk3w7SsIm62VGbkmrnBNMSTnesdgYWTwQa5Lv4 qU1BF59N2VYAyJJQn8Mx/SGKLJ89nIeZKkdNj+50phhVTZOgXaeNgv1QE8ftwDdGqbVaWZymLm0s ci57Y2G+9cLIOV+JMpoEgdZhXaPZU9g7fMj3OK5sFpFSA+cTxRjWLWCja9+HuauUUkRjUUetpewO u8asIOP2GMzJIkzRWkd8QL6dRmTtJGpBLj7CedGuTCoL0lviday11qK1HF4IpBTCmLFENiUtF62K VPDTsHsE/lWEJ0KjDXF1HuZyrV49jgYbRmkJm461zdIyTaJYSXE3+vqBTbFKh/LL85Fau+Kl+XUB TPZhj0glsI8tYKiq7wlyIsqORET7VnbES1Rfbi95q/OIlFl5slVHCgOycO/koB6enhPwQPBlKAKi wGJQsss0ypNNGuUazJ/SL0zUhibd53JufWdUM/0wRpDR5BAa+J4Wi4rzZ8lHbAK87Tm5u6FsE6/J ddiy4uK7lI4mGRW7NMJUgAZtvHTDi15ZMfaotCd1ajtyXSC2poIgbbTQwuMc+tWyNS8FrMHU1jR8 BiWyW5vXzduFfVjE0KWSiZO1oEQS1OFghXeBF4SsNo4U7HScntKybEu/loDx1D01J7HuOxP6Xccj y8W2ICCbr31J4eVbLH/kqaZFmbwz0IZI3mvReZAKkhWH7Wjkj4n/0FD1wu2jvv7gBmziFzxwBvDC SoYqXGnyFiip1L2ENESngEK12Ui/gx3r7A+kfcOXKH8TWAbEFocR1ozDgMjnZEgjm5Y+9Tzt4XCG /rp0VFB4YlCefLynwKiTwKmFAfMTQcpQiNd02QRnnZm5AMhd/JfHT77y9Ubz2OtQbrhS4l/e66m/ 19zhMyU+iJYccOGFZ5stZQfS9iv8+TBgorO6aixuq6x3rQJoVgXTVlc/aa92s/CfM7P9wWqn1WjX Bmur+43mam31+And9NWCU/kFzUa11dXgA3iOAi8sfIqH4Dj44AMlBMLsgHaHNZze74XtNW5xymLk 1+Tu1MndAiMRQwtAzkSfeBq1jEFfvE2fGBsJRpux2Wh1dXUfDw1oiKx7IWKBaDQh7UBUvYRj0qFt bmCs04pkEKEstSzhT2h3OlZZn8UTqrwl4dgn0WTwmpJRwXPzsuRMDPfZZwua95zuAkwLzd7AMCfs LgjwxjR7gslchpLbjeXBm0msTBw4kDYs0Uka5v3FMqF85vDZ9+u2kQxvKWLjK5BPBc5hue4OiUsy 0vSMlmKDRaXUu8yxTDMk5xUwvuiiXGtT4BdZyOyCwzRrJD2AkNi4BgEXyyLWwx5tcD3EopDDtWAh lNEPZaIA7T2gQKNBZPAxHtCWGF6Ge7IHTwYMEKshPPiE3L5GdxSgbux+GZtu9Q5p3a+99oMwpKMV 4g8fuZpFq/EbTpJrWJyLsZWmQ5zs6oFoNvqui7AKDuNmFXhUjkahKM8lsXOENpWPD4hh0wI9pEaT mb3hsNtb3Zvw7RXzyG5vvdszkYmmDILlTPeDVQ4qXT1eJZDoU2LiDJB+MU+iB4VbN+UkapIwiQ+/ 5cBuXzrAkE0znFtIAcfC6M9cSYdLirVN0V1EVWd01kBFAdalmEOgijmEX6u6Dp16QOUc1qWcA5Zy aAL1PeVZEEYw1XXrgKql56usGVpONdbqlOF+yyzqALSJu0If+N2cHooTOnwzjjGJiNtZLN8u3x1W j853Rt8t3VX3IHxOpS6OKFXB6o/w2Ii+B8hxLnjHdXK7B9wqrCm7P952Ndd31ly7rQ4qdM/eD+Bs ZJbg01f3XoiJ6G1jR67hWzj7ZqMNWyIz+j5y7fwSnptY83M4saufpK/ZDOxmksb7OQ89uOK37UwA dJxaDUC+xiWMjW9/DI/C76+uWjmM6Zx6OvTmSId9Ub0aBAOaiwguZ9W6FnzyEMQEVr+72Wnpados CyGDD51icg492Wi0uXpKk45bC88e6Bl1qrlD/1onhZML/hDTI00QH39GvyH3sqs/Doe6/Bll05ko XS/GcubqEpW8v9yiYejVDZtAs7KITsBEGctCzi5H8ZT8Ns2Ng6aUDwLN7x3tnWhQZpXjEdM3BSxM 4xyMAYirp7Agg8+C0Jg1CWi+VQZPjyyPjG+9W2OrbDuJVFKpK9A7sf8n4TFKuDYf5XEPy8c9vN+4 W5XjHQjDU4PgVej1iPQUDHio6Fc4wGZp99+j0mS4kUAll9g6XdWsYufa/p3jEU8O9p/rAaE3/tYM fKAH3rfyMj73c3aqeFZXBdNQ3fAv9mx6Nl1mlblcjRVrbfnXigOWoWmu83thrCrOhiRzv9Hyrprm UIKyuTncC3sZ4hVjSxoWGjS/aJWhxWRTtw1+YqTLcKDdxnbpMAHsOCqLFjKjFYX+PNgTpVKpjNAJ tqWpqUbyjtsQVF8kne1cJZkHIZWYfepMEXqThBAZg6b/1/prJO9YnoBLiVL+poJU2OLaXptS4qtt eACOdUjJsA8mFNXnjsd5sgf8aLkxLfZ25tQryg3h9povbVTodkfWsEFky95vteHHVlVRZ6yeU3DU HrgwSseF0JlVEoK2wS0RoWdqd9EUoDc7prCa/m3T7f9IagcjPcMUe4aiw0NVWJhsc5h/r+y4Ud9b KHcogd+Mst87yQMe+3eBj418fW7qPretTV2kx7PSHjvFHrHDM50m19BiddEkThiU987KpmsK4/nG aRXHOeodPAtPpdqpA+piLdRKWO/ashQThE6hwJIhCWRMvx9JOJYS2fvoZn8WgZ7RzUIuQKxh7a+n TYUxWXMkR5B8PgXWd3Jrc9S4w5+jHVqPnHmGjqlJYdzsXgN71FFMoN+bTuLotnQKmGQ/4yaSlflh xrapSRaeg4JzzakKCHHcCsYz1s+HqnA44ZRKxvufLysYrhOZ2YXDeUIWmVD4ynLd4Zv+cJapWejc +V2VTC41rRHbAXmvR+lErXPH1gIuXqfhj0AnB9IzIv9uQEurV67/ZNRSim5Bt4Vur9CrZT/BbcLb XcFoRR10WsOxe3NKWGrKohd2pml1jS5usE4a4Ty+TUG1xe4n/CuhI7dgFCz0ZVGC591nuG7tUKOm 2be+ww5RBkU92NKUbQfAZ+guVRzIJg9IGzbV+x/nChbPlxrmUwhcSk8BENfhFJm3ddeKReTX0LG3 FPO/WS/jGFemKwtKnCcu31Ob2R9VcDadqlqAQvc1NWbbXb6wc4nxjsr7WcAGrXar0tSogo91rgDd 8dupuE1RxlRZzCVsjxZMjiUR4B5Ghe+p2sx5y5KkC8RGe/76zWVWJDIKbbJJq9lcxVk/URai76+u 0rAw7f10NpraxiBlAkoynXpXbhLpxlG4D0wh0qYa6fsETT9HTVWf3lI47vSO3+pndh2KAtMFNFK9 mrO1BSK+gnm16vZWcnmTzQeWyuJ+tZiqgtpY+4lfU2mj9oHLo3ew65zagWtt6bXmi7S93dp6zrJ6 i69oh3ckNBJWE2VJuzv5c7H+ULh3thg6OHP7O1uqv5YPZdoajMXCaW8FyBNV65dyTrj3j4rD5GKg 5Ap75LxZZCgF3IfRXCoR7huxyHAzV06kgoT6hSKvLRwwoKfbC9DT1oPT05ZDT1vL0NOOz1aviNqP rBKO03QKZMdKWt/Td1/QgncC6Z7QOkPaWozy+hifII1rFQmnlbqEL888NDnfO250i0mn3f33zvdI qEreEFjOdTIQ2X95GNtO3mgUljKFaJERHbQNnJ1GOFUjCLAAUixkUeTmUC5JmDHH6ksWoK1RnGsS pfniGHrC9lIEr753hvlxFaYqnjxWX6LYiTWsigi6UTp1Ptvbmh20HpMdtIrsoLU8O9gCdtAx0FGw EfsUdatMoCq1216GNl7oSdefXMy6Cpuh+a59talYcDG5TD5n4RxzH5pYW+v4301Ylywht0+rq1Td 9NCxIDKWgTzan5gpqWT4ltBD5Axed97ml9f1yzZa0lxKZqLBguGMwF5Jo9jH1MWIj/TORB6RftLH R8Ult+d0D2y9Q2y9VcXWtzVbbz0kW285bL21FFvfhdd9cgp043D31pLcvVne75nb73Jcvl3SL9tm tjXDbz0sw2+Fe6ro+/NhdK0dBaQqvGCtWxjew9pbBYrvAEZTxQPAIlvPw85tVY9M97o1vHrgEyWa GzCg7nT+qEtLGUc2JS8XOT5Ws2nPnw0uxMzonLgDWWP1d+jlyYBgUwvxj1dJpHNqwaykppwHIM05 UyAk6mgkuvIr82+JS6RlH4760TibDR0Ax/aXCOITn6JNK+koTXuBPaYBD2LPgIN4kQFR9TaDhF7A BSo/2bNA1krOXiodpk4wEQQ1bZLghGXPgJUL2rHf/UCLf24xU11mIa7KNYCLEGkAu6L88aTBYitO xEU+ogLwKYZNnfa6h3WOUCd/JxShNXtEmyf5hWLviZWQosHXoO3Ozscw/0bLSpsRhTcJcNBJ/4YW b5LfoCVMCSv6tKjIL0tEnabjdRaXOO96FrIfGwdqsmMrT0wSpeiTl1IMbzoZDtZfY2wrpVXSEYyy qkl8bdaEPkiqHAU6xM4meMyG8TVyqCmlnLGbkEQdcaYwdxK066lJb6ZGo2wcNIVJLLFgcCgwyoqi VlD2mGIisnGsZHIYch2DBImCU+ibVXToirxeCTgw0DVs8Izde3H2Bls4WYCZq1iIL9fVYu7En5aj 8q9HBsScWEvchwWu4o9MWXC+pFsxzPLxlYMgGFCNuVGuMCvB5VAV9ZhQ3UwCbk0nfmLXY0CjNXjO HiBoVc8qkI8pHrcdYPzshK1EMPtXBtqDGfkV0hsqMVtukuQI1Qifc7IC9DavY7nKhLPVcsE8Mr+T e2WK9VfuVJ0HdjhkfoBWbTlzNmAFkfRWYDJRYh7sAUoem5TMa8rClgqXgG6+dM7NmLb1Kw7bE6dt FVcHJ8QgAX6Bh/E6TgEfxjdYbMRGvrpUi+yj3gb/RSRUEjaGbPycMhGtY1mngUJjLxZzLRHMlwBQ leLY2KWqDMw1NnGjOF1CYhXo4sxqr9GFfppymrkpFonJ7TIPi5V9X48M/jVCdgKOVToG9DseUQGO IRWblMroMmkFxjuVqEWdJsYvlLZgmTwgHQyVXkBlZKBAntAuj6CRkgBHUrg+SQ5YVPw9HFNdrUMr FJTngOCDKIXBKHCkMIxqhDp6dIvQ5GzTJj2gQ0YozbkioVJmRaVXVIVmgLlMOEPTkPdY6A1e26hU Bg6ipZPraKSqeFQcQIPgUqIeJIIrGAMhJgl2NOTFFR/T5YBEMp1StE8KVOG2Lul1cRqcw4NqFdZa G2EKUu/UxMycrOdo6EvkndPZiDyc6xrUeIWj0mmxAoWxKLFks0OIT1WFyBI8aWiuacEU94iZZQlA CAejiRx4O7D8ypzYJ0FAV2zrOk3UvsG+TPE+LLp1SWnl1Tw4ExU6Kmd4cii6Vs4aBZHdzkaAeuvp 1bqiKOpdqjiH2RKQ2UeD+JYdQqBJjIu1mkke8jFGi1k4wOikqQkOeIxMAYO88y9zhZIQLyand4xx iM0ZZoZAgFNWHIswoQSgAOGCk5bFkNFgyArnF+lfgtWhrKOqsstJTWYi4F9kqg8DDcb+CZYCQC0L CV2EE+JwUjrTKOPOxDefffABfzH7FOGMnhVlyorfUF6DcEIZHkZiOsodSsFwOGZYWGpjU9VbXKvn WEqWAnyyqUSraRMgyZDspa+WQagxdjJzJuXlOWwZEsjZMJWO9FpiKupLwkWdQUg5cthMQhTJpgnM B1T9omF8NeUCdiQuGNqYqFwqvMgxu3nSYEITdWlhTr8DJ4kdfrPZra4QdBvfYloXhKMpNowjafDg 2JhLoInBTb3kNgF4Y1CirjUuRlDanvW+XAFrPpNZmIZqFAGxUOzH7AHF0CGPU9zRrPhqGL+xkpJa vJNiXEA1viXxD7AmmmFFZOKOgGtIn1wBxRDRmkqXANRrnbfRiqiX/jlkJsGcLViq6CA3e2uOqjs8 sb5+pnTYJJxFqDYe2DS3/bTtGGACC0lvkyxW8uEojvmkJD5ANlSpGEYwJjW4nTeYUUrLmjK+VhsG OsCOF0jLdXaKqK6uZzfLJBaUAgk5b66KdTMFlTDYUHJJAuo8w0ABbWV2NZbEqgAVGOXsgqQutNd3 K0tEUaZiOA1fjlUg8FdFzFD6Aa7B1oQ4KY1SV0lmmwj7Yv7LQ/TJTRq1FVLC7qzbyvyS6g5lBmnc qoBJTtmsFWJVNcrGlNoo4hN/tPhxE5vFCzAsxAaZ+glJL8jlCrPCkyEyKiUkxg4/G5EMGHKZsbrs n76QN5cjkliLarxQQfcrCvN9SsPZqUfVsDAYd86RmloYJsWGY6dQLh6pAsA09shdocrmRdaCSZ0E oCF2zkSLtSvMSqgkOdTdIs75CzQbZZYbgX1KaDuhPCrT2ITBMKH3yuON0rXJvCw3aWAZnJ9jeCeV CHACyTSLh1dAEpCVophGumCqQuLENqB6VVMVrAPeOwXVzcbUyxgEXor+7/cnMxR7KAiFRKMS+Ql9 +QlZRGfTw8UY30UKGG0ngZXL5QbB3gxITjSV2pgDuTE46e2d+ZCUu8m0Tqr5jWQsQTQYxoNronPZ 3agPKqMSg4JABbfwZiRZFcAJ+ySuHWeGe13HU9iPbQIKp3UoogxlCKPav4Y6aexWnnoNKWxUMfKE KqUImbTWLswl5b45wXR6pQUUlPwVO+7f5RHBKMTGDpDfPzQygBzj6BL6fCjI0w4SJfZycy0QKFhZ C7QIi64oiQQSKf4wpSQ3KsARzY0CqlE4G2OsDmuIAiPJ5SCwKBNrWPyIdZCbn7AzxbZogug+bl/Q hV+asPHFqRaEeYQRTixJDGOJAdVsQw/ABkSt+duT7Pa+7vYMX5BytMQ/YJJYgjcjJzdeiOGwZOi4 wjgvPD6hqryb3SCVhH6ljjNaKyk6/IlUY6bIMAm23nveZdZ80NUIza/hpsEy+iApCHnpHpy5ZYBc YyJLCk7vB70zzj8RK6ImSMx3JjrZEbB1PCts9LMFJzpBiRKfXaqKnVPEWs6myeFHFu80x0vSI8YR 516h67yptaZ0Ilc5UTIqwSjeLE9NSScDKVNy8ps0ZXHnMlvKV6rNbWzctSRUbE5Locl7wYHAZyBK 2lta8CyLrnVGAkGYXK3AxVbJsjCcSwJPQTyD3YpIZ9TSWUNcQeQUoLiv6EXVEYBhtJgqGeF0VURS CFUQYJ0Ee4v0TOwoV7RZiUnVHMhLTnwWq+Jq6VUej9XcWwRI9l+EKdR6h0drHFfJBwn+FnQn05Hk MyK5FxFa8g5jalSUj2GVOJmE7LKckBWbamddNnasD6M7keeUUfJQizRZWFP6pH5tWrgtWBPRm06B vMca3YjLhSeZSVSrCgpHTDs4x2lrc4uYc+b40Jl5SCKNAebWEMyamMpf2B2DJWaHYJ2cmSMzxE0v x5fKSbeRGWn+dGKnSHN1CzuEmZIbYD3wCVv4hmn6WaiM9HI+umJat3LOkyxCiTAmsXg7xwPCdeB0 eMXr6JZU1FASdaIdTCumUu6Q7WjXE9hjbb0zUheB1hXpPa2sbW+EfGz88BGlHBUJbl7X8w45e7mg Oa2ZFnqJlx9og7OFCREG+QLbEoCFwWZiFrEMniIcJHr38pVykA781p6KwEX0V1ph7uz4Xw73JZck kweDCMakH0n1+kv7KjLmW3jcRKULKVPhISceRrz2DursCqsULKbi/McUU0yXO7lLujtJL8f2fqXq iR0jfz2sF6IbLmIHQuipCkUt9v3A1F1U5psQVx9Uy7uIzm+o3ZjwyrtuKl4XIKYI6UCWjsGavLlh 8FsYpc2JOdEUoNiJvudurjXCZ3cWIVCJQF1HGWvj/btOKDJIqPq7pXIjmfZsl9pXRfwkJSKSg6H9 Ol9EAXF1KQr0KoX1fDMRqY9JbIS5SFAbUyyJSLGm8opptIk26lyMwDaSwRqvWMwPBwbxo/DLK4D+ V3U5W9Zrph6AquSBMz/tdc3psNm8wiTdtWYypKErxYbQ09AxztCJI9cwmTHZ5EeWBLTmp0eMVjlR hufjmLNyXJ2DwM0sHaMgUkDqFnEUU59iqR93SaTn2smQL91rdd2F5fRdV+mEVLa7ScyGF2VHsLRs 01OJfCJSXZ9Tpg3TRLEVzLNTkIYwxThmb8I8NWSklfNgFBmUl4bDGHTLW4Vr6eWUhavBjC6oFc4S fenqpOiwkyAARKMYZgtztyLPpjaKRcNUQCtozsKfzioGDXH6drZrS50lZsYHSkbm2k5TpxUXZTK1 ntIQU92H4vggYq89Oqfxxm91emXanIYETmdk1E7sGSJi8iytyYAsDGyJx5CcVtOb2KJhRLjh7dnI +BDSHU9Cl9ZSY5TEbJ4feQTZSKkwu8uwoYSFUpvFmVvOVFMwe3E1VIagJN0yiOOQJkpFAnMHDEmG DCTXqINUA5jEXSYkG5vQfEnSwTfHaFUnjlu4GsjIIpQVkC0ZqUiHEqsBWSmGQ5sA6IEdQNm7JudM ZxMnMXtnoxV2dtbxDsbVvWu24EU1xXSMJRyVLblnpOxiOR1UintutHcllSQPb1sLcxuUcyRgIwZ6 QGrKz2mEBKH1xLl2mMJf4OSykuO9fcs8mkqyyfPTY2WdlNISOk8Pgd+UK8NBpFielx6dHF7QZiNG Y7otZRDrx0ikhly8xb9zcgAJtUkMaK2JyI+IS4dAskFT+kX3UkPd1HCue7pAG0wiuvAaEi3mCyIc IFffzZgHbStfrK8gySQ0RI+dYZ1SfSV9zOJDZtXoepRmkkKRIR6/meL9HgzpNE2yFGWXBiWgj4Yi Q3GhPGFsdXRtnOaq66D7ga5+isqLZkIqRRfuh2UhG+L92yVXtbKZkmayZAMy99RFriYsycszc3cE 1aqxOs/xQFHXROkbQ8zPzYIbaEQYlG+RMloKOiLONMY/oXR5OAMKji0K9L2M8vplM2Xvoz3Hyw1O 7ovji/hAFXKaG2FH35USymUsmgLLRqYh9lw8pDMlxNPclMmjpU75WF3703qU8QCjQquAnDeu0Nhm 9mEtUrxZuahBNzDprfBr+HfbTP0yppQ1JFpHyEDYkB2qMhe8mY4LBm9BwSdlpHJteabHdnKEn9I3 oHtE5rx/lvZYULULycyOWwQ9wckdUd4zkC9AXUBKlhsoYx96SwRBpVUslZEpP3I5A11DHAmMLwu5 RVAaKg+XMIZrgvUgjtESmyHuwQ7HI/auSXE/bxOmRMrwWjyfJEO3wpdKnI0dF12jNSQ+NTgIXqqO ywxj6v5d7i+9FvAyXMLkupzfKlHLFi1J1WKj0GPbhWyCSfvVOSJbrSOZamrEKVX1VUx65Z8anNYj oNM6I6EyPOSsEtbhfRoESC1EHTPm+8u7nK8nxU5ZvkQ+w8pTKvlN11P4JO84qRROQ90VS8OyErce EMNbtyDqvYqzp4hxQXCbDvjQXIG88xqOKjZGKTk3VP4YkXwh5T55C0iYU69RCmKyMmj/ApjayC7A Z+MxgV/bnxF3RHOwbXxTU4jFNyPXqCveQrcxVhBBUZ/oAwAlyXKva+RjolqhYHnUEuQfg2RglWDS 2M8ykL4jtm9MTDCY48bp9ba9a4TnlpkvD7aKgydGmGo4kXghdkjq3XmK5q0p3gaorJhyktRRtGMB WKSeeWVUES3NOYSTnXkbovlO7AnVE5ccdHRlqrieCGh8NBhjrlPyGFPAKJPXtIMi0gdVnMtAGgtj 0hAiREaULZh1CA0Mc8SKPFFmloxepUO9kzqIbt6skD0hCb+aDc3ess0ntt261P5riUqx9rrwAqIi bG7e2gw321sCOT/xvRBz2qskfq3UA0sSQU/dCTu1XAIhojSjuXUTubRsXM7tITkvufdX7M6iNQ28 X0NGpYg2FVwxjh5CR7TiLe/jK8zV3IiBojtN4HW+0aTLsrCqNmiPiixtlO8Jbept2XZ54Y5YYRxl CQxAbgfiKw5NUrzZBEwbagdZCjnQmSPD5xMAAFvejI0cfUQzcf1gI6v/NnWa5iGA5GM2TUfpLc9V sYCMHdXMSuookylPNu0gIB3SlZ827CorlL6Gpm2iVCHatY00COxBSUpaGc/oNp+qCfUxi63gWTZV xvhR6uWTfEXGxaIGKnBDAGBJckTFMk7ipbpRiejJ+TpSmlQkrrcOKPWacLQs07Z6K6O8yvlq7icK ogKLs3zPS8ZyQWOZJ6VXUDq9udxQ4meaKhEO3xHVAYkdkzu+o4FHOsG+tlFZjdi7lVspc4aRVEzD KeeOpPndVtE3tFJwzYWYtcmMNTQl+uJGGW8341xIlS98yArojNIR8U0MJgMI0DMysUrRz5y8jaZw hho7SY3stM503hSVshmBw3ONO6GCSt7huyDk16RlMsmvTXKQYy8qtERQj9Ea3weBgZKbgk7W/2x4 p11BonBEpZQjYyhhZQIG4wiF/A7IxmCEkpB/4oCRDBZTOIN9wYT2O+rJwjucI3/pBXEjPJr1P0vY oVygTIY8Jsks8QzRjUKQXMfv5DaCjYFqZVoRlYMgDkeiiZbtle1UdxVR4UNCT4VytvMOvohCqR0f Umey6xdv1d2tttXxDtviTqzLQhusgc6eYzzfjevyh1YKUWWJbSPNhxkCNafljzgPPx5cxQRCQSOR Kkow3uqE4E1NfY34de0Vz0qoeJuIuqizhksEE2ztZIZQutEeFuwByHlliSWL+sssPOsDLgMTAhkp EZ9d9IHBnaHthvcHkQnpuLQM0QQVwmLxaVT8Hv4LJDAmDL6aoRGFzNXEw1gc0XQ77Ks4rk/g5ISH IJkDoT67ucswO4G6sKp9cngGSpN2Ke+rGheExs3tcGNjw75zYfKIjlIjNmyam5nEc3dlrHwynlgk Mkf+9Rxdrb8qBScSQ6qouST/95n6qUd9FdmADWBLJjLbhJIjKfkUmef6z4B1i6/NiPdWR/tZkxVd y1yJogDXhyVY0WjNDYNG+PwElI+bcI+rG9XDwxl6PBqm8jyahIfwHjte38FiUNnWfFQnkL+Nxlwc MEWNnfCFWJaaieHhDSc7Gc4ZgwrQiU2I+/7h+QmN9vzw/LgLcoYTYxKSyUe1JT2MUoxmNnd72cDy a8d4ILX6qqNoFLTQa2giOGTmUwjQ5KNnYkFMWQ0c6ezgRGvYWNY2pSqFAl+pK9J7Por1RRdOjb93 t+qwh41qgvY9EttijfdioZfUYia+hW/AY+WhlY9csQdl1jPMYpJ9sZSrLuubxblVhtlNNCEupgiw raA4DqhWFBRCjo9nW3NyNpXfxkBMBw771dcb/Iaod8WZoCFxmrJTowpgo30m3+qR5OgzazG4V8Zs dDDo5SwZDhyWzl6AsreZqaGV3SRj2U3HVYUKUaMEjy4rMNHT2qgVrrHpBMjebcZs9oquSzjMiTx9 qSiDEsejV1Ey1GXfOEDVuGaRYmcq9UbjKdlrcCpecZ1Xp4ijXNrhPCmVIW4RifLMlR3NRgc0EDut Bh6+PbzG725gkfEtxtrEJqegzM4bwGBJiGybz8iUAGxmJkJrQl4mCFm80efABVJgGKTjyWwgLiro 0h8zTCtjOWskKQgL15iHBqvQcpg0+veaa7xHYnzF9aZQyRKfVd4Rdeh9eoaKrENWaXWndS6swPPh hwGH0+8HXTeN0PUM+AiXPKKjK/Ggxbh6TIqsNUzlTA3tDvG06DSomlOycxNxNLWsJH8Jj0G+KmKE 9Xv9CDuc3o1FLJIe8MIe7+32if0fX99Ow+7x2en5RXgi0lY9kF84hVA9fEYOhXuXoErC1DFr/tMA fW6ycfcg/H64d36+95PwjzYajUQKLaw3fxqePg9P0R5CTZlnl7TOtSUrCg7SmwIY4Q3f8Jhe2so+ h9kliDzEGooodyWZASrel4LUhYiv3sK90jmubBGjZ0skpMhLEDiCHi/kMFmYdHKEQ/doaHI7Ipwl 6ufpkiocmmTLa2o72UyHu+fvlkqaZs5ydfS7bxjCdzjz1wkH90p6YBauc30DQpwf7p+eHwTRYPKE d/VpUPse2npSyrKsekJT4PfWAkSpJ2GNJtO0R+fBAX0k6Qq1aPlavBxFc9qsPQ2y+OfA258QrvTk pvw4HcyGcIa/Dps/fRrA3KLrmFscR2/2ruOf4szPdbJXneEZph2Yeg2IQ09CjWP4Dv6BShGTY1w0 XmnhNRl8T+mQqJqPJHvuANeELnvnx5hXJnvCWP1HzUajJgki91WOqN8N5JtPORmKlfN97aeA+M9O T48O905wDl2r0B2g65E2bJPpQomTkn2qgYmOlIl/6MNiddWPdC1Da7lykqOsuVq31/5toGBTCcU7 ZsywxFPFsCv6p5tMKxeMSrXGCqAa0ne8BPMnEYmWKDeHeeChdw9DuneSh/QSgCYKUwLoyC0QZJUO Q/iDdIUljWKRJQ0BBj4w5WXj/ZInV7ay50wtTUBvHazo7LR7cnF4Hl6c4kCEgsTMKavNgAaHVocn B0LsTJ6q+xC7exO4VgWBq+i6jNDZFz3+ARxS13pHpE6xovB3lRl/HvWbT+NC/fNNULsHIHbB0sRu DQ9acH+KttBBrxqj+jArMf6xz3I47yy3rYSACxxhyy+NYy2UT2xCJ+OzOB4HMMU+2T1HMcjKsO6J UGAfS6iL4J2fA18zJRwZrL9kPXskdk1S8AGZn6Abh+oAYR2euYVEFICCZ7qmkO/86k7gcJ6cXhyG 2zvhs5Q0e1tOizRFMNNmN9WENtVYm+niirzQ0ZjDCw6sSRiTkz22cQfpfbrP6zk4PFCLCBWmw0OL r7DXINYzkXZUnL0pX0sFE3kEuuanKh0aEiV73ST+M3i17I9LQffZW7zwIOVyn6T8sNnUNjuzAaoO Xnr5s7g/RSzh22anO1SASHudZbkbjNDkx8ca1KRWJ5x5i0m9Gal7cIgTrdtKCQXfoS7Nz0BmFzLb PXiiZX8itHgukoEQWya0ggdMbyODv/ZGoXtcRPZLrRL2Tl+e7x+GewcH54e9ntxKplw2/LDHmUDp cBJcNZFkavhyJPfISF+2Njfbmz9VsyuBBNrnyOU0E+jjvRT2LIY97TqDJja8UMv0xZ2swaTyJFfn XCZaSutyk0rAvH5IS6WqY2QiNvfu4qEtMTDW4kJVGDEZsT3dzdQkl2bKR0kFF5NPOBU3I9xJdEWE kC8fbLMpezpFSm7ARgOTaE9JEdakG0L9gPjJcTp4EKLnofWRocvdqU3ORuX85J4HMCLZBBnnQodP b9InMejntFO1HwFQPaioMG3NnFh14vfV6gTp5PE3iXRmPd9GzNvT3n9oVUYwaoUBm4MwF37540Zr U1Hr09n0GtjX9VdIyfnJwd5XZNPKbSd6zVLO6bCm9hAls9bm5k8X37hFCUZ3qok2Yb5m9zwPzHMa 344pOxAKGB3NO7MbTMmrK8M8oHUE631TDgRiEIpRQkdfqrdQffxyTW2rXC7re3s1jq7cI8UoMGmF stl7rCGKdLjmkucmFOHAWhPWFr6Ue52pveCcJiA8aoCiW449MV8CNJsmfAOgtgdoGl74PKGDC/I4 5jHmnMgklu/LjeelAj7unb8bq/JCUezFbntw5oBQBaDFWqKm5sk4HAlffEyMgEQOVlaQhkYtWLQr kW6azN0lCHMvBbN671sL7H1r3t633nbvHWMngtLepDF9+9Z7bbp5h3stgxb2ekufmqtiZo9vgDAo wqZde5TPV6omKNoIJ80ldcQGrr5NTFSFlC8ysajyAMSMi6Ngfqdpql3Hq6wZ1oUlx9whtGlKZBLJ Twl4y2ya6VAKd1IO9mnCEyxMeBpwasx3X258Ra4hnFWwrlI/fKlqWlRZ7gArMsI2tikUkZBE9hN9 vwoybjLApY1RFhj87AuWhQmAiEOIabWNMNEKOWz7l4kTnrYWrgWobn+SjivRH3V8C/2je6C/n9aa Y7CdTym91DHw21ofCqUXRZ8i8VK3aTnU4eOw0Ia/3X7nt/t738h+6+Wq7W6FvbPn5iJUXGqQKeHb XEjPFNCTcCvVOBlhPU7mXgfJzz7D21a+DtDl1EBWl8RgmctB0dETfq3B8Gt1jRoRC5Gc/UiJiHTd inUW+pL8m7CJMqaEVpp3milK1G+spH4ZrGCiL9aNSwQaX3VImk7ChUmCBUPd5pKl3bbVSmJL/GKY XpeMQGvACPLMSl1Ys9JlqpgJSjAGCr7tdoW38MGe1aUVsSNhBEJVyZMzZUGZ07ZpuJHmIQUGjWGC fGsjyQB8hcG9yv+5Fsk6k7LkBOLIwZmXCTiw/JG6Jaa6d4wSki4MT7POyaPWrJQhnESM2uQ0JgO3 ZZsyRha2IQiEZTF2toZMZXC/MZc7ML5y/BhAvxFnnOLyuNqFXmq7k8VTqnVEKvEu6nVWoJrg1lQ0 HIOKOvtPFF7NAJpSLUPZVAd4TaTq5EZD5X/X5zScaLQhAKFz4oy0Nb57yKazARrSstn1NR4Z41sX cVw/b52LoSE7HwOGwYA30TjDdDTkAmr83Oy6CMXjYoFBLQSd8tCrAh+XweDiZqaSDPtxxko3T7KC JiHk+qIOugW/hiQfhKeWuQsNxrZtA2mAOFzXhcjiQYLjA6QevYgE1iRkMxw4plpTq+kkNrpot6d9 fjhrXgF5yapapykpoU7wXhfUwN3DLJb8R8YOHvoOicYz7roWpbbXRaw1Fg83Cm/lvqy6iRLEpy54 cmRcO7WpknhUPZZ4HFcBQezTmYSItrPuYBP3yg2lEcTwkOsc0xVamSt0nFyem+Du0Pm2OZR9rrW3 Ivv96TdJmcfACqXWAGM627v4pBd+zWYEHVBOBq6of9cfAsng1CIxpueJxjdEaVydTttQBd16ikAo 4pLnQYkO+pawdVaqJgllPZctxw7C2kl9UDtZq/8SFBb47+c1yXUO1PpElDIx9+pEIDr5gLor1ntT D+WdmhKNf7e5pqVjti5FVK/Iql+dmOy6rjytBj7QpR02ENE43o2aqB4LveH5AcrsmQZsNWXHqWtb o85fmxv+wKS+9GkYIO0rdy0ydstbOuBJFOfqXnKgbNloTguRLBJR4IOoZ1apfYmLc9Rs07Nda3T7 oSCmTVxDhoISTEUrrTF/pGyT0RAzibDHMxyBK6BxDdDxvzQUEQ1wo5BwH6UFRDEc5eSLTHM9xuoe bBK+SzSISswJH2XeSm1O8EBSPwpLBTMZrVnqtathElPqEQVU7tiu6HmC6Vyo9LAgGfRncjvStCVE BM4fpjew8qBy0lMUa9iBQqDLZxf6cXMoEIyc44wE8vDkQpEEWomSMJY5oeFJPSS4IhpqwKDEZV30 RJdAUQkAtCgU3GhwTvwxBT2fc6FhggGKq+K4STpBbHV+JVkvTUylApkAinCYPVNeo/Ob+HLSSnDy b2Dmn9dWrJ/wz5KV0Uq4crFyuHIC/4YrtyvxSgTfZfD7dOUGfp/Cb8nKFfx7Ap/X8HwCn3BlvDKE p334fUAtsJ+zlT3o5ZOV3kod/hqs1OCdNXorXZlBe2x5SW+/oRaX8O1Ueu7TuCNoOdWt3DHS3Bgh vD2C1gm0whnwTHHm1/AkgnlG9DyW9816cBTsPaLvQnjnBr6ZUNuJbjmieYbw3RvqdwqfxkoA/7uA 5zG1m8ATnCX+haut08p+CXOsrzxb+Ry++yZhHK68grciWkNCY/H6Imj1M+l5BP/ewXd7BGF8+ozW eLJySnMOV7ZXdul5RuPF8N8+rftS5hXBbymMFNOMavA8pvG3AVot+GzB/Oor7g5lMNdr+F9McM3v z1TgmwCsGLq3NNMpPU8EEz6jccZW+wE9x/lENAsb6hGNG9HYMY2SEsSHem/VN/au2t/yGFcEpVta 6fdgXQfyfh3+Cv+sRiu9EkjGBGPEsDF8k8H/EGpDmSu/F9EO4Deqpwb83qUV4j4NCG5qzTYMR/BW n+aYEbbf0SwRs3n/Iz3WVPB9Av9Vb9CKinkgSVHUjAtZyxXedKNvmysuZCoQirwGNC85gF9E+tLp GlT1TSHQKIhacpIE19llOpW+i5JBNFFu4/lqniSPGsdzk6pE8QubabGuqHqQKL2aidbz2iBTb9jV GvEzcYVhX/BErYCdmD3zrJ5cDRU/4BLERsgnAIGlbWjMvmnYqVoyRWPpC0PhFK/T9UECDCJjWfwV ZydVolZYk3TyrE2UT1nyGqwRR9EaH0GAJngXNnUWrmTkeRWZKRmyJXdJrPwT5bFzEWBlXi7tTE+C +b6KixChz/MOlTSYjUT3ezp3tqx6iFnnLSebcajHxpwpFpfVbFieqewrxWYIq4RdyCYREHQx9lLZ RG+j0Qj4PmVtSEzyZM/YYkCz4gIuE+PBaFlCyKVoZ0MJxv3UHAgjHBOuyumbTTANIiO3iK6wghvJ zGLJtSjQcAPPpW4RizX6mve+X1PAr6v1SdWMzCRhZOqhNTPP9Nh6TKJbJvfhl0pWEyLWDk9fYVhb /LqweNav0RLZtzUvpqMUd5PxyeWjDr1H0/5NnXNVEJHB/RrPpjnTFJAZPWm7RqWIeWFtlIogO9FX Zr3Do+eELGLkM57IJGWyXke3aeuoi8eWOxBn3i26tCEKaGS05XOkzCKjK9EzlHsrz8w4Iohf5kid vMh/Ygn9SUHo1zYA4950jFtxgk0mFBV6QuZh9JZAUlhXKK7ePoHOJXEj2cAM4T0ma07tuP69+vdW fg1//v0/Q+k0W/HLlijxGEnj9YotMb8mqXuoZY0hySfXJF/WSfYYaZluJiNck9w9IWmP5eguSVa1 lWOSnvCTn5GS3/J9xt5ZKdnSlubr1hupyMcsS7LExO9MSMZkKRZbXJGsdLviSpCLje+T2lUvLNtd LdCLeo6y3a3AOCYYc6vIaZVSPz6ocYuR06Mt/45J44pFk4poT/P6QbLCkvAv5Qnu2BpoNwbi3CPL mWoc1M6U3OrK0Gof1Hu13LzXVsqhrd4xczmhuRjIHut5KW1yEajk4c+yt9JM0hV7D1k/Qr3Q1lYQ dteEeaxrIfZc0dgDZ6+qtEZ7RXwW3JkHdPJ4nrfUN+pIvGtv9MyU5raz0qS31TnmfwcaW+yAPZXX TricfX1UYI1MwJmguvYS5LuOLsCUWUpk1XPSA/EkLQNl/AKnN02meOs00DYZMTyKNcMxy3yvju/V v1driKk0x0tgujHdMTIvGqUWZ1A5c4Vpkbj6RueEZ3dsBRm8ThGztDAepTpFw0kcDe4MO+SEnfLt JfpXm9yMfH3j7wg6IH5Nxj3OJco5SidYJUPPT83oDa4W41sxiZq8C0Cg3VF8H53b7uoyryTTNzQi 33TCPVeeIcci41dkHusLK8yeRbkE9fWbrl+fv1HE1HjK+cVnJYWu8vc9Hhe23plRhaapconSz+Vy ojvS159htU/KAqO25ozaklHlKjXJLPlojkMM12hkiClBRcWASQXwdCyXKTob/FTtTGJtTdmlvAMY Z9umrxMr1+kgvoowXaraK9x+vnSP38T9GRtVM76gzLlkUNoRkYcBN7/IJP0j5h4xqUdQj9ceDfq+ SC+XTwLV0ACgmVT4lqm+CpJqGbo/XsHS/dBhM4tLzLJCe7Zyc0etqVZwbKq0C8CdkCu2xC47G20l 4fEtH17BDftkOCtnE7bKCmdINvQhVdb5xKPDbjwON57A8GJbisQKlreYMQe2La7MCWOyy01BfmqQ FOfrR8kUrtTC79dWNoCXbQCXY45VK2ntSkKKQ7ttWLKIHSthUX5kq2pIdjLifMAtI81BsbcGzCYg DjygGfbgzaOV5yQtbNC/PyKOzCtwJeXXK2xZjamVkSBQWhmvxCRBMY9+Rf+drShZDa17/RW2auIs WDqIYE1X9ERBTM3GyJgRWfFYPpmJFZSlFLZ7ZyTZTVZYvpoI7HL2bTEfsCfJCXBIpSAqNiR5Dkp1 xLBmBQBQCSzAVHpXkR0p9xRl4uSuLtLs4jVUk2zkPZyo/amUwpJKXhkepeIlYXNLGKWpwtUHoaax xn705KaoJ883NPWwZrKcHHPuWitAiW7kkMKos8qzGITnmp5pOreGurl6Ll6bGaUi0houzhNVdDiM HH/65cvxV3XNVORi7vs5KyEZLJQbqCK3eh20CJ37ibRasfF8Fqqrqc+gT8kb4lL7eojp5EkDuiWJ ekL4Vqe/WT6criircr4FYtFEbNz2Mz7NthQbrnx/xZaQi/cOI8DeW9IisTdXT/C1Zyw/sfTHaGUR mfrYkqn9+qXSCZ5Yfb+RFah7Fld3sPsOV/4n0Hd+vHDlfwff2hCxNd+pRTcUZUKd5bXswsQLBaWN 8QqKI+rTTZrBG9IQEMZnQgN6BKeE6KS7HlsLZhppbgvKZhGtlN0L8fzULdC2s3KE6+/l4DqgnWWd 7UZTZfed38+94864et+rdPpI6H6VjmbGtfezRpqnmeVIdODi++G9MdLMT/Xkn4vhT3ldlXFK9YKr xrOk1A6gVCzSGVrv83rWPkOs3tjEEmsAmAskui1IJemKttshobV8IjCXgrgUOb6pVDtHK0Tams7R 6lciCVf6cgQBeaNg+gEdu6rIskWBT0dAgVHJZJkKM9Iiv8NfxGuOArpZ6BNGKD6pBR8QMqDDm90D 9ybhKBypACZMAEsSa2RoOrtcuEAptOI8U4kd4cVu9LhCHMQELgOnATGRVbFkpBtQ2opUFBVrtNd0 zviG0j599p13UZKysci1pVWdkyJuupIT4qm5zUaaa3MWvO3NcwekQRP4d0a07N3xHtXiYOVcRn0h 37OkhrIsymMtebqv78Htp03gMyFAwsihsdX3L2hOTAlDkPzw+WfyfkR9oAx6sPJSz/vMsXRmMF++ WUd69zOyweJe5jwq9JWCdv3JpZTQiE+3vAtgP8h5Z6zX5c7RmqUrH3HtT43MkXUGdSAS3ruQKHrJ qE95yOT6TVseKMvEVXgmK9AIn8u8cc9lJJQPlNLmaZuTdjU261uz5bgkm9bO6iTMDWpna+HvGqGM vgcw6NmbK42TsEYXyT4RGKFjZOU1NREhymfaI7USehnmzyNvWWWJwncIA5kDuhiD2IgW+xvy7ZgB LhY9Idw3zogP4gk+o7OXt2KjFpTKWK62lu83zzvPhKacEU0x/PNMqIri4UV6we+eeOaDc8k8Yw/1 STPSwtmKkTqVvDOhU6xuGWzvnL8S4vOqE2tkBeUDYs8TJZxjktuUvHa84krfRiqYJzHl6bHfwmxk j+L9z2LjLCaB+8dcXALPw8ovi594ZPETjyx+JrL4Y0jiarx3KYnzDdnbyeI+CJfvvX3P0FqxfdFu Nb9Rt4OWz5FAxD+a8psarrAVCU+c7dmm5BPshWGDIzDMxuJNmBBVca00SJv2VowkbXyq2C6T0azw W+TzfdqHPp1f3Lk7vRJzd2LwRdnE0OYyk+8MLGxcv6Jdmy4MEZ/u44PafC3InL1FtCBFN4pjudQX /RttTFpc91mcFvh0H9+8zqQ/n/6zr/Helc9QAuOZG1jwfIyFE0fMaI/HK2z7YNxkGvV8JVlx7ynz vI1n6a6eYRf+2b//ZywDl9/oqTONHoV4344UKXPoo5LC86PifbrPqqpu2QlnIkm9zZdF1pUe6SDa 3aauc11QQcWhSq1Acodk6L7lhDgRJ62VNtkindp5bdVrkk+P61VrTxHWMOmKxY40GEkJb0o+BYoX dnjliXDIzXiU8qQXmqu+pbS+JckM9K0YndzJCokxphTehrKe9Tp5hZ+tfT7fJeOd/vjpgdGkBhp/ y+Qv+8zZ1Na1cdm3z+qcHMG/rwhvQ+IeBytsJ89WlM/A2YrrrzohjwJlr6+vGLo1T+thCmLf5dt3 GsoDWHHKKZ3voZyujFpHJOnZnrgHNC/2aon02/lVdVfYA31CZxMpl5IF7bn66J3LoYbEgwwl3APd 8xD+baycrSh70JlwA+MZUb5DonvjUdg7P9xrnImLWL4Y9kUyNdftfKMlZnf8wk7LZZmiMeIm+kxd qLK2haPQyZKL+S9MokLKooeJyiikCF/Dp92Dho5TleNPiS65qBGcctZcMXW2c5dQx2JK6BFHB7Ie Hg6z2P6qqV0b28q1UU0E09TEb6bspWDF0GRfcdUynAlHuhQuAUKOI6d8SQO7ZeRciJIeSlYlKhcT 7DfadhIOqYOC93TtRjM8lPw/TMHWyQNTXXpe5d4azChRsXPp12m0JRrfNGGam9WN/19FSovwa7wN 5XClJONfmnwz4r7tzQTge7tVp3g7O/2dWB5NfD/nykwnTtQf/o7eBGMT0j51TIcJBvVNZxOxOsID Y1cwy+cmmaXJf3kxmcVfEWtA78VZMqV9NR1LevG5/TyPANM43EoFjaPTSEhZhrIbVexKXZIdTNJx 7Us7IYVCpZcmCwB0R5YJziwgJpSfz+KZDg6zalc7OdZ9OJJJSJDyGHE6QlzFm22AWUJhvcZiqsr1 1pkCvE4ydri/o2HJ3zahnOfIDtNL+P0qym4SKpxzdn66f3jw8vxQ4XktIER4EtYUOjFirNWxiOD0 iaJAR9FdPNF5tT/dO8cteWJldtEJYUBKeKJy1GJDfLCHyXElbwJmSDCHTFlIzjlD+NMADvgYd20Q v6kjaP4AofIk3N87P+ie7B09DZ4dvuieBLXv9WLK5UBdI4itWFuN859j6oTuc8H678uRCS8+OTzR 0wqfqO+LswoOj3qHxZYtX8sTSgx4xgGozmxuEPyja8t9JBXqHFK4GSwVvdcZS/Rx5Zl/Au/y1tTp 0Alo1ngN0EBN7o/o+582OC9G+PvhBjepfe852tQJyWa3gmRUakrZrK0wX/hhLxUYXMEeV30cvVGp wXiH8Mv8yMMom+5zIenfDZsIDC4DmF4BLl8hlcAWoUrs+vz0PEywn6YkyvAt4+AUuvFMVMcjI0wE VDSv3y/rSYDBExGmyRGSsaqc8XoSUZU7ZpGYIldW2mQ8UH/Sf38Xv8U97z4PCE49gGktP7ikDPkj fOWna+HvaYzm+VgwXriTp4iP+EJls6eFx9b2yBqe8gIEmelbIL78JS3YenKF5JTzwU5MsgRd4gVl /HyWFSHYkjKxrENEcMMqbB6jyueoDk4OFAl92vhQ1zA4CPZTzKEgCRJgL1MOoolepUA5QQcpVi84 AG5efIv87XT1MpO0DtNvoSMdpVqCntGxsl94uxFeeF7Np6Q2NQ3QRg1QA0XnSRD0OOvJJE2xZAT0 gdHk51Kz+3J2dYU5I/r92ThCiNIJwmwHeCWg83ZEKneK3YtxSuO7PX+TLGW6kBlmH43UTuqMsOQn OYlfkXImkxrE0WCY9j/DaQySrC/8ja38yitV2o7TdOj4nzbCAyp+4OaaEFic4xSPZIriYgcM7FRy WMsoBlrUNNM5rvH5iaQ8Rrdano2TaCIeZbOJiu7BvYOtO6GZq4C3SfwzSkBAKScLPSck6tKvwBUx N8NIaszg1z34WotlhBqU10H5sh72UHyyh7X7k15Yws+0680ll4e5Y4lbPbfPzCGGMj8fzrIbhAn/ IrtKOzxQm2vOJ60fE3Nc4yEewIlDucZKboFvYHwSEXCQAsKaXs6a5yAYsSzjWyUqTmWqHMaS0YIP xJdWB5jzZEJFiAZf8UXJyBacoA/aHpge443n1LDTrA/LBTvRWGHyVV3ekTwoulHQ7Z2GO53ttmpM GKa5tr61ksp1X+LTA26JpGtGkp6hK1+ZE2DSvuixs1D8SLVDER83ZtB2Ehc1mekNgBRz+dbDl4CS Lym8iitORplQFiQmKk/Fb4eHx88OD8JDgAZ5JbbD8C//xu+AvnUJopDJjqXruJCMJ6c105min/Hf a1pecOkCbsdJ3+kwkhs6t53cCeqspc7N/5pKj2IDgSxL/Cv0quYl2UuVaiPAZBmfPCHIwVs6Up4K CsiChD5RnBwLTC94/rH2GPVm502XLuz0vNoTQ0Wh2nNCTKSoO3mRJk2RT3yalAqp0gKnmAtVBswy Ftt/xFYyC3OTTAjC1SS6NiGLJgNMzlmEEshMrXzvdb7zVK9LgQhiMneUQ0KSPAnxphxHqoYEVRtj L0JyD5Fzaisw+hpUO4GLRmMYQibpmoQo0b7IbCL9RqhSyiQj3E8r1RxXwyLHe+8pMY4bPC8GFx8s k36Isg3dSq1wCq2jOeJGqMlktmsiP1K1rkSJZCOISkKFc1LWFjMbd/g1SjWlaIdQtFZYwt2c1EH5 hyKu4k03PJklRPFVHvk80xKDiM3tCIOnFPpxiwjIMR4ox6R54qX2zS5VYXWN0RuCQOT0jyKKPnhc OxBNPJSGDXq7iaNXd5SLqO7pTKcn+5mUtLxJhnGOTyMpSEZ6bynaYWCcr8lTXgfSFEZgt6mQC65R tg+KOwlfR3g6iIpi6KI9IoVZqynVVQ9Y3IXeCr+mmBjF691jLEnFGtWbySWMs5DS0wDGP6EUfiRN 6DIMJB0YkYLIdrBnRFed9YvcsoZGDFGbITKAZncHkgC0EVZPThdjnjqibJQJuYXJYnNeQzwIWDRi aAXH6QCEvL7E9KMKnBuFqcpE1Rkl6i/f1TGolIT6kX9yDgaRJnXEX19ph2MfU2qE5C9NYUqYVC8B FUbyCW6wwOztVvnBXd7Zsv40n4RQHRdH6hQJ2t0P3KBkgHKIkIK2yG5y9K/4DxFZ5QCOUs0KRLaj UyedghhA6SSIxSbMnk5PyFpIzfAuhmxpOBktDcrz2Pf2y3ED5tayNSdLxzqgBF8sLFhQ4flbRlUV LYMhN8NELLTcPnOYg4Ea7iHJvQgfFmY1K9I0FE+m8CpNdFmSVzTXsCTghZju3jW4qSwCFnqEJdbd LEMo8TMXobTgRshyYSQ2bFop6+oVZaZw5x+kvdCu+Jw66eGNWDyQ8xvWtLRd8bpx9VrDWoBKkT4M g94dsN43Ur9UERqkEs2N5tbm+mZY6+1vhS+Ou6BE106MRr2+fgh7/wILFoGm5VYRwGKKmSRe4upc QXB8evDy6DD86DzuN8IfN7Zb7fCfwnE+7h7uq7E+CrhbUtWpaC2TjtDOu8d1BbGlJPWwGmaWDsPW RXdGiZ3dFrNCYS+MAmYAyRaHljpKm0l5PVjbY0ENSTLiBR9q9vbMsCeJkOyXzl3IwN1YsoBn8S0m VugrWwF2Yk+4Ho6iW+RSKDxH0+kkuaRsKXh+LmNgRUk6w6yWdPEw0YxCraoUNni2NWFuQPMgmAfH 472TvRegWZw+++Hh/kW4f7TX6wUHh+fdT+FLKspotrZZ2NpW+CRs7u62PnpCIDhKr7nbp8H+J3vn e/sX0NEfQkfPfjJvQ8+a4dne/t+AuQRhGD47/GTv0+7py/N5rz1rmrYBFbY6OHzePYEh93qBqnX1 12Fegl+CMEiGyqHIdpHGX6fSj/TP3sXFeffZy4tD6dTa/Ass1/Di8IIbw8JPTw66F93Tk70jtSJ6 yXoFefRZ1Kc6Hdaii8MUX1MjnR++6PYAurTQ8Jf7Ujhz2hinSclQtebGRnPtc5rn2flhDx0Tus/D v37hnhMaRdcYsSiMUDI9s3AeBOUIhab4O4nSqdUDn1EJaoazMme3cUtKV34LK5/zfq3ZZBAIPWq5 9Iiq5yTTOyJCvdntLXIsnJWkdgXyIhTtCZ4taNSkYh5wPPf3uxcXFDVIRCjtz24ZAioXM57GsNUI X0SUbW6GdZiH0WU8pG6BUazTfdPAIgf0SrsRPk/eIG27G1NtW3opt9BDnnd3QK90GuFBMhCrF9bh ZS4+wGpxdzBHwgZsianyrJ9cn3xN/VD0YZqO5xIFHrKEEgQelOMXijQg9JOBvdzrst1uyDBIIRxu RhG0HHqmu5A7QXVrT9XdE4wnZo9ovXdu1ptkpDtgPFEQa+ch1gGI2QYg9RoWQlazTTIzx0RFLyQj mgxeUZJ7Dhw4YCF9c1pn41TdniZYoQYdAjL3zUbZcCoAT4+m3/CSSO8mdQdIuuwKhBQN04vGJxEq kbmHiyFVYQMsOrwEneAZIn1sWcShrSvNYya1d0gRygiCogeLHW4kA+eSENwSMfBFqQMP8keEgntf xZCj1EqGrEzJDmr9j04G1EBzDr9qtuiRD5G9JZlfjrUyFeNpVpmoIuttNlitj2M0fxhoKJMMMkqu 6UeHhVQgVCfjkdWH2Ao5+IsPVem5USMUTwsWEZ8MUW0yWKlPzoI4r95DTG9bmN6xMB2TTa3foj+M KrAOwMPSCvFjnoEFURqQf5/TzpEAjbMYRZQh2lBeGKg/PJO5H/PUDWNUJwJwZe/l0UX46d7Ry0Mi 9eeHf/Cyi5Cjr3qoROb7pk42G6wdiXlhYGp9FVhqYR6PfYzy41WfpnzrJQ7VXgE7hLdI0u7MwjaN UaWSo76XKZG5fRv6rhlGfgZ4hjrWGdq0ztB3/vyk39j5Qabzjg9Nfrw5LOjdHJq3PTDFHXznEpbn wGxaB2YrBNkvbH4HJauc2kQ/WTRuPjKi4hCVuIkNfOi4uFyUk4g4SZeuyR3ZUo1oB2KkRKFn8irp xzpHzywjGzdJO0A1yJab5uwHzyjB57kOMDgGnB/qC0RjZkS8qJ2srcMCS/AdnhQxHOGhPD/z0hTM jqX+5WQo7BIRecdC5G1C5Na3zGiwGCoT4rYeH3Fb8xC3tRQdFWSTEqWMp6p+uC41pkJarFfRfY6K a4x0woPe3pn61YjYrAUtiWst44w+H9vsx3KG7ouQLUTIXUJIwcgdwMNLdhZ4TKx07VJeZr8EIubo qVrAY+OmGqcaQVWrhbF0MbUT9EcsnyX+ETY6qagsvD017oXszRZx0SyNykNVQsqVF9Q78Eycz9Qq yqQG3YDxezEEVO8AFjY3LLK4G+5pouRRhWAIPXLwo+7FJ+bPsPeTk4u9H4dmoMK7T4PjvYv9T2DO 6HoMkufeUffiJxVTjXwyfHcAk95kg3CJzWrxOe57O7jfRL1dGa09b61ffJJd980588iNg8Bq5SdA 1x/3mgC+eS/w5EbHabVlDy37yTI7Z167536ZDoxe6JPB3znKF+eA4OJz6hpgl5oa8atTomrZUyT0 mM/8Cf7rXFiGB8fdhmJvQgS5WJMwn4Z3UfWwd3ixvn96fLZ3DuT8hP+m6JQe8IDu6cmcZTsrwx3Z Zvbo/IzS0Y8m0XhMJjVyTVkCBieFl/37Uw9Pz5FZnbzAaBeLcxRHf7bITaa6mEeXj9fyfiieNY3w JEbXQL5QmyaUxWmdbsZ1B3RDjhukPLX9XdkCZbiHwUv8vRGmnG32gJJ9IMSryrB88czhixTdGbAo DN3jy3OdBiYqzsYdlrPDirOF7ixX+QEdpG+xHzLNinv6QLll6Nt2JQROuKqU7k0PXbf8JmkIDOwB bIDjNeLqkuR9p30/rMIS1tTYyTIKX0firU1CJ1negaiBWEC2ePJAueVrUVbFZmP0wLvEQDADtRH5 DzC8eFwUtC5jcfJiz3JdtUPVDGn9za3OelNc65S7q+5U/DhpUOOtbpUMhZcvyTGNt0ZyuoJcOYn6 8AW6Lhq/B71wBQy+HkYxhgCh3TSROsWvePG0WXLTJlmkxVHYBWXEhThhEpafVkIX90+Dp0KU6mjD x+B1XK3BI/SDKhyWOvphCZlKdC1AJG/kXcryK7l4+kT27xgB1WOyw4pWJbXFR4pY2idGD1pJfT3A QeGQ5SxbKV8cYj3z1r34oDUqTqWtpmLpbEtNxrxXRvbnb4DxcXEmkmMDeSbw12W7iEDqyRO1BFWW UH8eJMxYCIuOgsVS4kkP2993K0gIaW56eLL8oF/xMtz4AtsvyYBpjIV47h63DdmPksmpuDTjRnCq imigLF+g3XE2cYf6JbEJm2HXPGPfUkkesfv46goPeer62ug+2RfNpJTUFmWJ5ZLAnWGsQwgM66dF IOnl+1/KF5CZ9Nx6fi6xJqZssX2gw0Mr5aGemHF6nEZTw2CPT/d7bhfxG9ZMFcfledlcDJ3rRxiT L8W3BjAGUPpiDzKG/pvLaKcqtQGCWep2TpVgYcscZnQ9LvntZVn0vebG31Td3oOfLMlObMV7iTNo 3rrfSTTv43ncovNYfs/8q6QglK4SAcG2tLzRbvHlv8wWXjoO8i6XneW5css22TQ3jM0mvJ6kszFa bkTyt1b84vz05Rmu7BArYHBLi5w1wn31DiVPUGlF8Lhx22SEb4v5z/YnbgQHh7398+4ZLgaPKrE7 fimVNApFDaXKKzC6JjWY56NdINWCm+Ee36P5+RAFGuCt1x5B12LZ6sk8bt2VSIRfiByvpSujb7Cj FqhZrj8yWbNpcmIrJpoG0nksvpK2oGZHJZg4KtU3fhtTPAZ1RLG15l4vpNtqo7fQjCX4Js6Y1Ukw nMRgcPIUmRYljoepX2PGq6lFEjFeGmvpoTCfpEOR/IFZyhvipU+h5niVlF5xhxzEAy/fJGPbc6nW n6RZts6RdtgPWTXXVChAFtsQAcTj3kDNQNhgefs7szZ1WYCpFHCSFE/CERKYH0v51OeUSyl5iOD8 YjbCWOl48IVOhcIc7AsZ8Jw8XrP4i1wfdiYV2SNqt08uA9rt1kEANBmTeikL5Z6s1YKWJJpf1XIt /vfFFXDx2SQuzlJPsD5Nr+MplTxm93d5JeSQWe7HTFi8HRMJlpO4WnWXJ+8Cq6PXTkfWRMlWPYyt Q+FsZd09N4CvtE+yu8bKYG2B+Ct+oYY7iFX6I8E5VbGQdzx3EoHDp7fsRolRlJYiy5WmLbiLFDhD FiInkISF49ODw3D/9OR59/z48OApc4zzw7OjnxS5BROgc9zhKjLWBzKmiI4hY4O4nESZZ3NVChIA o+l9aJRARpKh3JtECYmDR2RXMVPw0aXHPvDc0WXsHPhv4rhrwu+u9Tt43O91xq3jbVigwF25QP/K HXJzbI1Dsu8nu5lNMcND8eCrJ/OOfQ/aZZQlYt6xhwMnlWFQXaobYGkJA5NOUAgibgCKmVnFiVPI B0ihEBTnzGWQYTpfsK0VtKdR/Jp7y88pd8zGSMGmSmiZezbzx1IvZklWbKbDR1ITDlyOgaxMZ4lD yB15T+Kih5C7yJ1ErF9XJ8WPqPR0eMfbZAyo7iaGg0k6Jm8BtM8/iCBKBD4nwZRJn9Xow514aLSp oljgEYoQxQMDozK6wwjqITXucXBXiAdhlHrPggWz3MCLAy4PM41xFuDmwc0LMu7oPofHOTd5PrHE 4XHOTYHeL8/BnAOw5OEx54Y60UU5rR3TABeOUUAuG69ENFkEuX5V+JjiQvlgg2YLTSEmfUBFiGp4 cnrRfd7d38sxuNIX5tvOOf5dj66BItHDErFIu9cHwDvHVUysAFFdBV7SBOD4Q5eBRjnnH3PAMsYV y4shUubbpxKvHcF2xyOqX6onRUZi7oTdqfCejjyuRne6NqGcM7z2lPExdRQWJ6PgYoUZMOERpd8b cUIXUK7ZpIzgUDeA8r70mdeFdTGcmU6QYqKgJUY8NqFv6KKFAW/56PDOeoeQEA8Z4l335Pnp+TFt +DwXG2vf8fW9kwPLRNU9KInUzf1dL7Qij5rc3xW4PqqKOjWKmvMjB6EdPhc3btgLeH+qLGIZNkEL GZJjk5vDZ0rGVtZsrma5+N9D3JNzDmXH2WysfS5vofk64zyQbGXX9+64l3u9k0aT9tKa5EuYowQT dwfYh9llK7ARtnnDdcTb6GwgHiNTQ/o6iq9TJJ2wJuzEKo1s1nrlQkbmvOGC2l5oyRvsQWeJOBp6 kqECoZ5mUttWwUM8leH9XK9ApDF/IW5gS2DkZEPQOxH+8mfolLqeZOl6vw+iKayakq+y/arWbK9Z mTVqG3C8+lvr17cJ/BpE2ah5nA5mw7jWWgs3Pg+IkFFQeS/sHp8ddQHY4cXei1745Mn3Q86iSvbY H5+dnl/08CRO7qaYqJS+/gjgNIlAGpj1gVXGHxUxyV1FHx37xN+ye3B4gkT48JzGeotlfQ46SxaX 90yj4uXJIJoMeuKdcvhmGo/wfimjHhi/qzq48mFrDQ5hULEoelPoNVvu99FVswZ8K5g3oJzZWgfb TuY2FvGjtgnNozmttfGzto2trxdt/gLt5bUdfKc/7x0CVm0X2o7mNLX5Zq1J+wm4pfIWWujj/2HR AYkj9dk7vAhPn2MRXwZIYIkW0uAPXh6e7B/+MghzqllhknW7yd7kOiv0Hp6ecUqGz9V9hhjmPyWi V/Tmoils2LkTiS94Z17KlorryHOjnDtkPfDwovwczFJyb9NwBeDkpqe8SanxC1g08P3eFAWJwPaD 9DzOSeBluOJsVe4d4Ye2/6jNoMq6pFNf9pLiaiV7iAn0QIqpbTQazZ1OZ2u709nYbm9v7G5uNrea W2sh4DA+ZK+otcCWTcuRNTCYVdhjOuMAQT+a8lPseO/kJ1pCffYT9drnQdFrtLgXuRtWe5L7x92z 9WbjGSiLxzZFY45NdcqQ8ZGL5IGVaG6AV4LIn2+RG8s7KjWHJNgJguqDyNtFVNBuqLYdxmchgxkt J+RDiUD7Imo9UXAMnQAyKXau7stJZhhxmTWY1ymVMzi35+U/B5YPkY0ZgePOY0PyFPPDC8DJ38Wz EdYdvOdpTode6Mjk3hEjYEAuLjw7MSMQsmnXhz9q/jTEm+AXh+e19a1Wo7HVXiOEUx4N4R+1TAtA +K3NzTYyIeu2+t2hEQpRQfChylf1PAyeJZfDJL1G8N0VsjwHH+Ly5Oe4/wezZDiMRvXwh40wnmJt wkadZOWT+LVJgbqn0iUTigWh9UMS7vnZ3snhRT3sHh4ecgo+xj66mdREc52+qtuvH4OS1Nzdwarv CFP5OYsnw1uc1Hk0SKI6a13rF+kQlELYn2e6Xmpq0rTavVrEvI7DY9XDiUrZn9XDAwxygWHb6JCb paGVVATfxkWg8rR/ehzutOvh3hg0P2gMc2zrOe7dpPXwk3Tcn6RXkgX65ZBnTaylp0RETkWlIeiu fzxutDY6X7c2dhjqB8nPPkNTk5WgGreMt/aFm14sON7vodMSrRXIbfACROgu+iwNZgR9/AK+OpMM quRzq2bFCejclNzUEeJWJkFONRhhjTMOksWEGpJCLGnqJJOopQhEo4KDKuXHltBGW8tIMYkKW5kQ iXKv9YdRwmG8elrogjtSATqqTIv476nYKkkCyFTwznldlHFplYanva4FgAbBD1QRPGGTmaDvFSe3 ovsWUc1tqGM3Y87+iCuHR601ybWsACSzza2ODQAxe19Q2rth0k+mFphBD6QEjfL+ZYplWwSOg0YY Kqk+TMx8ncTSYlHEWjEqNhrzsuEuUMdTzlNDq26Hvbvby3SI+X4vLyfxq4QlHL6hiye3malWDBAU k02EWBkbBzZKsMsZt0HH64n6Uc+po33S61AE5jHqftU3/HGjtWvrvrtbnS1M6QMz6l68XLdabeVb bZuSH1dihMSI6xmi03B2O3oSBLcfaEf6u6dB+gEnAYyGT4P+B9qWg3+++QAgepNcohP40wDNRVai F8x3OCP8y/ophuBQ0Z5e0Ay/Dv+4/0U9/ONbuYD54/QLmtSYK/CwOz22URnY35ABiD3YQ2sGNIZM LkwoZ7H45CFzkE1s4XgwgnKlnF3pQf745Au0SKHqfsJHGWgxcD1dFRYhdDvDCklDLCPTH84yyggK okQ8BI7DCx0LPtxiUtdInbqMocoO5oiUnP2JjHZ2DQSZcv8mpbjmmk69igvKF741iaFO1ti9j9Mh N77zOCjQ0Uj4kw+syIanwckHiF7OVyMkednreKKh8DToXn+gQEdJp65HlIxRqnRzIk4kjOizCWSB 4inIK5Z80CWdIn5J0sALJHlCv8UU5CVZSCgwlemBWM41pfLRO5xWOcHDzgfaAI9xJzbVE2oHeAyb BTj1Uu5vmHGEBwfrx8frP4GfIPgtVodxYosuYknabPMr516JDxF6CvCwPndf7d8gUZ3ZGq5PJw5j AzFWOa4X160XR6uj/Fm4m0ssQBhBkeWmFIbS5w4l6GTChnRkr7AsrPuCDfpwlBTbw/bkTX2luKBv 1mbS7ZIN8R9QAxhsY4kl9uwTbQtfeh+JE2KVuHpoijCKGRN3aWDdB41nl8PFJs0zdut0lMwdIK6y oxuJJMlYzKG860UMeEH11S7i/g1FRYWY/DG5jmFsJyLqPrDIA4EIqNUpMH3PqHKxgRmrBd+V4Dco Jbz5dT2xjm0bLb8w4IBlsvstiu/y9AZnEkQwZ32RGVZunt5qLbCYTnhcKU0XlzRnOf1oHF0mQ8mF Bou6iiNWKCTJYjywhWsttadXzvAiSMMq/cvKrGsnYvZSYhRlBWSujWX2QsRuQrF0GIs0Hk1iM2cC 4wVJFSB6Yk2VQfxm9Zxa91SjVZbXVuWL1b2Blocs5W51tbl6LFdr2IF6fzVtNFfhp7W6d4274Xt2 v0VxxTRo3e3NW1pLLY2LD95jaarmIYylGt/yslQ9Q+tJer9FydxZCiwhuyOLsE1oX52FttVCu8Dk Fl/dqblOT0e5G95sta82UPlkijkL56kLD4qpSRq3Vw+MC+f85h2aqvLgcK+y8bU9XQrInZu8vrl6 KpkooH+WD/I95Af2d7SlOhrE4tV3z4625yxosV6CfvMJCgVwNj9uRrjzwAWBTsdYl+xrEBgfEcUi Oq0FBOs07odhUdkOyimyKkTtAXAK8GgxVlnNehzF6+uuszoXvi3Gm1dcj7Ycv1q8Dy3Zh9bHLdmH W70LVBv2azIZsYJmGB5rFxqk5LrCbRJbQnEzqdQddKnbodqpdoXIj6REwdP9nsIIE5iXw5DcoCIL adbEvhrU0sHb1A5YN4Hqfk6GprICnoQLIMpBKsJbHo8Fc4fp9TV5DVzpbNxUlhOBbHD2B6v9Nu9c W58gtXNpfuf2XbtWxapMGSXlTZKzieXyIG8W3EK2lmHhJWqDbFVOtnAtcmXyBQsmyS+MUcpo4ixx gJqHqj3ZpUqgwPXo5q/Cazdk/d9Nnu6IaEoBRR3N+PYpFzQ6BBrvEce5w2OMxwwXBq3qj1oIVgqR U1IqmYoNntqbwOc6I1qoBLUXja0G/LPdoBdfNHYa3PfUMnbZFR0SWHofeYRteM3Pfc5aLIsM65HW oiwYyQxdwJG5B0BmY79jliUl1JNbYqGOCQjYAx4W5Zgp9MjxyEETrgMjNF0lt8kwmigvXrU9ORiW ULcciGxIF7z1FwSSoWVeNVrnEmMDPMeUZYYeKwv1qotf8Lb7+MDkDF2FXZEoMwYlG+IKdNTbYwV1 NcRoc2dX3u420ETabWwZJr3KfBT4sv+FbXqhuVHgn6ur/c4qs+qSoXisZqfIytWgnbJXN/nVnbyw AINurjI/L3lzl95sFeUCeHVrlSU/l0435eV9As5+o7PK3HJfJEwuvACvb6+yvFf2+ia9viOvH4hc mXt9J/d6S7++S683W6tEFjnLrX55Z5V5XEd4XOfjzbx00t/UzwqSS39LP+sUnm0Xnr1obGop1LTb kXaeZyCgvsXJOa8+Oef3OjkVB+d86YPzQxTLzaFZx4qJIIKsrq+DYtuuOED4Yqv44rqRyO0+/EcJ +2gXzt96/+ikhy/3dyvOEr7rOYD65duK04TvbuZPoBkWaEL+OLnvbhXOoF5+IkWduKNm4WC5HW2X d+TCUXWVP2Rb0tkBbeNQ1fhZh9/4tZYcr11B8S3PEWpu6IfFM9Rs6ofqYKaNjnncKpwdI5ve/+B0 qw9O96EPTnfpg/MJ+uCm8J/tVUsJNT79qzWAftUB+gQIqq2b8BtVnOeTxu6q+EFQ203Z26bSD9oe 2tbs6IewuSAZ4G+b+rct/dt28dVN/WpLN2sXKaTyJ/gk505g7xL6EwSf5B0KSI2wKrKS2uK8R0pm qrUIUKpjlMSSjF1HIkd0KjoLOHqhJaFr26trhZqmZRaFnARZdTNoZuvY5l3zRKTdaekiqgGwWcBV wIGM7StAjxicbiOdncs1wtJVAXQ+oUTvaDvOWU+iyxlIrzQ3glXUR7pCK6HbVee6crvVKWR3BUUC 1mPq0opVXOqbhNczrmgolZVhhPk9siRdqc4YZUurKPZ9mm2iiBnE3luiXGCaNsguo52x4V3dzpE6 YXclUEZxnWz/RK7gtOlbwbpBeu+KEWV8fhax42WxCEbsPQhGzL3mxgl3SE8SIF8VrRZl9134KhAP O21tfiMi5ywXVCgqT63tQ8oS49/zVGxdJsHFosdf9l7MTwjssTZn5I0UtE22uou+WbROXGmJNQ/W rdnP12GZRdLKFSMrDYLVHpdSJek/Xn0RT1fRoxveR863ytUjqBHA5yC+Qh85YC/MwU1/sHnwEvxC yc5XtR5cjFu4so1tzJmjar78gH+WM/MvK1NSY0Lqr8IANjG9TSfjm2z1l61wN2yHrXA73Nz4fFU5 oJpQBDJ0pw3gxuvW/5HtLzIUpox+lpAJyR5qq/35asEltWyk9mKLSq0520Ntfr66wHI6iw2i4qSc EbYM3Jw1lS9pc/VLRwT6yuD6cIB9N9vhRtiEzre3P191XHvLutwq75KIktvrzucgg3V7e26TdW/P 24WeR3FyfXOZzia9k7M9pac7/e9y//Zzf+coYJkzX0M3ChSUB2vvz/89zv9O2VbhXpEGieEazlbt wKk/PHl5fHi+d3F4ULJLu9TvD7woIE7oLgLstM2Z2L84vOhdYCLEkt5BIy3F3ZcZ6utO160c7nKT kq6bhZmDnBJpr/vTqxO1EHeQjgxCjblt2RCtwuyxWjMcVfKcd7sFYkR5/8r6ahf6ApEFXZvv9Exz PW7xRIlh38YDFJF4S87kxZKh5OLyE9B8zcXlJqs9bxSnboWfsvmi9Cya04telYXLuvcn9R1yav9G PwKj9g/0sHzaP8YjsWn/YEUuLTGnhxTKdoEOVO5hFLZ6Us3ziqw6uI0BP/tuZ8JDz6LpzTE/9ncn Z7UNh0Wb/FQG7bLD2obDWrypf39a35/WBzqtb74Fp3XA6MiH53Q2Hc+mijMlsSuv7Db5sBVbqcHc EX2H2BkOT+1+mk3dUTZKj3S++w/NSXWF4venduFTGxY1l0E8jO4WQoj2sghRlL2twfzo0FoYHXYL nceTSTpZaCXby67EI49bo/mXsrXwUkQkd3p/M45HWbzQajaXXk1RPnfG86+ns/h6ijL7w4gJwtc7 Dl+Piq53hqt3XPpAbnrvqcN7nv4rJIF/l3n6e3b0nh19E+woYjZzRsG0br+LcaIPmRNthufKn0OX Oy1jRehUVXDxfs+L3uW9TetdMaOSkR743sY/yGPd2/hHK/KjPI533eubZkuYUO4Ox999kf/ccl6h gtW+ubG9gNm+yHCqScGzbrWh3sdTLP7o9ifmK35EC9CrtrqmX30MxeJWuZULw/0kHcvjin59vMOm trmum8t07WEchi3lOm4t03GRQzhg9iBDexlYeziEBWxP752leu9UQ9zT/+ZS/RfPoAV2T+9bS/W+ VaQnPyjSk8zca7o0pb3pHMuqkYqHs9CrtQrPhWpV58WTip0fR9lnOfLUygkAVZ0WDyl26qElzVbb TFeeV3QssVufNLYLV1HrfBPV8pQHeoceMjLmA/jJoL8fy0+2dwyl98R1tkUO4ij7mB56p/hAy8dV 9nnEdFI5oIKJK+89LkhI7Gwv5C60hU74BdBpKZPFRR1Du6Ajbbm0JkNJ/1bo5PEphxY3G7oRuY9Z YYA0c/Iex4at1QNnrp6+BDXgECwufm9/o/AoCP4PAJfyPoNPOo1OPrX3gx0Px4n54dHdIQHadRp2 z16Piq9CdUnAoVQgpxllTc6pQp9Wq0Kj/PtzcAF9GhN0NICRR339Rwlq9GaXSXGaXCwRVYz5c8St M1oerg+UgbTP+e8Jhai3t8bgRbQI0VQkvsiw/eZGCEKGxLMihrPegg6ewOWsgcIeVYYMVNZOeUX9 NNE3cpXT60tEHHt7KOmiteVKF+Ft/vXWqobWUcJGBPXyrtZ2NC/19dB23Pa7eifsrpooU3FCR18X nVWKHUUkHNDGqxAAu4uWno6BhqcrAEiuM5hZMi3vrWpeAB6GrtoggJBslsoU6XtvE4iywpuL+I0D 1aJ7XvH9Let9G+1sXbQUGgvp66JEq9g1BzW3P1chf635qBlauNmx19GycLNbhpvOT2suOpajcqsM EYt4OA+nWz6ETEowsgR5WqWYeB+8bt0TFVtviYqtt0VFbdCpwkSYu4qCdNCw2flcRYGCSEeEWZp1 F6CTm/ZC2ovgYjlytV3E1JiVx9CdInJ1B77O2nbo54FOSO7MaGcuWlBPsC57sNV5I8NC0uFAtyJG Cm+5CZ7NUr2waONRi1+/XSedxU5ryQFrE2o/zPGivpY+rFUT853V9TmHtZ07bMseVnx/+20Oa79h 4ua2CsFvDRM3V4yMa5jIuEK0csjaSMeUr30wSVslQX5ULVvHGoKIzUswwrVcKkj6luVl6ci8+Xby qBabZS4FgfmtpV03C0qrHdaAerfXClR9E6l65ytTkFgh3yb8u/G5BOcjOTZVFvyUPIekWxaus9xr gOm7YnBOB0u6mMmdzjUev2enp0eHeyfQMM01bK9akVZ5qpZoQpUfobVq1YVY5eoQZYvJv2pWs9Bi WosuprXQYhKzmtY9dtqUgbT3uvm5pEJozdvrsAifbWsVrWU3u7XoZrcW3OyksNut++92y97txZaz 4Ha3lt9unS6i7YmD39bPikHOSNI3TZWJh6TquvDMOyLsIGp+bZVfyZm8zIPlSLtexVuT3r5+/1NV m3z1l2grb1D1CvM41M+p5s1q7+xwH2vSrR+en5+eB94YLMw38iVtncp3TncjoS6ciMxE6hLSpmK1 vb39Q6uC3GtVcfD4NFS5vDEpFSZXN9ZgTr3d54J0OGlebubUacfw4GGsOksyFZWuKg8W619+hSlT 5DKgiZIJdEa/9fVvV3ncVfH53Vx8PibuObPi87uLhefb+X7eMjyfv6zMhluSt78k69w9g+9x6bT4 OfH3ztLd+PtTk6vfbfboEfgVAfh5GjV9rGD1ubHqBOHWAmUBFgHgOwtYp9norO6cUwB6YlJGsxZy JukHBGw2FadyCLT+VsUtTZdyoZPKr2Lj+2Wx8S7OK7rezQWEH3va5mm9t81yZJ/eUUSdzjNg020k pRBMiuHaTz4+WVvtZkqPwYg5GQ9xFAX3qDydJAKgKt21dG/n6LSuW9tkdwuktK3kvxeQOlP5+Qxd g9Ncilo/DE0OzJGkA1zooF0lyLdHHjBQdypVt9rTlrOne/YLS+2lKF/67Xnb6l25qSRHG213V8bN zQ9woS7l1T/ThTSXpk6cY5DvZER04r6sI3d5xzQitwLFvXglDnGzcsN26ajq3x3gy7yL8hJ/vay0 RG89yKXMPMO3colDz0keVZtHOmFz+/PVLxNiwzJTWV8Wal864OZf6QTKi9ja1bb4xtuC8TDHpyka poBRl4KFICoLnZcHVLj7MqY0Mci4ubbzVzqh7iJTmqZjNZt1PCtMn1SqXddrQ17RW79+Vnwn72Mj 7yQm6NoiQB205X9JR16jEwtOKP30vuJb2rxvm3R5qapTWQHdMCO799aGdA9COHKPI84hJjIloj6a anRHzL3N+FRjFvP6ykRUyuYuJhW7ZGnya5Ymb1Ua4a4n2VTIfKxdmaZl+UOu7aq5Y44vSYeaDtgI wpLeknQAe1PcDMHkP3qa3UN3ilp0lpG3dDpPUgasukyWBqEfmetdPVeLSnXe54H4tvgTt9kCtO64 hD6GO3GH8oy+UYO8WZgOLu5MvOkZ4jFciWk9W6uU7BGVc/vjcyc2ZLk7Nw+MD0wPkQWGMkTernJ6 Re5bMi0+UCYYSvfoHaA0f8mi6UvK5150XrxfChNn8rl/Vh8mlUm/2S5ZRNHn+B7ZTJSDKQ1DORnp NzUQe7EUfJAXyGlS2eECmU3ys56f2oSyRPabeMCam2bETebz7QIvr8HfPywmmn+zpq2kfC/ma6MS 9drPbvWzLT1Wa+GxtktlDZW0t+u15O5WPJNsp/bAtqDzJp/5VBoitypppyQi70MD4k3uZH5/HfsV e/apzsnZ5TvLxfrbWvAVy2KIclzRY1Akjk1H4nAc1ywpY/beDe+bcsOr9DC5JWLjcTCp9C+ht9TP sm549qVN3gnPgHAx75JCX/f0LSksCD1LbBeOdce1xNPc51iyXuUUUpy616+kso/CPLxuJRXeiIVJ 3NurpNjTQ/mUND0+Jd0Sn5LCLJbyKSm8fT+PkmI37pXn+txLT3krd++5XnLzKa3dy88C3hSvP8UI t+VeZApZ38qZu777F4SBe0EY5m4I8TB9x+8CkVO356eg61KQyNtdL2z7std9u24ZfvDI1ww/MPcM AgnvdUPY+i5cOLjd5i8edry5Cr/L9w9dChD6dt8+7Fo7sOvbgQe5hJhzB/Hpw0ukxo72tpcQ5Cj1 mLcQS19CNMlQ9fC3EF8FhcIonnsIUO+UkrztMdY3lZa86y1tg2fiV9Vcb7sDeMz1zY172esV1Xx7 uz25Yb1PB/uNGuybaHRubbwDk/2bR7fY+0Z4tNwfTYQbGnX5N+efh0gL61vMvZPC5jpbF7q5WyCN xmbW2iinm7BI/bBVfLNVeGgobjeXq64kB22Xil28nbhOReqKqTB/bQX2Aigcib3z3ZfYmy1/7tPv ssz+YZdSW3y7hfam7TPU9OeN/nWX21vthfnqu5LbW52FefCScru1/SWuQ4sMWUAiv/jfUhdMTa+z jrpLanqu0IjPtMNfU/n/fv46by//G1LR8RPs9xrAO9QAWng93tp69xrA+sLU59upAWwj3NBPh39T /7wRCpeT1B8kKS2v71Z7MbTIGPRAKWkLnVPx2UdJSOsf6kHS0fq7fpRktP6hHiYVbUnfj5SItmS0 goPP/dLQlvT+9jnRfcc9AJa/WWT5lnq6VSEQwIkyTz2q7U7xqfXublEQ0e+irLE5P017F++Q31bx 3fTkeH+v9kqZeVvp3f4VUHq3fAn9v9vXVJvffo13296Cbc8W/Lrru20qIf+t0nfbZJr9Tui7iEJ+ bbet7LLNTY+229ZxK9sl112bv7bXXTvf9HXXzvvSK990eApe2LS13/n6O9N1v+O3XW3012+joYB/ c/55Z9pumxICPZK2y52/E22Xh3oUbZe7fifaLg/1ONqu9P2OtF0Z7ZG0Xen9rUqueBVdoGZFZm90 1Xa7QhSAg2ueFvXc9mbxqfXuVlEEcfTcrWJZlz/Krf6n1O7tVd1dXw2ZX1tdNw8JR9ndYWXX/vku K76tjV89xXfrveL73Vd8v30Omu0dnNJjKL55grNIooivAuCrw6SfTDHg10nkAEsHGUerKlzZaIoB vUhVvlTvlaSLwI4BS/rTg95ZPj8ECGd4IHJdX1tdqzd1Coi2NgXv+jRtZQpuNZG9ArLCry3klvxr E0MX1a+F5Kp01n9NFfFW65u+d261fFLDe1X8nari6HjaeReOp/1O89GV8X6n9Q7V8Q7G0HdQHe90 Cv88YAW6zpZP77BOkVt2/P2JWvRE3b+IX7+zQ3vS77CrwRv59W0K+ZX3+bbF/KTjW9UtyQNvV8fP 2+Vbl/Dz9/p21fv8fRatDPco3Ofv+gFq9vk7fpByff6uH6BSn7/jBy7S5x/k7evzdZANbjblHzl8 m3RR9RYF+jY3sJeW/KN65fQwb1ehr6JnkIl3HZmYRF6V4kSVEPCkU9kovmWMTR2TgyTfBTxsVT1s m37zCVcqZtMpvmUMY53N4lNrrltV09muerhjP5S0JLvFvCSAL2YCVjqVXIEGTERjQXWrsmHT6TE3 3mbL6SanxXyIasxmPkuKkRDaPqnASTDSM4KB8Mz36VLib1vVMiZ2yxQtozfUz0MmS1mkYpknQcpb Zgi5b7WyYkffQK0yT76T6C3yg9yvPFSxm3vlB9laKj/I1oL5QZxiGAvYyPi4lFZS456WKqTmLHSx OmrOapcqpFZ4875l1AodLV1ErdjDN1FCrTCL+5+Q+xdQK3az9AlpLXVCWkuckMQckbev8MbdLF3g zVnqsvXdnJW/XXW3QlcPkX9rbmU3T+tl67oVJ750VbfCLJas6VaYwsPk3vrG6rkVZnH/3Fv3r+ZW 7GZpysFvLUo5uPU9cm+hurBllYVTekLHaz18X3pNJJH7l15DuDeXrrxmowYL79ZmFnEp37ykdJWN QiyV2/hTKpm5vS9RhCv34pyCa/nWCy1i8epbSrp8wFJr2OU9Kq3ZC12g0Fq++QJwWabImtv9PXd3 gQJr+eYLLWPJ7VVVpn6YqzJ1vm/V8iHTBJKKS76/wrJTwQ8XqztV2VG2eCWq6rpSdqf3Lif1w0Yr nFtMqnI9uepS56a61FK35FX1nOBd8i26f02nHzbacz3Y7EUpnvdDqlV0gk/kHjPvL3PigGI5y5f1 quFFb8PoTtUd+1uzNp0ucH3IJTosk/MWSkjQRYypu8XTT6njrZ22QyO3222kkO2vAukn2Ds5CHsv n+0f7fV6hz06yUjc+KJRSRFyhyk/zNukBZncJjFwhxg3j0Ert9JW+5bTPppNU1xcXxwq+rTdCPfc i61VMheUTgQJmLRIR0D1EA1Tq/AXTycrdGs6LmvbKsJ8nX09EGcd8O88LPhbHvAX2Uk1+PPt2yXg Z6jrXXDh1PKAv8g/FgJ/kY+Ug592uL1aSGLXPzrpOXBv3wPu2IkP6G0D9MyHau0FgG7Drl0B9Eqc bxvYlEzkXjjfrgL6tWocfGjorOuk8GtHczvFxE9FDGw+IAZ25lDdzpIY2LkvBnbmUN3O/TCwswjV 3czHHRdh3npAmG/OgfnmkjDfvC+p3ZwD8837wXxzEZhvFfzfNcPjOsHxwNmAzYdld1tzKO/Wknuw dV+835pDebfutwdbC1He7fJNKJE6th52G7Y922Bz7e0lpY7t+27Dtmcb3I7vJXVsz9sG2mqM7viQ 2RpWPw6MkaAOkN8NLD2bv1BWBvxrKxDXsQCgkpLeMoxfxcOwBU9byssa3q+HnaZqyx4i9XBrpx7u toM999vdHbddnNXD9qb6DhQtbtbchS53AoBu/waGpeHcNmxtq4ebu6YOFnQFI2Bj+GxSxzHwSc4t CR1uQ4cjEMHqYWuD/iTlENptw1+bAVoE8UWVbhh+34IPPGxBh+2OGQjjv9jMDy+27UJc+Hc93IG1 71gT6/E4HZhTZ0s/3ss9JtjYX6kh2ls8xza810bIbNAwgeoPVuJ7cf0ZDmUeUcUoWYzV0w78d3fD zIaaPXnyfXdCOb9wt2d1tN1V6wP/rOR7QwjmNij0cSYzgPOWoFSERpZwAOcxAWzcbIS9GNT1YZb6 mwR7z7uwtbDq4fBwNGBxKCOcg2+KVaTwUUc9Pmp2e4i2G/Il7gLAs7NLD1uehwHmeIEvg3E0mSZ8 YppbAcoDcj4Y2BOr5pagMWx7c4c3bRswa3vTfiv2vGeVyOLhZX+x0XGS0ZGCLzf0m0BkY4DMGVDc 1+lkAF224K3WFg2GDS4m0Si7TaaqBc9GNWrh+YAZbnfqgbygPE4RwrKMLV4Gnmt6GZbSbhMeBgp+ m/D9JoBsE/7exL/xJG9QB5sBmoyiSZIR5NrOKHGmaAGN1BGANc1IgOU0yuaGjNJ2R9nZcDpU3bVh nOkUmBiGOjApCPbki+fD6Fq+3FUtQVGYZhfp4Zt+HA+OozfJ7ey2F/98hizlZHZ7GU8AQryH0npO 4xZ0vd3kjZqhy9VUbrKecy0Oswl4nhW6wUaEO7AZZW9lTJu3ETU6uSaOQU/AoKAoYwVqwxVFonG3 LOjiHm4xZLea9WALvtuC97c6tJ/5EekGJ5tdrvuHQ/wKvMM1reG29XAhDBfQcJv5kdg7XPGN4uvB 1obuIpQunpVUnSVqtB/0I6AfGRoPk+yGCBV7pMIUW8QanAb4/MD28u2O+hNF/1q0HZ722nXXbe1r fGh8Zhfo+tB23l2gfaEh7ua8VuuyYMDiXWqMteMng2gK9BCEhj5xqqw7yjPDHdiHHTj3N3H/s2x2 K6QDNqu1G1zHI9GJEVV0G42w2xYhgd8L2wprSyb9WTJFkgxSTDwBbXn9QDGPoHvA8gOiYocIUCfY 5zfwERwseb9IOu2DuNPhJXDbIhUlsUOwWdrKKBckiZhx+JAosrQtEsCunDnE5DaphOilu+cgPWLq dqf04XpXFKK9YTS5pcvyQN2WI8u1Xn0WZbCtheZW62B7w98axc18YyBsbmOaqengCAXNlmcxm7km c6bUzjWnPsyXZ4ohgwgcJZMcuApP1z1LClxwDc8m6TTtp8PjCGXXGGXCJjCIwoOzJj5oFh+Ex6fy JL29nY3Ucg5HmA5Pdbdf+mzX+x6PtuF9JgPmH1rmI3y8nRsz9zg/rPUYjgkgPM2gNbcZT4bb4S1R 3Ds5I4HsFQnuyAVQFsLPlq+NS3DS0ShmlUfDzf3GbmNgpL6xIKNsb7qSFrJR3/eICFvYbRki5B9o RMg/sBBhMpmNAe2OemcHsNw+RV+ijLntPhSChESw4zzIzGskgmwxeUlnCLUuOipFQzJtKpjQA5Tg QInaB/DicMFBcLCHbM2I1yGK6vVwcIeaL5L3O3RfTq5BFQ0OgMhfRlls1JuBfIOsOBkIFKFf/B5L tT8bpkDJk1/EFnHcVbzaugKvk3I6iPvROJup3UCpD5Q0+DbJcOvGk7RPQijKne3g4BBI91blzGPN yQeBROMc9j6Jh8OUStnWUdE68H3f3GgFTvgOqr7w2XS/LaQggSZNt4nKLlJ8IjyhU+zWwXhHvlg/ Az0mmdK2wzN5K7yVOTbbzOeUVE4SeSdQEtKWkpADK37IWll5QhycPXxadiN7ZflnubXB99YcPfM5 iBHFIqTDPaUkI3rpr0GONSqcNgDgcjusGgDPDTqoW4EOGA9jsWI0hRvDPk+oL/wqyFlwC5rwbjvf hIy8+Qc9X4kLgYTPMJ9/P6+eaHw3LQp9Iw4hIFADRhkKoMv6r6sVy6nwasqTdDaNk9E1t1F/qaf8 nyoVkug0N/Mokq6gz4rkJrBtfOU1ktY4ug3HgDo8+XOKrbNP5JbmBfmH7rHoneExDQ7RlOWhGrEy AnQPMhH8tsl4BLSze2AkS/VdaH9pi5iuxcm2TUGHFE5yPVOyqwwhtU90jXG9w6zDQpvp5O48Rggm XFWbXzXCvj6UVfmd9MHzJGbyPXMOJdeDrDyUqmQkCkjhFevHO4ETISjz3Aqq8zeZ2fgSL/mfWrPV 3c+Zr5N9At/VX6kw3JBNgmh/A11FaQpKUSBtxDLNaVmeVRe3uYON6pGZYEeo8IaVu6J0Fjq3hUya vugedP0vPA+kdOd5nI1BXBEWD2LX62hCV5yaU8IBuZpE19qHhnbwReB4qxKl/ST45OBoH/A9uHHZ 4ydc+v0YVpqQcw59axeEF+XFGKbkYYiF4bWOs8VNkEQ7eg5ZbwIdXUuT6QbJwXN87ygeXU9vjJFL b5BsDtpSdjbIMuJ9AzFPSUc7TVAD+TENkgyGsZo/PjqT/2pq3LS0MtLIjG1BU4d2PSArCJnCmrvB UPpvNqF/8R/V323sYvf8p6YIuRV5RitaMTrYudsPiI2WpeeAtPEmsn/EjG7xyW6+ueSGqZOkbj07 fAW4c040ICu8yGfUN456gs1JFk0y+l4buhzT96a/VaaPXtGAe4bXSqDq8F4WhQNLdmBGVyJLBNKc 70Fwz82VyKavYw9ZR6uhmCcDZIDacLbp0CfqrIRIoJNgxITlXDjy2QExMnoyKD7Z9L3TI9EnnZS9 aT2nxannRgwYi8aCxXn7k+QWJZF0oqht5WFoMWoWrGoJcHHQ0qaTdHh28DIzKo1sbu55j21W5pkt HrQ3XTML0hNuWiehPSmXGDiKv0DN2nLngm93e6fhxTmwR5RycANhRdC39f02fY/Ah6+aGxuIwihb 7DBsgBDIE/T1RZSw/uxQ061t+Wobjw19gXYSImRopcOH251dJCjq9Z3WBv+5LdPFM4Oo2qqTyW6c 9LMQhQpitSgB01ttnFUTL+xAKJnd0iXfBhM2MqzTVYRMeKeDdLKplrxdN5Z+EbKVxR8QPGC9oi7W /I1mXSggiFOINuguCjsZXs1G+jYRZwsy+M9nCZsRs5AU7q2gd3Kw/9xeV5DNLqVgABxa4PvokIMX oq/iyTVa0wPVb4b8ima/xUul33c2WgxXWkaHwb3bbjL4O7v892aHW7Xt9eKaCMO2GLh8RQQUeIsh pQGNd6tAzidAGSZ4k8vnrXe63ts747PVYwqYv+UT0bbb0xbBbi+8sIyBSp+x7Z2bO8EPg5+h2jeh CROtUUb7pkFhmiZM6yg42juxr6YACMM9lUWgTiqivsvawsbw/7w2srkRDKMR2dialnpWIMSsrgXU k3qhtcwLC/ROJmzk8gu2z+oB2by36YUFZgNt24u2xc7b3PneiWFDvJo8FAHdvLBFBkFPjMBBO6LE oyZ1pmQIfiBvDaNsyjSy1RGBQyXTAnF9PqG27m8U1wvttYY9rewIJ/Qr35vBkTz2vO1ctAWjOILl T5mIMOEgIgSLSa7iKSlArU39h1GIA7bpgNrssUcRsQKqUmLxwRneEqFPE4TWZkC/rE/Tdf0N+gsg J7ZdBNp17SZA9E4dNJx2i6a92QhyRid5W7mv+M32QNwrnhcs94FrXnffXsB4v7NReIFm4X6tL8Mq TPsByM6+d6g759HB3n7l9VEw4pdaS79EIHBeI+RsVS3AMuTj8S59labkNDBXC+73Z9OL9MyzhB7h kfoeug0zEC+mU1KvgDUcpYCeBwkadq5nhJ3okkr0f4iPetEYvyAJu81fheqqKNG0IffAkA51gwSa 1FHvDLXeRF+n2bdrQYzSfDiYgPyFz5oBuWcN8AjAH5iiK7QMHPgVS0qxMCaQNbJ4NkhH6UB91arz lfxWXV/By+nuBOPZhFSKTvCLeJLm5IgmMy/HOwDegQU8m11dxZOemI3xm4Nnp0eqaUAWHIZd7wzY gdigT0E+QNBztyhRlbVQWuE2PW6VdNDWHRRaqA461Alaj7QhPNWd0GI3GTqk4jWppeorVJ2Fl3hv qcAhIFDinNphot2GbrsGq8LdqNtwRN4HWuPcUI2DYdO6BFX3o8Q4gRY3HcOzSNlb9L1lO7a+Leeb 0ik2O7RtXPrlQ9empL+vUvt0l+WNHPF/2JRrC7W5IIYNWz4AtLnjVh4A5nsbACIKVAoOVjMXAPRt A7/OQUA1r4TA/EYuBFp5CHQICsfiRSfy4cEkHY/jwfNJertHXk54WsVrxWkYF5vKsZJmOe8npXfs MBISxrPZo+DMQ2LyNp8GT2fOsvj5Uet0NLw7JrpEd4o5wVsUxsBcsGsA5jvw9K6pImlYQAbV165z VCuw0v2JGoGaT1vbSY/t5wDQ4+jNHvnwodNRi0X5JtJddiDKg1CBr1M3VqNNWJRf0tNeOgqcwPuP vR3T1hYfWJa3TT0ibZZY3ua9qA1wpKZ7B7egrfsCqvVCMy11DywYsyE6DygEGks2WpVv5jaUGqLx uYc8OuOTj2zJYF2LUe+42NZM0nzr6/9TNziI8Eb4xXF5C9N78alvFAcBsYPNZskjn8ERUCYoRRna YG9nVm98bnFFeNurqBfov7fuN4zpxuCPor98oZqIf++t+y0CRNv8eZdwc8xdKu7+rnUJ7F6J8t1j sY25kORbjnwL+3ZEXT4U2jh3EvoKgFvkLgS07Y/Pb6dl9ZMzCwaZub4EWdC5DFHAwD9ddKCvQ/ar AiAmI9w1LeDCqZCruiyzT5R2/SPM31n4vXpAR26x1jDRwJopv1R1wlv5+SxwqHVD73wZ63csqrEz 5xW3dxSC5Vo2Mfe2lutwZ9NpNM21WsojmaxiHq9kMjHmPZI3qcOTwBh3AEnEQj2xElLioQ9Gxo8Y z1JH+8Wxkdo8RwKd1ZVtXn+NzcW1Xn/njrEpDG9TmCvMeXfD29gBsGkgV7b1vLuvOya3QjG8MAI9 4uNid2GJA4EWByyhQ/o58fWza0GGtLHNXecLLYYjhPOFTuscN4HiE9KttqfJU6JnJ2Ly5AfFkIXm jnoVdQN08ppy/0jA68ayq9SrFi2afCKUdXqemIBG3KDZaarBmUjJH6Fv9ODkiHQxUHFH6ehHE5Zu 9tnZCEl2Jzjxfg8QtIwMi4dJBChL2WESc/2uAxwQtOCFHa5LnbPKHbMWuq5c8CZsQaNrIMEqCxtd rRfKtOZydXiuhmCszSK4IPdX+9hE75ufERz3jHUBZmLjgBM7sbWLcmPZ81hagERZ2kKc9kqee57O NfwGsBK6pyEdcdl3yZt0w3nLXEfzcgsLUg1ktrZZzgR82S/4hfuS3r3CeBEuCg2ck4lwYA1yXlvP uvnoAD2wkMGz4cVmntn1OFHcwKySoiWa3ka+94WVWO8j70Lht+Nt6FnPp/EERQfBjqbvme8tc05c tO/MaeZZhefMVXdl9gbxii6thIcATT0NJB2ajoQnJn0K53eqXUZ2g3SMnUZDllAdfn46Sa5JDBpd 58x5+J71sJl7THaBbdHytutsG9hlFi1yW/nrzhTsZq0FRlG8kVBgp+J1d5TZ9DpFzhaBSPcpevcS ddgJfC5QABffWcJuXo9gjDO2loqpxfou09M6Azo7GLBVeRt/dyzAHZIQMayKBNAJ+bjX+YoYyXM0 LLheC1CLj51lulFu+q+8dUJuTJRFl9Rd62VDJY88Jqs6B5xZ7b2chLvdrWI4WXFo2/uj6lIraLYD HSMQmgmHvquuQE1ci2i7vHCMb7N8ULer59Ht1d0LpxbJU8ankjZAHDFz28Lf5r6cAq/P7m613rxp uV7SnyAdobrJClDYZ41ca43mC0cRh54PXh7w7T4RM7zhP3KckIqOXXXbNu1zZMJO7FiYOQ4mgXqt u98TxE6HQ6Ja+Is4cZ+TlbOj0Hs3/8yFF0UfW2jcast3PgfOVj3v1TMWU2tZmKZ67gdSIK562ssd 3rM8+XCNIDuRqEm/z8YDWtxu4A1GwOlQZqsJqxH6UqmD7ekB0/ZMWlu3OQBZvuOxNKdNBqPeRDSg btfNfQ35f7Bhl/7BPlDqxTtSVB4CsbdUuXFbkyB9tGN9YV9y8J3FmQpdGE/PpjnrPUtmRH//IPiD tFeXENUAXZym8Ygi+tXdsiy33caWoa/FTnBeqIMmCil8djcLD1W0OPvu1tHeW2yC2l6n8L3PBz3f ppD0wtuTNxjbM1lyNrUGsczYu4wFbaXNt3hZeNwKzXWE/2ZwHkcUzruLjjF4HU/6Xp2MffyF8rds BaI++RgzbsqmQnrblZXIonK5CfvoXoATLOgWiXYc3PHrHdp0PVE+2NplTM1Wvg8d/4Ti15outOva UYBM+U06NEHJrdyEKyPhhcOPbpJhDGQVYcoCKk4rAx6s7oi3N5wvRJS0v3qKxEZ/owmN7ki7uaq9 dB441BAf0LU1P9LzIQn6KLlN8Jn5mtyP9ybXQk7UN/t8PQzfnBe+mQDbm2QxxQCYTSSkICfEPO9S nons6Gh0ppxynYtjQHzUX1le470gi8ZMKztBT/26i9829RGXZ/YX3IIDu1r0u8Ry0R8tWwril92v 6PWW9XrLvB4b9+xwHEt4j0WEeodHdTbtoKGgXWdPFPa3Y3obKHvHcTqYDWeZhYdynZQ5gei9z5Ix 80Y4A8VHmYibu/pZ/gp5W2O4IsvZzWyKUgauaTvoneydH9LZzGzzICCeYy7Ekwg455TWqZsbM5Tz tt2nDq6qojlsKJJIAfVloaVKWGK17VlfO63cl1l7PKgrFwijc+qneQcv2DZ5YIWVIONQNltbCGhX SkjSj+UKBjM4e46zCXrnxxyXQQy7LYdCLFoOPdqgHQsQF3q9E3mpojEhzRTE1kK8jP62PGKGsrDY kTIg5+gAbXQSNR6eJhq/Lq6nTab/7LQyDKcpCG/p9R3JJ9hCecS26uTpmvfpwu+g+0zr9Rjv2HO/ 2DUt+Ei2zRdyLvGbPjKecyfGgjKU3lFc5emIUwcJMex9us8Iry3YeFlrm6BJmML97wh49YxESjW2 CMCri2AqoYgwfxWVCDOgb0OkyMMZ6xdbWwGAcv11dBeqONdXKG9SFH1d3FAkF45wRWszWsHLYDYC uXB4RxZaFSirJcdNkTkNJ0bBbzfAqP+ckLlJX4aH+6eW++OnwSttH+F1ansJLFOe9T6LX2uuLN8t qBJIEIZ662PtwA7oibdwo5K+ijef5szlMzv64vC82R/LnyCa+J6d0dceVReBI5Z36yQ17YBX63vl gKheuTLpTLYZBeWORzVgv8VmMX5W9SRTCt17CW7uXgXUg/zo/ouK5lbwo+B1lCjxgpmIIIX1vUN9 5ftQMjvRgWJnqj8M/jCepHvXIJZoGQ2pV4voR/Dhy4N9OJjNRvvJVgv+pSDT/iQZT9NJ9oQcthRK k6LlZj4GLaUvG6EWw1/qA1LHArUj0WGy4tMpWgA4Mn5dXCnrPOrUum803Q+jOzzjTjA9T3DAoTAK sbMG6HIJsAQ00gNKjuB4N0GcwtLizTXaH+XRz4mPMbukigFoU1JLzF6sk0hnVl7kaYrp+ocgjHNm apQScSjMvqxpdmZGVincOELBuN/juDjIaa9LDm8hYjZMjXrDWf6EC4FeYjJsFaHdXPtK3KC+wpTX lL0Nq2Nj8uos/BLNEl9heme1Oqk2PMQ7IFgTiE5con6KGUkG4U08weLy/WjGqbbHaZag4oIxmzMi CpT0jWCRQlPFcWaYLkuloKZep6mpVsxiK0wljPqY3SDhhNZU0NuVNxu4TpxgNIatG09I5bWC9LTL IMF5SGoKVlDt36QpomQY5Xs0cCdylqlc16jAHlsKLFtmuREuRAFMTUjWcDueidgZDa/RRnFzGwJP gd2IJY02zKzL3gls6sWU2JwNXCI5MmgUTakQtfAUTLmtPbRhCQh1ij6WZD2UsFwARPsH25ziNRh6 uvLuwSu8U4SNY1RJRjBG+OXVJAbUUO6vAKooRL9SU/wbgeG6ZcAYz+44eGQk51JXC2/igIQq9gbn x1HbeMd5xhlvaVjZFM7aGsKWYWpwbHgToR/tEE7S4I7rtmuA8DsZTh4ngiRXpRM3Vg+Y9B69wFgw Skfr9oCy65aVBKWx1+kMdpuGJjCAVs3VvgcpnjBJzR71iUDTnGllXcHz12ko0iQnVMeNwMVG01R8 6+uIkMBvEJqckRYOEGx8/CaB0wCT4pzs6cgcHugUpobGjTs66nAMomuyAwH29D/DPl+j/kut0ymW PUd6z0nloxHxj4l5D4fs3/WHCKCu5M5P+/0ZprWwHPR4WjDeFbC1GIMChhzHhmrVJL2dhjg3kSuJ VNE5U9OEgxGHsxG5ozPCspM01TonpX+cTnFmEowABGhyjTgfVvmgaWrQ7YUkQmdMfpoAU1o4HKRR uBFmKR8pg6YboCWPcDlawWfCeT2LgJFMY/3FEBUQvOSml/O6G5YlBCLFCAATF69wtG0Tbaa0+mcH L+lUJlR0IMLTcTUb0gbEE7RhAjSUshmyxpjhS5ksj98bIA6ohUQqblLQVjlIw8AZp/LH3cqmsmeR HHx1AQMvTBTVDE9oKNp83S1n7gzlBsOQTJufE5l9HTMq3SSXiUKFUPwHhIqrcYigAw58NgKVNrSc eupqVGNck4N3iTijJh8ntKWGl8eK1yCtl1sDjK1PqUbkDfz3GqsZ1DV3tkpEDJLoeiQcYTT4mMot TNAEps60Ed9DkptoL5IGnJIMUdk11MkpFe9MpgncgFVfdXbPtaFPq+t4UvhtXrLCIGqPurRqGh5A O0FDk1PU4jKIW1TqYaCPhbp8kIAmmMXZ3oGeLJEPFGIG+G4LTv00Rhu2IroRMQ9Ce5RdZA3CB2+A DscTQJsfkUhg2MsNIXyY3agdHPMQsINwlDltzeVsiulbVVsVb5WpFutNmQxmeJXLOXysR6lRDgXi loM1Wu4PKZLPAgLSjgEJp5fMeZsbjWYjaAF1Fi7cRwT+mX4PibO8q2CQKESEDUD/x0SkWKAhRLiE OABa0+GMkYgzAxgpysuJPm4S2FQQfpHo69NUZ/xF0gwHYYZikmIwJuSNmRwbnIl63KKwAOL2XWgF fhKKg3J9oyRfl3ZE4fUEQEdkIsMCIPr62nc2gGjMOL+JnIURkkPVsHd4xEIQay2Ul3cDwXqSoi5x k75GW2TdENxZpnFHybKWB+0gjQX0r9JkIMOR/jBlyXnGsinGluLpJjRKKI+vKkei8jnglbvVM7Q8 3tsPa3Ro8SSt4UP1NB25MzKSuEWrlaA7JRwnHDEcQlFiIpL9GTAsGk9tHIJ9+Dq6w9hWskOHNRwQ wxP7HJc9BPyQUwi7T2mJr67WaJEOjb+JMs54HCFaXgP6W+OYfS4RKkkLneGSOS6P261LiLqA8ErR TaHZKLi9SgYo1Rzq3CuwoD6hkS9uUIuqTNJoVOjIfvv1DSKYvfW08X0uAqMkNgU/zhnGBXEAC2CW dHiRrBnm2+0RoG+EvyBPuaVLMDq+RKmxCc4IpUKWwmDZV0A9sfQNakJ0CPm0qsNT57MUKep3m8Du wmLTyTVqd/DSyV5vL+yNUXI7u7nLUPqUl4kHfdk72zv5KmgDJSAiikUV4uQVszLcXMQ7Ji1ZxHHX 7vElQdwSV0GyWue7bcxgQlxWoS9Kstdxes3pR0LK2YsEdipIPBsNk89QYiNWQ2MyNr2B2U8uFa8B Jg6zu0W6fIsyjTsd4vN6r81sJvG15EKC7SJcfJmh+KKqMJUgJaI9KgTDO1JGuG4RzuLYLnKk1KWI CkUp2SeZKtmN1AxEXSShpKkhoxFKxnhIA80mtLuiFNM4KiXeAEcUrjCn/pI9M9JaxnEfHXmIuXQv Xq5blco6hRJlW28PG7yfLwJn7zGBg0M+wK5+YzP37evx6Vvu5EOg+fk9AfLFWyD6eSlEzvMQuUpn owWhEe4PiUduNoLAPNrc2X3S2tjYCGuHa0Hw22d7Lw7D8C8nvxOYP17RX+GyP7/xwQcBTEgVIWB9 yR05xJFp4OC3w8PjZ4cH4afoB9I4mESv4Tw3NmH43/idb+vTmgYx1QfG6IQQFLfpzTTT6ioIKScp iR4aB2nXRaoTsUIj3QCZEpmhfsFYjhSeuC58j6xmhKE7EVpTyWg2SUHDCilahwyafXRtS6gwENLD 8Q1ZTcekHmGrBASDq2R4yyItCBJ86UrWWLJiTNjgrBmXMlBOGogBar370CWs9GYanl5doYm0Fu6j kH6WguwCrHNzC7/5ZL3ZajbDF/Ho33mFTXow5i9AWYNjgEbcEbvEOF/PgTgm4SQhtaeq0z2Z+4r8 PMdMdXH42yAX/0Eof/yT3wv3zveedffDv9z8nXAdaQVZCmzr0hRLVwyH0RhFIpIKL8R4MrfP1u+o tmiXwcMvwS5WwT7Y066ViUilKprbdxvne4DmGrYxwvYhWEzyGCySodLHPFcpY+Z22/md8GutyPaI +swmbAeiaSpxtNtb7/YWn+0mzpazDpMxWnkExsoRsEkxdnP72cJ+Dt9ESCqxI8edwliXdT870Hyf i4mQ9oV7IIV+lKZntvFZownNz7TlXYHhOVlSEIdW3v+8/3n/8/7n/c/7n/c/73/e/7z/ef/z/uf9 z/uf9z/vf97/vP95//NN/fz5lZU1+GzA54/g81+GTwSffwo+/yx8/jZ8/uvw+Tu/ubLyf/0LKyv/ IXz+AXz+5dWVlX8VPj/8YGXlCD7H8DmBz4/g82P4XMHnGj5j+PwcPv9N+PwL8PkX4fPfgs9/Gz7/ Hfj8d+Hzr8DnX4XPvwaffx0+/zP4/B/g83+Ez78Ln/8XfP7f8Pn34POn8Pkz+PxD+PzH8Pn/weev /KMrK38VPn8NPv8YfP5x+Pw+fH4An5/A5w/h80fw+Sfh81P4/Dfg88/D538An3/4H8L//oOVP135 d1f+n/8P+B/+9m+v/Nt/70//3r/5p38P//e/4f/8L/Cffx0+/1P++7/P/xEg/vaf+62/9Y/87P/z Gysrf+G3fuPlb/3G7Scrf56/e+18t3rzWyvm2f93pdj+c893K853fx7/WfmAv4bv/tFn3/sL+z/8 T6588r3fWFmV31c3f+tv7f8wXAl0K3oTH8mz+sqfx39+gPvflD2/hM/PZe8/h88/DZ9/Bj7/Ffj8 Lfj8VwUn/jn4/NcsvPiX4PN34fN/Brz4v/wFxpO/+FsrKx/C5+e/xTjyNz5gPPkHNu45f/wHi/1R 3oHzx99/2z/Ke1twHKfZn5b+seB6Fuwt9/OPwP//C7+B//lLf/u/9Bd/E//6c3/pb//fPuBv4L9/ 7V3vP9KHP4bPvyHn+J+AM/g34fN34fP34bP5F1dW3sDnX4bPn8Lnn/hwZeVT+Pxt+Pxr8Pn78FkP 4B34fAmf/zV8/gw+9f/Eyspn8Pkfw+cv/qWVlVP4/NPw+Vfg8+/AJwTMv4bP34XPb/6nVlYO4fPP wOd/Dp//CD47/2lYI3z+V/D5M/h0fhvmAZ//JXz+AXy2/zKsHT7/Jnz+6u+srMTw+e/B5/8On7/y n1lZSeDzb8DnT+Hzj/9n4cjB50/g87+Hz38Mn+P/HNA0+Kz/FYABfP55+Pxb8Kn9VaBJ8Pk78Pnz f61iK+HnH8LPP6Af+o/6Q/7kv/V3Vjv8j/UM8eLP/Q58YCn9b2JP/iN7UQsee+ePP3vQP96663c1 0fssYeU3f2cl+N/+5spv/Hv/xb+68pt/Wf8ulOEfQx74P4TP/wg+fwc+/xJ8/i34/J/+/9zaB2AU xf7A8UnHABJCN6EoEJqK0pQiQVBKEJDem4CEohQRpFelPFGaVJ9KUwSkKQoIEjpJgNACIaGEQBIg BUIkhSTkfWf27nKbvdMY+Ov7vzs+v9353WW57JSdnQsSkIi7uIcklKD+S+IlvIxaqI066Ibu+ABj 8CHGYhwWYwm2YCu2YTt2mNrVKYTgNO4gDvFIQCIeIRtlaGvPwAveKIt6eAXt0QEd0QmdMRCDMBXT 8CAxTj6va5uL2uaktjkkw37s1MqbtM1qbbNMmK/z3V2N1+jLLsZcXxu5KGf784FBzsb333Iy5obZ yCU6GucI+qu/9r5RuveJhvKcTMcMzMRSLMN27MCP+Ak7TX39DM7iHBKQiLu4h6RC2lhQiL4vv/d9 GlVRDdVRQ44JaAxfdEcP9EQv9MYHGIPP8DkWYCEWYQ3WYh9+w34E4ABO4wziEI8EJOIuCjH+FEYV VEU1VEcNpD2QzzgZYnHFvHNOeyFQ2+zXNju1zSZts5pgaROvuxvr5PBTxlwLG7mgAsZcGxu5027G XEddTt+eLujaqa02IXzlOWiNt/AuBsMfQzAU8/AvrMe3+A4b8D3iEA9XxnQ3FMBTcC+ijfcVUQkv 4EXURCv4oTXaoC16ow8+wnhMwCRMxmIswRZsxTbswI84huOIwg3cRAxikQ3Btf4ZeMEb5VAezdEC /ZGVkhWfkiWfUdomTIbzPFOygrRMgLb5Wdts1jZrtI0aYrWzLVtV7trZXNiYq2kjJ3ta7lzdQvZr dldB4/sb2sj9pmuVue4GZPD9J+ZI6dbXpzwWku0W8nOA/HyCf6Tw2J/a9LC68utmBN6yD7yDARiE d01tYDbmYC7WYh3W4ztsMLWRG7iJaGRD0EYc4ARnVEJl+KIJXkczvIE+6IvxmICJmIwpWIGV+Ak7 8TN2YbepLYYjApeRglSk4SEyUIq2WRq1UFu2U9TDK+iH/pjoaZoLxOKKeeecdqkP1Db7tc1O86v6 +YD51Go9rainsfctKWrMlbKRW+lhzJW1kfumiDFXUZczjxL2r//f6kYp0Vieh0mYjKmYhm+wGr9i L/ZhPwIQgtO4gzjEIxF3UYwxoDheRE28hFqoja7ohtH4AGMwFuPwFb7GbuzBr9iH3xCOCDxAClKR jocoyThTCi+jFmqjLurhHXlzg8mYgqmYjhnYUjwP88DEuN3aZqu2Wa9tVqmq187l2JLG+kgvYcxN spHLLm7MzbCRc7GRm1PMmCuoy9mv/8907VS8Js/FVgQiCME4iVNIx0MU5/OXQEmUlmM53sCb6It+ 6I8BGIiJkL/zUizDcqzEKuzDbwjDJYTjMq4gDfL8FeO8FkcJlEJptEQrDMBADMJg+GM5VuBH/ISd +AW7TNebkziFENwuKed8cdoM7rq2uahtTmqbQ9pmt7bZqm3WqwkfjEOr/src5xlj3VwvY8wNtJGL LW3MDbWRSyhlzI20kUvWtU+b879G8nzcQRwSkIhMZMlzzzFLowy84F1KW9uojTqoi3Z4G+3REZ0w FuOwEIuwGF9gKTZhM47iGI4jGCdKaWslEbiMK0hFGtKRiSzU4Hw8j+ZogZZojbewBVsRiCAE4xRC UJDzXQg+ZfR9/0qczVFfpm3eBRrrXzvXzcsZz39gWWPuLRu5EG9jroONXKiXrbFee62b15/Vtfa+ CF37FI2exJpVf/wLgfDhc7+NuTiIeFTmd+6HeYgom+cZju6V/LztsX8mP4Un+ys89ttMDzurQMJb 9ocqsk5RA8+X0eq7DuqiHt5Ge3RAZ3SBP4ZgJmbhY8zBXGzDdgTjBE7iNM7AlTbjhmfxHCrCB1XQ EI3QBV3RDT3RCx/jE3yD1ViD9fgWUbiBLDxCNhxpi07wRRP0QE+v3HO+P5rx2V//2fScsW++aCO3 /Vljro6N3C8VjLkGNnL7yhtzTXS5P5//HdKNU6KhPCe90Bf9TH3ZH0MwFLPwMT7BXMzDd9iAgziE wziG43Cmv7ugPCrgWVSSY4C3Nja8gBdRE63gh9Zoi3YYDH/MwEzMwmzMwTdYjV+xF/sQgAOmsSYQ QQhGNGIQizuIgxNjjzPKoTwqlNXWf5Lkmo92nb+ibc6Z0zbWf2TasgJkaROLfYx1U9JGbkVlY87b Ru7rSsbcczZy6ysac1V1uT9qE8I3P+N3CdqQL4bgS8TKfdrhYhzF87TdUTiFNNSgzQ+F7A/p8KWv zMEORKMXn3crLuISwhGBq4jFLaRxjtLRswrvxxmcRauqtCE8QApqVOf/x0IMrSHEMAzHe3gfIzAK ozEV0zDoee57kSW/QrH8y8hSW1PQNhny3KU9uH83/nbMjcgr4RfPnzkVfPzIwf17d//80/YtmyzD rWvh7OxsF9f7KiYTHV1k9r00WR6h4kgVR6k4WsUPVByjYpt0GXeo+KOKtx7KeFvFJRkyfqFioUwZ C6s4Q8WZKkZnyRijYor6HKkyOjoIF/Xdj/wOSDSVfaAiKqExfNEdPdATfdDXVP+D4Y8hmIlZ+Bhz MBe7sQfnEYoLuIRwJON3PE1bKQIPFEPxclp78kZZlMOrqI8GeA2NTe1NzrFaoCXewQAMxGD4YwIm 4gssxTKsxCocwVFE4jqiEI2YcmoN0LQKeAtXtZW989omyJwOMO8Y1wG1XjexurEnPqpmzE23kXO2 kZtd1Zhzt5GbX8X+rNBD95qN9b8mf3d/zs+Exn4hPz/zZA/wZA+t+5l7+SgYHup7Pie7639esv23 oI5b4h0MwEAMhn95rR2MxCiMxqeYj8+wEIuwDuuxHwE4gMM4AvcK3HuhMnxQBdVRA+3wNoZiGIZj BEZiM37AMRxHIE7gZAWtHYbiAi4iCfeRjBSk4inapTsqoTJ8UA3V0RKtMODZnPV/Oz1fv/p/K+sP 1v8HvGjsmzEvGHNDbOTinzfmRtjI3a9hzH1Yw37/T6v+J/3fV56DgRgEfwzB51iAjdiEzdiKbbiI MNxHMn5HKtJQlr5fDq+iPhrgNTTGuxiM6ZiBmfgEs7EACyHn1ZvxA7ZhOw7hMK7iGiJxAzfl8RlP GqIzuqAreqAn5uMzbMD32IgfsMU0Nj2J9b/jtYy10dpG7tTLxlx7G7nzLxlzXW3kwmsac711Ofvz /0hdKxWvyXPxE3biZ5zGGZxFKC6YxvEw0xh+Gbu5qoRU0eZbZbhyeeEcQqtpcy7z3OpNfkc/rMZ2 XEECgmozatURIgPB9ejTWNCA+wpsQHAj+jpefo2+jrSmQhRoRn9GISzHRmSixBu0EVxAGMLh96YQ vdEX/XEL2WjVnLkN+rUQYhxO4BRuIAsdWgrRCRlpSWmxSYQokSQixeULPMVZ9uTzlAg+GiwOBQcE 7w3etWPXZvXcYZLzdK8n/8quqKA78rnZaVndQe67mZJuptedm/l5CqH9ZV6Bl/x8hEzKclHzX+p5 W/6az9Zf+jlxnJy/BdTq+M3af9LrLWuW4o2/e46tZtDmR8p/V+F+Pgq6A9x9ooU7eXubrqA9nNVF v4mP+ervZPX3f05yTzg5qIzwknVSiTGhMj5lDJmPZYw5y3GUdnQMxxFYO6ffJuE+kk19uENd+hF9 OAQpSEUavnpFiK/h8aoQRdEP/XEUx5CIu+hRnzaHm4jGZ4wBnzfIGRMy01OS7yXciVV3XOdOnww6 cnDfnl+2b/l27b9XLvp8/rwZU8eNGT7k3ZMurq8+kvc59YlFXKOIBZzFUw7unA7uvW6o7PBsc9ZJ Zd/LltkwS9ZRZS9Z7theyJSvL8o0v+6gXl9M2d01ypyVR1fv68TdVoFCOe/rnCXfl2HOkslU92NZ MuPoKVwr8aHIVn5kKq/OVuU0y52ai+s0bt7cXKcTn3LiDi9F/vyGVBm/V3Fjqnx9U6r2+maVC1d3 iREqRqu7xBgV26j/va2KheR/VfXvrP9M6zb6/7Pw0Lqgm60n5eOVPHZ33Su2VndzPWi47j6iYPNC Qshm6OAp3FTPV7P+SI8A4eBgHhmeeZx+mftaXQsnTdfsLo2Zj+EqruF36w+YYF2w/8pNu6/k52j2 X9EVouy+EmlduGq3EJG3gv0D2C9YHqbak39sQe3K+hQFzGO+uZZz1bm7Kqp24Wx5jyjzV+uxuy/t AnuxD52aMLVANGIw/HXmAZjEnG1yU23ult5Um7OtQDYEc7SjOIY2zMvaIg7xpjman2mOlpl6n1H/ 5rXw0NPBRw/s/WXHDxvWfrViyeefzv1k5rTJE8aNGfX+MP9B5nPi4tr8dzmutVBxnYrrVWz6QMZm KgaqGKTiAjWWLlQxVcU0FZepMXR5qhyTiwrXYozGQu0Vt+xVTDfvVbLsbbTsbbLsNXxo3mtk2Ttn 2Ttv2auXYd57xbK33bK3w7JXP9O818CydzBTXTMOqVW/Pmps75tl+uyHs8zvOqLtcY25pV1jbsuN z99dp/0RI+fb1s35v7mgG/H/BwpCN3qUta6TWMzg/mcmSrQSoiS2YCt6+nFPgKKthfDEFmzFm28J 0RzxSMDyNrQJTGxLe8Ev7YTYhbZvC9EOKUiFS3vmHPDBRxiP2ViHQIThOu63z5n/3bx+NSIs9GzI icCjhwKYAcoV9w3rv/5yxdIFc6Z9NNJf/m5FXCvJuVxROQdzUeUXLGVnVW5kKTupcn9L2VGVp1jK 8uLp7vqpuUyfma/W0a+pGEl0d3QULg5qmV+Y52srb8tXX7+jRh4Vw1S8pGLxeBlLqJiqYpqKaxPU qKWiX6KMrVW8rmKUilPuyjhVxTr3ZKyr4nUVo1SckCTjRBUL35fxaRW/V3GjijWTZXwpWc7//ol6 /x+YBz7ZQurjFnRHs/E3SurhINundgfo72AaA7zleoes+2W4gWh4Uu8+qIrqprawHwdwCN1oD0Mx HO/jEI74ae3Dx9Q+jrTW2kdPU/twom0sw7Y2Wvs42U5rFwPtjAlyPPDqwDHQAq06CjEaH6BYJyHq IRBBSEAiJnemHWIF4hCPVKQhqgvzSUQjBWl4o6sQHdEZF7rx+yMao7rz/+NhinzeM7mT8tD6GRMZ ExkeJkLPpohTKSImRaTEyBiUcjgg6GzonoA9KQGHU4g7GFPkak47P0fRHv4FhLtaz/FQa0Ou7Ks1 oro560VuzfyKqTUiuTbE1tm8JuTBebT8fAVtbalezrHcTDsFzetI8r021p6s1qaa/5VxWHTQ18kK rMR6bMcRhCEZZTvq6ywYJzrmaql5/FYkP+sy+Snk57PF/d8V8vNxzA/XnNm+p65U1HT1d3JU/d/r SdXrNTyy6puvYC7mYR125+qrLeiTLWX/vCu/SQ8/G3Rwz46N61Z/teqL+R9PnTR+7Ej/fj0mje+a 69dycZ2Zc9WVSzNcr3vI63PxnOv3CEtZu37PNZf56Xnqyn1ZxSs5R7qpHam1fGexnCMNtZS1I002 lznSFHWMCypezDnSlix1pEdyPcdT/qSrOlLVbHNZm5M0s5S1OUkXS9kp53/2zPkkYy1l7ZNMN5f5 JDPUZzivYmjOJ7n8SH0SF8tsxk0dqZilLD+ZKP84ddcH72N0Z9tjr3m8TbOuQvsF3XUrj102j10p P4fWrT7ksaBbPNAd7YrdVy7YfSX3w62IdvX2diw662aWiye38c7cxXNld9T18RK6UnF9j7d6pZgQ pf9KPTbrql0zwxGB17lWNkVoN+36OZdr5jwcw3EU7iHE0whHBEb3ZMzAt72E+A6bsL43ZXzZR4iv 4NGXuSbew/vw7Ee7xMP7d6IuXzp/Rj/3XyMn/4sXzJ83e9b0KRM/+nD0iOGmc+XiOkzd4xdRd/Qe Kg5X8T0Vr6l4XcWL6n4/TMWz6q9vLqh4UUV3tYpaUMU1Kq5VcYRaUR2p4k4Vf1YxWcXfVfxO3ZNv ULGhujNvpOIaFdeqWF+tWTdQcbmKK9RqcBHhulDdV7guyjatDt/UytE5vXxChurl3eQ7SuSMH70s ZW38GG4pa+PHDHO52t9dr/Z7vP1X8vi3D3k8mv1Cfo5mfzizfzRd4fYTLfBwM83xDzoUndX4kXnG 7+2ojQJulrIcQ4TXeFPdfoGl3bV6fQ4VTXWbIOuauvXAKvwbmRC9cup7A77HERzrpdV7YG+t3ndh dx+t7qujhlXfnoTJVn28JnxxHQ+x5B0+F9Zh0wAh9mHPu0L8ingkYMxgIT7EWCzCYhT2F6I4PsRU lBvCvQw24BDOIxS+Q4VogrfQBg2GcW+DcQwiHyEjNSkjNSEjNSNWPVMjI1JDKcmQlHEGCSHimDgc Ig6IAxEHIg+IhJBQ3rebZ4j48UBGrCyFyDqxnvHnvhuwnt0XkdHqNSftLsAj565Bu0PI+cZX/+2u 9bfO5rsI7eeK6e42zHcCormtsVbWQ2NTXTRDF3RFb0zAREzDSqzCN/gVe3EQkaY6TO+Xv2u/7isO XTdKtC7Y7wWBC/L2tml5e9usvL1tSd7eZl3Q/XKmRwXxH/bOBKyqau3jC4gjaQLiPCWlOXVLb5mZ mU1PNl6re8sy/cwBFecBNVNzyHlORUPFKVEEnJWuKAo4ACogKqA4oIggChoggiLD91/vXnudvQ9s OiHa8z3Pd+i3XOu/1tlnn/Pu9a5x71idZjZ1m9nYrhjKHBLaMlvPktZ2Oc7MtMKuVGFTZPVSmrL6 i2Pw1R/R6ssVH713YHUr29683tr2wTFBW9ABDAcjwDiwGngDH3ANpIAbwB513AQK8+7euZl69eK5 M9HHj4Yc+H3XNl+fdatWLFkwZ/rkCWNHDh3Yt5f8olXslG7u03Y29lVNBTLGe988r0Qqb5WosQ9K lLwuUhkiY6NFnodU/GRsl8jbLZUrMnaD+t7p5lb5Fd5O89KfyzLDZMxDHGmMVBbLmKfIWy6VHTK2 V+QFSuWMjJ0XeYlSyZSxLDq7bPPZKb0Imq1kTSvDZlXBy6ANaAf6gL5gIFjWV/HjVs6pX9AOessp tte6Yo1srCq2wChHX8zHumJR1hWLtK4YK/1yLcNDzCAPkVWGhxheykPY0ftpbbi+tfZT2+FNwA9E guMgGlwDKeAGsEEbbQtMoAFoCJqAduA10BH0Bf2AO5gJZoH5wB8U3MvOvJGSlBgfeyLi8MGgvTsC Nm9Y47Vs8byZ0yb94DF8UP/evPOhXNlV5TXuJK5/Z6m8JGOviLxXpdJDxnqLvD5SGSdjE0TexDLq 6TKR5ymV7TK2W+TtkUqkjEWJvGhr6ulkZcUO44B/FQt/0lV6tAkyNkV4u6lS2SZju0XeHqmck7GL /KBNn4RtdXVftwFMN3elW6DXJeLcrSs2ybpibtYVs/JD91lXTOtjyimm7URoX66l6vxm0SuYUUad /7NeAc0Y2Dhh/K+te2of+xAIAwngHLjIbQiKuf3x4zUADcGzoBVoDV4C74L3wIduVnu0c9pEvDZh fIBAb+uKjbGuWCfrivW2rphhU1Km125t17FG2f06Z8dSGuyl9OZKH6nC10Ltyra7G+gPBoNFYDHw BIHgdxAEwsBhcAxEgxhwBqSCh/eyMtKuXT4fd+pEeFjwvj3b/Tet9/516aK5M6ZOHDd6mLvb998J 758oPdll4eWSpJImYzdF3i2p5MjYPZGXJ5W60hs3Ep66sVTelbEuIu9DqbjJ2CCRN1gqk2Vsmsj7 WSoLZewXkbdEKua+5zaRZ25jYmUsTuTFS+WWjN0uEfNIdxBholVxLxRtSQb5/8qwWRq4BUoA64/L CzwLmoCm4L3+li5giyZRjqewrqJfaFupxXpbV0zbOpRTTNsklVNMO2A1LiZero/qSZ6S9b++tfZ7 H3wExoJxYCJYDzaAzeA0OAPOc1uDh4ANYOx50BS0BF+Cf4NuwIPP3YDxYD5YABaDh3nZt9NTrlyI Px0VceRQUODOAN/f1qz0XDx/1rSfxnuMGNy/T0/6CsoV3qRIufpdi9Rr/lUZe13kdZDK1zLWXeR9 J5XpMjZH5M2VSoCM7RR5u6RyVsYSRd4FqdhLv1JVeJpqUmkrY6+JvPZS6Sdj7iJvkFTmyNgCkbdQ Kr4yFiDytkolTMaOibxwqv9PyrZXtKMiXRdAl7iy1bpiR60r5mNdsfXWFQu2rtgc64r1tq6Ytnui vmT9dX1UT1BfrXerwGqwAQQNUOZZw0DGAGWu9S5oMhC+BzQDHcGb4G3wNegGvgMeA0vPyT66e7Ry rBxrXbGh5nglFBtvXTFtQtfrNe4CW7zkHJ5r5fn/eo/b9nw+PhWkgbfQZnYGxaAE/GsQY12Br8Xc fEFedmZ6StKF+NioiMOHgvbuDNgsFvrmzZ4yacyoQQNW9la/iujV8CUxZm86VcTvwmgJz+ZQ3XyP R6tirv4gVVtSx5PaoURVbUh9g4+/qTdGKpQlNC5PoZBPnan7/NrTqt7rhaKVKVT965cy9rXI6yaV oTI2UuSNkspsGZsv8hZIZZ+MhYi8UKnckrFskZcjlaqyLXIWrVMNqTTi0wvNKmoj7frJG0OUtRN1 3WTsMNgf+A7He0AeqDaCsWdGWL0jTrce8BhzjJcadMV09wFY+RUeY8J4m5D6wvjerrFm1Z/fIWAy r/xXV/cAN3wUW04AE8FLIxl7GWwD20EWyAbPj0b/AMSDBDDQgzF3EAC2grcwQu8Mxo7FZ4AXxjHW HLj/wJg3CACF+bnZdzLSU69duZTIb/06Ghb0+56d/r7rvD2XLJo/82flLgDeIRGe4Jkc8gSLaDU/ llbwT1M4lZ6iMe0Br/X7ClC/nc21PqiA1/pPHgoVyqe0fr+IwsUP+XtcUascnMz+47lCrp6VqnKk uEJ+JN7zIxWKqZgf4yMKPyafE8lzHc3vOV7M38PnGUmFMom8zS0KM0rkjODuAvpuDemsGil3dJEX 6krhp7Sf4DMK59LnzaNwOh1nBo0GG4vRoL3pD/5PC27j5QAtCdl5AfAG9WHnVsMVu2ttzu29eIRi 74+Fndkoxc7vCDvbCPtGeSj27T7GbF/VrltBIvgDPI0mtCFI+xHvnYC2aApjG0ECSAVFoN00jEPA +6DtTPQ3ZzE2DAwH90AeeHY22inwAnpg74MTIIn3xubiePMYuw7ugJ/m4zwWMLYGdF6Max98AdaB 9eAYCAcLl+I8QRDYD3osY2waiAbJYIgnY9NBi+Vos3KzMq/jL4tdzSrQ/Wmk8/jLRIoTF3M1Kxd/ mYDlZl3Ff1BYTBypudwXKSu39dTVXNoLarl6rK7yWq4cq6vGcs+nZvVYs0r85eOsx5Xr3o0TNyo1 55phzhnDHO1wxNqztnhVN3tnZ+Y0Y7199fAqNrG2NuvtTcxJn9fFvsaMeUUiv4u9yZ6ya8xwt9Ee xQklY215KXcbFDRp/b+j6v/rWPpbXi9boB62BOsnoU8IpkxmbCooLKMudv2Zsc/BjumM7QRtZpau n3tB4KzyfgvdOsDf0qTqZuGNT0d3X2blfmhF+hjlvtAHMO8RtBfr/nvFHLKwf4PHbfMEcE7453yN j242R/HTx4WfLtH4aR+QIvz1JPhq8/0/F8/zPkDE0bAD+wJ3b/XbsJaPCvgN4JN+HOcxxPzVnUw1 ebtcx9xa16IW8j8UfkVhPrWT92nE8FKxWlppkV+mFvmMqkI5Sy3peWpJzXeH85VEJ1opdHjV/O6J NIbwVlUoayzGEKI9/yaFWuKn6HzsKZxBZzWTwlT6TD6XTbv/spV2O8f8/jHppKyjvs56ChtRL6cx hQ9pn2IhhWPoWGMpNK80spaVZSO1TV0LEsC5BZWw189415xuI5DOl+uKGefovLyV+wONj3bVMEfX Zug+9C+8NF49hPG9e8KrN4JXt3HV1G2tj6+j3P2tjPXNz4LQlHiVsTpGtqu9EJlgBpgJPl3E2GeL zP0ly76S2y+M9QerQDSIAc5LGKsBuoFvwEVwCeSBfPAB+lRdlpr7Wds0fa3v0L9C3/9ORuo13vE/ ERESLDb9/rZu5Qre85/0o8ewwQPd+qBu0vWs7IC/SmGyuY7U5MPcqjTT6xCp1MYeRbx++nElQlH8 SeE3yzqEK8ox8gsfS7+AnxHqJ+QXFnP1mFLuF7OnOKr1FCY6jzcp7EThBQovSt/xbT6NRPLVT1Dm KoLy+fECMGJxOKIcb+t9roxGjXY4rCgeD7iSzJUwRblGiisf1YQqynM0ounOlRDxrXnc1pUpe4bh pfg/zSvT1tnaazZTmzC+QT7aMCfEMEe74q7P2WOY88iJjay8l6aHdpQpu2s/K9HUUlkLLWqopmYf sazZmrzDFnmiLmtKhFmU0PgETalQy89wedQ6ysdEUWJMNNhTGRPpuii660CXk2qYo5sF1eUcM8wJ 1CZ2GxarSML4RI1ztC8xB6O5RiLLukY0+RF/kh9eVr7+ytKUPlZGaXEF1TKyYfPlyrj2EAgBu1bg VwU7fkWfD3T2gm8AGSATTFqJdgT0WwX/AA6BEDByNWOjQJg3Y4dB8zU4LlgGPEFhbvbNtKSLZ2Mj jx3cv3uHr4/3yiWLZk2fOH7ksP59vyt9/1dBLveaA+6pXrMmqQPvcfWkVF1IjSK1kfSwNUhtTH43 RqrOpJ4itdV9VXUitfV9rjo/UFVHUmvQHNIGqVYn9TdSuxao6jOkfl7A1ctSrUZqEqkXH6pqVVIv 0TxTjOy5Pq2cGc0zDShSVQflG1P79Lxsn6qQ2pTml0KlaiI1jFS+D05R7Unl++FYkydp6+sgdU3F +oX/n1OxHPOrdP8PXqIRt/vrGttHL1dsf2iFYvvgXxXbfypsn++l2N5rpWL7kcL2sasU209drdj+ tLdi+1eE7f2E7R+ABWvRnIJ8cB8UgxLQaR1jH4NUkAaeWs/Yz+AX0HADY/8A74PuoAfoCXqBvuAn EA9SwXgfxn4Ec8E84LSJsaZgMJgNIsAl4LKZsfbgEnDwxfh2C44P+oIkcAXU8kP/CGwCN8FKf/T2 Qb3taP/AtJ04R3ALZIKau/j6VU5BnvFfDv5kkczreZn4QzTpvKZMPMvLSSrIY3lJ+MtBAfWZgMo8 ngsz3zOuzA868nu+25c5xyfnDsuYC/xKWy/nr1Vs8+Y6xRaqHaYJOzTYoNghTvzWlr+z4ybltx4k futw8VvX2Kz81hfFb/2e+I37aX7n/NzMm8lJCWdPRoYeDNzt78tvBV72y5yZP00YPWJgn149vhVX sT3ttSrjGRy9btCdcLsyVC/nSqV3Z3DfNzFTVZuQOimTq+FSfZbUCFKb3lbVxqQ2u83VyVJtROoU elKHHT2X4ykKa1FY+w716rPU0g2pdFAWV0dnq2oDUj2yuVotR1Xrk8oXMJxMvlKtR+oWUr+8q6p1 Sf33Xa7a5KpqHVJtqY3cItXapPqR+kCqtfjP+dzfYff/m560Iom/5ax1a5rixdcDy/T/lvXwKT+z zxsFRoNfgRfw0fjBW6AF/GBLMBQMA17+Zv+YDD4IwNghoLJnanVfXJdjfHeYLkf3HuN1AOPPqUiO LqGbB0o0zDF4Obgoj/erJ+d2NXeCu2qe8aK1dV3dyNOkXg31HpfN3UB/sAX4AZetaBtBCrgO2m5j 7J8gBVzfRnO8WbdvXOe3eB8PP3Rgz85tWzZ4ey6ZO2vyxFFD3fp078a4D/ue+s01eL/Z0dy/daF+ cy+p8v4tzZh+z6c4XHisTaGaySdy8J621KteKWVl9mUVqZelqswdJ5FayNV6XLVRj18EiVXnsT5F IpP0vkU0w+JHs7j+1FOP5wVM5k9KILVBsaoqn9SQeurfSlWZT+5OM8CuzLSmmI67lkr5c7WuuVQA zUTFqiqU06TQ869MivIytZqdKezH+//PVcRWdbeb+z89wBFwFLjvQBsAhoChYNiO8nyWrk5amaMb b1/VJipyNN3crJUe/WQFcqxMaF+aulpfN4NTxWJVT1P3Vb/gKBXNURzL8P/oWdT9q/ZcCBaBUBAG zoK4HUo/eDrYDw6AbugHfwP8QQDovZuxDeA3ELyXsYMgD+SDmoHwP+AF0BwU5OdmZ6TT/14l5uSR 0H2B2/x9NvDtX3PVxz4O6Kf/uZSnKzjR3geld/McqcrzbgdROJhC5ZkLPhQeonoQYu5DvnNZrc+/ 5uFA7XAge5MXPSMig8LMPP4ps/ncQUNzzZtDc7YhqspH3DSbMJzPJtQ31+4RNJswjatVzOrPpO6V qnLMQJr1jedqA+WY2mdSJFJ4gd45+YH6Kco7p9Bc8A1VhZJOq0GtaR3oRZoX7lUgPq3Z47Spca9E V4+Nc3StoW42Vpejm0O2Msc4oVvLDzMs9sgJ9SVmB9Xa207WXk2tb1jOWn59tWaX5yXK7BNgFFKH j1drg5ag9S69jbX25fXzNdAefA2GgJFgDtgC/EA0iAGpIA0k/s5YBtjyXxwP9NoHnwK2g12gzgH4 HlAPNABtQFvgHoxxBDgIQoDdQVzX4GlQDUSH4HNAOrgJvEIZWwViwRlwE2SCPrCeG1gCPMFREAGO g6ug52GcEzgCjoHnjzDWDOwHwSAUnAeJIAVcBx9FMnouXA6G5HwYn34Nf3kFlzJ5Io6IjsxDKk78 5VD8sExnylgoC83Js7N4XpvRkx1KPUOuvWYeoIxnwFnsHVKfJ2f5/LfPLH2vamPVpsHgYBm2vQd7 5oMi2LEYzA7CtQCiQQyovx82Bb1BHzAHzN1fCR1p4658RY6mGyVU7jilcocMVr6Hv+RaUxUXxheA yugN1JH7P5+EzZeApcAFdbsmqAVqH1Dqv7beV0NdfwY4oo47gffA+wf53NAfmdeTExPU/9naf/du 9du8cbWX+tynOHrw06AB9qbz1K5XoxXYZyh0pDbeiULzfkp72gGq7Pu0N+2n8ACFwRR2or2Vb9G4 4gM5S9+S8fa1C6nDpNqC1OH0jr0UBlIJJufxm1MJGxpFdJHqC6R+SLs+Yik8TeE5+g6JFKbTud6U a8bL6Bgb5TGa0TF8SP2vVJuSyveM02iktTIaeZF6SB1lD+l5fq20rAz7tDqEtgP4gE2gBPDl2w6g o/DVpzT+unLnWIwTVu4leeTE3zLLo/tyxt+0vP0ffP6nIvb7IpSxL8EW4BeqtKcnRJuaDJqiLW0G hoCh4CSIAi+g/WwOQkTbqrapAehybQVTw9HnBAvAQuAbrpkXPq4++O34ru0BG9d7Ldc+9M2NOdGd f8qV/U/Gr/92VIPepvAdCmtRbapN4SUKL/NQ3M+heA0fCjfRCLtYrqO1pSOWkNpLrqO1IfX7Eq5u lurLpPrKmqv6HWUfeHOKt6BwMoVTKEyj8Iao6U6mq9K/vETHu0Y+pYGs4/8gtSHV/LFSfZHUcaRm SbU1qdmknpO/Uit+dbR4kvas3CY137piuoSunjxyjnHCuJNSuYk/eVnc9VGntDdooNazEHAR5IJ7 gEXg7aAF+Bj0B1PAFhANqkcqfeFu4Buw+jj63uAsWHUCxwT+YDuIAadOVMy35liXeIzeXZf4Q5sw Ph3dXl7jYmnWJYyPZvHS2LodzGen3+v7tPZKcHFz51dHgydl+69OMjYdzAA9oxj7H7Akij//lz/W PyEm/NDv2zev9Vq+dMHcWZPHDXfv37dn927/+QJ+K5/85n0KY8lLnqYZGztmb2vKLaS+zRXSr5r1 VUW0GphdLKZxxHMxc2XaltI2JWpamTuJpOMcNx9nmzLjmk26ZufteOW5m3ukl+5Ex7sr029Sup70 wR0p/a5Mv0HpHjLdgdI/yPTrlF4p0+0pHSLTr9H5hlKP8SSFUeTfU2WJdso3lP7+VUrXl+lX+BXT pCw7lmU31V6ZMRhvnkJfEHiDjeDtWPQFY5X7by+Dc6cRBwWAT7LeAX+A+WfRFoBYcBoExDM2IQFn dY4xZ9ABvAE6gq1gG6hxHu0N6H2BsX4gGISAnpcYGwnCwQWQBppfxnvBQ+B6hbFO4EEyXCZIuIb+ C5idwthKsA+EAOfraNvAG+Aj0CaVsc6gI2pgV3AXVLmBNjCd8QdCotXhwUP+z+38VPq7nX87+Uri w/xkyGdO5kckHxUZqfnJwcn5iZBTLf5KP+lRef6julIvxv5cK/2MR83IXvt8SMsZAhexyq+RzP/3 QfWBkJ+UVzeXgg7R+G1Aa9j9RbAkRn8NrBbXQQzsfgo8EHa3tLmu2SrQJh5j82ic0O1K1CUqcm7G yxK6hPF7dIm/1Nz/L3PnAZjT9f7xc2heEj/82loxYu/WnkFp7dZOpcuqTcWqETWLUiMoRdrYlF+V UlStUjEiROyqkCYREStWrOTN+H/Pc+588940fa3/fX2Oe55z733vm3PP8zxnXrVlL5jn0PZoZcfc Rm3v0HrIs6v23/NZ57Nattef08v3WIcy3sBQvkXZDgOtL+BhBPtBMEgD6YDmflyLNr5pXV37ecl3 YuVn+fI/41/ENodG4h0VLeC1dd1+jKTviJbvOqoFcLM1pR7FPzSpPHY/tQJEUW1eeOJyVjcdweT8 EQ/buBTl+pCMJw38KtUyXqMwhsLLFO4m67FHq8V/StdNpTCNwvt0fiKFxcjSeVHYgc7sSGEMhZd1 29QliWzQAU3jv8WEhq+oafhG9Fsq0T0UoesVpTCYwgPCtJV/HnkWAv18BCRFOBQnk8tuHTG5OFk8 56ZliqnR3ZQSaZlifY51ivUdmHohrM9x3PLqJbgulWCxYnPGNv2T2ZR3v9GRdRit62zwBGtnfOuL Phq9YIb8Ah0uoj4IFoHF4C9wAUyAjZ0I4hR7K+xsCqjyN+wmWAvWgeJRuv1tBF6PZiwfOAPOArti k3vhj9kb3IEdvgvego1tDIrhz+IF+t8SfYF3bl2NFa99Cgvdv3f3js0b168zT/saKmaBMDnqyc2W nUK5rvtlCqtRCatO4R4qYb9TWIbKRVnZbyj8wgZ6+W9LPefiDZkkhSQ3lT59BpcsyX4PxHFxYkyV tzzuKn1/V1p7vhuNP573UNVDcg7JN5S2lu5tHfUn5hY9h/X1b89D/YlbVSkk22hu10MKH1HfYoMn 6lWz0zkNqb9wvpDWk+csoN7Bg9pxUt8douMChG6sC2n555Xn1tbW2gpm0dqecyHlpGWK9R2YOvRN KbstU7ZbpohNL3eGsu2dSdnuzw2l3HBOfSfnmMu88eh6To5WNEH+py2fA8B8sAB0QEW1I9gENoNC txnzBDlQa84JJt7NLFtN9ewsprz8iCutQ9adTtYpWfzriM3wHDQ0PnMGeQOt/0fUa+qCPPjqksAH 9Adlb8Dmg7lgDTiG/L5wU8/v3sjXYWAXOAAm4Q8RCqrBeFcH7onwHcF08DUY8ICxgWAZeIhbfgTy PcIxSdAdIACOwhrwE6iO31cD1Afe4KN01PXSxRQfzg6BcM7ZeeCbjbPeYDyYBepk56wF6A78wB1w D5R/hbPaoB0YAN5w4+ww6JmTs1HQlTvAERAOLoFFuTjbAobm5mw4WA7+B66CRPA4Uf8kJMbjk5AY rXwu/ZWQyBITTieGHQlTEtVPMIWX8JGnBIsLiAwz9v86ex+YcQV/w1huqvXldh+Yne28m7Fn17EH +FVndUTWxpUyrOb1UbAFeb0V3AIJYDjy+nOw1Ele5wf7wB9gEH65Hwh6gnrFE/05KAFmJ+vPww/K M7EBpKgDg86dPhqSfFC4A2LG0MplyUGBC+eL18KK4UHJI5KHGYuDmy3Z0BY/gXzfDCur3JLtSB+T T/AJhcYVVOrQ8XUd/HA32yyqJ1wm3yKWWuhzC++7kcGWpwp7u0CVQvItXf04heEUbqdr/UbhDboK DSdsoFv3nuSldNC8FGnLO1J/xE4hbah/4y7yXQqlK1JIPOnK+ruqpO+yQyyUU+lF56dJdZl84eeo iq1TTA74c7y3LEauZe0w6xtVWnxVr8E8I7xRxvb/Io5l7Gc7yr49ow4eBoaD4yAc3E9lLBF8mK7r 52FgG/Sz0NOds0n9XAv6t3Z2qZvLQfdm8W/sSl4+26s92zuwjrjiDFgfJjZDjr/1T/0/RV5Engv7 W9lNt7shoFYOHAM+zSntcDSIUezxaLAQ9lf0/Yoh4afCDx/YvSP+1y2bfly7TAz7+MpQ8/sU+pdq VLEU+lO9akyGd3qXoRGTZSmcT+MhF1D4JmnwKtQKVEO03r+la92apItLp6hSqXXLUO2xLLW2Z09V 06TufYW0vehDJimTPcnGcRxutgg6s7HWt9yMzmxCulzMbZLSpiTtk06tU5r0HZLuJ+kTTfo2SZM0 zT6CrvVI+4YmlP6YpEnaWY3Fs1LuafJH9ZO2ghHwi0aCj/JwNgQMBVXzclYNtHqNs9Zg3OsO5d/a qXXFrbaOmK5mHcni1axtxsuPqJtWzp1bgre08u9qPo4HM8BM0KYAZ23BgYKcHQS3QAII9+TsBJhd mLMAsBtcBCkgFZQswlkp0Aw0B9OKcTYdJIDbYKgXZ8OAV3HOioNNgHxAdUHAP5NpOSDFFVy/avni b5P1VQHxzGensirX1/mFwi1U+sTYkJx+ermtTeU2SJVCsoQ8MxofYvubwtV0ZojQBhG6jjhC0uua VPYruqeqcXF9uRY1xXFGPbryQwofpao+mbq20C7yJauRvDqFiSR/QGFh0l9tSXO1o7Av/ap+FJaj 48tT2IjCkqR9SlHo2HZ1ULz/u7Koz1RAHtcGF0AisIP8efU89kLelnLI3xXIv+0gDJwFUeA2+C/y saghX98DbUXeghVFZF6WB1fBY1CvBGftwR5wAvQtiWcQ/AS2gj9KoW4GCpfjrAioD3xAH7AO7ARJ YHB5PK9gIuAVOMsNDoOzYHZFzgLB65Xw/cAXdAf9wedgKpgPNoHdIFtlzvKAjqArKP4GZ5VAT/AZ GAKmg69BKOhchTN/cANUrIrnuhr+hon2BHzi7TH2mHhE5Cf+YgyEMZSUgHiMnnxeRgyJiXQAnRZz 0X4RRziM7i1gqOdlrPMZ64JOVg2UCZ1fdFk2aatn62M/x9pEFm3Gy/cMxWbQ836mWIQT/89Rv24G ycAOOqM8+oJwpWyuV8rlvlKyXEaUxjMAppRBGQINynLWEDQqay6v3uBJOZ7V322KuNIq+KJGX1nP HbVOyWLE1M1kfZiyOW3jK+BY9zPEGmvjv553ngvdXLu8rp9ZBamfDyn6eVZFqZ+nKHr4Z0UPpzxK VKaAnZJzwLZs2iBXBSD//4vRQwYZJoG50XhsD9ti4cGHSjsbSN77XK139F06bh7Z685aH2lrkvpS +0phzWNuRVI5G3ODJm1J0o1kTa9Ky0o2tbRDu5C0rzmpPhJH4VUK46k/aNkj9Xot6HrLqQ+opbYe TXOStqK+np5k73tROJrsvT+FPlRreZ9qLWHJaouTrJ8cJ2l58ZdorHs4FejvM1yVQvK5GMJU9mny iFeWtrKDYisHG2yjtfZ7+dV068J11jLlsGXKPsuUXcxic1pe3U0zvo45jtkwpB3NJC00k5liBYyr gMryn/+f8lH1cY6C96vovs4YcN3g85SGz1MGdAAdQTg4Af5THb4Y6F6Dsx4gDlwFr9eE3wkqAvda nHmAj8F28BuIB9dAs9rwJ4AfGAxWg7Ug+fG929fiYqNjoSJi5diQ2OB9e2LF6uAbY/dFrF+3Ur4Z XIwPYaIENKUy7i9KvrteWsaQdKUmlaVFvp87jcJ0CqtSea9GGkG8eSVnJ65595fUOM6MpON+l225 dOYQkgylMJjkByj0pdC4dmENOuYN2v+MwkEUXqJQ1kVq0TF7aX8fhdc0jbORZn4eTVZ+CyTHaLan pyj1x6SkMOmBQUJyFJI3X3QeW+uFLFpGV84xDSh5tpf+f+bCOt0MbQAZ/D9RVzHm63Kw0iFvyyIv y4OmoDnoADqBuWC5Ib9FXrdG2fQFn4JeSnldA34AsSBOlOM6nI0CU8ACsBBEgysgW12cCwaDMWAs uA8egDr14G+AweBIfdwfyO6Npxq4g1ygJqgFfMF0sKUBZ9tACAgFaxrjXsAV8GUzzoJA5xaoc4Kl YD241xJ1GlCyFWdVweLWXLwL/PHNx3FRCMTnvNg9j53TxxCE7AvZCUiAtHvYER87HYj/oxSB+Jhm a1qt2m4e8anPCc0wC9SqHvgP/YDa+M/W/1bv+tWR+SfyKTvoArqCaWA62AN+B96GvBoCfkNemeYv PdtJYK4s/2CdYqpfvZQ7uGKZkqG7X9n+ocXP3cn8r05w2Z82T3eAUyhXZxzKVhzI3ZSzPKAFylBL 0Brl6F3Q5D3O3gbd28BegAfgIQhqy9kSULM9yjBYDda0F/0AosVPdvvSCFBUBg6JKaArln4vloiZ NF6d/5ntrrCIwygcTqH7fRF60OpZm8WaWm/rVv6X+8IWNk9UpJC0oPW0eovxXE304/rQKK9PHilS SLpQn0I38tG7U7iYWuACKfyD7PJ+CheT7y5eupjDNhChezY32xSy4VMpDKOjjms2fAN57xXtqj9i ozuoRHWZ7prUjaQ9SDpDk8rxZTO13mg32xUK/emuxlDNp4nm6Yj2S1bhReXhDXCzvWttAM/R4FpH XKlYPHVf3lP/DcRmKOFvm2JNnNh/YdvWgh/BenAR3AVfIq+WOOTfoI6cjQNnoTiugBs+sLvvc5YX FAUlO3NWClQCfmAYWAqWgz/BBZHuC38DvA8Wg43gHLgMvD/grD1YBX4DIeASSAF5P+RsNzgJBn/E 2WQQBHaCcGD7GN8FNoBun3A2HBwHp4AdFOwCf6Urfgv4CewAl0AcqNiNsxrgI9ATLO0BnwEcBxEg EaSAbz7l7HvQoSdnPsAf7AVhoHQvzur2EmOD7tC4oOux2hChC+qOQaZ/nMnUz50zyhAhow13Nq/D yg9wXPkhw/gfH2PZLNcBfh7oB1aDUNAQ+d0OBIA5YCzyfRyog7yv66PnuZ+S13865HFncNyQRzlA IPgOfIR8+RgcAaHAC3lUHKTZnzxMiIs8d5yUPSp0/1sROC8gbeb0qWlfThg7cvjAft27uNG7OPPK Ny010etzNqqhiR7QnO/oGnwkjYmpna5ImTqiJ4RCOevLl7RkOO2foHAyzRgIT1I15n+Z6NvJodav aI3gvLa6WjwPxSdr8dz03VOorcaPrj6YwgpUL6xIYQGyAgXprn3T1DP/Q1fqr8VzUfyiFvdg2uw1 irtTvJEWz0nx8Vpcrg48gX7VTgp3SYtT5mXku7Vie2o/0LpR+NlGnvp2XOl4duUcq7YmRf8Xzawc DgJ+4CvoyGngNDgDxkJHjgOdoRN9wbdgITgIDoEb4GYP7tIaB644y9EupJy2THHlDkxrRmUxxWEz tOE1y6R97+1M0ppm0vbXxIn//w5jBZ5FPm+DTfwVdDLYxTHgd9jDveAgOAT69OasL6jUh7PKoEVf +JRgEPADI/pxNhL8BDaAtv2hg/oL///2zdjov84dPxq8b+d2sfrD0u/FgM/AwMDZM6ZNmYT98fok MDdbMlmGIKEtPXQbsIRswGlVytQ3dUwkPfw97QdR2J00ZA8KF5EkgvYval76OPL5Pcm3L0zzLGLF PItmuh26QlL3JFUq78GDWujqq1JIvMnGiFZ9acWkZz+GpJ3sqlR69j7k79vtai1GflMKSVuJfo6m +je1ThHfRONIm8pvkmNIN6Wq15T+/4vIv3vG59xUiKwjJofZlXNMEVOLv2nalynyHO/tTxdSMmyG suuRsZ4vdoWed/TxM9MshYTP2hL4OsnjeqAtuAnSQX7kcY2+GfN9JBgl5AOQ36A9SAV8IGfNB3G2 CwSD8kM5qwYGjuJsPOg0mrMBYBgYDm74o6wDNo6zV8CH4GPQH8ROQF1hEmc/gygQDYpO5qwY2DwF 1wch4C7oOxXPL/gCzAXBIBJ4f8XZB6D/NKSDMHAR1JoBn2YmdB0IBGHgb5BvFmdlgTdoA7qBvrNo bMcdfOQIjeux16Ou2/Hvgv3cCfsJO7PHhp6DfL/9XBQOij1nF7FYJF9A6gU65w72lCEh2tgMDp+c 6216r2fw61Vf3ti2Z54tUMiZ/+90brg2/qONKJ/NB8i824X82g3ugftg/Wcoy2Cnkod7/TjbBx6C gMGcVRkC33GozNfKwzh7A2wGv4AH4CFIG45nBxQawZknqDGSs5oj9WdgAmDIez5atvNci4uMOH0i LPTA7q1yju83c0yLwLvZBpIuvkVhQro2gj/yDs2GzSfWWG+ua8f8tMZ6FdHy00KXVqX2oFaJqlTR mYlCZ3Z6oEiFxqU10xc9UK8pj1tM7UFFHipSSIpS/24JahUqSf25nqI/14e7qytP7NLicoRYpydq XPYhfa3GcbUZZFcCqKdXzmVeIuoUufT7X0qtRJ3tqlTely/17cxWpZAEUPsPJwuXjfR/UqpqFcWV WKkXkf+uNPU+2+ZU64hppEYWI1m8dLQLKSa3VNsMGryF4xucDDahuclC+JjW+szlxP9DLbLQvymf HUfrOnsg+Mygu3eAnSAVpIHr/lKfmyoj1gNzrFNMf3lTs7jpsCgXIhHGiHUVyvqwU8aI6dJHjRHT OdYp+mYeFZDTGMszNTDNsa1fyJRVZM1PQybPjfI0FHQ1X78fw1kQqPoFbDo4CU59YbbZA8F88C24 PMG5DW8G+90cHASHwCUQCVKSYA0e3xZTv08ePxS8Y+uPa5Z893jRnFliCejH8qXfPZU/l5vtdKrQ fNeFbisqNZ/sex9A3vvANMeWnUnUDvMuyd+jtpdYra3Ek64oxskqY+xJWoikSXT2QvK4xVrxMq0g U9aDD0pR15tvoDWzi1dyyNSGqWrqSS01v7z/U6Sbv9Tad/KRdDLdmZ92D/JdV4PpzrZo0tdIupWk SZpUvutKznxzXEVSzgcbkC7G/7yIvKwxJTMbYGrVMOkB6xTrq1l33bnSGmHdDedKF6F1xFQLsU4x b4ayXtRpHz/jr4l3Q1j2/0G3eKr5UxMcNvjQ90CfqWZfeo7iT+83+NR/gx/hU68HceAqsMGnzgF6 gd4gBBwBRabDZwdDwTDQ52tcH9Scofvg9cAXYKzBH5fzgGL+Fi0A8SHxB/fvFUvCr1sj3xCkzwUS z3YLam1tSWErCmdSKGdqziF/aC6FXUgHdKWwI2mLTlQK14rC6aX7WutIKtoUchbXfS07aZxuaYoU ku6kTXZTuIdKLo0L8tLPiUzTZmZ6yXNkSbxCYVy6rqXqU2luK44spN9Ju3Sq0wtpMaVOT0c7zuy8 Rj19Y1VtqJw9jn7HKU0q7olVeBF5b91y+tTNm9b9ataD/Fzp2bOOXHQhxTpiGoBo2gzltrgp5mWK FTLFilm0/xbV3v/ytGXzO/DmbNQFwHTwNYgDV8G7AZy9B2YGZPkZsPYDXYk8215XU8TaE3UlYtLy 1inmzZCfJf5x/IeXwxOk5L/nv8nDWSAKRAP3uZx5gCsgDiSBZDB6Pmf+YAKYCJovQN0STPsW1waf LOSsC4gDV0HDRZw1Ar+C7eAKiANui6FLQL1AzuqDroHa3K+4yxHnT4SJ5YCTf9/1W3KyXA4sedXy JXJRoNEjBokadmmh6UqqLZ1yvR+lj62krhU/IE09WpNKTe1PmnqtKhVWgCTFhe4tJSUlSOuOonA0 haXJiujvlXez1dO0uZt4ITTCwSSXa5DLNoxfk3WbNI/CnWSTdpEWz6NZI/kr8tKvaCekJfT7bU/W aKsqhWQbfc+rZI1eo/AzCgelqVZCvA+EVRLtWavBNvAO8tsH3AB2kA357AHagx6gH/APMOd3tnmc VQctgec3nJUCrcH7wA/5P0J5DtT8nwvyId/bLsz4LCSA2yAU+R8FHoE04IHnwBNUBt4gGJwCbfBM fAiqfMdZHVAvCM/yEpwLroHKS/Fcg6qgLuixjLNRIAisAvbluO4Kzn4AG0H3lTgGjATzgMcqzt4A I1dzNgMsBMtAmTX4zWuoHVD/JMTHaPuRtH8mMv6EPvVLzuaKRBhKs7piaI7XIXGmTFXb95ytBmKx luP/MXcucDZWawNfezNj3JKTkLvcFV3UqXPqVEc35B6lr3OknEQKJyKkJEmpI8qp5JIucutzGaEk hnK/DGMMymVoJoMxw2DI7fzXs/b77ndt82qfMfq+Pb//stez1vvuba/3eZ51X1GvBfPt/2v5e+l1 lPY/P5GLHkq1ItbqXv/IJXQT/s7Afnns+dURYwB5tgYsb+DY/9+yuR2hwYdGx275KKxjY6FhSLfG hnTqBPp0En6dGNatCrAIXfpu0oXGgQo2xeoyinJ8Znd02f6fRVTk2I/1TJw//lM9svewQkGXcdFP wnazAQSxl4WgHtwD3UK2VNvRRMiCciF7eg+c1h4+I32vs/RLtvzM+Hpe/PRPP3p3xKsDe3cPr/oK v0rJeRmm56OGxHPc+NUSr+j2rVSX+J/deDWJP+PGq0o83BdTReKT3HhliS9345UknurGK0q8iNsT U0Fpbxsnvn6HhDslvE769wdIOFDCKuL9q0r4FwnvkPBOCe+ScLzUDSZIWFQ8ejEJJ0g40fXutcy+ FpLvOqlJnD0dqruE6gzndGdVjYIos2kwHUZNDqjRcBxyod4XAVUfZsIsKDEloEpOudD8n/xM7oxy oe7vFblod3bRv4HtMuz+nsix4Uq6DP8SKsfbKbN7oBMMglfhdfgSVnnKdD4sh+1wCMpQpo1gHMyE ClMDqircBq2gFwyFSTALik4LqOJwB9wJzeBh6A69YBfshlSoMJ12KSTCDsiFExA7I6CKwEL4ARIh Ha75kvYqvAuTIRuOQYn/Dajq8BR0hW7wCXwGP8IhaDwzoB6Cj2AcjIctsBWKzwqo2nAHPAjPwOvw Ecyc5dYFdV3OrvOZep8Z992UKlW/9fylepJDYs+bHD0w7I74lgyN+DapHwyP5YbHi33Wenjrgr71 vzb50d93YBTcQlneCt3gaegOz8Cz0AM2QOLUcDlPhi/gfsqvCaykvFZBbcqnDrwOw2EDZZEIhWY5 c/+1P9Cz//U+H3olsJ77P/b990aNGD54UL8+Pbo/qfQYah09hrrRtH/qyj6nPfW8mkQj6SVzbxK1 ZIORbJSx1YbufM06SsaGZc3cTD2Kut7kmyWWt7XpKZR5NXK20jqTalprZtcNM7PzDQnflHCEhG9J +LaE/5JwsYRLpN3WRfuOteZuT0l7dL/rTWrLdzog0vtdn1JLpE3Ej6xz+w2N5S9j5vxL2F/Cx+Sz OknLcbnrF2tq61Dn9yjP/Mz2K9j+9fzczepAjPJuVpdflGMMVpeflWK9PHZ8gxVbb8XW+Zz/vDbv /v/ykfpWGDJgP5SdjZ+HdnMCqj28DIPhlnieEzgFp+GpuRgiCHxF3QEawU0wBv79Vf7K33/A3b9c /CP5Gb73v8a/lP3LckN0kYjyz7svL8mKbfJfT+6Jbcyj/BMp/0tV5kfhGMyZF1Dx8MF82hTwDayB tdBmQUC1hVWwGpp/HVAtYOPX0g7IOpiRvvNHPejzfYIx+59N0rs/ZOmDv/r37eFpCYR28Ba7Zk7l aiEWc4MrbSjSxAg7as7WirSjznkybcU/hOf3mzO3bhX/cExLNxubfVxm47Rz12GZU7jai+2dJ+F8 CfdJmCGzdIZoD5Jkrn9VfMohLdlkJFlSY5/j2ur6csd4seNPu715pWLHuP+/epLDzFYNryk3HuEy mZGUc9zJW1fyHj2ux3913SUpovwfoby7esr9TujoKftalHtD6A3DIB2OQgzlfRV0hX4wHuJBUf5X QDtoD+/AZ/ANJEMmBHkeKsIfoRl0hCGhZ0Y/L4/wfHSFdjwbvWEHZMOj31BfhX4wAmbDd3AEcqHP woB6HvrCbFgGcd8GVHmoDo3gPngYFsK3sAh2wym4YhF1ILgbOsJzMAymwTLIXqTrfpm6zrcXfoyo +aV4Y5EVw8TVeb3N+cVbo7Prfk6NMLIOaPcFmvpfcU99z7f+17ogdHUTfM5vPRmu5fdtAFNhGpxe mD/7n58R/igjBXsoo7878ncT1pRf/8+JfOXt2bdYdj7Zxxts9vH/0ZTfGRiCLrwKW2EbLPU8/4eh ymLafNAUmkFgCToNy2EF3JiArkEWZEPlpVwDRZahj1AfroHB8ArM+l72AMrcrzcA1bv8LV2sD380 B7+OHvnGsJcG9u61SI5+ML9N7Oti9Yaf18/yrVjnz13rfLPknixzeJJc6U0i3Sy2We8RFLfNWOJR YptPa8lWIzkjtjnBtc2N5MqlYpv7i/0dILb5M9c23yg5zE6gm845FtrY5hTxMUtcH2POrjTnz5QV f1FOvtM4/U1TzDcYL989y/3u18s12ZL7GWmNPCvfWp8nE7fFXHNUJCv0t042kpW8V7V/j/K96L5/ /1Hh/Izw+t/Nv7fe/xr/3npLy6O8W2Tvrv3y6O42K7b1N3v87dpgijv+r8u3BuV5o6dci0JdyIaT cAfl2QZmw3xIgGQ4CrGUcS24CzpATxgOn8J8WANZS8M6HvwhoK6EnssD6gVIg0PQbQV+HQbCMlgH j63Et8PL8OIqnk9YDlvh8tUBdTXcBS2h+hqeP3htLe1O6LKOOioMhcPr8WeJATUWvoLFUHUT/0dI hDSovTmgboOmWwLqQdgOP8MXKQE1Bept5XeA57YH1AAo9xP3gAw4ArfvCKh7d4TWBuTk9Zfhvs1K zToVjuWc2pG1LYOrMpJOJTmyLCctSXqCItYBOCcAOHUBaw+RiP0+Ljz//8EL2d/ZMI6yGg8DQmXj LZPB0JLfvBUMy+N3fw2y15//+190d2fBRvx3ByrY71awnxPl3fTrAvv/VLqU5TwPmm0MqAegyiaj cy3RsakwDUomB9RlkABLoW1I9/ZG6F5l9K4KtNgaMOfBZe4P7f+btE/v//v9PqdfcHKmMyewX58e qljsi7pHsKbxd4NkRd4RLamhvaZZU5cjay3myfjLfPHFeu6gyWFmXDSR+sNWV2rmjWwTqay1EKlZ xZHtxMlxWPxxc/HHA8X3vyhhK6kBmJPdrJl/krOv5OknoTljwuzb+6vUCLbJPbdL6D1tbrfkSXVr FVMlt1n9YeY8dpd8z0j4sNy9w1m9/++lKqeWMALegj2wd2sB7P0RZcS/ilGwKf6jLv7X+E9LzE9K 6OUZ4a0ZscIv7x6kGu7+n35l9ddtAdUY+sMA2ArboM2PlD9sgiQoju8rCU2hGewL+cRUfOEeuHJn QJWFOlAX2kBb2AN7tXw3coiHuZCUKn0/uudHd/gv/nbu7OlTPh6vj3cZ9urAF5xN/zvq/3ZMbB95 np+XUMlTHZDwXtGH+ySMnB3bW9Z+DdUrwmo7mhsT+5rsBbTAkSL5WnYOmp2jwzmyL1BrvQ6stL4m Tq5pI6vD3tbSWuE7jZTVYSscqa5pS74mxxxbYXZjaCq7gSYcd6SxIl0qfTXV9Gqx+8P3rC4nwnVw pEgekVPg5uc6V5t1wwtEeplj9UK2qpRYvuau1NyzBXFV81KWtX+j2b9v1T8lP43zbdGlWN221mmN UXYpLM9HSh4vj4batffSrg9vYGl7LVfbx5y3G8D9EZbg/PZ/DaXK6jprHxgEc2EjFKLsSkBlqBkq y7YhfT0Jahd5oCv0gqWwepfR4+thMIyE9L3oMsT+TB0bMqFLWkD1gPfgU/ga9un36QE1B0b+ElAT YTv8DBX3cU9oD91hIsyDTAhm8JlwH7wJk+BP+7FnUPIAz+JBnmt4GJ6EgbAG0uGKTOr08CD0gEEw CnKh+CE+A1bDKSidRfsDRsIsWAafZvPd4SAUOkweqAsvwLuw5LBnfmDmqV9ywgO+vzhvIjsLzZ86 TxKRrvz3+/EbC/at/z8UrU3eDEl7KMe9plyfTDNlucBThhnQhDJsCs9DX0iD/JwBW7AR/+ka/ydf x+q1sFKsPsMLvDx6XvcCu37UsaxIx/PPfy1/sWWbDo3R07thEyTBi+jmIFiNPq6BEgfC+lgOpsF0 +DO6dhvEw1x4+pDu83MP90jSAz9mv48Pxrz9pt70+589unT+e+gnKBbbJxuPNsP4w+eztY/L1JJ6 YR93KFv7zUGHQ1IkL8l68NLaz9cNe90/6HiwqoqtmCPnwFUSf//3o04u4107ih+ffsyRmhbEDPHj 7Y87UtNqeEj8eJorNZ44XaSNcx2p+ZZ3i3ef40iRxItkl5bUMZLdsuPIndJauUvCnhL2knCphMsk bCx1/7vDK8Q7hleZ65OrJc4d28v8r0tRhpa++x+ubqVYKlGwKVaVwqpLW37fusZy2wneSLw3Yl0z wxvx6t0MS1/roa9TCml9PREITCnk1tCrBSJzdXJydSoUG6nxwx2NH+7U8UvrcYFA1TxmfUZaCM84 QhldXt3hKnxaBViCP0uAh/FfHeAX2AedjgTU41A+h7ywAlbCc8cC6o8nAuoWeBNGQLtf8dew/VRA /QjFT/P8wGB4BX6FU9DoTEDddMaq7yd8Ny9+utn2QVf3n+vZrUvHR9V5r5jYY7v1892AJm/cDWFN apiq9eYLR4pkikgq0ZSOu95IKu/RV7bQkgZhLW4p0qS9jtRo8ea9Wjo+zZEaLZ6Qpu95WEuvM/c8 IpJ5+5A8prWrVGyn/by/NnzN4/v1nUodcO5kvu/lB6St4Eh1W+GAznfXQedqk++vB2XukiNFsvGg zvdUpmNJTJuia6bU/7McKxiq/2dp6aKskLUM3fM7vWFGtYIu/yibwf466b9qzjqP2VJQ/5OaF3gj lur6p1h3s5TauvXnKuLl0fjrrNhj3lOcPXrZAL28tXBIL28t7NVLz+nN15JraCHn9ObEYGBoIcvH 11X+FsRrZ2yLFLISV+h66hZQlG1FqA93wGewAP5BGb8AU2Ex1D8aUHdCJ3ge2lP+3Y+Z50A/Ax/C R5AFJyDtJP4FOmMPnoS1kAxHsAtH4Rx2oAg24M/QGFpAK+gJ/WA0jNXxs8RhCAyFz2AGnAB1LqAu g7IwMhhU78APULFQUFWGyfAVjC4cVJ9AWkxQZUHt2KC6DTpBXxgGr8M0SIATULJIUDWCNjAGZsA9 cUHVAcoVDapq6NgD8Dj0hNcgGbKhcnGuhTw29szJcMMMkWSEUpx/03a5byP/lPPut/cH8owV5L3/ Z4f82uym0AxGwFuwG1KhK+XRDV46G7UtyE+K/wE7Kd6ItZ2KleJ/zUWn+H+3pSrvl0fbb0RrDxb2 aPvBsF2wz4C/IY+cXv2//gLtggaO/peNtixfhiWQADlwFIqgb3FQGarARhXkFw9aOrgcHkD3msML 0B/2QQbciy7eB8mQArHoZBF4HPSa/9Sdug2wdPH8uWbPv/ffG/WvEcOHvDyw/3P9u/f/R/9O/HRF YlRcO1xuCf59wHHcyo0FrZgsede9gEVCkpjYWdu1Z/2JMK6Z8aw7tuv68xM/6rCzhB9I+KGED+2Q HnQJi+3SYfFd0mNHGNc07F2r79L3vcmRIrlZ8j21K1QTCfnmriKdqqU3hq+eJlcvdqRIlki++3c7 V5t8TaQWNG63UwsydZnxIt3pSk1dZpdIj7pS+WlqXYqytWr5+70RSzWsLjgrZZU3Yt3NSsnP3k0X HbF02EqxKhH2y6O2D8gSLNreee/h1MzK3NTS8TO/qeMhrY7enpSJRhcXwXfwE+yAnTHGTw6HZPzh FihbNOwPq4PVJ2s1k6xJFlZKlNf85BtJji6y0huxPueiU5Z4IwuV38tT0ytSLbQmL0bJs1AilFQp WHroB2flOQmlxLopSD2bQrULWLs+RvWsOesFr8xv+c6Fr+Ae6jffwiLoXSKo+kD1kkF1Nay6LKhW wxOlgqozHIEc6H55UD0DV5cOqhqQCBvhxSuCahDMgtlQs0xQ1YKTubyyczNy9+Tu2J6Uu2FlrvYJ X+ZOztUDQ2+98cpLfXs/+3SXXG3V24hVnyNzptJ070drYz/TZc7UKD3/qWXY+o6WNRFyFnOrsFXV ZzEXM+cntzJXm7OTe55zrjb5ep3T+c450rCf0cNDEmvuGlqzt2wpmWsc1yJ8j6bhe7Rw7tHc9VVF QjH3zkXMveS7BaspuTD8ubHO50osxopp1yC+r0TIY8on1C2osvRfQ21tn2ZFrJGWRd7IHN+Umd6I dTfrQ/2/zkRv5D3fFOtzeBUPqY1uiX1wVnRSt8M8ytZShVOddpqxx861txZ2r6W15722hQqnyrU6 vYT1kY4l4K6lwxc2V1a62z6M1hqU1u2Tv0E/GAZjQVHuZWAxJEFhyr8CDIWxsADWwHSeh6VwDEry LFSERvAqTIA1kAqHQ89KcZ6T2nAzNIWZsAx6oPtDIB5WQaM/BFUT6AYvQUdswfOQBr9AUWxCabgS ykFn6AZ9YAB8A0tgNayFTMiBG64MqsZwL7SEtvAETIcv4QdYB3Flg+pyuBsy4Rg0LxdUo+B9mAAf QyachdvL832hOTwE6VD5quBvDeR4/zJPuftAuP867zJSMzxS6R/xtvv8zpCK6vzfh/4bOzwIXoLj kAuNQ7+R/m3ys05/pzeS5I2s9UasayxjYPXhTPVGxuUjxbrb+yqvl2c2haOdiZafTgwu8WhcG6me hTWO1Dw18/x8Vp2w9UVZH299sVVEj5Mq/Vvl2gLSPM90FXgOesMY+Df0rYD9gJcrBtVg6FSJeiM8 Wxndhqwq+Af4tSo6ATOqoW+wF36G1dV5/q7mOYP74H7IrskzBSdraf+vnX96rl4MtGnDquVLFn0z f2bo/KfRI2ULeD001N1TTrGPyuyNv8msjhg9YtPeePLYY1pSV0vaGUk92bt3iIRdZQffbhJOlPBj GbFpo0di2oa9dlsZjfmbjLf8XcKdMoNsl4QHZATmoIzArNV1kAfDV66T2VjJMtdri8zJnncmlIPU +bIeVPYyaGsk22VuS0OZ1WLOoOwioVknKvWG1uG763iJUC0o3BJu49ZCHP/fxrmk7u9VxlYrLscb uegV91Zt3EqxOpatFGvW9kVf4x/Z6pvi/639I8prgfJeDfKg1fPcNo9VH629M8Svcsq7FXTW5Qwv QFvK+n/gHfgcEuEAlKfsr4UW8ATczjNwDwyAUfAtpEBhnony8CdoDWNgEnwOM+EHnpWDoWdmLM/L RJgEq+FkVfMcxfDcxHmeo9bYie7QA96ArXAAcuEk1MFu1INpsBDWwAYYXIO2DMTDQqiBXbkGpkM8 FMPGVIVm8CSMhsmwAn6CO2tjD+EonIZTuVnYoyzfv7RdaSlp68iyIiTIkOwJ52VEkteeTcavmz2f LNd+/lxvz1mS/43fd89/bB6N/f0VOtcNqn/Ak/DPetgHWAfrYfc11PMg49qg2g9Wn6d/JMreXauF b9USrBT/a9Z7I1YHUpRfxzrH+UtvxP/rKOXfkve47YfPr5PHuJeFNbyoK3PuUdy6udtH4PH17S+w U3g7xy6UyU/5nmlIvReKXU+dHlpBa1gJq2DzDUGVDB0aBdUjMB4mQKubyAe5NwfVCTgL52DPH9Fv SLsFHwTnbsVZ/Smo6sM1kAsn4PrbqMPDA9AcatweNPsF7du9Y1vK5o2rUzav+D7hu4Xxs74MHRWf wmvzmNEjU6SSkDJogBSMM+M6XcJE8bBmf56iEiZLaOaN/oe78wCvouj6+GRDbiIICAhIeQUVQSli RQldAaUJ0lsgpNBrEIJgICT0KpCE3pMAISAgoIJSRem9SeiJUkMLpAHJ+5+Zs3dnk1y43ASe9/vu fX57ds7uzm4yM2fOlJ0bK44+EnXuY7G1iDp+lajjV4ttZ1Gne4ptuNhGiK3xO1/5xe82y7e1qogn +ETEJX9LfrXY3hPbhDRZg7ex9gHI3gdZt+t9121EL8cIMdp7Jp58GfIBYuL52Vdu8e1Vsb12i5/X /C55QXReC4RZZW7PypXTWGUQBhaA15EHyoLhIBRsAzHADXmhJKgBWoLvwQjwXXmNjQTRYD0ogbzy FlgKVoJUkB/5xh20AkEgDPwM9oPQSsgjYDc4DD5D3qoNtoHdoGhljb0H2oFvwWKwAZwE8ZXN+XAE WACugRugKvJhHdAGdALdQV8wCASA8h+i7QY05M83wNvgXdBAybvR4ARoi7zbCTwEbyHfDgTfgX/A DcrLw6pkavfFZwhn/l6LpdPOGRfJ94n1r9JXbn7XN3O9kdU4oM32X8vnVZ5NfkusGjB12pgWPzC1 +uwM7LLvtOcY2KYGfrYZkB83pdX4/mNTv635bT1zz5HZymeuDRyta1hhnl9HgnGwu5PBhk+lHVbt 7w53pL+7YXujwBZQGvb3TTC6hsZmgnCwF7xZE2UIVABVQSxwqQV/EnQG18AjULqOxj4Cfp+jbQF+ BdfAB/VQB4GiX8H3AiFgDijZAL4nmA1eQUYeAgLALDAHHASHwWUQByY30thU8KAx7t8EdgA0AJFg NTgAcn0NewdKgeqgBpgEJoMZIATM+ZqP4cfzH/C8cO3UtSNgH5DfI8reEQolgF30lce2XvuVviy3 fJ3fySi3mefuqmuAZujryViOCxnnmH/jOyvfMKP/yBpkp+4tA4ogvYuCS0jjy0paW4AX8AY1kKY1 QS3wy+c50BY0RZDt9mPOxvY/dlNpR1xNZkexOSWzk456eb1OZfZDKrd+oPCXiBPcAXf5/ldGea4N hoCJYBL4EawB+8EBMEsp4wXASBAE5Lt/1unB4tU/uHsb1kUtu8HdvdDpE8aOGDbk2wF9+F/uagmD 55XXSf4mrKvFNU2GhovQCBHKb2nIe1DaGiNCjdLFKL1VK32l7mKUZqKuhWaS8A4Xiu0psT0ttgdE f9E9Pu+3nZP1er72Sm7LgSTSQnNQ9CANEL6kn9iuFdt1Ypsi/MdUsS0v+ooqiG242EaIbaTYBoq7 jhRbY9UD+aZTU3GGXLesuPAhS4htXnFePj50VP5FpqOd7cKcDeTsi312BmwvS+DIEdvLEhifrN/z a2vDv2invwlQXC1fR8ExkAt1pgtwB9VAABgOloMVoBfq096gOurPGmAhWET16UFwqIljae3IdC/b R2zHZuqUMzXhd6oB03iAnUc22AxIS+z09J78jln05Gc5atAhi1EDpf3f/gnzv9rp7f/COZ3u3J9y AaVBTVAL1AbNgCfoDwLBSDAWTAGhX/M+tbvxV2JjTh3a99cfWzatWx25dOG8WdMnjQsO8B/Qq5tX x9b4D+ZxdnLJbTknrLrcjxP7L4l9/otPrs5OlhuQ8uhD5cw8acZ+CWW/QpoRQ8U0GUOlND2GRsqZ XcW+q+h55/XIPFGPzMf2JWe5/m5+yz7eyu+o1yaulv1Uy7yXruudhL5yOtfTuD/Xs1wuLK+TaNt3 QNDV0u+RvHI2f2OjnXHlHNKf5fr2hv7cIxkjfx9c6KEr9Fjq6j6mOKCr91j+FaFCsjccTTNTgUpR A/dtBna5Odlzmp2BQZPsOs36acZYkTJORcs4aWG9mfPHTi4nX8uF58kKt5N+zCUkPdXllXyBRe68 7lmudFYRWoq4Zdb1d1hX+Vme732m8efzLOdp6WrJHHvXNzLphAVxwh1kyZfWiOXVy988sBSEgyhw n5dJoDXV2EsgN3gFFAWvg7dBRVAJrAGFmqGd1CyDb287sHKWkhXsvOYJsalZIfuxtc1nBJarR2wH rB9nkYrsazUxnyWnsSzTM2dzmpEXWCHetp0LFoMl4AK4CO6CeyAFpAKGNHYCrsANFAZFQEnwH/AW KAPKgwqULypT3lhH+aMw5ZF5gH2DvAXCwCxQoTnyE2jWQmNtQTfQA4wH00Dplhp7B7iDz0Fv0BdM ByGgfCtcD3xAbxAAhoNF4Nf2GjsOToEEEOyB9j0o1gnPDLp2RpvWE3+fl8ZmeiOf+2jsNRAMloCl 4DNf3BdU6YrGM2jRDc8HPu2OZwQTQGri07+3Eq+CW0JeFftx50lxK/EMvrcSz8fROWcOZz0KlNVq f8/S66f0QDTPybLPKD15Wu4AO8EfYBf4E/wFdoMGSM+GwBv4gHAQAVISbl+PO3/66ME9O3//ee2q 5Uvmhf0wYVTg99/5+/v379PNu0MbV0tEuqz/eA++m4dR//2r1qgeRo36MtWoxtxvF8uyFF5zL0/h NTev71ek6PV97VSjvj+h7Pd6aOwfUfbbPjL2Nz8yPIma5IvUsvoi9RVfpImy31LZ76B4M10oBi9r DD2UM/sr+/7K/nYlhr8oht3WGA4pZ56U9f+bOZFuJVo65u+b/HDb03VN43e2A1vVgGnILkoNmGb5 mY6YbmqKzebn6d68R3a8eX2ubnc+w1fW22WexUsozpxC0nmdsr9cxieneqqAnn4lwUfgY9AANARb wFZwC9wG9WFLvwSdgWcGG7sYlGsNGw1OglMgFjwEedrAboBy4B3wRVuN1QWJHTWWBFIS79yMu3j6 +MG9O7ZsXBcVmbhkwZyw6ZNGff9t7+4+nh3bqs/tKn4pm3uw7uTJViPZmvzzNuRze3Jf3FOf+prf MtAadhbhYGtYE+G51jA3FbnFL36JMO65nOJunU73IHmO5HmSC+je/Fcg5RCes3jm30h/3KqX7YMT pK/IrVZnw5pVImvWUddD50GW70i63iKQcRwl/RWu72TEcVW1iJ2ysIj88tI5mfamJclM82hML0vZ PnJYDZhewzS9dWE6st7mkZUOHIlUA0ttBjJ+qDVt9LW4GQW7DSswipneAO+csWXuph7jZ2c9t6ed HfamU1b2Rh8dklOM9dEhPv+voKNl9i3yndaDDcC3s+FHNQGpXZC9vAyfahbIAz/qZR/H5oc4EsjZ jsRsB7Ldq+hIBFn3C3pa1//Lblq6g2ogKIO/3BI+citQpbv0kbl/PBEU6KmxgmAsGAciQCSo0Bs+ JWgGvgF/9uF9Qgm3b1yJu3j29PEjB/bs2rr5px+jl4cvmhM2Y+rY4GH+0QP79Yru5s3/SldLDFng syQ9yGJfpnAsyUcp0loO4Ov5eRlW1C9V6pMf6nppRVOEtyfX8XO1NKFeFj4fU5zF+3LoThfpDpeE pP4cy6M7Mt4v+OyLLka8de/KmPx0PXQD78oY/iV55a68d0ACv/fwBKkdRfKDB1J++ECe9VoiP6tY otTuIbmXZPskKTuQHCtqUVb2eafhX2BtP7QB+2kOreBlyvN2lnvbK4SbetLtvMb2EUeezZFrbAeM T9bl3Cvzip/K0S6MFedpWgtp56GkpZ6Ge8Ax8AnSsDHwQhr2BVP7ww6AuWApqDQA9QOYBJaCKLAS nABN/TTWDmwA28EN4DQQdQv4GASA0WA5OAoaf4v2P9gE/gR3gGUQbBSoCoLABLAKHAMDB2ssFESA lSDIH3kYbAStAzR2E1QbrrHaIBTMAkngMQgJ1NhssA78AqqM1FgX0DxYY9VH4f8CaoPmoD2oOhr+ EWgNPIAfmAbugRTwzhiNfQYSx4g5QPGZfgkqVlWo+/H64QumEy6cSohXr7f5rod5HoC6LthT1v9q lbGMqml3EiSBZNAR6eYBVoJocB5cAK8izQaBKWCZko7HwH3wAHRBGnqBNWAtiAVxoBjSbyiYAaIH kb2/Cnt/8ujeP7dsWh8dPm8WD06fMiZo6OD+3T3bcj+9MLe9XQ0//j1rWPrxU61h6cf/oYdhYXeR v81n1Ln5GtY/mfR8xUipl1b6S/Khf9L10OWic//D4/AxnqOKNSyfY6Y1LJ9jvx5GHAcojnSu8zae g5Evz3/pXerlczRVn8NbxrGe6psTJE+a6p2gVKkd+kjKYSR9qbaSoxnszReV5rY9FEcWP7btCTly xNQgsTOQ7T/Bkd+NNz6KFfc1tS18njDq5525Nij2pPKo29jjg8x29WcQNARhkGco/ECwd5jG9oFW AYbdjQcNYFcbBj6p7nfkJXxTBKZ0yXaV+qICprdJnrm6Z6Ya32h3Kjmha9ZrA5hzTrGcTudPRhr1 qBc4F4R8hfq0OK9TwTfBsn5V69YW4C7Vo+XGyHo0dCzqg+T7d25eFf7/4f27/9j++68b1q5aEbF4 /uxp40cHDU8eOtivb8+uxn/E1fIaWbdiJL8m2ZRkPNnKWyT7kofN3xZzFW+LibYBXw1QzNX+jHFL PsMa/lTcJeSevPowyUb3pWxM0p/kEJLe5Kn7kNxGPvj2JHn3Nsn87m2pX+tyipSxJBc/lHIJyfLU 31WBZCLJJJLl6W+tQPJv+lvPmNslsv+3bE6nWRg4A2LAyHHIP2D7eI3tGP9c5//YLjN21gG2f9zb 9uybCzaPZPsaU8B0jSmg24AdTq7WvQKjaqYZFiHrdoE+v5gVF77qGJlukZRuyWAI0i0AXEa6sQlo D0zUWH9QZjJ8fdAM9AEJoOAUjZUC1UEgCAUFpiNPgN/AMXAGjJihsTFgIVgEtoFjoRq7CCLn4F4g 71zYHXAUXAe3wX0wZZ7G5oNFIBxEgiiwEWwCnefjHiAGFF+gsf+AtsAH+ILeIABMAD0XaWww8AdD wFQwD9Rbgr8R1AlHOwQEg5mge4TGekRktY6XXI4r/krClYRL8QkxCfGXEuJPCO2lpIQje47wnYSk reJEsZUHN+v+ekE5Eqc96R0v82hfkUxzhTO/B1Aok/9vc/2vhk8rszz9Y8Fm5IHfwAfIAx9OlPnh G5AG0kEJ5IOSwAdp70v5YCS4ORX1A3jvB41VBo1AY5AO2DSkLXgwzcgv74LNlG9k/0/shZhTxw7t +2vn1s0///TjymVLF86dOWPqxLHBI4b59+/d3UeWBKNv/irJa0K+rGnMxclSWZhqnNWIbHZjkrWp N6UOyfskH5AsQDa8IMkWJFuS3KrbdJIxJM+SLEO2/m2SdcjKf07yNsk7JPOR1c9PchTJ0SQ9yK/v RHI4yREkt1AtsZWkL/n9XUlGkVwpJCv7otPY9lrQds6VtjOQs7E5Mls7Z2OzM5DpY64XpNU3ag1W Iqtyx+31cbLZMSAX7LQLeB2UAlWBOxg+w7DpYzPY9e2gZAjsMPABJ8GpkCfNG7MzYHuml+m0+Bd0 xJEncCRgis121OrHVN9nbPk5a6L+L/G807sV6vbWIBbEAe+ZOA4egcfAcxbq8Vnc10++f/PqxbPH D+/+I3nbL+vXRC8Pnxfyw6RxQcMH+/Xs6qkPAue3lOI99B2MNa2D9DCse7CwevktJfjsyG5Gv0pJ mjU597Gul/0q82iG5LtppGeG/6yP+a6gvpoS6XoroJZ4Di9ruKaIy5vqnS0kt5K8QPIi9e0kW6+r Ia5LoeOt6fgc6/Hq4vhc0m+w6qsJ/UbSH7Lq3YX+MOlTrPqqQp9q8v9biRB741nSaCUoMhv+E/y0 cBAxR/ptl8h3uwpugfvkx9nprmf7iGmBGFPA1HdvWm/QdsA0qcT2n2CK2vRWuZ0Bmx9ZUosYc8Vt rxvV0UldN2qRS4ZVhBUL0MEU6mZd/9ORdM0HXgEFwavgLVAGlAXvgPKgKnAH1UFNUBs0Bc1Ac9AS tAa+4OGD+H8unY85dWTfrq2bN66JCl80N3Tq+NGBQ7/t29O3c7sW+szvd4WPRPO2lf1KYl/Oeqqc LGc9vZ+sz3qqpZxZR9n/QrmqHl1V33pVK+XMNsp+O+WqDnRVR+tVvZQz+yj7/ZSrBtBVftarJipn TlP2Zyr788k/XCCki+XvZP4OzxkelyUmWZb4wijybh2drD3QPVL1sLSUx/Uwyr+c3cZKP4/07Ao2 q7N2NqrZ287A/4cImjHzx1qy2Rd2zw/uyHLlc6ruvM7lHbeKrzDLe5oa4cs8YS2DhQ4GPd16gHSm jyVX5pnAhfX06g56gt7gOzAUfA+Gg0AwGUwBP4DpIAQsBktAOIgEy8EGsHGubMMfmWu042+AFdRm 5211T3AeXACD0CYfDB4m3rkedzHmxKE9u7ZtWr86KmLh7BlTJ40bFfg9f6evh29n6y8BuFpyi/ZV bssivpJTD1lzL6Y2Vyka8y6dKMvKCTEyfpK0IdQSCyW5iuRqkrupV25Pkiyne5P0cnoqySiPfyv7 MUlG6T5HV523XnVDOTNe2b+tXHWXrrpnvSpdOdNJsQPOiiVxIUtisVqSQsqZhZX9ospVxeiq4pDs zeeR9o40qjaqZeX/aATsaZ//lVJv2KFXHS2rgQvR9ge1F2msDhgLxoHpizU2A9RdYvSnDVjyXPt+ c3YA0fYon+0jtmNzZJTPdsD4KL5cL9OoT88njP/1UHqD9fE/R9JS7w8dC8aBuEiN/QMuLYO/CD5e obFPQDVQHSSA+6BLlMa8QDAYBSJXamwZ+B1sAXmiNfYyqAvqRfP3KW5dv3z+9IkDe3YpYz9hYSFh 0yaPHz0y4LtBA/r4dnG1/PhY+j9XHustntpMzIClEZFPqCVXhWRjkk1I9qMWWH+S00hOT5c1AS9j /M0Bve3U6Lo8Pv+GlAtIzrkp5VySSfFSJpMsckvKoiTz0Tyv/CTdSVa7K/+em3xuWC+9tepiib/L 3yJPukdaPm+BRqxqJlAtSO3aWglSn8b1PQ19utDntrz0gPRlX2R6Pkcb4IipsLP30fbI0IsK2PP+ t7m3J9Ooj77ed8bx/+J6un+A9PyI0ldN13iQGmWka0WkYx1waZXG0sDU1Rrr9yNsAxgHSq1FXgEe oCcYAYJBONgO8v6E9gZovx52B5TegPhAfeALVoNToOJGjVUB7qABmA7+BP6/wFaBuF9xf6Bt0thr oC4YAT77DXGBdVtQX4GLIBnU3Yo8CMaCcaD4No2VAGFgJrgHEkD97Rr7EqwCq8G7O9D+Ad7AD0SD VeCrnXiundxG3Um8mZia+G/ixcTT+N4Ub3n9K/YPJ7LEg9g3fw/iCLu4OzHLr2k0x9kYsXFi34As RnDUUZ4Mv/wiRo3UlWSs738ZI0lNebkMBqPA3+AMmLI6c7qOB3+DM6DQGrQTQQvQEiwBS4Ez0jcX eH2tkQ+qAH9wDBwHL63TWG4wD8xfZ+SHpAQ+0nP29IkjB/Zs/33D2hUR82dPm3yCm/lBA3r4erRX srqLpWAaf9s6KE239w0Zt27B1FNX2Nrz1UDoi1CPWCOr/iuhb0x2fjnJaySvk2xO8fW23udLcV0f 0h+w6usL/UHSl7Tep95/mTsTuKqK9o8PF+4VxCQty1J7LZFM619pb/tiab1mlojmFvmXv1pqKoiA G4qa+76ipWm5gruoJYoaxSLgjooLqKiIAioIbojw/mbOnDlzuPfC5YL2P/fzHWaes9zDnTPP88yc WZi8Af9+byFvzeTqiI5QIW/F5Av592fyv1d0LXfjCxWr1Ps+rdX04e95nuG27lluC32FLfyEXdOP yzcK+cf0p3z+Uee/PX2A7elNq9PaNl7Nnnur2j323LXFHkIW3v+b9/9xIaReWWWyJ/ABwWCUpLPH gj/ADvCv7ZoO/wS0g47+EgwHI0CbP+zLcxv7i+n2WF/TWZc4Iifs+ZF1Cd0MdpW+mu7fxubgQJQ3 NVKrruTtp5b29qV9Z8rt/4X8r1uV+fw52AbbvB20kmzymJ2KPd4Ktkl2OQNkgzvcRpv2MnuacyU9 7RS1A8zr3xD+2y8L5iTMmDJu1NAA3/59fLzZD6O0ZUSVKG0Zu0voWF4qSRCxQyJ2rIS2ldJ+stUN TsToaJoNpUlcmF/v4kj7CDDpXKZKoStjuN6N5X/T+NiQH4pU3fkloTp1AH+rlCJ0ajsmP8l17Wph H75g8jW8vpHM/x7jf8/y7zmn/DU4EKrqUQ/g8uX87wr+V9+ji/dwiC3id7+cW4IV/N3WHnp3qUp9 YS+X1aJ3dgayRlWVby57NR9L56Jaf21jfY9uTjjrfrFuZYEbVvfoztEtR2U9seUNB1sO060OuaWG dI7UxvK2za0+nxHHRcWJzu/WHNeImJpXJ6U3k5/RXNamjplMm9+B3pGDE9MjFvt/PVk67zqCrpKf PBvMk/zl18G7kt+8FWyX/Gcn+Mwu0Zof7Q18JH96D4iW/OqWoBX3qwtv5eVkXjh76tihpLjoqB1b N4av+nVx6NwZk38MGRHoN+D7//uWSBt/m1KklvIAEZtapGiFaUKSL2K3RczEx8dXe6BKOopYVxEb yI8aJCTrRGyziEXzo/4SkhIRcyhWY3TEAD3qOSEZIWI/ithP/KifheR5ocncRexlrvleERJvEfMR MV9+lJ+QrBOxjSW0/fdh5bn1ZlJdsY9qJ7VY2npOrlTObD3Hz45zPO04Z4m1c0pv/5BWYBpJ0w91 KlI+ab13G9gh1X/bgnbgRoyB5ILGcQbiEWeo6uyrYcdj4mfHOXIiskoTYuOa9/9J/lc0XzeBzeBg vIEcApEJBrITFIL7oGGigTwPuoJuIBysA/9JwrXBWrAOvLffQN4HtQ9Av4DmYDFYAtoeNJAvDtL3 gXk5Vy6lK8u+7E+I+5su/LJl4+oVixfNnjFh3IiAwYN+6NtH/feMpn3F1M8LYt7eUBaeZ2E68/yY l9T8GpSem2kYbUMdRD0zIztz+E3anuCSr0qdmLR6PpUOEFJHJh3IpC4FqtTApK4FVPqNkCottt4F tMV2niqFZH4BvaNIFu5kYSEL77Mwg605c5mFTuwNv5GFM1k4i4UxbIbQWBb2ZTOE9mctAXSOGmU+ mwH3VR1fJGJE2L1q3Do64y/xoHntFWsgPUAhMPF8fpXn8644JZ9Tge8+AxkGgsEksBfsA0HI97Hg beTzB2AEGAtmgXlgKfgVHAHJ4BrIBU54DkwgEASBv8AB0ATPRQswGoyRnhH6TISARofxXWAsmAky jxjIFVDvKHwY8BnoCrqBAWAgGAVGg21gO7gL7oHqyQbSH4SA+scMpD1YB3aCAyAdvH8c3w1+AqvB CZANWpxAXQj0AP5gPdgFToAs8HqKxTXAstknA59shpIifOznOXLufpr0ydeNCRUjQZXWQWutf7yV 0Il0ABZaDcX4zy6PukxXbVuAPQldB7F/fk+lm3x0Cb7x3p2Sxz/I8kzQ9dQyNQZ0RlnqAi6iLF0C GeDyEX35qg+agbelsvYl6CyVOR/QXyp7/mCkVAbHgulSWYwG+6Uyef+oOtdzVual86dTjh7YF7N3 5/Yt69csX/rT/FnTJo4NHjZkUL8+PYlaC7jBfeZc4TPXF37uiyLWgnvDb1jwmb8Xsf78qB+EZKCI BYnYSH5UsJCMFrFJIjaLHzVbSOaK2GIRW86PWiEkm0VMa9nYz2zZgRLRitGUtmJUMzVjOt5oepnZ gldY+D8sfJWFdF4yoymKhXOZhZzHwniEpPHDyv9//l2fzsuz3vBgPRHVTkpYX9hBl4iSO5FYWP/B zlaB+SVPOT/n9uwLxDTOwgyPztXMZUW1zWRSq4CTmP+3KsqqU7JiR11BDVAT1DtWVh0wurW1PWWc k2rTYfpzHreprqE/p41Nh+nPkRN7bEvYVxOouieBPYVPlZV/qj/kCd6Av/NvkAASwT1QCJ6En1MH ND+h+EPfcn9oPJgAVoJV4CX4Qk3BSXAKjDqJ5wv8AXaASJAFsk+ydiCq+eks/8mHE+P3Rm3bsi6M LvU8dVJIcMDgft/16vkt9a6bM/3Wi4W9WUjfhrmZltIRAb6aH7+MSVsVqVLFj29dxGbqF1LFj89n UjqnoiJV/PhhD6h0IZX6aVdYxKSsfXWwdixtY61uuqpKIclix9H1B5SzlW9yZu8wXxBS5exGxfRs L1VK12liksxifkeQXGH6W7MHyqyWBx7Q9Gm2L5XaQ1NasVojOCvs4iURu0b1v/ujyGfrXTBsVOXW +1fpXgbpOmjZuEfXDeuwHXusT0Bf6Ukq2FZd8+EGE7fxZx1rjb9ZrHpxSkp5N1Rr/OoSeSY5P8Ik kg/oq5Z8rf9HXVpHaQm6g0EgDeSlaOVxxCkDmQzCwC6QBPLAJ6dRmQARIBp0PGMgPcFMsAzcSzWQ B2BwGp4B8COYAGaCUBAOboKAs6hPgq/OGUgn4Ae2gTjQ+zzsEYhJN5AUkAOcLhjIR6A7mAqWgr0g BdwGr100kF6gNxgDxoLfwHIQA+LBH5egc8B5UAwmZBjIfJAM0sCTl/Ecg69AbzARLAXrQQxonGkg H4NBmeqY4GtSqHwy89MB/ZuZn3acfsSua0fyD7FPWv61hNKDifVredE6ngnpMscFy+sJmY0LLmf8 b/uy9PAHyOcPgT/4FSRK+X8TTEO+zwBhIBwkgERQB/n/FWgPpoCpNJ5q83uhSiesjwfSJSr9Pfas SmFj4rxte4jurc4QXcpfl+ruoNcEav+vh5HPniCMl/Fd4ATI4+Xdl5dxWp5PggKU2Vu87N4Bdy/Q ul9+9sXzaadTjh1Mktr85k4dFxI8PGjID337+PSg/7rR1DiP2jmPPKUG9GIetX1N8qhdbU1b+IZo tvpTth70etbKtoGFTVkrWzO2Xs9ndL2eANU2u5l8RJpa5eqmIWoaVwpgZ+y/o15fseZ0bR8309y7 qlSx5vPusnV/VCkkB1kbXjXWeufFwo736JlD6Ngdf+3MgHv0zFmqFJI57OimbMXJZizswEIvts50 MB3b010b+7NWpJX/4KyaxpXOsfNep9VH96rIr3vg1YuK7n0LeHIdbGN5z7EtUelCaaPGsT4Ph40J 69N16BJVsok6HSvPDlK/T8kTCFBmoNVpCnX8X1n5R23oAOAr2dIpYLZkU9eCCG5bY0Ect7HUtqZz +1oCOsKudgJJYD8IhB0NAk6woUawAISCx6+wtp+8nMyLZ08dO5wUF717x9aNa9la7wvnz5k2ecyo QP8B/Xy0n8DNNDEHz3aQVnYm5dCy8/Q1LoWkLlspdTWVBGpldg2Tel5XpcrZHa7Ts/epUkgS2Cqq DW7Q8DkWvsfC91n4dS4NO+dSTdQlV/W4u+aK9iQR8xexEblKi89IIZkuYvNEbDE/aomQbBCxzSK2 gx8VKST7RSxDxHLYXV5jYSOmJ93p+q/uDyuf4wKkp1RXPbaeiBtv02H6c+SlP2w9R05Yr6BHyYkq f//nwGPy27gKtgT0MM6vRVsCEi28/3uzhrls4uNmsjq2lslaIB4EXsUxoFWWgbQGTbLhK4PW4FPg dB3ngvVgw/VH1/fP+h7dDOO6hO4wXQ2v0u3wlWi7L7VJWjuIyGO/hxJ57PdhAxsb/ph8dHn9/wIJ eZrWYcaDTSAJnAbXQSfkdV9QG3ntAbqAgeAkyAV/Iu9TgCvy/HnpGfDKMZA+oNY1A2kE3sEz0AbM AL+BYlDnhoG0Az5gElgFroIS0CrXQNqCCBAJ0sFN0DLPQIaA8WA+CAXrwHpwEBwCNW8aiBtoDloD TzAezAM/gTXgBMgCT+cbSFMwH4SDaHCcygpwz8APDAXLwGbgewvPPQgHm0AueAD+dRu/D/gafAPm gXCQdNvSfFHXzCS8tniR5F9EjZF+zpT6lD6WPhSlRwmodUTd+0D9mtCW63+dK1O2b4M7oAny5yWw ECwCH+Up+fUx8C+Vbwt43i2T8i8SxEv5mApug6Lb13k94MjBpH1/7d0VGRG5LjIsMnLFkkXzZk6Z MGZkkP/Avvrioli7UPHWZAV/t7JSSLQeUJEiFsePiheSZBFLFbE0fhTtr1nDYCRMSKcS5N+KWImT EQm2xsJw1dHQUtTBIOoa7lRiNHlkUG/DF6HzMMXb8Mug1vnpyzSsy8KUKzQ8ycJ8FhYokqs0PHWV +TZZqg/EfZssKv06G9KhWj3GNYencUSNHPr+v6ry0brOviwn0iu7J9W2xAk5oevwvdzb2mHWE+Vs FV+5zc85y72nKdVCC/6I+mYyPFKKf2BSHQUxkstBN6ZLMg7DzVeTMdf/wwipVV4ZVHVqA9CM69YW YACIlX0v3YI51hMTWZfUcg/TnzPbpsP058jLngUT881F+x02EP6bVtD/8nPe/ESWO7GYjy1dzWXv 1jITSTn6bkWeIun7G5p9EbH5+0nN8vKY2s3tYDZs4x7QBLbwK9AeeIIOwAt0BJ3A16AzKAIPqBw2 shNwgj00ggSQyO3jfnAAHASHALljIA6gNnjhDh0LQKuBZ47E794avmzxolC2zQqdNH70yCF+AxGH qK+PNU1sNDVn70JasPcsbMbvjVot7y57q0JHfjEpJOEl9Dh6JtPE7DihuWkjEuFjgKHfqRVwf1BS 8gT7trb0Xc8GehjykyiybUJmFLILQuYkZLuLVZmjkJ0SMoOQ0RtTZPS+ajLZR6qM3U9LYaf+I2Jf i1gvbrt6CwntuUA8qjqPq9Yl1mnu/bYlYu1I6KZu0F1tk5zQdfdfRUptkmbdaGG01bBy9LN+tS9N q7tXeMUvqpM6Ny59exY13hP2lMtGwB28At4BX4COd+xr36/a6Q91gzMy5MTvMdYOsydh32bPCq/r PXpaXBE0oqGZrDw/wdLzWZvmt5y37jwvO4HVYA3Vw3foXKzQB3dRZwMDwW9gM8gEt8C/76GeAKaA hSAenAHOhQZSD0wA80EEiAMN7sPWgNbAC/iDcLATJIL9IB8UgC+KUF8Ek8BkEANOgAvgqQcG0hh4 gZ5gClgIVoGt4G9wFGSBYuBfbCATwVYQB14rgZ8LhoEQkAWKgD9+oWCwBKwAJcDFwZE0B++B3iAQ NDQ4kqZgMBgJosFR0NLRkXwOOoLC2+Tm7ZvX2eeKxY9yxGX2sbT/rMVP6dqc1iNUjAGvLff2tFBL 7FpWeabPgA/wBUFgpvRMbAN/gzMgX3pGXPAs1AWvgbfuKs+MJ5gCfgdOeCa6gtX3lP7dynifxNjo qD8iNoStXPbzgtnTJoUE/uDTxez5JqotDKN2dJPejhYJmWZH2xarMs2ODhUyzY5uVmXMjm4RPSQS ROywiF0RsTsiZuS21SRs62Mi1ljEPhCxdiLWjZ/ZXUj8RWyqiM0RsWUitp6fuUFItouY7bVY8lxF 8nlTO8l3D5fzxZ5EN8+KX41unnas413g2vvJyQ3WexCLurTQQvuppZWU3V1skcnatzL32tDsy0iV 3yupXpnyOxZ6fBN4Bjq6JbA+e214JymvKz0Xbniw1LitW8/1USXEJvlUm0jl8/xRP5+ktqV8HAR8 gR8YzG1zWCn7nMRt9HGQKdlqB9jkeqBFkWa3u4G+YIxkw0PBKrAb3MpOTzlAh/fs2RMZsTEcRiB0 zvRJ40YPD/Dt/52Pt2QJFA3mKHRZbRFryLWaNlayiYhpNaP2IubNj/9WSAJFbIaIrRGxbfx4TctG 26xlrdVQlX57s1jPxdksnHNfOYsORVfs1Z/3VXtFM1KRZQqZs5B1KFJl1YQsRMi0eml3YSfZQ9Ww Mvltvapm45LN1ifH/VtO6N7KzVpp7TAbExXZ/tmWPcVHr3j9j+qRumYrPlvSVaSmPeV2Z09Jm+vW 37Ux4StX2uy6gDztum6Pfvu0Ir+dN3Gi+demdlw9a616Jy1o2NEV1rr231VDs68ilborUkPWw7Re FQuKQTPUlQJBNMgEHVBXehn1ou7gG+ANepSUZfN1iW1dpXGrulXXH2Jiopz40WoCm70lrfyWls2k snn+MJ9E4mZvvrvhN3scrAZrQBzqwvEgA3Xfy8CL1337ODmS78BNkA88jI7kRSOtE1+/dPpwXFRE 2Mpff1kwb9rkcSFDAwb0+67XN1292ot7NZquFtJ22vrU4o1S2mkbsN784ffVdlqlf99aZj+VUU67 WR/+l6ilC9beiDVlvfDbFKtSByb9nLUD9y3hUkj6lejbgenZ1FK7mdoWqW3IyhW1NYGVPj9fFalW O5geuVlvjbs8UGWaNY4WMq2VOFPItNotbcNWZFrtdpSQabXbtUJG/zuldntRlbHardb/P5v2/29Q FXn5AfgQtASBIAjo3gfq5nPRdeq7Kid0/eorvUf3Bk+3x/od7LNjj42XtnWTenCMKtWDQ+rdJx0V XG4/j2FEWiFQ1wpI6tB8/V/QD2wCf/J8DgdbQQl4Evk5BSwHW8FfIA1kgWLgiu9sAj4EXsAbDAa/ gERwHLhWcyR1QTvQDZwDBcDg7EgcQX3QALwH6uEp9wK9wBAQCMJAOHjWFfvBIOALYsAJcAE8VcOR NAZ9wBAQBZLAM4/hOQXvgE9BBrgHPGpCBlaALSABpIMLoLGbI5nzuCNZBG6CarUclbHcNzJLfdJF LI2kpN9ITyY3km8cYp8Us096wt83dt9gnZXM++rL6/bW1rXg6VvuROuetOZv2ev8Whs7QNpaK7/H wHHQCHnnDvykPF0KtiDvIsBRkGwlH98Hz1ZX8rM+6FAqXwN43o4GU8ESKZ/vFORdvXw+7fjRxPiY 6D27tkesXfPb0sWLFsydNWPG5LGj6Pjf3j3xK1KdFi5qXfa0gZVVO1Pe9hnZaC4ju6bRtI+Fl1lI Z2jkM0vUoNOpG02P3aXW433a4ztEszIfsH7g36pSSHqwfuCDWZ9ufxYuZeEy1hs8m/b7Hq1Zmhwm fbdQlSpXfY/Zxp9UKSQ/s77ghwpV26WMfzvC+nsfZfuuFHJLqnRGafwo8lo3G5duCIY9e+xJ6HoH 2rhH16e70ndgY6dw3RSGljcrdUWzEf8h6jseyVaMLj1fYF1byuLv4AjIAgZXRQfrhr8myfMr2vP+ VZcI3CdVLyt9NbFVtF0uuKipY4HrnjLaYhMt+OW2ysr2yyva7kDvlb4p3Gih9XBcIzOZaHcgj1nL X2pjm4C3QHvwvWRzR4HpYCXYzW1wLCgGzWBvx4Fz4E3Y2O4gBiyDTY0D8aDwVm725QtpJ5MPJsT+ uev3LevDfg2dPm7YoN7dPcWQe6qdp4lWsAjq7W/Rt3jNKFJlmo99R8g0H7veA1Wm+dj+Qqb52IeE TPOxPYpVmeZjdxQyzceersrYfc8QPvZ8EdsgYrEidkzELhQr9uiikGSJmEFYrWdF7CURe/O/5N0H eBTV2sDxwUlCkY54aSqgIAQLCFhARJFiJwhKEVSESwkWBETpnYTeuxQbvUlvCkh5TEAE5MNQAoQU msklQUpIQr7/eafsTJLNF5OA3ufb5feyc2Z2NsmZU6bsGbMle8pO8Rzj9IxpMdh+5Rl1Ql37opXL zbxelY0zOt4nVrXK1bXly81zBvbDsaf/vbmnn5PzP846R8uwNOdunaMV91ZGf07TF66MQfSDB+NB +sIP4UvMxS7sRtESulYMczEPOb7iJztHjrN46Dk7E9n5nJ+8znE8HK12fse+WvaOSvVPVttOdf90 n5LBtqrdm1t5PeAe+g6oXZK6AN3xKTbfq2tbULQUyyMEofAvQ/2BdWV1bT1iEYd3y7E/ingkYNB9 /BxoXl7XWiDpxjVzYKCIa6dOhB38xdg/WLt6xdJF36o9hGvsIowaqb4lZv/ivn4fyDEjdR+QfEM8 /ecn5djPLiuVlN2Sou7EmG+wkdIyNW3P/8JV6bNfV7GnxN+kL39E4ljpxY+TGCn97ijpdz+iWiYZ C7ipfPajcqSqs8QuEh+QfYzyElMlarfUO6VtkXe+Ie9UrYuvjAHsKyMA+/o1lqV/lLhd4geyTAeJ 22SZH1Kt802j1Dkmv9EyapBWLa8jX8uV1rVHS6fPlxb369r7WIpNqF6BfUb0qahrZ3ARycj/oK4d wG+Ix12Vda0g6qIRVlaFP+0ETuLyI9QR2Pso2yBKPUbfA7XxDBrjZXTDRxiLiZiCGdiLnzHoCeZh BvZgdG1+dmzARvR/kvdgKqbhS8xD36d0rR/GP816MQNJV5Niky5IVM8LETx/N6YuJB1K2ifPPTyt GEvqoaQdSbEbYplaBUeRK6QHqv/eypfno5c0n4zu9p3fXsJ1H28v3+Mvbi6TlfuFZ3ynCPf3QbQX 70TZde0ruMb/8D4ni3dqyeLasvM5roHZXHNivM7xPuHay3PNcbV4GQ0Z69h/G5LJ3Z0GO1oOx5FC V9titCjW3C55tFLOujUG5zCKsj0aj1Omq+OLikZZV2X7VxzEIRx2lPUEfMXO5tc4S1mPxH2U9/ux omr2jgFkZ6/d+xzXGDA53p8Pz9piuTvhfvwfuT04g/3/dNtP6dud72nr/HDsp87/Bf2o8/uj8OO6 VgTTHXX4XrxfU9fa4+latAe11DHBPy5EnDr6m9Hob9+2eYOn2afVHztq5LDBA/p+3uvTj40/kK/f HPmGdg/51nNPiYXku8+FJT4rsZ7E3TImxB6JLWVkiFYS/aSFzyvxmrTw1yU+JC18JSNKO19Z4nqJ GyRelnY9XmINaYWfkBgh8azdIkfK2qMkRkuMkXhO4rPyGfXkCOCIRLNnUsA46zVSUtVoEEaqcbTw EelxHLBTjd7Or5LaPsnqA8lX0/xzO498aG990QCjarvb4j5PGW2u6wLw7IwH9f90IiFri7km5JFB TWHWDeWymmcPP6NrNVELSUjG/jpsIziPC2j8rK41wfzndG0BtmIbNr9APwJvNqCtwWAEIRgrX2S7 Q9WG9CuwrbGu/YBIRGFZE11bju9f1rU1WP8qPxdOIhyRr+nGWKFxl85HqxHjqB7ipH4g/rh10/o1 q5YvUaNHxKnhI8aPCR4xdJDnD+Prd0ZKaoTEvHIOOZ/Eu6UfXVBiMSmvxSU6+91Gie0t7/1cYrzE BImlpNyXllhe4usS35AYI/GcxMckjpTeepDEKFl/tMQfZW3j5acyrhV7W5ZvKbGDxKLyrmISPXc7 MWqXV2T0ikkSD0j8VeJs6katuurzzsQsbMcO7EQYjuE4TuJPXMU1lCDv70FJPIrHM9ge/OrqWj4E YwG+wjL4sX0UR0U8hFp4Dh3RHTOwAquwGkdwFKPqsV1iDOZhAzZiez3PtnYEZ3AWl5CIJvXpk+J9 BOIgonEDfs+zL4C5mIfvsBCL8AN+xHaUZNutgOGY8YKxDavt9yhicSMhzvgXczJG/ZcQFxZ3OM6Y jFH/qxiq0s1lDsfFSKrMj4nzvD9O5hVW92zzcnbQ6t1ntC/h7eyfc2+ikPmat6rJgL+jbOe4IvTe ZmSniszdCvcfNiGPTOp/tf3+B4moTR7Vx1CMxyqsxvcIQSj24RLuaqRrOu5GFdTCGMzACmxVaeT1 82iPD9AB/dAfAzATq7Aam7DFUfdfwZ+4Ch/q/5IohapYi934GUdQ7SVdewqv4x1swQGE4zJK0m7c i94YhZVYhdXYjFCcRwIKv0LdhBp4Eu+gLdqhI/6NThiCWZiNr3EKF3Et7qJ6Roarf3HmlDvl2G/y Ks0z0lgm/eJqDyBNDVAi81LtbbSHDOqM5n+1rY1C/td1rQB+RBiO4RZS0e0NXfsQt5CKOk11rS5C ENo0s2MB/zUTzmtPMxkTOItri83VOc6HY19wqHl+2Cz1nquByqpttgV52wVrsNaR51G4iufJ86bo iUGObaAYKqI9Pstge5hA/k/HDoQgjPw/h54B1BMY3UzX5qDgm+wzojnewlIsx2bsx0VcQbHmulYJ lVEVDdAMD7SgDkAN1EQdNEAgZmI3EtDrLeoevPE2vzO6Y0srPrs1bSDG4TtUa0M9iMOIRMA7utYG f0BryzwEIBwxbeW6oD+SYsw7Mxj/a2eOm9PG/0d4XjFfKQfMaZUemvbuDhndu9XbEUHXUUNHLeGu Ebze/yEgN8p0jwBPns7Ea+TV6+hL3vRDVzMv+mOGmSe7zHw5ingzfz5x5MlWtOFv/04bo38fe0n1 708eO3Rg766tmy6tPy/9+nnTp0wcN8LY5+/WRW309Lhlv32T9M03S9SlB+0jcYj0oIfK+YC5SdaR 9eaaur5zlT39pqxptSx7QuJJecd1e4lm8o789lH9AHlHAemN35CYKLGy9MkflnhSeuad5TrUIuqo /lDPnnxROdY/z0419uTnS+pxO9XYkz8hZynUXQkklZSPHXslJ8yev3ldUqpxXdJaOYqwTuIxiceJ WpU7kX9lKSPl2uqZjBHj/T6uuTvh/cLNO7UC11VFOf59PA9vR3zTjfjsahW0Ms78+aodfRnswm6U eJf9PAQhGDXe07UnsAM78ROavU/fHyEIxeD29I1Q/QNdO92B/TH4dNQ1XwzEIBz8t64dQlBn1ovl WIFOXXStM4ZjBwp0pX/Z1Sj/8ezfnz39+5H9IXt3/LB+zfIlX82aHk/hDxrevw//9+7Z/aNA+2/h N1DKm3E/KB8pFRUkVpTYOtkugSM9paqolCp17zxJVWcN7fJkld1dcryth6oFhlultIhfBVULjPCs qWKyWlOYlUrKMfnEgBTrfcZyzVLUcmesVFIi5HjDWakhuqufb5inLvhU6gJ1DYiRaqyjbKpax3gr lZQJ8pOeknjaPgpwWMa/bSnHN1tJLHVNlX/Vfl3ElbaevG9EXrfABMzCQUSjAPldHg3QBl0wGGeR An/y/3kEYgSmYjEKsT1UwH6cQTG2jSqYjGX4gm1kPH5CmGObeQUtsBxbkYoSbDfbEIIw/AeVO9Ee oT0GYReO4W22qUDHNpaAZNRm23rZsa1NwhSUZlt7DG3wLj7EQIzBNCzGcqzGbhzAIaSiQCC/Jyqg EuqjI/oHSv8gNm0bn+6Z0RKxZjxHjJDXKp6z5hpbe+bnDe/N9MiA1upOlPvs7Mh7n8jxsPreV+06 ReQ6w+Oa43qP6/7Prve45nhfgfe/geY69zdCxnv0jPXoOIvnWGp4JmcIh6VvDUrlpF5+1ywPHRzb +gCMw3hEIwZtu2W2DXgfKMb7nCzmZ44nvDf3rgnvP1sWJyK8zjmuZfBw5Gm4c6DncC3NNzyCvHzz Y6SV/6X/aj62wyMf6tqjqIO6mI4yH9EeoCu6f6xrnyIU+5CETz7Rtee6U698qmslURpl8BJexoAe bIeYh19wM+HiuWgeEdHH5ITfT1uMA/lzpo0bMVTdBSY6ulsH+w9SRFq6fKOtdtG4gl+mafvmSqu9 T507C9fMa0N9/fZLL/igxEOyxCJ1xqydZwz13knWtLHOi9Y088okW2vzlbWVld5+L4mfSewvbfkA acv3pVhL+8iam96ypnWZXmpPG239Mum5bJK4WWKwtOejUu3vpoVbv6saS1JNGO18Jfm8k+rzgjw9 FP9b1rTxmwywpiupvA7CVEzHPeRvVdQnT5ujJdqgN77APCzBcvyInTiCMMSjIvn/FAZiHPKR9/lR HhXREI3RG1/gNOJQmW2grrktNEcwpmABvsFBhKMY28b9qIGaWIrtOIAwRCIaFXqynaIb+mIu1mAn Lqu0XmzbmIDJWIffUPUz1osjiEHt3vRDcAb657rWGl1Q9wv2k+DTh/YSD6Mq+mIiJmM+jiD5RsKN izwTzP+tZ4L5VK+TZfqiGZPtJaPsdGtKPU9JdB0fyORbQM5eQZqxgFrdqTKd46o4i3tEufs5Wbwu I4vNhPcf1LVX6Jpw9SjcD0d9PjqDY/xdXHf8aJfH3WpY9b9V36ry8zbloiUmYYejrCyiXCzGdcrD DYRTFk7htKNc+KAF5eEt6H2McvEu3kNI38z2/b1PeP+De98nv40HD27jh7p6h6453vM/43ye6KXF n5DB/j9bTek7kfeh+AUH0LKfrrXCzwjB2f7U2fAfqGvV0GQQ9Qd6oCeaDWY/A5WGyHGAy+ej7RGh I3/e89P2bcY1QPO/tE7uqzvEdHf8lfzGy/HACRI/kuOBH0ucKXGWxPVyTc8GiSnSI7gl8V9y7K+U HPsLVq3/RE8bPUpSiydbqcb+eAlp+++V+C+JQ6QfMFT29aVdnmj0SsIlfYy07mMdxwfDJZ6V90ZK jJIYIsuHSiwty5SReMjex/9BjhD8odr2CZ62vnKqOc0SD8s7VklU9xjV/FX7FIUY3ERe8qgBWqEN PkR98qUlJmMFwhGP4uSPvyO/8pFP9+AoeXUOXYfqWj9UGU6fAOsQgceCdK0etuAcXhlPPmMRViJ4 Iu0yCk2iLUbxqbr2AJJQeJqulcXj6IvRGIvZmI/12ICR03XtS+SbQSWHp9EE7dADvRCMdQhFEgrN pH+BRig3m31eDMJYNPySth9XUWYuv9s8XQvEZlyPvXDd9YxMM+1OPfE7T28zIy/8YlYtGV3r67i2 t2j6a3vd9/oqYfUOHMulG/89IDfLZ2X0QV80It8b4yAO4bNh9PmGZbkfkJ2dwn/yhKv1yvEc7xPu h6Oun6S5WwmzNSib1Xz7HK1HUCdgPTagzkj6iuiPAXgvWNfex0RMQslRunYvNmIT5o2hjOIgDqHM WH4ArMBKNKLsJ1+7cum81PD7Q3bt2LR+xdKv58+ablTtaoCQ9u++o6m67omLqg6rKaPc71Fj309S NV5embdXUotcslKN/b2il1TqC3aqsd/W4JJaT5VYFatKDJW4T+4N1FTdBWiKp3YPkHsDDbZSSRkS p5brcNlaq/GN646XVep3KnWyp8VYKKn+8Vaqsc5q8WqdI61UUoLkDmZdr1jrNM4QBV5RP1c3iUXk CG7RP9Vys/+0ljM+ZY6kdrpqpRqf0vmq+pQtViopW3mtPXin8jaLZTiLd+30/p4sfo5r2JAszsnO RHbqMe9zPA9HWZ6iZXwkcHImRwIn2f1/q9w1xo0JupaIgpM8bW8tnJ1MG4BLU3TtD4ygHR6Jy4hH H7Mtttre/rS7AzCGNnUsijra1cYzc2Ff0DWRuxcQ5/gY8t/yE2RyDNmR61PTH/8td6fzPoC+VDOc m6Nr5/Gno09VFsXpT5XA91iDtViH9diAjfNc1/seO3pgn+wGbFb3iIwzbhI3Pm7MJWtXwPgj+PrV lx728xJfkNhA4osSG0o8KzFSonHW7z7p/1eV/re/xB3S/94pcZ8sY9yHOUXG/RiijjFO9dTZQ+W4 4sSbVqpRQ0+SKxFayrpbSZwicarEcvI598kZw6Bk651GLR4sZxYrpJippFSUn8RffuZqEj1XKBt7 BUfkfjLn5E4y5yXOlrvHzCFqj+RWnmwy+8LHcQKPzaePjlfxGj5ZoGvdcWrBP7v838aJ7PRcXSNn ZedDzUcetrw8eTIo/381707jua90rRM6o+DX1BcojOZogY/RG0MxDGMxDydwEtG4jprfUMfgVbTD YizBRoR8Y5bz2HNREadOhP3Pr/tDVDnfuGaFNUDssIF9enXv1snzSxrjGgSlWCMcTEsxxkaYbqdE 2K+u2K8K3DKWuvuWldLEftXafvWBuVQHO2WB/WqN/WqrudQ2O+Vn+5VnDPGLUk4vSawupVV9Oyiv fDtI3cf2d0kLS7XHFuqXItfwBMg7mkncLnGHUWPJ8lGe5dXQ4Sw/RtJPSVTnR3zvosYgvZ6867lb 6v4fVr6r/K5u5vlA8jjIkc8FzXy18tPKRyv/rHwr8C37xAvZN8RWnMYt3LNI1+7HnCW69uxS9vex c5muReGV5awbiUhB+RXsZ6IeXkZTtEQgZmIRNmAjohGDRNxEmZXUV3gYVfAM6qAhGiEAzRCIbhiG 4ZiJWViMJdiAjdiNPTiOE0hCKqqtYltHR4zFUqzCZqQkXtMS4xK1xPNRiSnm82TieZUWpiWq/9Tz MM84e763p7FsXNrj985v9/qwJ+/jOJ6f6XkAHzVtHx9QdwvQmt+uMu29RnKNC5q7NazrylzvE1s7 OkYWcd36xfvE1vez8Z4jjveoh1H7qnF3/uKdpsYWeKn4yQc1vxuOUVTNh9+2vOnTpqa/05MxUhQf 6roSuGRm9a8qz3ejIAqhMIpgCmV6KqZhOr5dqGdyHbRrYmew40+S1fc4J7zfrjU7E1n8CW7Tw8yD v2lbkO2w2F/N5++wCEuwDMuxEquxBmuxHhuxGVvStAWpGEFbMBKzl7jbhFfxATpg6FI1RizN/4UY 142gv1swZ8bUyeZXfdVVv3IRQBHp9RpX4rbQVK/XuBY2XmKCp2VUQ6Izt6H0mhtJbC3LtJF4RmKE Z3l1SF4z+tHDbxpt+4ibVjseZL8aZb8aYy411k4Zb7+aaL+abC41xU6ZZr+aYb+aZS41205ZbL9a Yr9aKnsTyyQ+rno8ftVTjH5EDfn9npBY0+wL1bL7PZ+pTkXlnOTp3nKObcpVSr1PBN+p9zgnRmhZ eGSvNC703XR3aDHNr7hfQRKdvKWlpnlkv1XwfHa6dWY1rXB2y+YwfI1vsAd7EY5TuIprKEf/7j68 iIbouiyz7/9ksfH2PvEf50R2Vn3+v39Omqu/037fzxwl0vH9n5zkZSAmYOIyT38+Ws0z++v9McDs t8/CQrP//r/snQd8FdW2xiccEkINKkWKelHxAgLiE7hXEAWV8mj66IQqNQiiFKUKRBL0KVWQJiiC tAsEkBAITVogQKSXUEILAgmBEAIEQgL322v2WbMnOXOYnASe1+fk999Z+1v7zEnOPrvMnlkzi5Q5 fKwyj08T93w9ffLQ/siIjet+Wb7w55/EfR2+/lIs5PTrE9C1o7/+L4p+7BT3Y6fdHMmVYKskHfOU orQcpeXvixUWsfKjjxsdNdHL1yW1NasdSG1DrzDOz8rRITWVRpOl5F1GrzzIr2xPrzxE6h1W9bMX d0l97oFT9SdVPMPEz6ceq21JrU9qR1bbkNqJ1M9YbU3qIFJnsNqK1JmkhrPaktR1ov0/n9P16MmK hydhtjl7gtAUUGdqUOs22CqWta2S7X6+ipZrwYOZ+Wugl7+ZP1Pv7TPHO5NmjCYZZvyu7gSkPeVs eynKcfTTIcaxdFnleLoCqAgqg3/I4+sD7yv/l+nJmTvVzIEge8Wq2ivWwKqYzYxpb3+kzUXtefpt yTz3cPFt8ctO3Yu1lbdDjPWVpiHGGktAiLHOEhhirLWMDzHWWxaEGGsuoSH6ukvqLfHM39PHj4gZ /wZ9xj9r2rfj/zdIf9p7t07+cp2vIPf7T8u5bQlWSrFVTvrKs/IaW7Wk701WarPVSvpas9KWrU+k rx8rA9gaLn2fszKSrS+l7ytWvmZrMlvfsTWNrRnylTNZmcXWAulbyMpitnZKXyQru9k6mS7O/3pa jysqKt/aJepXeIGaGVzFXrEAe8W62SvWQrPeHmVrctV6m9p+v/6a94IHqV5xjiXe+ru2yJX5XRO9 THmx+Wx1oSV62/qLC9ppk2ItNBxsDTHWRKNC9HVR03zeNPTurK1k3BT7ZzaLWb9mfBtbxay3LB2P ibqzrrc5eW3Vx+P+dvo9rH7FuveNEH3tOw2kg/sh+jp4M7kO/o1cBw+R6+B1VqA/AbPAbHAMRINi Kx1acdAINAZ9wcfgIDgEzgDxTNjLsadPHNkftUtEeq9YNn/uzGmTxn8VLI4C+vYO6N5BVo6fz7W7 zhmt6Be8fRLpms1mtBLSPFXMeT9NdZboSiX0ezUZKyb56PlCvvm86FxqPCkvUoy3rpS9J5SRQvHV lVHGVZ+03y6a86pPP59qrH5AanVS+7LamdSPSd3KaidSt9FZ3+2URqTpvfaONGdfvY+ti9J3iZVb bKVJXzorD9jy5X4/nxwT8lP/n906tjmxm6FmptrLTHhMHnebqzlzDrZR8fuhbTSb7yf2a9kn+Ilz VrtAFBiE+hwKdoLdIBWkr9DbassMbfUkOAviwFO/YH4IfgRh4L1VmD+AUyBfKPyrHdqL4DYoFYb5 JKgN6oBGYBQYB3aAAyD/Gof2JCgCngHF1uI3OByO40xwHeRe59C6gQFgIAgGY8BcMA8sAAvBWhAO joBj4CK4AR6A/Osx3wXlQQNwZQP+Z3AP5N2Ivx0UBIVAafAsqAkGgIHgvvBvgh+8AF4ErUBr4A/a bZLPDNJ/EtnSI3gTzxiK8ydG+cmoidc5bVSnw8V1wPKMnxfyXjLO1+W9gDn+t7Wn/fRZWe+XQZxS 59Z3cz1r6Tlo6bHO7LH07LD0WL/G5LEuttbSY39TrtDz9hLX7Ll8vpf5Hg7Ka/JleI3qy5vBl/n+ r74ZX/2Uu7pMBjfBKLThQLANbAdHwFHQH+15ALgl27azTY+UbTpCtul8a/Q2XXSt3pb90H4Lg1rg TfBWuFj7S4iLPXvi2L6oHds2rgtduWSRGPcnjA0KFKN+187tTB+iPpKNpnsaBN0Q4+nKG87x9CNN jKe/kLok2an2IXVpslDDbjrV3qSuoStm77H6IalppNa55VR7kfr2LaGOYjWA1EC6J/weSqPoStum t1Eitz5neO+2UK4IxaErCaSkCyWXrtwnpXYKFC9dqZMi3um3FOc79aR32psiyvUTT5Ly0cv1p2dL RQvFW1eO07VoITw7EpfI+Pmc43x32tN5cf+XMjldz57czdn00CObLXajpWe5pcf0cFCbf5tNj2lT 2rHS9nK7abkON75cbnxeGX2u5itKeZ9M7d9O22wCmoLmoCVoBTqATqBzuO01X088pkteTXdk3/g3 W8UmlLNXTD28VLYszb2mPFju276g5lPKxbHestyZ5l4e7jvTflzt29U80tV3o7Cd+u0BPgJ9wcdg NQgDh8L1OVkZzKWeB5VAW9BVzs26K/Oz0cocbbIyT/sZzFfma2FyzpZqOg7cvHFN6MqQJYvm/TDz u4ny0fC9e3xAVaSPBfmT+ExPkn58U4qV0mw9w9azstRzrFRmq6b0vcHKm2w1kb6mrLRnqwPdSbwj pQGUTqH0R0rnUJzHVRHnkUfvp6+Rnp9GsQKUNqO0+Q39PVrccO65HVsfSF8XVrqx1Vv6+rDSl60B 0jeQlS9gaWVzon7drNqome3ZzZgurjJ5VtrLmF5jHY2bs5s+GjwRtD+X2hPncT1Xe5T9jas+oXBW 2qf1aRfzsf5AW8V6F7YqlgOnarL8OQ72Uz9H8Xnpn+OuzNdMZHPfRh252He2j/+N98u0b1fvly9j vyuOlXes04+Xj67Tj5nzrdePlcvJY+V96vdgt/qxm568OE39HrgppmamqJkxlp7Blp6HbkobfKBZ z6y0HGqf2av7Kp6/XW5f/a3Eb1dvl/doLq2oVsBundff4NAagADQC8wBS8BZEL9BXztJUNZP8mw0 1lDygwLKWkpJuZ7yjFxTca6nhIJfwc2NtA58Nf7CuZPRB/eJQNCN6/QL/7+fOmnsV6NHDB3Ur29A 9y6ySr19ctEd7QtSdGYTEZ3ZUh9hm5IyTyjperzMz9f0cXD+Nec4uJCtVdIXyspqtsLYWiNLrWVl HVs7pG8nK0fYOkp/4zFKz1FajJ5OUiZR/I1tkPq20v/qtqQPoXQoeaeLSNL7+n8w47pQwoTyQFfW kBIvFE3fw5Xr+t+RcN357vfY8pUzmLxJYvzPTt2ajvVMTz63+Yx30yParTOmHZgel2TKzHtDyfxg WSwHt8fTR3O/4Hom0crLeV849FT/zC17Ktcxofcz9niFstJGD3gwYk9TK8W6WC81o4T0aJp6Dk9s yn+Trj3uPvqR98c5OP7bmsvkc9X3pm/U17YfbDTWt8soa9yvgnfkWrfpaN2TmyKZMhcsM2Hq98A0 qTcXU79i1gcCIdrj2Bx+2uObyWXoJfwy9BItXfYSml9W61uc22gD2irnOHqCIWAsGAfGg1MgBtT8 1aG9AdaCcFB6M/oUUB50Bd3ARDAJ3AYpIPcWEft3M/HKxXMx0YeiIrdtCl+9YsmCuT9OmyIu/Je3 ++7epRNGut10H4g98WIErCLu7XBPHxNfpfs6dKC0I6XTKf2Z0vlXRHnfBJRP08vnTRB6MKVjEsT6 6YUEOWuQUbu/k/raVafqRWrVq/poWu2qc3xtwJY/Wz1kqZ6sBLDVi60PZane+F0gl59G4ghk5BrH RC45W5b8gZU5bK2SvlBWtrK1je5tsZ3S38SOy2alTm32/6bH5M6ItCpm/Zreaka9MsjG9p8/Bji0 nOk17PX/7WQdi/r9SbbZe5v0troF+KE9FpftcymogLZZFVQD74K6oB1oD4aC4WAiCNjq0D4Hlbc5 tP8BzcAasAV02w4/CAYTwVwQAm4ArwiHlgtUAa+Cd0Fd0B30AP3BABAEgsEEMBF8D2aB1SAM7AX7 QCy4AJLBTeC1A/sHfqAwKAteAvVAAzAQzALLwAGQCG6C+6DQTof2BNgAfgUFIrEf8BZ4G0wCM0Eo eHqXQysByoCXwCu7RGxoEv1cAZdkjKfIa5fY8bCQ0KRMP7EidZ7ndfVsGKtzvxT/6Z8TfbX6nagu vxfWxwYmj/Xob/J4cjhgM7NNzdjctSmG0PSacMuMsT1kpL6n3reF7/OccdaflmHu6ywV4OVu/p9x xqwVtao/0a7bKm27n2zfw2QbTwf3QX608efBa6DnVr3dq20+FG16NdgJIkEsuACSZHtPVtp8ZaXd p91VTgDQ8X/oyiXz54r7/InYP/1aYOVDFSPefb7GSeO4j4oyJqQSKzXZeoPiNvRo+IaUNqK4jB4c rfGxJsb4nqQOYbUvqUNdx4SMixXdqk/bOJS+q88t/ONEmfGU/khpGKXbKN0eJ+YidcU9rFL18vXi 9b+5frzzL32fre7S14OVALaGS9/nrHzD1liaJ42jdBqlG+PF+J+duj7QXqkAN+vBw+0VUzOmC7RM sXwmz2gPMq42Z2spbWpjqY/9+PKxr/8Wyqk2a7q/a7yaMZ0ntz7AM2VMdz216bHORKuZQ2pmvhrd Y13M3palesp+VI+r87ky0kf5Dt/N8B3Ow990MVZoTzj727eVuVbXCGO+9UmEMef6FAwCQ8AXEfoc 7K/4nxzdst3+sxr/k526F/PvcRHGHHxGhDEPXxVhzMWjIoz5+PEIY06eFGHMyx9E6HNz+/E/r/Bo X0Ne0VyTlVpsNZS+Rqy0ZKuT9HVmpQtbg6VvCCvD2PpW+lzF7PwgfT+y8pMpLkf4/sXKUrZWs7WG rXC21stXbmBlE1uR0reLlT1sxUlfPCsJbKWni+u/Pa3Hv+J//hzxP3bapDhezg0KKsfNxeWx81/x P17/0fE/D6tfsTZSS66P1JdrJN/LNZL9co0kWa6RjNnp0L4E58B5UDrSoT0D2oH2YKJcI1mVYY2k rFwjUWN/tmwKW7Vk0ZzZ06aM/0Z/4Iu4CjhzFXn75KVIn6Ic6fMpqcUoxmcopcOoxGwuMZBK/EC+ g5QeosifJ0Sczw39GOxJivxpLJTrutKElIVCSdSVRRQLVIMjeQbQfmtSfE8HVvuT2pHUb1ntR+pk Ui+y+gmpl2Qcz2WO3kkyxfHQ2Vvux4uz9az0PcdKGbYqsFVRlqok+v/ns1PH2Y79eVwRPoGau02Z LSdmXB/5s8f/FPK0rbYF/qDybof2CvgOTAWv73FoNfa4Oy9o8py19FhnTJeLmzyHLT3Wr/HEYwox MXlMESImj3NTvm033Vx/lOxyfc99bMgNN/u77noto6iduuwGuoMkcANUjXJo1UA9UB/Eggugx28O rSdYAVaCRHAdVNvr0KqDoWAYCN6HfgSM3O/QRoHlYAVYCVJkHMjhA+JBn2tCQ3jRb8SwAZ8EdO/S SV908vYZQdfKjqQ0hNLlFPOxiGM+PqdyiynmYxVHdwwnNZSiO+6wOozUu6S+ydEdQ0l9i2I+Pmd1 iP7+FO2xk9JIivloKOI57uhjQyOK57gklBRduUzKXaHc1pVUUt4QER63dKUWxXzs4piPwfROu+kZ JTcpvUXxH9NFtMdNeT0QxX+Ix/z6JuuKRncdPszxHoNoL0dI9eVR8DPxMb7wiqz7fuAiSAPPK/U+ bI9Rz0Hguyi9jseCGUpdr5d1nf6bXtd1ZF1/AYLAuL16nY8DDQ44tP8GbUB3MAQcB5dBHEgF90Dx g+h3QClQGlQClUFD0BR0AEFgEpgLboHboOghh7b2sEPbCSLBUXAMnAAnQRy4AnyPOLTaoA7YA06A k+A6SAIvHHVoL4K/g3KgLWgH+oJ/gUjw5TEcN4EY8DvoFO3QOkc74/6uJN+Lxe8zV86YovxiXYX6 nTGF+sVmCgQ8di/WdF7HkTm+j+P+LOICM8f/tXwU7dv6Hl+mAAyTx3Svf5PH1KmbPKZu2OQxdcMm zypLj/Xf5onHvLmOCLrjpr9OceO77cZ3y8YMxjhXpBV5WH/8C1gFQsFWsA1Egt1gDzi4392zvTx5 6pfNzCOMDFK2LK+9/3Hjf+SIb549FLZbx4fBEXASnAex4AKogH765QNGnz4VTANzwV4QLfv2E0r/ fkfp430PGv18CVBS9vfG9T/7dkds2bR+rXjm94J5c2ZPnzzh6+DA4YMG9O2lrgbpxzZFOBanKFvF 5PWuxVl5ia3XpK8qK9XZqit99VhpwVZLitxpRWlnSsdSOo3S6RTp87uI9CmgX497kXQHzVJyU9qQ 0kYyKqcxR+U0Z6ut9Pmz0p6trtJnxP70cBMFNJStYfSuwyn9nOJ/crJuTf1+lLpgYzoeNBdTM9s9 yKxXM6br+kzFFtvLmF7j2Q2BlfP1BYy2VkDGE3hraNGb88rxQCoBXptl68zGWT+PIoGezEqb/Cv+ hz69P9P533zOufXLyvy6ppxjNwKNQSD4AvyUYZ5dBHPooqAaqA4+AoPBMrDmsD4HD1fm4YeVuXg0 OK7MyS/JeXm8nJuL+I/LsWdOyac//7ohnJ7zOHf2jCkTvhkTOHzwgL4f9sxU7d4+78oIjLocd1Gf rebS14KVlmy1Yqu1LNWGFX+2ekhfT1Y+ZesziukYRGkgpWGUbrkmRoM7SH3b6KPBXdJLUHxHyURx VPZPZ3yHvKr09es0plA6jtKllC6j9DylsTLG4wJHdiSzpcmxy4tHLAdbT0rfUxT/kd36f1yxYDmb MUWWGZsyj84YKfEnjf/yy24bth4jrQ+UTNNw64xpBxctM2vVCBPT4Z2pWLA63JiKObdHOWY8nt6c v0HKHESZ77fJfG2g38P6Yef6SCAYC7aA3XK9xPqUWoRaJ9bFPAn9HKlmhnqQMY7GM346/w9jiwo9 rI6jlHWxa8ra2H1Q+KixRlYWvKSslVUF9eSamb9cN1ss1818jzm0vCAYjDmmr6HFgyvH9PXfi7Fn Tx49+Fvk9l/XrVquX/8xTl///ejDnh90NOrR512K41go4j4K6WPrIorvWExpWYrmeIniNoI4msOb XhlM6iFWc5N6OEEfG48kOEfLy2ylsuUjIyzycFyFL1t52conS+VXozmeNaI5qnDJWrLkm6zUZqu5 9LVgpQtbXSmOoxulH1E6l9JlV8X/dvWqnHHIOcU1Ut+55vyPHeIjfMHTOrbu96PUs+5uDvzUWb6p mPVNI6aqfbj1ayZrOb3JmIxHOEL838SKaQU9ba/71Lge04TOlPHkCl/T1brW1/6OsPTYvbujsQ5q 72r5Rz8GZIz9eeRjQkFT3wvugP+KdmivRRvnMiLADnAIHAap4vwG8D7u0HxAHlAUFAMVwG31QzY9 wdBmxnS+2LrY7/aKZTtz1jLzi3oF/DLNvD3utuxrfHP9aLXJmAXKb65SohCV0IrkZL1XBJXA26AR aAyagP3gADgNbonXnnBoNUBN4Djp0MqDCmDEKYc2EkwC34JlIORUhudA6vOCsJVLF4kTwzOmTp44 7sugwBGfDehN1xB6+7SiaI1+HK0xktT+pAaxOoLUYIrhMJ6YKmM41u55IJ7rkUzPSb1JaTmK1Xid 0vcp7UBpR0rPUXo+Th+rY+OcI3QCW14yNiMXR2TkZutp6SvByt/ZKkexGuX5aefePlUp9ae0HaUB lPaiGNi9Io7ET58L7SP9HqVplFanedE/KH0HqVZO1POwaL0+nXXprEdRh++BrqAW6qqZUl/VUC+1 QTPQEXQDfWT97QbHwWUQB4rHOLSnwcugImgMmoC2wB/0Bn3AZ2AQ+AKMBrPAbLAahIHdYA84AU6C yyAOpIF08Mxph/Y30BgMBMFgMdgJosBRcBHEgSlnHNo0cAFcAsXPOrSSoBfoD8aDGyAZ3APaOYyB oCpoBDaDoyDtPD6PWLSdCw7tHVDkd4f2LGgOOoMZ4GdwGiSClOQk+knBjwau4MepWf2kZPq55EIT h8vO88EuzhM/4eo8sNbuUbVb81xPjQB6hOcCsp3ZYq+YKbPOnkfdzOdk1ecxZnvMyOJKU1FnH7tL tttjIFq23xNKGy4aY7Tj8kpbbhjj2TN/rDNuTuyq0TpuTuyqISluigVZFVO2R3k9rof7zrSfbMQL aYWzW/fOvrx1jNGftwcdQWfQK8bo3wfGGH38qBijn58ZY/T1KTeTrhnnfTesWRWyeP4c512fPv2k T88uxvE/rcTzda292Bolr3ANZGU0W2OlbxwrE9iaJn3TWTGetzKPrflsmZ+4Il7pKrIjTPpcxXUc k75oVk6wdUX6jIiNa2yVlFGtpTiWtTxb6rPgK1L6OqU1aAbUkmdAo8RH+IKndWjuuNWwLTf9u3qu wPrw3Tpj2ttgNQLFuljG7Y8dj+Fh/+9xJEDBh7XHVTHG/Gvzv9k7D/Cqim2PbziHQKgJnUjvSLOA Ut77PqWKipciIFGE0BSutEASOogFkkgLvYMQQLzv0nsxaCAKCgEUuUIoCUQpaRBKQsn7z9pz1p6d nHM8qUbe23y/5Zo1c4qZM31mTZTRBzsXZfTDYqOMvlhqlN4fO6Ue/HFykk89+OMk2UDXkqkHf5wk e8W1ZOoOBifJXDsB6dpjr97OzV9Cuezksehzl72o97urgmqy/z1a9r83yv73cdn/fh/97L5gL9gH ksFd8CL6183Ah5dN5/8ivj24d8fmrzeGrlgaMnv6pxPHjR4ppn/1GxRP0rmNSDq3UVKcySitj3lK 0SmNTsLiqVteJ8s6YfHQLaF0buNlPnXxKb1jCzqL4c3WT8j6Lllns3UaWeeQNYatH5P1Kt3eck2e 3ojlMxsJrLnJOr0w1+TGOQ4vGWfcXVaFtYy3mDVkrYWMa8mWtqx1lnFvsaULa4OhabWyk485e/dL frjuJcPz1J//+LPyKMbDM9ONh9PkePhFOR4ugjGwOxgBRkY/FXeAuBiThQtBlPnlMlm4/6O0k9sA PP/0/g+P9K8um9U8Lh1j0cqAVWA1iAYxIBncBXOvWrSQq+KCUX1OpJucE1ks50Si5JzIm7Hoe8bS 3b/xN2Mun/vlp2Phh8W1XxvWrVy2IOSLQH1qr18fLf1ju7ejDp/LmEnWunRaYyhbvyDrP8m6ha3B ZN1K1gS2BpE1kU5zjBInNSrKOzbopEZJcS6jgmxn6BxGdWEpr1tqkGWAsJTTLQPpNEcin+YIpHdP onTzxHmNsnq6+XSCI1VYyuiWh3SDx0k+wTGDXhlJJzgsfIJjOlmtdLrRg62fk9WT2kc/kv6UYimn +IxSLBOXF9fIjbzMz3eAOP4GORsjH6XsVXRScis4iSvvJK5cJu//KJuh/Iv8Gg8mgIkgCASDOSAE zANLwXKwAqwFm8DX4F/gNrgDPH63aJ6gD3gfDAFDwUKwCCwGS8BSsA6EgvVgB9gJwsFREAF+BjG/ i7mAhBuxVy6cO3Pi2JGwA3t3bRe1wpqVy2jSP+izqRMDfHkTuN6n+TbN1rs5mab3fCLZcpq1KzIu mi2JrCWliRJzm+Qjko9JPiEp2syChUTpWXJHhJeSDCW5/o4oxbfF6bNKeim+Q3aPZCE9SfYi+U6y /vm9k22f2o+1wTLuA7YMYW2kjBvFltGsjZVx49gynbUZ9KmBVFsadx/NEn+2ujmR/45PeeTiIQ3H 17c4SaYGXLr/IdOzsH+38x85XX5dnOQ1ra9mZZbY8ZHirAQceyTer85ZmS4gMSVz7cnrFWFde6Wu pq78VqI2QP4ayog1KZHv1UFj8KqS56FK/trqZlEvXwW/gz9ACkgF5f+waF6gAegC+oDhwB+Egx9B h+sWrSPoD+LAI/AYlLmBfgV4AbwEXgd1b1q01uAWKHwL/Y04vA4MAHNBCAgF68FREAHOgJ/BNRAL EkESeAQeg/LxFq0CqA3qgFagNegCuoIBYCAYAUaCGSAQfAW+Br+CNOCRgD4x6AZ6AR8wCowB1RIt Wk0wAviCL0EoSE7kuyCTlH+65aY4EWoYNFMSe//SXxuZ/vxn+vU/h+c/vdO3uSJvr4FYJY/vK/lc GPl4yrUDHkuycMBjiGtHTBx/A03L9T0zub5POGf9vxttkJ3PK+5qnovyXQFUBJ3BW2CYLOOnwGlw EVwClVCmva4b5f1f4H/APrAfXAHR4JasB+KVusDzhlEfNLiR/j5o2z1goV/qOz+Cpk+bRFeBUc7r vZ1pcs7LWPP5jLUlMs5Y19nImljDKUQrOIXcdpDcSfI8yQskr5MU3rSKuv1DrKQ8o/f0utAKy0SS k0juJrmHZDjJI0/Eq+rjr17ES39VgzRhf41kJ5KTSU5J07/l1DTbd5vN2nIZt4Itq1j7t4zbzJYt rG1lbZtMtV3kf73cylvHC/smV99ZCYS5lizbgd2uJXMxoD9KO/yMvgNLsXipLXMerf+7Wg5F2/wi aAZ2gz3gCDgKom446/eZjnGYAj+ou+dMOydMyRaqu0ecJFMD2e4RmgK2J9fzJO/6hvJX5ulK3l4E CaAW+mK1lT5ZEdAV/apucXr/7G2ljzZb6aetVfpq4Up/7ZTSZzsLzoHfQIzsw6WKbX835L6/k6L+ p4sg+BDgpLGj043/3XkVvDRrZVkrz1pFuX5eiS3GSnodGVeXLfVZ6yDjOrKlE2veMu5dtvRhLVDG BbFlMWtLqHVYSnIZyatpQl5L4/2Imx7SfkRfWl8aTXIDyT0k95KMJHmK5EWSl0j2pzZrgGz5BnJ7 N0ys/9TNqfzNdhlLcS2Z40CyGkhQA4cPuJRsnrqQa0r2VO0DMu0388xy2VT/Oj+qC4FO9n/8FdtE /l5Pnu//sI2V4+OM8XJqnDFmLhtvjJtrKmPnFsr4uY0yhvZRxtHDlLG0L/AHk8Hnyth6tRxfb5Jj bHnu+7dfTv0Yka6616d7eSWokFsbWacZ691vspaxvhvM2nDW/Fkbz9pE+cpJbJnC2gwZF8iWYNaW ybjlbDF2g22VcdvYsoO1CBn3PVuOsfaLjDvLFmOnWIKMS2TLbdYeyrhHbDHuRnCTbVHhJ2L9P6v5 /9f4/1WneZ0kS39nnPrkTbkyynE+9/+bU2XZ8SHfCNe88Ea86Voy9QflJJm6YczxWUXHgVy8ENrZ k9e/Tk9H9fCTeH2u80U519lTznVeB1vU5t5JMVQDfmpgeO7FmJ78sHsnk+W/ZAE/y2+F9U/9kMu1 eHf9Uz8omNE2yJrRFmbJaLPzmyj+Z3l9A7RLtGjtwRQwFRwC34A7cl67fBLaB1AL1Aa9wDug6W2L 9hx4HrwAXgTNQHPwEngZtAAtQSvQGqy5rZ8Bv3Lx7Bl9K8jObZs22K79kVf/fTior57BaFnFHolq +nzathQx0tlOcgfJnSR3kdxNcg/JvST3kdxP8gDJg7TDYj7vlBBzCoXcFtD+ie/ZuoCsP5D1F7bO J+tZsj5g6zyyptA+jMYPhWxC+xE/EvsRq+rfe5jhWbpKAfYsXdStoNhfWFm3WGjH4QLecRhC77uQ rHvYOpese8kax9Y5ZI0n66uPbVZaDK2d23ns4qLdZYcxpo1hLg4FTVtGcjEmd2aZxONw/1dVJ7tB qjiJq2x/b1gFkbePE/W8rSbztjHoDUaCWPAYrEZefgma3EH/AASDleAUOAcaJlu0RqA1aA+6gPeB D/gIjARTwVKwFhwFkcDtLj4XhICFYPQ9izYGTBTct2ifgjEPLNp40CMFdRMYBHzB58A71aKNAxNB CKj40KLVA/VBS9AK9AS9gDd4F3wEhoFAMBMsB9+BSHDkkUUb9diirQKHQNcn+O4gCKwGx8EVoKWh TID5YAFYB7aCHeAH8CO4BKLBfZAq/pvhzF7GE37XTf8xnwwU4Wt2Xp1Eq+mOfME6Pf/n7aweFvnd DnnbHgTJPI+Uef5sspHnrZR8/0dyDswFuXgY3PQa01asbMeY3NGa7pzarJ4xcJxMPnm8x8Ncbyhe DZRVhmrqKkPZ7OSzrYz3U8r5cDBClvclsrwXuquX88qgCpgry/sTkCbsKOtV7tEe0OuxF8+fiTx+ 9NuDe3Zs3rR+zfLFC2YGTZsSMEbc/tDHW/+jFnKLJK/bcSTjaQ+nt9itWd3wdvIu7dg8abOK19wT 6WLv2dq/5ZTud7J24z2ay8janXZuTmTrUrJOuq+PnCfft42lp7IWLOO+YMss1pbLuBVs2cDaVhm3 jS1hrB0mj9/f0nd55oHtuyyh71KZdoj6sHUxWfuTdQNbF5F1I1lft/WU5F/oDYS1mjmdj6faKb/+ 7J+tUQOmpR/T3s9sx5j2i25yGGN6jSlgeux7E6nuyl7NHFn/z8QetDK2stcCtAQ9Qa97Rjs84b7e Dp8HF0ACSAS10R7XAS1Aywd6G+0H/EEAGAvGyXZ7A9j4IAfahZxtMf42AcfNVIbHhfq/hlr/e+VV 3n8FdoM94CD4BoSBCPADOAYiwa/gHPgPeBn9uxYphv8P6Qw0Ilz3B71JXQgc8dGQwRjvkWfjMrTv tuwdvWYtd8dWn1ZmraaMq8WWOqw1knGN2dKUtWYyrjlb2rLWjj61Pd024ct3UKzQRF07muLGkPQj 6U8ygORYkttJ7iAZQfJ7ko9IPk63l7gU7QYuUsOoz8Wu4KJuY+9KKyzjqH1cQHIhye0kd5A8CanV z27e2PrkTqbiqisBx8mWqDt9nSRz7bowF8+cuRiQT1Z3ZuTfPcGap5qHpzF+OgMugkugGMZDxUH5 h/q4qpIytnpZGV91VMZY74DeylhrqDLeGi/HXEEgGISBw+AyuAIaY+zVBIQ/MsZhj1JsewD+8zP3 C0PXLF80b1aguBdsnL9wCjgQv/Z65E+3PslDJL9JECWimPCt66OXiOLkObchyUYkfUj2l750B7AH XV/Wpsi4qWyZxtpcGRfClnmszWdtgUy1kC2hrG2TcdvZspO1cBl3hC1nWPuZvvdZkpdJXiFZgjzN lyRZiaQXeaNfiJqxSE39r7CIaskdwv97vZzI92z7+8qKWzBTIExdMjZ5hDclm6luG3WcTD5P324f pRdQU9995pHZcnsqC5t6F7m2qXeIa9uKh2h/8uRivv0lPlpzc79xsczUxb5gMggGK+UcWSJIAm+m WbTOoDfwBjNAIJgn58iy3Qk2lVDT2YureRQ4rwZM3830dXJxIGA8Skmupfj6Ez6N7Y8+fQqIuAzz v5Wym69i7nOtMv+5Xc6B7gL75FzocTkfegKcTtPnRa+k6XOjV8EfafocaUqaPk/6KE34prXq/X7b /r/T7A9o3SrhD2j6J5Np57eP3h4m3rS1jLdv6q3mHbbcZc3KPnyLsFZU+vwtxpYSrHmxVpW16jJ9 DbbUYu0F1l5irYVM35ItrVl7TcZ1Yksv1t4h78W9SQ4gOZBkCMl5JFeRXE3yIfn+fRQnWvvOwstv Lb21f4tuG/AhOZzkeJIT4sX+v8zkoZM+/itKwEmvvJ+jZPluId7Jk+n6eJeD/n/hbO4FNN47w/vY e297bUvRrJbNEqAU8ACVwbNgv7rTw3RWznFgqxrY389RMlffINvf4COXkmXqsfd3b+tyPr+nWeen XdQiC+p5/XqBjL+j23b2/1yys//Hzm+itKO8bAgagcagCWgKngfNQTvQAXQEnUBn4A3wVbU+oC8Y AHzBGOAHAsAEMAMEgWCwCKwDoWA98C9gZf8/YrB3+MAeUd3b3L+NGzPyn4ON+z87kBfTjrK2f43r +B6s+ci4/mwZyNoo1vxYC5Dpx7JlPGuBrM1kbbZMP4ctIaytYm0ta6Ey/Xq2bGRtN2v7WTso0x9i yzeshbF2WKb6li2RrF2QcVFsucTarZti/58o0yL/bXnfUOZ5U5nPHWXe9pH56Sfz0JZ/G8FOMA55 NwOMKmjVJoNtFqt2GNy3WjVrIavWws2qtQXtQAcwFASA1WANSAGWwng/cAg0K2LVuoNS7vhuoBpo BJqCdqAj8AZ9gC/wAzNAMFgEvgTrwHqwDYSBk2BHUXwvkFwMn1fcqrUsge8Dxpa0ap+Br8FR0K2U VfMB/cFYMA4sAsvAZjDTA58BuntateHgdGmrdgVEA48yVs0T1AZ1QHvQAXQD3cFA8DjF/C9J+XdT 0dOnM6c0LJqaRiva3Dj/6ejsp1gX1vq4WtazNO7r5yiZi2+Q755Mj/+Mpt88/stYFYvxn6eWI+M/ c39DvLnD+t89J+vxp6H9Vzci55/2P47b/9522v+YbLT/6dvfADAc9fcIsBn19xaQjDr8LmiOOvol sEHW08dQPx8Hv4JzwIL61QpKAtPK7Qk1kIsnNrMSMH0305ygKSbbAfOjjMxrO/AClvWToJkYb5TL yTy3tdVVlfa6iWyznwfNZdvdQbbfnUBnd70df89db8v7ggHuepuur/vRBIAY/6sHAOkW2KkTAnyH qQVWs50DDIzm3hprs6Nlb40tIaytYm0ta6Ey/Xq2bGRtN2v7WTso0x9iSxhrP8m4E2y5wFpUtOjH XiT5B8nrJMvGCFmOZA2SNWPE2L7dVYzta+tj+/ZXhX3XNSF3k7wfK+QDkv9FNxf8N8lJdEPBZJJ+ dBeA/w0x/s9svpnmo0znb2+rgfBXXEq2sJ+jZI4DpjfI2+cpGvnLuqWYq2VxjLvexw4AE9z1vnaQ u9HfXuP+dLT/77mULFNPvh7/u5q3Yjy11l0fU4W6G+OqA+AgOAS2Yly1DfhjbJUEboOXMLZ6Gfhh TOUPNskxlgfGUJ6gKqgG2oMOoCPoWkoff3UHqfeSbv0eLecDDu7Zvlm/BXzpovlzZwXrC8CjRyqN gF6nLr0garhlJENJrie5geRPJE+QPE/ywgVRs74ahZq1jl6ztomiOpJkAMmdF6muJZl6SciHJP0v C9nqipCtSTah+ruprPOf45q+FWsdZFxHtrzGWifWXpep3mBLD9Z8ZFx/tgxkbRRrfqwFyPRj2TI+ Wqz/ZjZvszQOVAuV42SmlnyAawH5GJ5Tm6oFy9KsQM7W0k/d+K9YTpdX25xJVs7cZTtwSw2YFuVy MeB4wXCX+rsXT16u9SsjjDoFRMmQI4zKJj/D5dQ881fmumbJ+a7FYAmo4oG8Bw1BI9AWtAM9QE8Q BIKV+bAR4FRpfV7sjDI3VrKMMT9WU5kja6vMk3WRc2Wp0vfTrz+fOnH8+yPiEvBd6iXgYtvf0EG2 P65eq1nYr0YJec65JFs8WGsi45qy5XnW2si4tmxpz9ooGefLlqmsfUy+O6bZ9+DR9mya8ODhc17Y +5NcSHIRyY0kvyIZRvIwyRMkT5LsTi3V2xf0b9Djgu1z32dttIwbwxZ/1oJkXDBbllwQ/f/czHcn 64UTlYCTZGogPB8HDruWzBSwPSZ/HHnj9cloW8pnp3yKueweoFcZp3l9QAk4WRtWva84Sfapa8lU VyNOkqk7kxy3K+bnKfIFo3mmz8feoL9coxgEhoERYCQYByaAiWAeWAAWgjVgLVgHdoO9YB84DE6C SHAZRIMYcAvEgwSQBO6Cx6BQWSv5+7P1941DQPNmsbvnvt6ypu/JHi3eZ60/awOlB4xBbDFuihop 40axZTRrn8i4T9kSwlpG74GGr4/NMm4LWwxfHwdl3CG2hLHm7AaoGBl3lS2xrMXLuAS2JLGWypo9 /x+abMMKkP+PrOa5ixs21qtuQhwnM7kJcZJMHSI4SabuEU//5Gbpzd++PuyV/xK2PLflty2vbfls K9e2Mm0rz7aybCvHhVF2i4D64FnQE4wEH4NQ8B34HpwG0eAamFMOvylwGcSAMuWtWnkwCAwHM8At EAfuglRgqWDVmoD2YB+IBPcqWrUSlTBuAW3BZDAXhIPjoKoXxiygCWgB2oKu4G3QFwwAo8FMsBDs Bd+BFFDoGfy/gdLgMxAIbgOvylZtNpgDFguqWLXVYG5Vq3YMbKxm1b4CD1Ps/Mvo0DfO0K/p/7WX Nu5hlPyPpmU451tKnP81r/N62Dvzq54H1nrldP0tfgdO+gIu+oL5P+syJq/9v5S15Zkou9Vk+W0g y/AIWYbXyTIcIcuwN8rqu2An2AUSQRJoivL5HBgoy/D0dGU4RZbhxrIMF0S5tYAhYGhFOd67FvXb 6ZMR4Qf2bt+yacOalcsWCy+/UyaOGTVksPkSmEJuN+jelC7iXGsDfdauK/nvqMPeN0IpXV3yydGb revI6k3WwWxdS9YPyFPHcZI/Uop4TvElpUiguFrky6M2+enoLzx31Ne/wQCyrBCWerplJVkeCEtd 3ZJC948Fs3+ONfS+X5B/jn+zdTVZN5PVuGlsFVmvklXcBqZbV5L1WdknMO4Ga8baGzLO8JAm7gTT amYl77eoffD/9//jvITlc/8/uVWWHe/dN8VcdhiTs35fTBeCufiarMSYLgSzu3dfmZdrkIX7v+o7 8fFSz0lcXfv+X8qJvCpeyeg/tQCTZB/qO9mHquJl9KEaK/2oNkpfqrvSn/L5X/bOA76KYvvjC96E 8sAEgoqgggJCQugttNANIEiNKIIEsIAgIEV8SBXw0RNAQZQuTar00HyQhBZqlEQUEEhIqILUAAnJ /zdn556dDdnr5aaI/t/m8z2fM+dMbsrsTp+zoJvsV02S/aq7sj/lgb6TJxgj+1PXlf5UUXA/0WEQ iHeN/Z816RRrV5Ld6I1dh8XZV1+9jj1ClkYi2kNZ3dL4DseJoDpzhWaPE+Hhvoety8m6l6x/sPU7 sl6/o9ehN+7Y69BbrKVKn8bRG3Ky5iljPBRgS1HWSknfy2ypylo1iv9QneI/BHMsimX0u4SQNZqt S8kakyZWxBLNHivCzf0VkgHUZl4UOXzwfymR0fK3fteXdSJz37SVWaFasuT6S+O/PLwS4JO2hvDI zGc4qrHyl/89Y3+YPAvUxGzNdKV/ysrXQQ1c9nGM/1FQrXv9QE3QHgSC/mCAMs6d+bw+zk0Ed8G/ MM7NB+qDBqA9CAQhLxjj4AMvOD1XZNrYk7mec5aeGEtPdv1uRyw9mpaLewQFRK9AuZvKO7jTyqXb 1ut3bAHlrCDu3cJZWu4gCSSDvMXwfcATFAReoAh4DjwPSgAfUBb4gglgYjFjHsW+F9DYCrhzx9bN G9auXPrt3FlfhkwUL4IRO0E+0ESLt4JOvu8juZ9kaTrzXuaG3tp637C3sRVZqy59NdhSk7X60teA LY1Yayp9zdjSgbU36Ke+SXIcyfEkw0iGk0whmUqyIEX50OOXBJBsSvItkp1uirZ7m4gtUl7v02wn S7iIBFJOt0RQhJAzJM+STCGZSrII9ZaKkvQT8T+8M6ucrDvlDjYJFncq2ww1MoiDbGqz4iCbmnjE c7dZWRNnc0/BHv9ffcaGvoi+HxgHxoONYBPYCXaBMBAOIsBusAfsBdEgBsSD8y86uhf+NsGYMhxq 4k+uDLTuLr0JUDkvXsEU/0+UeyjYDU4Bv+I27RWQG+VYGviAOrKs7eUsyvgCsL1k09xAbpAHFAFF QQ1QGzQHH4HhIBjsBBVK2rTXQBvQHUx62aZ9CU6BZBBc2qatBvvAryCiDH43cAycBefAPZAMPLxR R4HSwAfUBfVBC/AW6Ay6gIFgMJgAJoOFYDEIBdvAXnAcxIPvfGAHC8ri9wCxvujfgtLlbVpV0KMC 2kYwCAwGi8Ea4FUR9SMIA8fAm5Vs2iegSmV8H2gE3gBvgT4gvSieahzQ9LzmLzXXZXN+0/kvh/E/ O2fmcy/uidvKfeEOcin3R2HlHikj7xM/UBP0AX3BFHmvfIt7Y1FJfT7g6uUL8bGnT/4SE3VwX/gP Wzd+v9LYAkQBoXuITUBu7t9fEa1hhDj7XlFvDXfTSfdzJONJFqHIQEWv6W32c9fsLXVZ1vykryZb arPWXPpeZUsL1lqy9prM1Yotb7PWS/p6s6UPa8OkbzhbJrE2mX7vKSSDSYaQnEpyGsnpJOeQnEsy kuQBkjEkf74m/kfL0SfKXQH/o9KulNv/3v+YkT064oP0XsDj8P5HZ5/DP8B1MLoUxv2gIurqSqAu aA66gKCX04z1suu9f+vUxCo1sSybEnz9WRyWbmnisKgtc8Xsf/+f16OUbW/wIRgFPgMnZbtdHu10 BTAUbfIwMB5MAKFgCwgvY7TjPylteZxszxPAJdmuJ8m2PQXk9NbbeFMb8NPRQ/YAkGvQDsyd9UWI eDeQeBWcXgJ6fdnmgr3mDGStwwW9fn2DLR1Z68nah6z1lfn7saU/ayOkbyRbprAWTCeuQkh+TfIb kvtJRpKMIfkzyZJ0HqvUJVEzi1NZuSvprddgskeR/JFkAsnzJG+SvEUyz2Uhnyb5EskSJI+QPEqy G0eSyeu+BjJ3N/yUMllVrpnbHbceN1gvLWVuwnrL96b6TmUTVzaf8Uo//msltZZ5ytlnsIDsaxcC hWWf2xtEBSl/nytn/Eerez1c+oAgq2yPEGXgcTmPlSnt/yOcOvRwVLZiTOULKnrrY6t63sb4qqO3 Psbq5K2Ps9721sdaXcG73vqY62Nvfdz1bzDMWx9/TfLWx2DBYLq3PhZb5K2Px/is15FIGftlsYj9 MlnEfhnUr9d7XU37P0Ttu+a8vc5dy9pO1iJY23Ner633smU/azGs/craSZn/FFtOs3aVtRus3ZL5 b7PlDmuJrN2Vue6xJRe3GV6yPSnElqdZK8Faada8ZX4ftviyVpu1eqw1kPkbsqXxBbH/w5Vyzq4o S6PVAYSTH+3ilZVnrNJ7ph+X+iZfRp7bI0HKfzBS/XdaJ3ariVHqjeTSBwRZZbNOPHQ9LrE40rlP svy84ZNq/bsUrPDW58W2ehtzY8dANIgBS3yQzyfNOG+TWo6mx9E6Yf4AdWO3dbbRamKkmhhsmTBd ebhHlH+Pm4Yh2M5siLHh8lOfDXda/kct97llbdo8cNrXpp0BJcvbtFLg3Qo27T2wS86B3gdJ4Fol jC9BMihT2aZVrmzMiTaU86JNQDM5P9pRzpF2Bl0ri3hwf1w+H3vKHPnffgZ82uTxY0YMGfRR7/ft 5au3vb9xi/ubbHHZksRa3tN27UnWPE/LnTpsKcZa8dNi/PQiybIkO5DsTvIdkm/QWfA3z4gx1lTI 3JX1kdw0sv9Op8Ov6mfEKaJHBZIDKIrHQJIbKIrHRpIrKYrHKpLDzgs5XPYgRnAPYhJrX0nfLLZ8 w9oy1laythqaVjoryvSO+siZNghlV8I08jprmc3kcSVxUk38rGX9Zb2Sl88Y4VXOodZwxijw4dpP K+TMMyjWK/qBj8AAMBh8DsZV/t/47/Ed/z302emO//6sfMeDiSAYzAZzwTywEWwGoWAviAPnQDxI AOfBBZACtCo2LQfwBL6gHCgPmlW1ac3B2mo2bR14voZNe6GGjAGKOv8Yh3wW48Bpk8ehsqc9Hu+/ 09UoOjf36r+KunEBnZJeSDLPKSHzkixFETteli1Baa7/G7HWVvrasSWQtV7S15stH7LWh7W+Mlc/ tkxi7Rvpm82WuaxtkL6NbNnMWgRr+1iLlPkPsOUQaydZO8NarMwfx5Z41m5A00r2keX+uSzr2Ur5 2st2HzgLYpVyTlDK1162BYAPKAsqgnqgBcr3TbAB5RsOiqN8y4H/+Nm0OWA12AoK1rRpL4I8tWxa YbADHAG/gFtgeG2MP8AUsAgsBuFgLzgB1tfBzwCbwAHwaV2bNhQsBcvAZhAKEsB5cB8kgaL+Nu05 UAZ4g1qgNmgCXgFtQFvQC/QG/wZDwDQwHawGa8A+f+Os142r56+ylnQ6nS894+mkaBCV/hkx+hL3 d65Gzb3EWm1BuaarLt+mXc/Nn+eDHNq9P+TJL/sJMLJetFtN57/aZvQZz/hcwDtOZRv9vXPZXJwy +P86/vfISD09Bs/tEbX4rAfqM9Tic5BNTUxXE1PUxHhLjyuJNJdxCiNtJMasjS30l4z/PezlOBZ4 oP71BAfBKfAbOC7r4HqoY+uDlmAAGFZbr5NHKPXyQqVu3irr5wiwGzRDndwcdAB9wIg6Rp2t1tPf KXX1OVlfcxxI83sgFi+cN3vWjOkhkyeMGTV0cJr1v69SuR1N1dvA3Wz5ibVjqaJvEJ3KcVqKLE8V cVrmHRP2+SSPkYwnmUwyTzT1LkhOIRkcrf+MkGj7J89ibbX0rWHLWtZ2S98ethxjLZo+OYbkGZLu MUJ6kSwUI8aYQyBzV9HHmJ+SfdDPQn5M8j8kGx0XsjHJwySPkKyGXpNWJrPL3pWDs64krqgJJ+Mx mRKm7zltmVjbSUmstMz28JWB/rsrO/yM3d0Pn/qoYhlhVvPKrOc1aqjyt7tyqOO/lgnTmTrrxHo1 Yf3RakNkzuZ4hOjipUf3sf/H57vZd/QfzVlA2SNyNGdmnv94hJ0gBdLWtaJvfFfpHz/rb/SRX1b6 yWVBOVAB+IGo7cofbf2fNEX5cZBtjHPZ1Cg/DrJZbipzMmG+svuMvos/76HPTu/nFchImdvHSo38 jfFSK39jzNTT3xg3DfY3xk5j/I3x03x/Ywy11Z/i//x+Ie70r9FRB/emG/8n6C3N3sYfStFbz8Mp PAZm7aL0XWLLXdZypuq+J1LtFjfWPKWvAFu8WPORvrJsKcdademrwZaarDWQvoZsacxaS9ZasdaG tXbyO9uz5XXWgqSvK1u6szZK+j5jyxjWvpS+GaL8S7hajqbGeIWvkjDFADBlM0X5cZBNXQxykE09 72GdLe2V5U+vK6f+/7JIQPmdeSbF3MZ+cAZcBJfAZeBfD31DEKWOAR20/f2cy6YWv4NsTjYRasI0 vAy29CjX4xBBIivvWE9nyncAGAhmgJnAu75N8wFjwFjwX7ATpIBUUKWBTasKXgcdwDawHewD+0Ey eACON8T4AtRrhPEFiG30ZzFgRACAjpqHex0Rk6WG8e7ruvfFaOhbuxWWRRSlZQRFaRlJ8VbWJ9lP xa+j79lA1p1sXUvWXfQdpZJpzpiirDTl2CvfU45m5BtGcniy+LnbRY7q+s/dQZZEYammW+6Spa2I 1VJVt7R7ID43nqO3rKHPTSBr7hS7dTVZ86QIa122riKrP1mnsnUlWafJNm86t3SzWVsvfRvYEpYi 6n972V+UZf6MLPPWssynyTJfANaCDaALyrgbWAPWgVgQX18v87ppyjxClvmPwIayLgpCwBLgL8v9 ILgKyjS2aZXBTLAILAdrQRJwb2LT8gEvUPQV9E1AGfBUgE0rCUqBWqA2aA3agPdBDzAADASDwSdg MpgCvgWLwFawDewBkeAUeABsTfGZ4DXQCwwE+Zvh54K1YCfYBX4Gx8EdcB882dymXQAPwJpXbdoJ cPJVmh92GPnL9BV/Pe1kcJpwYEZaSxJVVdp4YE7F/+qY1c/3XbU2NR2CdsVjigJh8vxi6TEFazF5 rBPWv4EpkEyG/x5zyDAl/osyeq/u4KR3NQe+qulHfDFHlnkmvTo4DpRurD+PM+TzeF8+h2/h+esE xoMJYCKYBb4G88CCJmn2flu/wdt6U7epmP8Sj4OgIsWdyiavbD7Vay7d9Pd/1zCd/8yM8l4IvgMr wEqwDmwBW8E28ACkKPX2SrAKhIItIB4kAC/UuYUC9Do92R4GaN/unds2r1ulv/UX3YAxo4Z/Mqh/ 39493+sepIlWr8cd0RL3JDmD5EyS4SQjSB4hefSOaImDRMwcP70l7koRdoaTHEFyF8kwGZUnnGPx RLJ2VPqi2PITa79K3wm2nGItVvri2HKdtRv0U29S9J7iHL1nM/19L94V1lFs3UTWz8gaz9aNZE0g a/t7dusGsgZSVLxZbF1P1q+R1kplVflFqYf2HfTiMxoLxpWE6dR2hj/NyYT5Up5HP/V5zJT5v0eI OvCUKKunlT6Un9KPaqj0pd4NMPpTHwUYfapB4OMAo281McDoX30ZYPSxQgOMflZEgN7X2gv2gfsg CdRA/8qvqY3fARt99MDesB1b0s4B9erxbrcu+r/Rzb0JxbIYRfIzkhtIbrytP22bbtufsVDWdklf GFsiWDsufb+w5TxrV6XvGluus2aT8b/cOCKYO2u5WMstc+Vhy79YKyR9T7HlGdbKSp8vW2qx1kD6 GrKlMWsdpO8NtrzH2vt3xP4PV8rfelXmoLobwPQEm7LNci5bL3XtxUE2dVpJXll5RjfLT2ZmY1yI fK48zw5i6KrbL5wM+zTTuWC/PZ3LpmW47B2Vzz/ubHk+V+rnHqAnCAFTQb5m+ri4PxgARoIo9dl1 0LCrz252tf+Zm3CyN2G+lPa/Zqa3/49Q3zzlbHkuAd/LeY91ytxHtDL/8bucA0kEd8GnzW3aUDAe zAdrQTxIAKtfNc+NnAKXwRVQuIVNKwKKAt8W9v0f4jWgJ47/dDhy987tm9etXrHMvv9jgoj9NbBv r/f0du2LVL3NE+scumUma+HSF8GWH1kTu0LcaEeI3Aty/hvaC3KY4ofNoPhcM0keIHmS5E2SGsXn ykFyDMmxN/Wf9PlN++cHs7ZI+hazZSlr26RvO1siWTtAn3yQZAzJZJJ5KLZX3ltidNNXxAKrqY9u +pH9MskrJL2ob1SIZOPbYv9HZpStk0eorV/puV+tLExPjSnbDHWPgYNsasL0G0y19EzS0lz2sbOf zVij/ye1/LK+8czos1m+hdN7fqxjspk8f1h6LquJBDURqu4+sM42Qd19YJ0tS1dcsnI1P73WI0dO Le0uE+Pe1jxPKmVrL1dRphVAK9AadAKdQR/QF/wbDAFjwedgHpgPVoHVYA/YC2JBnKi/wQPwfEub Vgy8CgaAMWAZ2AMOgGgQDy6A6a/ZtBkgDiSAp1vZtGdBD/ARmAiugmsgESQDt9Y2rSIIANvBjyCx jU17si36LaAxGA7Ggd/BfaC1s2m5QBvQCXQDPcGA9ugPg5Hgg0D8zWAICAYhYDFYAraDHWAf2A8O gkMgFsSBB/esv64/9PW7ocer9lPX03yr5vr7P+xz/0/Q+z/sz7Ao75ZKmXdUyr0L6Aq6g97KfTBY uRdGK/fDHOWeWNHCuC9CWxj3xrEWxv1xtYVxj9jf+Rdtf9/r8sULZs+cPmW8/rbvnu90Efs/RAu5 nleydrF2UK5yHWLLCdYuSN9FtiSyliNV94mdIXI8z5qH9HmypSBr3tLnwxZf1qpJX3W2+LFWX/oa sKURay1Ye4211qy1ld/Zji2BrHWRviC2dGNtpPSNYstoUWOUcLXsnVx+j3Juh1ZURndomT7tE3U7 Strr7/eOpqxsjfJn1XNcqKVe3zuYK3DytTzqdhAH2dSJZAfZ3nEum7pVJeO/m/qsOJy6yPa9hc+o ZfWCbJ/7y/Z5qWyfI2X73Bnt8NsgFGwBN8EtUBltbxXwvmyfJ6Rpn5Nk+1xBts82tMluoBfI39Zo n2u2pbnfqwlxJ44fPbQ7TN//sWiBGOSNGztsSP++PbsHde4oImPdEyOYBSQX3hPjnsZi74e/GPfk dV8u9Lr6GGgFvcNnBO/yEHuBH94R8oOW3o6QHZqxI6Qk7fcoRTtCAnhHyHbK0ZR8Q3lfCEZxIkcd GaOZLHeEpbZuSSRLG7H/o5ZuaUt7P87xjpBt9LnxZM3Fuzy2kjU37f2ow9YtZK1L1hC2hpJ1qmzz pnFL9w1r62j/R2aWu2mW5rCaMFXPWejZYukxvabI5Jlj6bFO0KWstddxsA5f24GvljPvBMjK/WYF M/q8DpN96iuyT91a9qXXgnVgfTtHe0BMY70M76aw9pjW6Y9ZZjOF4jclMvfXcXZDiMVbJvwd3FF1 Ld8plO7+j8LOluEZcBbEgjhwHdwAieAeuA9yYKz0BLCBvKAAKAi8QCB4vb0xrrJhbOQGPEEd0DNQ H2f1Aom3rlw8+1uMWPs3bQEXa/+f6mv/XY3/kV6bNaEV/ldIDiA5j+Rykito5b+2WPmvp9e4dWjF /U2SHUnOJjlHrtLP5bX5xaytkL6VbFnN2kbp28SWUNZ2SN8PbDnI2iH6qYdJHqH1/+REex0uprjc 3B+QL4V8b/N6fzj5utB6fxhbw8gaTtZKvN6/i6yVaRfAx2zdKf55JTOjbJ28nU0Pu2n2ZUdxp7IF q3sKHGRTu4IOsqmJhzpi8srKtfds3huU7vPv+ajPpn0eZLIyF+JKPM3MfROAg3D96rKhdbj+yWo2 ef2T1nmV9aZ66nqTp1WZzgw05ri2BhrzXHsCjbmuSHAg0JjzOhNozHtdAnfBPZD/dZvmATzBs6Ao eA48D1qB1iAETAW7XlfngA7uDfthy4Y1K5YsmPPV9OAJY8U534fjf7xA6xnFSHYhGURyGsnpctfG F7xXYwZr86RvPlsWsrZJ+jazZTdrB6XvEFuOsBYrfXFsOcdaPGsJMpexu+Qiazek7yZbbrOWR+7o yMv7OAqzVkz6irPlJdaqSV910y4RrWRGy9rBqFdd1Mn4NEDW7Sx4hOsft/7vkRnPaxi4CC79H3vn AV9FsbbxAfcEiLTgpXgFBBVBRJoidgg99KIXCEXpgnQRQk/oRQJIBz8UkKb4AUpRlCYEkJBA6EV6 UelK6ITcZ56dM7sLOcdDGsh1z+//OPvOnM2RmZ367ixoVd8QrUGMx22dnBN//zNuAn9x3K/1/+O2 fHfnuczvJ0FJUBc0BOPAXLAeRP3HzOMw4N8AZQT8GxQHJUAtUA+0AYEN0bcA6YIRB0qCQFAOdAZd wCAwGMwGc8A34FuwHkSArWAbOAB+AZfBFfBII/RVQG6QB7wJyoAPwCdgFtgIToLTIFamb4zfAr4B S0HaJujrgFLgFTAUjAFfgsxN8W8CcoLcoACoDdqAX8CfYMS7hvgY5HrPEK+BbqAfmNXMEF+ARWBe c0Msb+5eC7JWdaxzkbg1In5O4kKyBPn6/Idj/SfY0/0bCbaAfSAeZGhg5vWjtvwuasvzSirfa4M6 YCfYBY6B6/K7KANvgTJ3lIUXbeWho61MDFDlgr4fp+n7sTsmatO61SuWLta+H2NGDRuYwP6Pg+N1 Sx9vtnqWB8gUHYpQcRu0ZacO7Yqnj0W89gUZPYq+IJ3p7dGFOpu6jBpF3U89QG1Kz4x3lTfHe9qH o60O9VNx/bUlTIcmqLiJDp8RMzSbV55DXWTzBTlOPXFJjnSDpBdIWXOkW5WeHxHUDdRz1PNQUTA5 8tqx36OjY5+YEy99eXtj4aUvb3cT8ZLMfuL4Bep4+Lw9bKOAshwFiKxJvVd99PDw8cRxAcelL3hM dtp+ctJ+stzuFeI5WWoeqez94dx95BXD6f+xLa3Icmd9K9vhWcFWW7wo2GqPl4Ll4HvwU7DZPsf4 tqFHzAO8XPwgHam9/pslMXku+2RRwVa/bF+w1Te7FGz1z9I0svpomW39tJdUX+0t1V+TfbUNjWx7 fzje/W4999GikfufKYvfR3qlawPPN+lzuaGcy+9ntfK1Wa937dCh0yrujLZc1yG5J4iMs/w//HQo QMVZ/h//0qHnVZzl/1FUh0qrOMv/4zUdKqfiLP+Pijrkyf/DDL2tvmn5f9TXoWYqzvL/aKlDA1Qc /T+eSmx+LrL7WDgW1xxbcTi2/PCSzL6Q7iWZfWbXSzL7Iv+dR2qvsD/Y/iaZfL035TjqdzWO6oNx U9/GXud+7NW952Q+bs7heaeOxMTc05Ha67GpXToze8rbPWAvyIZx8GOgDqgLhqgx8vw7xshPqDFy LTVGfgZj4gJgpBofF8WYuBj4UI2Rj4MTIADj42zgsWbqmd8jB/fsjI7cFCHf7r1g/ozpE8eNGjGg f49u7ds2a9pQZolZi12+JscwV7jS9bRe05Jrti6/Z7jSNU5bo2kdT+tebY2idR+tvaXHSAVrP5E+ 3E/kmNsKy3H6kSzXviFbmO47eoyc0dZIWs/Sek1bN9N6nX4kTegl0pR+JKHaj+Rnpghj3FLqMvqI xMoU5c1fcJmWYtJHpJxpKR4nLSOkJdC0jKTHSB7dFm7idfPSN6Sstm6kNVD6fzyVEnnt2GPfMeY6 4jFmu8cYzyeOnR0cMY5dGnz8TmJiPG9A6DwSXsev4HGt/o5VOtt3yntZ+y+X8I4PthSBd377X77e m/nBU6AgeA4UbuYtnx0bKyQ5JsmbMYTZF47vOh6iNd4E2ysvJU5k9pS3JcCL4CXwGggE5UB5MBgM aWbNcb7U3BClQFnQHnQAHUEn0Bl0AV3Bh6Ab+Ah0Bz1ACOgJeoG5zc250vlqvvQ7ENncsR7484Z1 a1YuX7LY9viXuSdEz26dP7Cy1Gwjaim/i9ra26KpDr1Lr4r3qKOo4dTR1DHUsdRPqOOo46kTqBOp k6iTqVOoU6nTqBup26lylwh/vxbSV6OiWVu3ZBsWRh1AXU+NuKZmJq+5f22UDu1QcTu1ZbcOHVRx h7TliA6dVHGntCUWIVEopfI66Z669pMkr77cly0fvKz/2GbiKibprb/3UBclVF9kT8p9GQWiwa7m yf2+18SceHm80L4W6cgU53ODHpO5j4dvRjjAnZ/uvDwOTsj7F9wEfi0MkQ74g0dBPpAfvAxKgxqg JmgImoDOYAyYBGLASZC2Jb4LvgCrQZVWhqgPGoCOoBMYBcaC2aB/a0OMBzXaoCyCEDAUDAPLwHKw GUSCM+AsuAauA//38bdAdpAD5AdPgdfBGyAIVAXNQQswEAwGi8E+cBpkbmuIIqAEeB1UAzXBdXAL BLUzRHXQB/QH0WAP+ANcB7dBug8MURIEgVVgJ7jRHn2qDkZC7/tIeFs3D28F8bBjHD93F1qv+781 vvM+duf/NVsZMFpY5SA9yGArD3ltZaKQrVxUs5WN+qp8BINGYBQIB9FgK4gHAuWiICgEZrW8wwdo pcMHqF9v9wZQ+v/R5XeYvj5HqOno85me+gr1VWpPai/qAurXyivm/7VXzCId+l7FrdCWH3Vom4qL 0ZbDOnRKxf2qLb/r0C0VF6ctt3UoXoeE6rek0b2VR3Qoo4rLpC1ZdOhpFfeMtpTUoVdV3GvaIj1g RYGk5Lmj8d5iX5zzvFnLFvuEoJdkdncfRzLP33G4+3hOlpQjxf1/ktwKuNsYeUnvbQ17AplT4t6V 9fw//j9/D/8fd35lQLvrD3KCN0HlVmY7HWRrq9vb2utBqs0OB6NBNrTXj4F8oDSoAvqAvqAi2uVK oDKoAoJAVVANVG/jbOd72tr6Jaq9v2W+/oVvhJNPBa+4cwCYwPtfEunnERRKP48f6MPxI3UldRV1 NXUNdS31J+oI+l6MpK6mbqP+So2lXqaG0PeiZ6z5m3rFun/JQB2arOKmaMs0HVqo4hZpyyodWs0r r6Fupl6kxlFvc3eQFmgf01dSo8/LcvyXHHn/j//H38//o5Ly/0ipeze1/EI8j/qS9yTJu5K4j1T2 ALHv/5GA/0d2ez0rx1Wb2lhjq9/bWOOrK22sMdZNEAfiQfr3zTGXl4kcu4dIkpcMN9o9RLwks3uI eHYX99GRPPWO1F7/C0hqvsux9mO28faTtjH3q7Zxd2Xb2Ptt2/i7lxqDD1Lj8L9+/0sT9U/1j4+H bz4epiVhn1jxdGLz8B//j4fD/+Ov7se975vzYpnamvNixdW82Dqwvm3q+YCkYIy342H3/8jiSx7n bYc6ATQEwWAymAKi1NznRTX3GafmPkuouU+/9oZIBzqAjiBrB3P+83XwBggFYeACuNjBeu47avP6 tT98t/SbL+d+9un4scOHhPbt0a1Lx9YtGjWQtX5Temxs0X4c8s0PLr8oWgNuuK17ac3Gt8C8QTXf EXNYpqhmjoCO0FJJ+mlUNS2V6bnxhPbL2MOr5Ka3Ri1t3U1rbVoba+suWpvQ2l9bd9IaSp+OJdq/ w9/vkkwRZP7VWFqKSj+OKqalGD07hktLZdMygp4dubUPxw5eNw89O8po63Zay9LaTVtjaP2IVstP cpss30+lRP7ef/+P5I1Z6TFmoccYddjW3qt58dyo6nUfEHvKIC9XqfKX/h+V7/L/8HY/PtnREPlA flAMFAelQGnwCigDAjt62//RMax2DKE8x3g+8TLSyudTshF2P5Dk2v/x7/fUv80bKas7/yurvB8J FiNPvwGrwLxOGB+A70AUiAbHwQlwA9wEfp1RDwB/8CjIB/KDl0FpUAPUBA1BE9AZjAGTQAw4CdJ2 wXfBLLAK1O1qiGagOQgBPcEkMA0sBMM/NMR0ULcbwmBZd0OsBsE9DNESHANnQY0QQ9QHM8ECIHoa wgXeBo3AJXAdpOmF3w8e622InKAAeA4M74ffBGr3N0R/UG+gIQaAQ4MMcQRcBmkHow0divbrwpkL Z45fOHM0gc8F/bHOxZkDCX4EPzFHzSKarVT6sPJVc9mX8IQ/beYS3iPWM372Z/8CEnr27849IkXd e7nPy4EqoBaoDeqAcWB8R6vMlEN5KA9qgl5gbiezDM23laNIW1naZStP12xl6tb12AtnTh09uHeH fN/3KtkdWDB/zqzPrX0AOrZt5bhp5Zimnl7dekeH2qqVr3baEqJD/VVcqLYM0KEJKm6itnyhQ7Pp 0TNH+/W4/OKp/vTfefSabL2nSU+f6mbr/Snt31NXUG9R45RXzm3tleO67g49et2My6gtmXUou4rL oS25dCiPisurLUV06AXumFaU2oTvf0mufH0IXuTieZkx+Q/bTGz1+/n+l4B7uSeNzmZd7+Pa3hTf kn3g2xKg4y0ff/kwV0qunqb4ukDyrP/dde2E/l5Ge77KNjw9yGBry/Pa2vNCtja9mq1dr6/a9mDQ CIwC4SAabAXxQKBNn6na9/RovzOAHOAN8CZ4C5QBZUEgKAfKdzXMdwEdO7Rvp/VMGBqBqZPGjw0f OXhA/z49u3NDGJXtqHvpAZKRmomamZqFmpUaQC1NrUCVbxHy9/tSro7VUPtG0l6DXiI1qf2o/amr qWuof1IvKc+OWO3FccXh2SHjhG4/0upQDtXK5NSWAjpURMW9oC3FdKiciiuvLRV0qKIOVVKpKmtL kA7VRUgUTEy+x9idM3x8yHKSb5VBWx+TeawzxN/7/S/JeP/7VJdlTKn7OFFOP/aTJDfn979D4Thx Hrb2v8Zd7X+Ke31YpSx7QnVuBVARVAKVQZ2u5nisXldrTNa9qzUuC+/6gPv/2msLR6b4+HoR9/EQ +v8mNr/lWHwymAJyYxyeBxQGgXJMDoaAoaAWxua1QR3wvhqrjwBLu1tj9i3gWYzVXwENe5hj+EFg OTiqxvKuEPd7gNyrg+vW2ByBpB9Q+Mhh7h6BlWUuv523Zfu8ixpPLRkvtTG1CbUfdQz1NBWNY3xa l/z+t3Hy/BCth+O1p9Dv8p/TlRZ9BaSJoxfQbeoG+vlspN6kZqQHztPU4tQS1CXUpcqnZ5nDk8cM 7VRxu7Rljw6dUXFnteWGDt3klW9R/UyfWGp6agaqv/T/KZxSeem5Yv/ZfuK5vlydiBPPV3P8UceJ Y3J3hcdknk+W+pZMqHuv7LPC3JVDpEmT4FuGEvskSOLqf1/uu+oh5jxaRzDDNpe2V82npVFzaiXB m2pu7R01vzYCTAab1FxbajUAPvoSeT45Zz/x/EcdyXz8TvJewHFiP3R5s8qWGQqwStkTyZ2/hppH fREEgdZgAlgLToFrao5Vzq9WApVBiT6GyNTXEJn7WvOtX4Cb4JZt7jUUNAxFOQV7wF6QMUy1C+fP /Hb+/Mljh8+f/2Xf7h3QbVGbN643Zw4XLpgvB407xm8bGz5scH/rn8jfL0Suh00VHPP1vM2d+qVl imm5yvZim1XrL7lB/9BwtgYnqaes2N43GXuF63xXqTvYeqzkdVZRD1P/oGbkFfJSy1M7UadTf6DG UEdRV1IjqTeo66lbqbeom6kYcqr2Kzv/UhVqW2o76mKoKJ6aeeZ5acjHBb8knzjWfJL35DffkiXv Be4+zLbF7ucn73a1/iODqA+smkH8+857qQIYCT4Go8Ap8GuYte4xEBwcdPf6xyOg+RBDtACrwZoh 5prIPnAQxA71tk+449lvzyee9xb3ca/9Ex6T+XjieMY8yVdLzB91nKgDPQnVp7Ct9U4Vssa/azXY thI4Bfmf0nmefZghngdFQHXQBKQZju+DPOAFEDHSEBvAb+AamBNuiLlgC/gFiDFybY2+IWalrur0 OTPX2p4AV0+FocbLxfWNQtQa1JrUW9yBIyPr5aLUYtSNrA/3UP+kXqJOYk06j7qJ+jP1cLxzFJCO o4AMaV1+eVjbl+K3X6Z+Qh1nXpvfvmR9+0y8bQzxEdN01y2OWfOrlItRn4ssfm3jVNvkn1bIur0d vULWaWsaWtfzV0QwLqO7feM3svhV0OcyrXjOnV/7wQEP+bZtnCFiwHnw2URD/Aj856EPAMaBF1cb oiqoCRqAXdG4FujwiyG+BjlPGKIlGHca+QnG/4HyBQpfMsQHYPg19CNAWGaXGACuPO4SV0Hosy4R BtaB02BeWZfYDiICXWID+LySS2wFVSq7xMegSDWXqAeWgmWgXHWXaAcO1nSJLLVc4tLbLhELnn7H Jc41wvcau0RMM1wTjOjgEiPB/BCX+BJMHeESP4Iyo12iLAgf4xLRoMdY/LaLx68eFQd2xew6EHMg JvJAzFV81sbwhKw1P5HSYtrd/11rBuUnkib3+m5AAuu7uRh2r+Xa13zNcA69/vv4I+1kbtov8076 NB2qCCOTGaPO7lwPFtWT8x5NA/KComOcZeYCSDce5QTUB3H2uivJztmJ+U5iLpBavy3Jv8DhM5PQ KEC1BGlQI+S+l3zrC/aB9BMMkQEUBu3BNLATZEK9kBk8D+qCdmD6RKvOWAkOgMsy3SRDvAZeB9WA /2RDlAWBoB0IBV+BY6DCFEMMBkPAbPAD2AtcU91zQqd/PXHs2GHZ8TcbiGPubr+1WGTODQlZP/Zi rT+J+jV1CzWKmpm1Z2fqXOp26m/UANbP2Wx96nSsq3NSc1ErUM2ZpR7UCdSJ1G+pS6i/UYvwOkHU qtSB1B+pZ6gvMGVNai1qP+p+3c8/x7kmlznnY5txeoa6gf4Ju6mXqLFy/afY/chXR2lNrQd4fDx5 wH5bYmYuHCfyuOvOt/r/uX29zwJBCOgJpoHFIAakmYZ+ABgNxoAlYDM4C/J+aohWYAaYCdaCPSD2 0wdhveB/9EQdqiTkSYm8zf9/6EeAgWAQWAgiwHlQcLohOoLF4BuwH1wEOT7Dd0Bj8Aco8bkhSoJG oAsIBxFgF3h1hiF6zbDV/UcPHdi7a/tWc3eou54OVoMDl9/jnPfuSx1FXU89Sr1KzcfV/PzUZtQr VD/WmeZbw5pTQ6ifU2dQT1Cfp2eXubfTKOosajR1K9WP45ES1KbU3tSx1EXUxdRz1Jfowd6aOow6 nfoTdR01jlqHY5ww6gzqcuo+6n5qANu5GlBRNDXzqzeYOuPhu/cdFW4K/h1HY3APt7s1D3RXS5Db ni+LQBS4AarNxNgfDAQzwHKwA8SDwFmG6AFCwGKwEZwHpb5A/QHOgnMg52yMHcA7YBSIBlnnGCIA FALlQCMQCkaDa6DgXMSBKqAp6Ae+AjEgwzznuPNe7/+4c7LcVzkvNYgaRp1L3UmNpfpfkFqY+jw1 mLqOup16lZr1IlNSA6nlqIOoEdQ4aoE/pL5ObUVtTV1OzcO1w5bUkdQZd71TIoA9vHrU/tRp1MXU rbZ9B9Kxz9eAOpg6k/oddQ91b6y8/+9Xvj9sdcDf5kQd7vY/qffgeLAAnJX3I/hwviG6gVDQ8StD dAJDwO8LDXEapF/kc96nVrWaWic+Lkl6ruUTs8ApDy/rf7kTm4dDlxpiGJgONi43xCZwHoSsQD8S jAFDViEdmA02/2SISLAXNI/AOAOs22yI9eAgmBGNfmS0OXd4CjTfaogWoAfYvQ19S3AMxIJXY9D3 iLmX+l96hcgxsrmudpx6WY+c+0Swjt0g9QL1IrX9Rql9qYuoi6kfRUoNp46mRm3jt6i9dkgdSh1G /XqP1EjqFupPB6Tuo+6ntjwkdQR1JHXJEambqZHUqqekvk9tS91yWupx6gnq9rNSD1EPU//DVq81 dQ51FXX1OVn/34+89DzGdpRjzzNcSU72X/LuBc7GauHj+MJ+JnKtVOQWIvS+6iAqOjgpSknRKSlE 95BULrnknimXhFxKJddKFL2dHF7MRDeRyzQal2QY0mjcdobBdn77v2ZmP2PsaTczZg/n+Xy+/9oz e/Y28+xnrfWsZ631hPimwY+xsHQTZOdX8G+nH/Wu9T/KBzu2uqAPZmEhYpGIahto56MtnsJ0zMcW HEDdjR7TBIvwPXagVIzHVMBYzI/Jas54dtaGCbFX9Jz5mdx9Af92eq+P67pw+bO9r7/EMUT86DEV URc9MQrTsR4/w8R6zKW4Cw/iWQzDAixFDPbi8k0ecxWu3/TX2/+LdC69QpmkLKRz5nLKGso2yieV A5Svus60NymPKSN0Ll1f2VL5mHKmcrFyvfJnZWmddddUtlD+2159VNoxI0XVx3yVcpJypnKP8oSy puvqYndXb/Es5ULlPmUB1XPVlHbMY0flC8rX/Bcfa5/tfXQHnsNATMAHm7KaLxy8hMvx0/5Lfybj lmlcSPlg+ygWO/EHiv/E+RxaoTfmYBW2woer4ygj8CIi8Tm+x04U3My5BBrhdjyCwViIJfgeRbd4 TFXcgHboi8n4GNH4CSfQcKvHdN0auK48f+uZy4CowNWfqKgzXP+ppKOjo7KTcpy96q70Ki/UMVJJ WU/ZRvm8coLyA2WU0o4eKKz/r6FsorxL+YjyFeVspR3JtTG9DWr7FIcqP1HGKY8rL1av4XXKTspI 5YfK75TxSq+ygGue5y3KdsrHlaOV7/vnf16b1/s6w4czx3V/WB5kGKR5Fof9BP/rZPhOhn+OewuM Nz7tqHe1/8rl9Pj7GkW2eUxZvI5xmIsL42kLoCL+jjaIjM9q/4flL5lXH5MQd1/wtl/wF8jwwLWd 3tfrKvUD1//KZWcfvom5+BbbcOFOPj9oi4fRHR9jDXbhsl2BMUCP4RXEIB6dEignMBRdfqWdid6Y hHnYgSSU2usxt+BpDMQ8fIvNKPubxzTA/Xjjt8A4o7S6IcEODUhISFi3JiHBPSp49gz/9/xVRELC dr7lryj0t4torvK5hXKocoayurKdsp9ypLKo2niJaqEVV11QQjlKOVW5R1lEz7f1y/3KB5SvKqe7 6pTPlXuUTypfctUjtgbZoDyUXo9Eq/y3LciGykZKO4vlS6Wjf4f/rlCmfl7uz+BNlhB7tjKMfQ3e 5snO6dRZPG3PsLZMdp6W4VfI1LsX2FzlekT6/2YY75upJLgiN46zbfChZaLHtMcGbMR+TN3vMdPw Eb7an722f3Y+Kvn5A5GhyM/O00L6QLg+DcH3f7m/uv+2whygnYir0QiPoBv6YirmYwsOw3OQzxPa YfzBwNjPX1HykMdUQAPciR4YgEmYh/XYhr2oeTgwXrQrhuFT7MMlXsorr3ssWGAoWHx8VHx83BmH g8XHv0wrW+XnIJWLk5VTlJuVW5TlVF5erayrfEDZTfmKcoLyC+UaV2n/h7K83qWCsofyOeVH6WcB lNnK65SNlPasoZfSzk2c5qodNp1W8jdRr4StgS6wZyPKl5VjlVuVJ5U+f/lfJ6/3aYjtvxCbOyG+ QPA5VsGbYsGfdhbbjDk+GXBvIbX/s3OcvYsfsA77UeYP2oYYjHE4gBpHeC20QA9E4l9Hcrv8z3E1 kZ1yOcfvk+PfNPj7uLbQyv+c7s9v0DDZY57HC5iJPah+1GPqH7Xj+jciBodQ4xj1DPpgJAqleMwV uBut0QOLEI/qxz2mAzpiEOYiCgdR4ATvh/lYgHU4diJtLmBS4q/+hj3/TR8STBWQlJShEkhKGvPa MeoBkzYb72KVqJcoVyjtPIzVKlP3KX9XVtPz7Wy6ycotyuPKE8q/6WftGcSXrnLe9uv+n/Jz5Sll G/1UF+X7ygTlpfqpy5StXOV/UWUt5TXKLspo5Yb0euFkphrI9kn557KYunm9D/PqCn+OXzr4MZbh aTmesZu7D1zbmY7/TNf/y4V6XNU7yfkeXsBGFPd5TAnUREcMwTwsRbFT1CF4GB0wCF/Ci9v5NwTf UcH3WvA9kJ0PxHnwPn/hA3Gmnp+08R+5vW+HYhgmYgli4IWngGN6YirewsfYjMMoTUHVAj3xPIZj IVZjH66kxroDLdEVC7Ad9TyO6YbuGIsN8PmOH/3j0P59Pt/e3Tt/2bZ5U8x6/93Efb7o48uXLj7k 832+6JOPP5wzc/o7b02e+MbYUZEjhvr/QhGPqgwerhyhXK4srdKzmaulP1f5gXKj0s4Asb3+TZXd lYOUg5W2pb9deaPyJmVn5S9KW7f4XHXCjXr9McrlyoJ6pj1XsFf2bO+RPUv4Shnrqh9sf9XVSns+ EajZ+NPWDcc+Ow8O33PmgX/L6vg/0zFU0HHM/Xgd4/BvnMT1EY4Zjxj8iMO48gLHtMdITMbdhfks YARmIQ4nUKuIY27CiSLZ2//5+UF+rlr8W/AzAVM+L/Z3hQsd0wS90BvvYSfKFeW18DamYSVSUKGY Y9rgbSzCQRxCieKOaYzOGI3duKAE74WH4b4WHJfa8I+Lc/f2vzctLs72/8TF+S8IO7pfixPRXtlf ae8JV1Jp29X/o3zaVZrbNTZuUBndUdlJOV25Q1lW5fVDyuHKEUo7q8+uAmL0OoEWO2cE+rpdrSpW adcICZxB2Fa90fWGispKyk7KZcojyhs1pqSzsovybeVBZeWT/v6fvNw/HVLnd58Hx/I58z6nbZmO f/d+WYKfcVFJ2gOYhhU4gZO4tpRjHsNIfIuf0Pciyg3EYTMKXOyYBngQr+MoSl7imFa4G30wH+tR pLRjWuMJzMFcrIFzqWNq4CEsxEYcQZ3LaLDgAbyORdiDmy/nd8BgLMNyxKJsGT6PZVQueL0HbZ+A 1+vvGt6+bo3Xq16BBK9XpcMxrze1Z8D+zzRKCfsnS7t6t01pR4fYkSK2b/eI0o6vus/VFvteWVNZ K1MJ8o2rjWaP8JbKzq7yxbY35yuPKm2p9IlyuXKBvr5DGa+sqK/bduiDyjXppcYveoZHX/XfIMbc EI79HpYDITtvmrsnaWEpWvxbVvV/Xh6HkfgCZ7GnNyzX88LypiE+yLhlnv/t3i+LEYtiZTnm0R4f ITp1PZYyVzjmVgzCJ1iBh8px3og38Q0OoEh5zv0wD0eQjAoVHNMJE7Ef/1vRMbXRAgMxHd+hZSXH DMBAvI3tKHalYx7BJEzGR9iIfShR2TEVsQulqlCGVXEy9AHb5eDWrUlKsp3AJ/yFfVLSvA9i3d3A I4f7S0d7dcyO4Vur/Fl5RO25IvruhcomyonKaF9aaepEVFX+U2mvz0W5riNuVV6h59v+AztO193v /LCrbLdXE39T2lUg7Hm/u2/arjthW7HdlMOUMell/ja9a4ryuLKWXst/fyhTLxz7PfzlZV6V/3lV 5Ad/4N+yKv/P5nFYFXegG8bgAMpWzQ/7P3cf5OdPk3/Lav9ntZ+uwHV4HJGYj4JX8T00Rwu8iMXw on412oV4Cf3QH9PwC0pW5/nV7Zpe/vW8Vqau6ZWIiKt5fzyI9diABCy6xjGf4WvsvpY2Bk5hZR3H rMKOOv6yPjlZbfvk5AT3CkBBFgAK/E0iVrpmaNv7t7+vnKGM1rjrH12r5sx0rabwhdKuHtdYOVT5 jvJd5SrlV8oiKnebKl9SfuC6pugeL1hSWUrZxlXL2DOO0q62/T+UdjSJHRG4RXmz0o5Wb6scoNye XiN8q9fyX7GkuA/Dfj7fjv/8/OC0LdPxn93jLra+YzYhBZUaOqYKrsK16IkReAursAF7cKJhVud+ wX+HEC/FBh9wEfxpIb5pjp8W4mXiEBv1wX/GvYW0/nNO9mW1Ro5pg054HiOxEMsRg7245GbHXIm6 aIGeeBnjMRcbsB0F/s77ogk6YBDex2psR7HG/JvQEHejC/o1TuvztcM9sir8ExMD839sP68dUTdT aVdatuMzhqjEnukqvXcpC6qsrqq8VXmvsr9ynHKWcqGrtX9Q6VGJa9eOa6hsrXxM2VP5tvJT5Url eqW9Z0ENV9l+r7KjMlL5jnKhMjCv/Ylf/Y+fVo7VXPCFykXKuQf85X849mNYJsLls5/J3Qd/MiAs +Piv8sGOqwmYhV3w4ZImjqmH29EBz2NOk8CarBtxCDc25Tmp67P+gX7NHDMYY/Fps5D3fYgPgg+R zN33yd1RnhkeBJ//E+IEoj8f/5fF/O9yZ3NffwUfit7qmMq4AwMwDsvwK46hwW2OeQLvIm1N33XY hxRc3Jx2aPPAOr+jsQolWnDOiZlYiO04kZKSnNbXn1YhpKTWCCkpC1JS5h0MVAsbOSlIWZn290rt pbEjqOup1O3mKpPtzOo9rjK5uMpbdw+/nRdke92jXXVKA2Unpb06MNRV79ieHLs6dC2dWXyif8N2 pb2C2FW5SLlBaceeBMZyp12DsDOXHlLaUeZvKOcoo9Jrh0dP+cf/5fV+yt2yMvhhFeLhm896a7Pz INj8z9DG/7qPHS+uu90xN+NJDMBifIXDKHyHY5rhHvTHOKzBZlzTMrD+dlv0wEBMwAep63H/Cz+0 zKr/P8Qy85z5mbyq5YP/jH/L1Op39f/n5X7fCx+K3umYpncG1md/Bq9gIj7EcvyKy+5yTFXUR0u8 iCGYhHl3ZRzvEcr6H8VVtlaxfTfKdsruSrtm5hjlUmWCMkVZUucAFZR2XMVNmUZXTFHOVi5R/qj8 XZmkPK4spZK9uq1plK2V9yj7KPsqv1NuUl5izwRcfUOdMp05/Ky0VwvsqL9GyieUduUPe/14lb/8 r3029kssduIIirZyzPX4Bx5At1b5+/pviP+cc+ZnMm6ZSoLyoeyvKZiNra0C91Iohdroh9dQuLVj iqABlt3rmJXYAC+KtOFzhVZ4FKOxAjEo0JayB03xMj5rm/E+DVehBSZjLir9k/NQNMKOdrRZ2wUr B9L6AJYsmbFkSaZOYI4dzZezc6ErK6sopyjt9bljygo6Xioq7dwJOw9jdLbbebYFtlsrDnfTjO23 lPY+8WW1PkdNZS/lBOVE5dfKb5Q+ZVH9Jg2Udyo7K59VTlHOV0Yp1yqPpvjv/5TX+zf8p8fZeVrw mWG5254NPgMxxKe5t6B3fnC3/7J7zB1CyQd5LlrgPvTEK5iHlUjAMVRv75hb0LZ93o39C7GszLDL Q+yxzatyPMQ7A/6V/Z+5/zcn+3I85mNf+8D9dG5HP8zE1yj8sGN6IwrROIRyHRzzdwzAb6jT0TF1 0QWjsABJaN/JMTMwE7E4hSqP8LzUe/aU7+yYCmiMIViEZPytC6+JthiAL7AXzR/leUidIrJ3906f 7xefL3WSiM/3zaro5Ut5vHj92s/tf1K/mDplxOd75y37p007s7b33Vur1tkBV3/vNao3nlW+p9yp tLME7VU5O8bXjhuJULZWLlfG6bvu8YG2BWfXAbFrSEW5ap4rlXYcyMPKnsqxyreVdtzIj+5aqFE4 9mNeFftnsa45Z14645b5/C83j6uhmIU12I3LH3NMJFZiFX6G83h+aP+fxRoln730aVum679/Zb9V xG1YjgM4iIufoL7AcHyLgk86phCq4UlMwRZc+hTnjaiH3piJeJR52jFlUQdP4jUsQt1nHHMPhmAo piAaW2C60j7tau/XthgbcBwVuzvm1u7u8d5eb5DLgnzDv+jTBK9XJwVer79ML+I6C7DX5+ydVu24 CntnQLt6k527Z2fe7VP/gKPz+ghlI6W9y9Qc5W/Kwqob7FiQW5R2vqGdBX5MadcaKa+8z3U+Ysds 2JrA3guqtrKj8ielHblYWVnFVRP8cCrtjMOOMbxeWf+Uf/xfOPZrWM4BzrcHIf4RM26Zy/+cHGf3 YTtKPsvzUAtt0AvvYgEa9nBMN3THSHzaIxfOAUIsL4M37sPy0mF5H/+W1fi/nOzHGJxEq+ccMwiD MQXRSECxnrQlMBux2ATzvGNqoCn6IhIDX6DswQrsQeUXHdMML2ENivVyTHFUxZ14DK9iKi7tw/kI mqEDXkm9f2cMqvV1zP14oG/6OJHU64L8l0ohPjFRX16TmGirh8REVRCJifYSYWLipAnr0v6GEcNV atq51Rdk6jXKXF/Yctj2CNl2ub0XoJ3b86CeP1g5RPml8gt9184Osut/uEfyjVAm+QKlva2PGiq/ Vm5KL+3tXKUS+qqdOdRYae9i61/5ytwYjv0Y/sZzjq/Y5LP3Cf7AvwUfCWDK5/S46oEpWIqdOIwB LznmY8zHJpxCmX6OaY1O/bIq//NZ6ZufC/YQ38e/ZVX+Z3cf3tffMW9iEhbgJxxHlQG0+bAU+/A7 LhjomOvQBv0xCmVedswdaImemIcf4Azic4VJmIzVKDGY98WH+ANHUHOIY7piPgoP5bXRFs/iTSwY 6hobnpCcbM8DUh+vS062JwTJyZlGCupP6UR0Uou9n7K/0q7TX1mt9C7K2co4pV0v0K4LZVfci1J6 sqwFdvxpSZ5Wij8Vcn2RVXlv6wV79uIfRWjqh2Nf5rjID/FC+Pn2Ptl5oO2M4z/s/V+ye2zFYS+6 DXPMe5iOpTiEosMdcz1uReERjmmEm3EfBo44L+b/nzft/5zuy0lYhrVoNtIxL+BFjEcsCkXSjkBf vIRIfIY1SETPV6l7MBVL8f/w4YbXqIPwEeZhNQqNcsw1aIensHo074utOIQ6Y2jHjEnv3/cvBeVf BCq9hz+1f3+xloDaPWfm+tRFoHyjIkfo75TaT75VacfjFVSpb1eHekH5vmtcRkHXeYA9A7CzdUrp Zy9S1lXae0jYdUbilfY+4xWUFZVtlROUdt6ox3WGUdWeDfgyluhpK4asVf6gLKSvH85UG9gZQ4E1 oqgN6oVjH+ZV4zl3H5ybvVb+Lav2f6jH1CAMxwwswX544Yx1TBO0Q290ft0xozEGa/EDEnAYxcZl b+5XjkvEEK+khvgzwWvr7Pw+ufvAtbmu8gcdCWDK5ea+vRa3oRd6IwrR2IH9KP4G30dzDMYQTMcm VB7Pe+EZ9MNBOBMccyNuwqOYil0oNJGvTzy9T+dPZn72Tf+7RBTU+JfKymeU05Wrld8r7fpKpZWv KqcqVyl3KWvbukFp538OUy5TLlceVV6m0vwqV89/M+UY5VilXW8w1nUt4GKV4Fcq7f2+Gih7K/so ZyjHqEyfp1yV3s63a0zZPn+7ktXtSjt6aYi//V87LPvN/TH973mQV2VAsALBnGn833/YOxP4HK71 j5+EGSQidiGWbtbW0pYuXPSiG70X/1Y3iqstqrRa9GopvbW0VVr0VlFCEpKItVV7tKg9lhBUQtJW SSt7iIQQ+f/O77zzzrxJ3nibVXs7Pt+fzDMz73bmPGeZc55jpLeRth3naGIU8J+niQDw7FLkfzAJ TA3SxF4wJEQTS8GqZZo4Ch5bgbog+HAV6gag4kZULIDXJk1UBS1A282a6A9abEEdA0SH4T7ZinrH dk18B6bvwuuBJrtxr4G2ezXxT/DyPk0MBn4HNREDjh7XRCT4+awmzoDHf0PbEwwAKSma8E5FPeUS 6ing1BVNuGfBZ+XAZ4GZYBE4ADq46WIQeBHMB/PcdXEIlPfURWOQVkUXlb11cS8YDhpV08WzIKy6 Ltxr6KIB6AX8QVaG/JeYkRjHP+LwL1Ei/8zijnEGz8pIFMYZsadFlIiUF4Tjn/w/SsRlCOHdtXs1 0bO7u+gNhlYUHu0q/kea8KcoL/8Q5fAnzvLJe5YPz6puu8JyWFSwvYQ6r7b8s5fMj5+BYHAcZIO/ zTHvg9FgGtgATgO3LzRRDdyFe+N50BeMtt0rYeAsqDZfE11AV9APTAOBIBycAn9fgDojGAXmgO/B ddBmoSbmgkhwDCSAW/1wv4BhYD04B+JA+UWa6AT+BT4BfmDyYk1sXqye/6opQOnpDgVDenoay4b0 dJYO6eksH9LTbfFfVIQva6xutYZbf+qAHNPTRueYntUagXswVcWOUbP621Dvpg6iqr6a9ywjxudT wy3lxS30/+2pQ6n/ob5PVbODrM8aVOwwFd9VRRCbS51HPWkvEfpzvOib1ANy/be2ZZH+Ze8vS6v1 XVqlifOvILeC2v+lkR+3gGig+WuioX/p9f/9MV+6eH8dbgX0/+WXPk+AD0AICAfuAai7gVvA42Ay WAO2SQI1cQlkgJpLUI8AA8EMsBDcbqk/TAah4ByoiXrEbaAz6AWeBFOCzDrGPpAImgdrYiSYA3aB Vqh3DA4x6yBBIfnFd7SHd8y3LWD+MJq+hTX5K5aZPvfQA39J3U9Npd5v6QNSazjMtfT8q7mjyudX tfQKdaI+QR1HVf01KtaYKnFU/PCOVGvpM1LV7alq/R4VF2Anjx6jqpmfvvy7PlU9L1azD76gmmtB qIiSQdTg63L8f1mk9002/vMP8zC4MDtyK6j/pzjy3wbwMyiPtsAdYDJYucxsH0SCTqGaeBG8FPq/ 1P5zni6l9QlybXnK/8Kk3xSwDcSDy8BnOeoQYACYCoLAYZAEaqJdWA88usJsJ04EISAK1FwJ/wP6 gWzQCe3HzmCArS25EpwGd6/WxCtgGJgFdoBscO8a63PefPuBMjMdvH+mJR00fRL9dih1OfUX6gP0 kUOoH1PXUa2RuVXsResT2H4sKaZQp1LDqFsto0BVaVKH79KO2p86gaoiyKh1OlV0sMp8LxU1Uq1D oZ4vq3kF/tTdqpXBz6CiAKgYlGp9UbUOxU/2UmAZy7nNV6X/L4v0/N/J/4VxBsXb6JBbQfV/V/JX V3AG3PoVynDwEBgGZoDNwOtrnAO6gVfBAvAD8FqriQYgDFwF10C9b4o7/UvrZy1BX16CX0FuBaV/ SaRvNzAE/Bf8ChqsQ7sCPArGgrUgAVwFC9ZrIgbEguug2QZN9ADvgMOgwkazP7Ed6AfeBsvABnAM RNv6GqsAb0uf452gJ5gBjoGsTbmeGdjGf9p2oxISVNmRkCBLjwhVfCRgU80H+Uvaxue8T1Xzqc5S z1FzqKp/Xq0IqlZyUxFbUqhqJbeu1G7U8dQjVFdKGTXXS43wVz363S1+3lwjYiuvV3POTlvaCZup cgSS6FAW6fUnyFal9RWKvCO3gvL/780/9242+/IHgMnAHxwGMeAyaL7F7Od/GAwBgSAeeIa5nP43 88/6h9nJteVJ/+JK0wdBAIgKM5/t6OARMAGsBzmgx7fwB+AdsBicAh7foU0JRoNZYAk4CWJAMrht myaagvagJxgLgra5Ev/F8vj3LekRky0eVa3q09nih8dSVURF1c+vYjs4zJjFq2h8QtzWEmPhc+oc 6k5qVUt8mVnUfdRKrP17UNtR76OOoJ6glme9vzF1ODWEqsYcqdVIz1HjqHX4re6hqsj0r1naLWuo X+UpC+S6oqJVWaTdnzrDueioXBxEUuTT5JbfSBAj/xt5aS3YCaJAue0oA8Dt4AEwCLwO3gOf257X HgC/gMug4Q6UFeAh0AeMAx+CReAbEA1+BddAte9dHv/l/LS/rnH5Gsctb/zP0k77+0E3MAXMBN+C ZJAD2u/UxBiwEqwF4aD6Lk08Bz7eZY4RWA12g2O7blQGoN4eKHt+Ai2DgDQ9if7PXAXJiJSlYuyq 6I3+1N+oKt7629RvqClUNUrfjLd7G723igrfhzqMOpE6nfo1Vc0liKUmUKvRk6uIYB2oj1Ffo6pe qvnUYOoRi//PpKqxoq2oXalPU9WK0jMsrREVRXLbdRn/tyTSJB003m2O5XgU9APvg9m7i3v8Z5G7 1W+ycabFu8OtgPi/rqRX9z2aeBYMBuPAIrAChIEjIBOU34t65F5z3E5PMAFsAdo++AjbOJ5/g5D9 mkgESaBhuCb6gqUgHFQ8oAkfcA6Ig5poBZ4GC8DCg+Y4oNiDlrx/g+F/Z3KN/+vNfKvif8+iqgip ahZ9d9bfXqbewzpbF+pE6lJqCvUu5twXqP2pAdRI5sez1EbMaw9T1TO8A1TrSvGqR0DVSh+hPmnx OKom6kdVqwirqDNnc9VK1fNGNdLkGaqKGTvCkv+tKwnL0YGiVWmnr0N2dx7H2PnoWxfjJRdm+G5p 7Tj8BsX70pYtz1i/fEYBC9/fm+cyQKNDmugCXgFvg+GHcS5YCDaBX8A10DRCE2+B5WAF2AESIlye /+li5bkE6/Iu1r5d/NRFfp/C7HBzPv67fnGlaZUj8A+gK5h4FHUCsBrsAxdB5UhNtAPvg3VgPTgA LgGfY5roCP4BPjquiY1gk22cZzaofUITncF08B3YBk4Ctx80cQfoAfqCeSc1sR+Eg19BtShNtAB9 wBIQBaJBKvCNhi8Dz4FXQGJsnvmi16IyM1WpkpnJcsVxd508WZY0lpPlj63pHelfn6Oqef6qJd6J HluNKbQ+n5tGVbM9VUkxgDrQUmpYR/up+ZuqFFMRAVQPxUc8cylVjfFQPci553+qeagy2pjoUhZp d5ONyyjBly77ryC3gsZ/lFRe8v1RE/XBg2Aw+BhsAHt+/Gv+v9xK6yvIraD+/xulVbMzmugPBoA3 wXywFhwH58BbZzURAALBRtuY/Kug0TlNtAZBcWgTguMgCdT7FfcQGA+mg/qW8fsDwSqwE+jnNdES jAShIAp4xsOXgJEgGJwAngmqHZBmG/+RlubYFEiTLjooMM3Z+L9prKVvoqoIjqoerWJvqfFyasRe KlXN5lR9BAuoatWdBKiHu7vQ3Bi0Ea/8YI6j79X03Ww1xFJ/pHqxvTCZ76vmfW60tO7Vap1qNKFa O0iVLNa1SevynLuoLakqNoE5RlD5/Ktsz/jwXetSH+P4j9JO4yK7Yed1JeeOs8ju3kUHXSbfJ0U4 38q5O/r7PON/fYuS7/4ORoHlIA7USNTECyAYpIHWSUhzsAxcBD2ScQ8lF/T8r8je9ybbKbKXL/IL yK2g/v+ipGM0aJ0CnwE2gOQUcw5WVTAbxIBWaZp4BowHM8F64HVBE4+A90EA2A/OgZoXNfEwGAf8 QBKona6JDmAomAKWgKh0V57/Oa7/EMaVPU9RL1Mbp0vtTh1F3UE9R/VlfPYnqOOoc6jfUmOp9TKk PkkNpUZQz1IrceXQe6iTqIeovRjnvTf1Deqb1GXUZOrdnKUzlbqVWos+fAR1A9WNnvxu6uvUTdRy LFf+QVVxKNdR1UoUjVhC9MmW/T9llY5/tpz+h9mxbbb83yB3nrqYruZOfghWg3BwFfTLQJqDPSAJ eGaizg+evoz6AfgS7AC/AY8rmmgD+oBRYAbYA6KvmHMy/0qKmyP9SzPNy4H2YAiYDnaABFDjKuzg NRAAIq/KGC6aaH5NE73BVLAe/Axuz0Y7E8zM/v3+v0KC9HsdqROpodRoqjdXxbyfOog6g/ot9QK1 SRL9KnUM1Y96jHqF2iRZ6gvU/tQp1KnUedRIahLVM0VqG+rT1LFUP+ouajzVg2tV35UmtQ91FHUe NYJa/oLUl6mfU7+inqTGUUew7PvgovT/JZEu34GzoNl1TQwHX4CNIBHUysFr5vyV/8tsx7YZ+d/V 9HoJfASm5eSdS38QLBC6WAjau+l55tZ/Cea6m3PsD4Nby+niNrAALARNy+uiGXgOPA8+BTPBHrAX WPL66dMnj6u8bmb1eXM++XjSe2PHjBgmZGt3NOo53vpyaEU/UcnNozytK2j92W4tR+sZWmtkG1Z3 WmtmS6uf3epG6yLse+h1r9uswpiXYX3Spp6xq7gci9kKV2MJTtp7AjzcywnNXX/pOvsJ1BrA7jyq IjcdpUaaPQpp7FFwx/uJCtRK7qpVf41r+zY5L7UHdTQ1hLqPmk59IF7qeKo/NQIqmpdm2jq/KZ03 j52v8OrQNEot6k6ydadMMuavhTiSZ9OZrT2aCM9H/IRwwx3uZu8FcHPLO/6zXkF5LhtcBy01XXwE fgQ/gSY60hS8DAaDULAc3FFBF43B/4EnwWQwBewCu0EGuGz9tA7pWbxHHNLT+U4JfoIyOeK4We6G RUaKO94hviWVzpkgoKIuAkE8SAAtK+miFXgFDAOZ6clxsaciI/bu2rr569XBSxbMm/XJ1Enjxo4c 8fKg55/J7wvBN2ZKv+x12fDL1Witcllae9mtVWntTetcu9Wb1nm0drtiWKvQ+vAVaR1jt3rR+hat 6+3WyrRuoPU3u9WT1vO01s4yrB601smS1pl2ayVaZ9F63G6tSOsJWmXMKWWtQGutq9La127Vae1H 69fSusgotbz1KteMfVleeegdjX1c0Ynl3Ch76afJH7Shq2nlBxaBGFADn6Em6AGeAKFgufxcnrpw A6+C4WA92ABSQKpnLv/vcA+X/RHn/t/5Czj45TNOjxTZyzv/BGoz+veGullzd4BD/vfPVTYY/r+4 0rZhZV00AgPAQPAZ+C/YADaCq+AaeNAL9QjweBVddK8ifUBi3C+nTh49vGdn2KavVgUFLpw/+9MP Jo9/+43XBr/Y99m831W/cEHex27pxn3sQ6t7urR2tlvr0PoQrZPs1tq0TqY1WFoDzXpgCK2n7FZV DzxNa/1LhlXVAxtckvXAHoZVqF5Cb33yJeOdavG8KbQeltYA850iaG2fYVjVO3XIoKewW9U7zcqQ 75RiWGFJ5XlNM413qsnzmmXK8/pLq788z1tfYD+jBs9YSM95xG6tLn/ORkVJu7HgbZAE7rHFyhpo i5c1AnhU1YVn1Vxl/kXrjsMRh/pYYY6cL6UjDlndYcfhy8VYdwpTJ73BZj7Ft+TsJfnmc+OJj6OH CBTC5/ekYzfwMHgDvAl+ACdBw2oqPtoTthhpz4EMkAmaVkfdHzwF+oAt1VUMNRk/raEthlpvsNgW S+0oiARta+qiHZhbU9UTfmEfz+EDO7dvWr9qOXeWBsz/4tPpUye99+47/x79xmuvDpU/ivHM9kPq eWo81Roj5VXqcKofdZHZ2npRtctk88xb3y/bekFmLg2nNdNuVbn08nWZ++T4cVplqc3z+srzlpo5 vx+t2+1W9Zo7aE22W9VrppivuVS9ZnP1FJm6x95GVC3BSvSK/4RWXGKW/zuMfZzxPc9Iu2Dk/7ry 52pWmulaWjVih0zkvAHpfMch6xf5SJzTI0Xecdxs7TxLDg/K2+KzHF0qRD0jbeYhnx0CbWqhvg/2 gPNgsQ/SD5wCreriOHiqHtqJYJWvLqJBz1twDdgD9oNHb9XFM2ASmAn8wGIw5na0L8AhcAb8BuJB 7zt0MQj0bgpfBA6AQyC+GeojzXWxE/wEBrbAeeBFMAQMBa+C4WAMGAfGg3fBBLASrAKrwRpwGsSA WPAjEHfqwh10ALNADBjQEt8bVGiL79QO7R4wAQy6TxcLwcf3475/QBddQFcwoRN+u04yBmSqivGY mhGHP1MzYvF/bP76A/9lOJBxLCJDZETgQmjqoQx5D8sYjxW6dq8qAzWWl/8Lr/tUVMfHWrir+I+O USLvM6NE4roauWI95or/yDiRvfPzt8a9cBi0rmXeE4PBbsu9EQ+u1MZ3B53r6OIh0A/3yQs+jvfN afA67puR4Ml6BfUDubhTmDEDZT/OwMEtuXikyDvW/B6cz/zf0khvw1/MAit9Tb9xCnzTQBfrQP2G aIOCQHAG+DTSRV3wE/zJz8D3NpwDGsJfXMvKTE/Lsof8iTphC+2/KWv92jVZK0OD/fngR876GG38 DN76bNleDzHL4s/4TP0gn6MfYsv782vGGapcnsOn5QeonnxmXpm9wrOzjfNUKXvF2Mc1WdlGuWxE aAtm7UPFdVOjsmL4ntv4pH479Sm+h5oz9il1JlvrkfITBZt1gmPXZJ1AjlOjVRjrDVujQ6sZJI9S X6EOo6oVZ8LtNYY7ZDXnrpJIn0bSr8OfJ4COTXTRCbjBn7s3zZX3SysfO69iF28+TnB6pASvcdix bfnX90Py5n/fG6XXvSh324L2lnJyNvgSbLOVmbGgf0uz7IwHXq10UQVMABNBEAgGLVrr4k4QBraC im10UQmsAV+BzeD7NnzeYwT0Ukt3bN287usVy+SKHTNnqP6BoQOFzNfp8cgNy83cmG3s4x6/Hi9z 0dIEI7+qHrWgBNaEpTXUzFsXEmTempRos8p+gkR5XoUk42rV81aRT3lbU9skyTMWyzOWma/knyRf aadhhWWX/Nv9FqH3TGbboleyvC4ixXhljdcd4VPeZGoNPuutT22Qart6VCqvHk3rO3yWO466guOV VlJHclzSG+xj+D7DeAf1BGwnRyV9yvFFM6GicUmncWEmMDtUcR2OuNhwdrjGoWLu4vucKsQR5zvO P8FBUcDmZebcUCFHa3rtruA21M0twl23HluW+5hDjreM/XO7JW9vQJ0b5cMj4DSIARrqxHrbvHXj ieBf95l1ZD8w7X5VV276QC6f77yj1XkH6E9Od5w/2SmMZ3dIXIcjJ5wecdg5Zt05at2JEJbN1bqb 3KRLcUN9xOHpnZGC3zjU75aLXN6+gDvI5v99iiuNrW2iex+EPwHh7dGWAwv+hmvAqI66GA3e7WS2 m+aDQZ3RpgPBIAREPYT6B3i6C9qRwB/U6KqLzJREuZ5TjBzsU9BYnzEj5A/nrW+/CO/X081eMnim 2/bhCSvTV35IX/kRdTN94xZqDlVwrOZe6j7qWeo5qhqlmULdxbrkbuoc1ui+oLZi7ay1ZSawWs2j /f9TdyZwVVR7HD+ADOASqZlLWqbkc9csyzLNlBSXzF3Ucg9NUVEQ99wQlzRNsTKTXNgSFwLUp6iV O26QqJFbpuYuuYApV+T9zplz/zMDXB7ee+U95n6+h985c+fc4Z45//M/y50RYVMR/ibCVBGq/uFe bSwqW5v5d1auiL1XyYNre5nHI6/wMEqEP4jwVzG/f0y0fWevm1s5J/Gd3KA493FZ7cIquwAwFmTp r23LkQI2G08xYs252fdfuFmwiOFDtU1X9z900NX9JsXMdZ9Xihd4OZrLb6UsrzKt1DLz15VbJOjv qbAg0Op9hQ0BE1ojDpaAEPA9WAniwMH2CrsNnumA/EBl8BKoCRqA5SAUJIBd4D6o84HCeoEu3RS2 tzv6nuAimNNTYXNBPW+FtQUHeyssuI/CZoOVIAEc7ovqCi71x+eCKQMUNh3EDFRYLNgBfgIlB+Gc QG3QDJz3UVixIQq7PExhbw2HDwRMGaZ74pUhXvduXfvjd2ZiKYdM5hdLMe03pZh2mMRf/qZDpi3y xWNx60q5DXNgU2/LURgajdGN0Fh4QocY7cn7+R/qkz1K6NLVPCob85BpxeVfnuZkYSSIeZbNUcZR oJ+nVtazQMv3tTIfKst9co6y5+W+CqyW5R8PfmmDsgWrvJAOarVF+bdD/6K9dn3ckdeIu7xGaspr 4wd5bfDrwnBzX3Xl13bxDL/I779eOHv6Z5MnT54Q6O83wlgBzM/MVp/JESBC1YLeIwt6SrO0seiU wz4O5jPqbtw+8ukbd7F6Xo2fEfEJWeb4aRFnj83xU+IzHYQdPy9C9emuaeIz/9Y+iX8ocxG/5XVz Mj9tUL3TzDURPuChutpLuYYD3RydlUzh85tE+JJY6VlVhGdFeE6EjqIv4CTCbSJMEOEtEaaJ8f8P qU0U9r9mYZd7Ac2qNc2EzU2LwTVPL1jE8ufc0UdsbgyuFyyibjov0E3OCgib7+DkIEKd/X/Sulj7 A81ON+yosKqdFPYySOqssGTQoQuO6Qq/AXTuZrTllmdsDGv5rLmPh2GOpYD3yijgGdj3Bh3WRP60 uIdvWl/ARapkx9JBDbNyjvXknh1yY6ySrWXK2+dLuja6Btrnf4GaoBaoDeqAut5a+90ODEIbPhgk 9s7dnq+Sbfp20OpjhXmCQ321Nv4BaIU23hMMAZn/8Me9iq6B7kGv4jGvGWsjw8RTXjMyFi+cPzc4 g88Wm2eH1fslqKO06h0U1PsvfizS+4pQva/vZRFGiL2RIlR/Zas+FzZRhOrdGS+Kd6r35skWfQwm ehcOInQUoZMIi4nQWYSrRbhGhG1E78JLhJ+I0EeEv4uexikRLhQ9jUUi/EOMJvcR/Y2PRFhcnIk6 Yq3eZ0h7AshhrR2qCNnwf1GG1nTNCyti32miAv580/LQkc1nwDfdaEGu+R9LdWomCAI/gfrwoxuA 9mAgGCt96xkgGfwKjoFaOr+6ORgGhoPZYM4gJZ/GtrAilm2sZZNv3zOwZjzU0LgZ9uTYdLY9VnfX B8t3gmKVnlZZNxiMtgS0+gTXFJiKftY08BP4w0frdzmDXkMV1hv88in8xk/VvtgVcBVcA9fBDXAT 3AJp4O9hSs7ffyUnJx/hqwjVrkFYsny6N6y+WCLEvyBn5a6wkPdEmC7CDBHeF+E/InwgQv0zodTn c6u/mw0WFlVdZXRa2HnVg+8n2gX1Xo/6J8Bm6u7loD2N213ZjNA1Vps12MIts5g5FKlMf/eGNeq5 iPxMInwkwnYi1/Yi7CnCYSJUnxa4QoShIlSfTOUlwrYi5L87YfULq6xugzvg7rD8/MCnGLF5UVDR jOS3/ieWsco5y+YeSAcZIBOYgDJcYaVAaVARVAJVQD3QeLg6btIUeIIuoCvoBnzAQrAIhIFwkAgO gpvgFrgP/gEPQDVfhVUHHqCdL6/f3K+7cuFsasrRg3t/Ttj847pIcVfHL7+YP3/+3KCpkwJHjxhq +G+Zm5ODc3ElAjXHxclBiRR9bJ4SReqY3JdCKcdJnRX18xzVu5uat9TJJObeOouaOFGE80W4wKTm 94XJnMt3pMJJRZKKJhVHajepfTK3/ZSSRCqF1ClSf5G6TOqGOK+bIrwlwjSeq7hrJR9xuC3S7vB/ qIY9y9waF8vmyIpLBXqb7Z/Dcm69GHvew6G8h4PjV77M+WSFYnyGJg9cT85hSkh2rHNyibTSJSvU ftHLgykvKrnyK4w01Ro8T2MAZfh4Z0vQCrQHHUAn0FnW2y9l3eX1dR+vkyMUlgVeGol+IogG68Am sBm0GYW2AxwAieBNP4U1ATvATrAP7AclR+P6Ah3Bh6An8AYrQCiIAJHgKrgG7oC7IHoMPg/Eg01g hL/CRoLRYAk4Ct4IwOeCJuAtsA6sBxvARhAH/gQXwAtjFTYJTAazQDC4B9JBFngMBgWinwNGgJFg F9gNDoMjoPE4fCYwpYvXHXbDdOXinxfZWbxOi9DS68ZvJ5JPqNwQf3O8YM/UceShrmIMV2nsOl2M 5+Kvou7h6Q4ucnw4jxV+fOVgWcbyHo9mXexlq9uDDiAAjAWBvtb18wxesGFPARs8wzGGRt+wUGZH TMHetrJgb4sq2Nu262P1Cmw/GjLHkOxUN243PIuznJviVylXGtVzVTmQEl6/g6PZG3jeUtmtAWEg HMSD3WAP2Our2oH94ChIAr6wByOAaURu+/AqaARe47YB9ATeoBfwA6PBGLAFFIO9cB7F19LeuXn1 4rlTJ5IPibu4bYqFOx+6/KsvF8yZ+dnEsX6+Qwb25f8kbycfPja3eq2pFf9ctvDzKWUBqTC5L5xS IkhtJnVQvusQpRzOw0co7ugCj0A5kiU8g6PCz04SKwT5CJJrnObb9xVr+U3mVGa+87P6e2/tTvT8 MxX6JBdSz5N6Rb6rBqX8i1Q3ua87pfQg9ZncN5VS+NOimMfTKmtDPTZU0P3TdBHLPWDjMfrIHisi O6zYk6CPbLW4x3DWm/WR/d8ww+YkKjxzcFFXdeg88ThzfSxsm1DuSeqlAlxARVBpVH5ruwyeU+Lg gr2tg6OFPYZIuKulPVM76SKWP0e/1dB/3S4hC5nT6w75fuuVmENINv/O4z348dm8Dsm/Hvq8njAf fV5P8xqQV6BW/s/kVa4vgMqgCmg9SvXpOgAfMBqMlz7edDAbJIBdYA84CA6Bs6A+/LxXwWvgLfA2 aAumggVgNdgCtoIDftLu/3XhzO/Hk9Dd274ldn3Umu+/Xbro8+AZUwJHw+p/rP9fVCs2mOy/D6lJ pBaRCoUq6ejOROQ4H/pQ0y8+Vu3iJXrndVI3Sf1NqgXZzy7SonallF6k+pAaSOorUt/JI1dQitYa rSO1hdSvpE5m85aC3yla9krXPxJtjzrTfEH+LxfpbLX/6r7c9w+l8N+ssWrWlvev+qJIshgxLHA8 qI/stTUSWNNBi/jr9xgiYpPXfccC16wxzDkkO9M5pPT9Cscrt0H98smjf/VtidxpA11yp51zyp3m n/t9VCvN87OOajvxNNuEUvaqu4kg1a/APv/67brCs3mSY/07uqbDsGetPmL751SwdNaGzcn9//9q kzWirL7sHgIFfWxX8AxwB5VBU+AF2oFeoDf4FMwDX4NlIAr8ADaDE+ACuATugXRQDH31gWAQWAKW geUgDISDCGCC/b9y4Zww/78I8x8mzP/saZNU8+9ttvrjH5mt2ARSM0gFkZpHahupBFL83snUJtTi Xjy3kLWzzPvfItWUlBepIaQCslTbOpZSgkgFk1pCKp7UbnnkHkpJIXWC1AVSDmS9n5H23J1SypEq T8qD1Pukuskjuwv7/zTK3aqqVde+BsGuuVlxbtiKQv1/zpp6Ggk2gy1gPyjur7ByoLx/fmW/vqTu xOxrl20v4RgbrxfDVpTs/38rz2qgOmgA+oMh4FMwCvjpxl1DwDIQB3aCveCIHI89CUoEKOxF0BA0 0o3NtgarQASIApkZd8SMj+gCJGyJj924Nnzl8q8W86GfCQF+w30GfCTOX7Vlh8iqJZOqQ95yE+ln v0Up75J6j5Tmv/uQWk5qjcwjLA8PPY7UTlKppHLOJa2XMzsbaJ4mntRmUjtIpZHKlEeaKEWhNsyV VFlSPUj5PFKPHEIpgaTG8a5DdXuVsbE6vW5X86uPROsjEfrIGn0k1NbI+nW6f8HSltNj142wsqJh /0s/af00z6HEgB9BrG4uxeZFroZIdKquBGzPTR/Rj9ZbFbG8ySuhCPQ0xUhgmf9WpleAw1iFlQRl x6rzZZXBy2AU8AfjwGwwBywHp8BV8DfIBiwQx4IuwBv0A6OAHxgP1oItYGcgHwMSS3p0c/7ro9aE LgtZ9Hnw9Mnj/Ed+Orif7h9RLZnm2+8n9ZCUg/SxHcmLLkOqIqmXSPUlNVoeOYZSZpCaS+prUidJ XZNHXqeUTFKPSTlSm9WJVHfpnfeglL6kPiHlR2oeKfU5YYtEqD7h8WcR/iLCXTLf3fT+RO7/V7d3 GdteUfWumM0VNfq8XXP72VJutBWtkSZWtqD18ihIAmdArXEKqwdeBe+BluADsBSEjbOy/zfZri7D YbvmdvXJc2NFpP/3pGUbDRLAdrALlBuvsIqgCqgH6oOWYD74FqwCP4JYsA88O0Fhz4MqoB6oD5qC CRPU8X9Y/jyG/8X4z6C+vfiZq9brjUyzHWuVqVo2T0rpRqoPqQGkojN1oz4/ZcpRn59pfzKp30j9 RaoB+eCtpFfuSSndSHmT+ojURlKb5JGa17+P1BFSZ0h5UFvWQPrzDSmlBSlPUl6klpJaLY9cQylx 3P+vxtetvAtagI0gBmwF28DLKK9qoA6oC8JBBNgIYsDLKLNqoA6oC+aAuWAxWAJugTRQaqLCyoDW IAb8CMpNwnUAxoMJYCYIAsdACmg0WWGvgW/AMnAd3ADvTFFYMxAGwsED8BBkg5c+U9groBdIAcdB h6m4fkF30AMcAIngV3AM9JqmsN4gFsQB1+kKcwODwGCwAWwE5WcorAJ4AbQErYAXmAROgzOg4UzU GxAEZoE54CB4DDyDFJb1IM9X2lV2ycKufPZk0S4IRiuD9Ct/ykit/3WocT0R623vOp2PFT1gV5v8 rKUhf6tyu607N2vGpgxbURr/ycsOTwFBIAQsBV+BXeAGuCnrdMmJWr2uC96cmHMM4Du7Frc+Yigg ayLhFiOr9RHDks/c6z+13r+izarrVloXhfIvY0t5N5c2vQ3oB5aCtWAdiAVxIAm4wZ67g9KgPKjA 7TvoD0aCADALBIPQSXwM8La80cdp1RXYFBMdsWrFN0u+mBs0TboC/H9Q27Fg2bOZTT2bb0iFklpH 6hSpdHlkBqWYSGWRcqIRvWaGmX5+ZG9K6Z/HjP84UuuzdT4Hv72H8Dn20f6jpE6QOk8qUxytqEdn 86PVEcVZuifEbRThaRGeeaie3dmH5hxukUon9eAhX/9l73K0pmNnuTpajkSH6HKzJgNjbv+2MTdm rlHW2/7Xy99+orq/0jl32vY80nrm2//LWff2gcPgKDgOToDLwA2+V11QH7wOGoN2YCpYDELAt2D5 5JztgH2n4qbZNbdv7Jqbly43ZlX/r/CuAXP/z15lHg1SwCVwGdwEt0AWeAW++RugCWgO3gUdwQIQ ClaCiCnC7t/Id+Svt3ruqv3ypZ7MSFJTSe0kdUT2fI5SynFSJ0ldIeVuGBPkR1allBqkapLSVgkM yGfkcDypiaQWkNpF6jd5ZCqlnCN1npQTtU41SL0pW7MmlNKcVAtSrUmN5ON/1exVdpFgE7gxxQ6/ 7zbUJNtzW2nX3DoVKDdWROp/zrK7C9J5XQQmXpYga4qxf/0uaAc6y752b+AL9oMjIAmcACfBFdAC /ezWwAv0BN5gGNgOdoE9IAUcn0prgE6nnkg5vH/Xjn/Hi/nfrxfLpf/DfQaYF4Hya70uXc1NSTUj 1YrUUlKRspZEUcoWUltJ/USqAnlhtaTPV5tSGpJqRKoJqSWkwuWR2i8NNpDaROpnUqf0/t55zd9z f8S9u2dFWFpatTJktyqQqkTqZVI9SX0ij/QR87/WlnlBa4s+Yk3vzNAh+86KyFPaFLMLxft7duv/ FXr9L2Xv+hujH0kxTLpaE4lx1Y3y2J6bfc+tqu7ccm7FxNfLVwI84VXg6vI2XQUBefTuG+WxrjfT +p5AWV5maXyMdJrCuoLuoA/4CASAMLAObADxYBM4CDKB43SFFQPFQQnwAugBPgb9wCfAB0wEq0EU WAtiwI9gFz9uBvqToOwM1f+7LPy/RPXX3sL/Wyj8vzG5/D9tfUw6qWZk5TpKK/chpXTPwxZ+TGoW qWXyyG8pZaVhFF1VP5C6RCpdHplBKSZSWaScyYtrTKqd9PraU0pnUl1J9SH1Oak18sgwSllLah2p WFKlqWWrI/w/e5e/7fO/g3WV1PbcvO2am6+l3HJu/9+1XrNOZW2tsxVBJd28iFVfa127FlKYXXPT RwzrzQwRddPWfxWZ8s+rDM1zWwOAL/CX81yTwTyQBE6A38BZcA6k8XxmKqw2qAsagddAKzAefAam gWAwW86N7QF75RzZJfD3TD4HnJ5+5/pf50+fPHbkwO6dW8XQ73di6HfqpPFjRg1Vh37FptoxbWXm Tr3fzB+4wdQ7KsvfSi15LFJCZA9A6xMsJ7WC1BpSqaSuyiOvUYr2u7A7pBzpfOqRaiZ7AM0pxZOU 9rvlDqS+JPW9PHIlpWh3MtlIahupFP13kKp+B/yZ07wHwfPR7hLC7w/CqtuzvC3fZtOaO9dEzNHV Y8PiTmsiEd3smVvOzbpVP4Vf6w3zVfwLKWNtPb0/U53XjtEPhxh6e9ZE9DdlMJreHyzuMdjhVVZE bN1yfa/q7/aKxDXhri/LbOAcpLA3QXPQArQGbUBfEAU2gx1gL9gHjoMSsxRWBlQEVcCLoDHoD4aC UWAsCATjQBgIB2vBHpAETs7Ktfafr/8JFet/pvMnPI7Qm36xqXZsK/m22q+o+JgpWcGLWcIKXsoS 4yaPeVhGWvKyZLUrkqpKqiaprqSGySOHU8ooUoGkppCKJ5V7Bab264VjpM6T0saZ3pNtQEtK8SLV jlRnUjNJzZVHzqOUxaSW8cah2tMo95iqdrUJj+yaW//Cyc3a+n9D0ep/HvVV+dC+9f85vi7pfeCP cguQ9dNcN8+BRsFoH8A7oBkYBKaDbSABKLMV5gJcgRvoAXoCb9ALRIBIEAUSwUGQBJzmwC4AP3Ac nACp4Lm5CisHKoGOIAQsBStAKHgIMoH3POQPtoEE8AvYBQ6ARFD9c4V5gLqgHhgLAsFkMAXMADNB MIgD8WAruAXemw8/GHiBtmAJCAErQCiosgDXOvAAr4BIEAU2gI0gHmwCyhf4bkAp8AwoC54Db4Oe IPNB5oO7LO2B+Jt2l4eETGZmkdfr7n+ouw/4KIrFgeOThOxZwAhWiuJDFOX5UEFR+augKFKkSLHw x/IXng8QC0pRbAgRRLogCggEUSAUDYjUEEoC0qUoNZAAgUBCIJAQSELI/zeze7O7IQfn5cTH3ec7 mZm72yQ3O3V37877oCj2nDB51pd9Dph4KZB2Wu4XSTiKquwDd6BGvwDP+3Um/FwgnuJMuBaI/UyU +ChykVuREUBg678Xt+Z7z/85X3k+irqoh1etut/bqv/9EIXpmO1oD1YgB3kIdbQL16IBmqClo33o gFEYi++sdsJ7HvDWLRs3bFidsGThL7NmTPlu3Dcjh37xWe8Per7jHQlYfb3uMQ/omP0ZHpV0f1fN 6gvv0Dk1dOx+HaujY110rKf1yvd0zsc61k/H7D52kY6tsF75Z870MWOFhd7rBm9X45aGKmxkrfY1 1iOdtjr2io510LExOhZtvdJeHZRrgqJqsMo5uEd9XIkJJU3MfNBR3cc4H/EzUfSm10+cR4FKevzn b6n/ZQOto9GY1t/dp7sXzuo53vSSL8MFd2vOhO9Fve+diYnCx80xmw54/e8ij/rs9b9yvsryMLKR 398cq5VCVbRDB7yOrngHw7Acq7ERW7GtmPHcfaiLBtbYrjnaoD+GYBjyc3Nzjsn1v21q/W+heern mJHDZdPf4503zl3/K9kMyIz5vYYoJ2rkbLHmcr/rfsY+q3Svjh3SsQp6++e7Jt1eCWxWTP9y7mca 2+t/9icXLtOxXYVFzyIIN/YW2iuBcl1T3Brssg6oOjrPviz5RXojg7o1Z8J36yBKtupz8eu/9/zP P1s/JyAK0TiIDJxEyBdBX/99wlGOJV//DepqctHbpVXqzvXfC5VpKMrgCTRFa7yC/0MXfIefMBdr sBaJOINrmEtXRg3cjTpoj87oikh8VmQO7vsawI/ee/fNTv9+9eV26p8JN25TI+KWKmxljW5b69Gt /elMb+qY/flM488zLrbXE1foWKKOndGxMlYfcJVu5avo2J06VlvHuuhYT+uV7+mcSB0bqGMji1kn 3Gq9cpvOsT/rL13HTujY3efpd+Qaorj1ryjjGOe1vCVfY5sa1K0NC+rWnve1tUtl/c+fOinXxbZg Dw5Ya2RHUYBagwzxAB4ZFIT1Hz8/pMM1O4wKIDGzm6PYSrj+U/zaj9z+JbH+82fKtzGaoDX6YyCG YgKiMB+FiBhsiPK4HdXQBCMwGpMwF/OwBidwGqFDDJGbzch/b6Ic+ctFn5jpctFnxBA18u8qR/6O 67+T9RXZB3XsKn1s+x/WFdZVdM79OlZXx57UscE6Nst65Wyds0THVuvYDh27RZ/X9aB19tdDOqeR jjXVsWd0zP6UwsHWK4fonLE6NlHHftCxXTqWZr0yXedk6VheMWecVXYeF6tKospfUa7uCt66hHXN vbVKQb3st15Qt+bs9sSlUf+vLa4eXofrcQMechyveB4voif6YACG40t8OyQY1304E4GsG7oG6VHO xNgAEr533WLH0pfi+l+5kpT3emzCVhxEKk6g6lBD3IkaeBR10Rgf4lP0wyh8jW8wGmOxEIuwdKj1 OVDph1RvoA4BxKhDACOGmutAb3VJT+/0qvW/FLfKEW58d1aGk6wR8/d6TGwfkbev94jTsUwdy7de eUbnlNZj57I6dr1rPG3GWllj7dY6p4OOddKxN3RsvI5NtV4ZrXNm6dh8HYvXsd3ONZ595n+/v9B7 5GCC+mbQZSpcbn1KSrzuLbfKjz65zVnOsmx3YhdScAA1KYtaeBiP4AsMxEh8hTHFlF22LO9h9A9o g2exFMuwFuvQbLghmuMFtMUmbEYidiMZxpeG8KAevscP+AkxuGKEIa7EdbgeFVARVVEfz+AtPD6O NMaMZ5/FzihDlJ5oiJunGqI6PkRv3BxtiCp4b5ohBuO+6XI9I7cg23FPSymaI+8pBXZecsHOjSJ5 TXJCckpyHPf5ybOTheub153fAH/F/Xb8ynsa3y68394jfzasHmJ/hof7G96d3+xe3Df+nP9zP/R3 CMmgQbDrcUDN/iu+2tn/gq05E74vBil6u1TG/9cU1/buxAEcserySRjU2QdQFw3wHJ7HO5iCmGF+ fx+I6/vTjwWQiBrkKGHfH9LhZyJq+5/fmrxdimt+1sjEPk5VriTlHYv12IAc3E+b/Sga43/RDt0w H8uwHnuQVKR9L43bv7zA9d9v+zr/b6ie3YwkdllohDC+KlA94SK1NhhrrfAt1s/boGM7dWy/jlXT /X1dawRgXz39jI69qGP29478oGPrrVdu0DlJxazTZevYnbpHr2+NAOzzw+1vc2pXzHjiKx0L5PiQ qBLMcjxPK/pgUCdapYO6NWfC9zyj+I97PPcWEnFJjf+d9e9ePGiNtx7Dc+iDkYjCLMzGKmQhFwZj rBtw44hgXPuV4GiKS/4RMc5P9whkA+6tiQvczHc0sM9/+duO/5ULRrmXt8bfcuz9uGP83RKtrHH4 2+g72hCRqD2WvgWfYwBykYeXvzU/+0le/bNJXf0zR32T98Tx3wwf+PlnfT75sFvXTq/ZnUCE8cIp WvzL5ffsJQs542l7Sn773hqdm6Ry16rcSqe9uXtU7k2n1ff1qU9M2qjC/WremFKoj/b/KpvI0mZ8 lWo4hfXIanOutU29YrsKc2QYGiLCyZffRRJu9LVW5+yVPvfnMZqxqTq2RccOW69MK+ZKUo/uqexP L36iwPH5UvKUMHWE375etL2OdXYdDRO3Brv8XkEmjmM8860J2BFlzrtcx4d9Hyz28wt5XcNI34nj JU2kXaRHAkn4uKnT0sxvFrzc6o3CQlWoKn5YiAzVHKXChcosbKI5Xy6Dx75j/0AMZmHQJObK+Nf3 zBHRF5E4hkx0/8EQPRA12RAT8fYUQ3RFaebbZdBzmj3fHoJa0815dxs8i09+ZG6OM9nHj6YfOrA/ effObZs2rIxfNH/2T1O+/3b08CH9+vb+qNfx/T27dd3/5usd5b8ebvxyxvu9C+FGkgqfVGGaCtNV uF7V/Q0q7KTqfudc2UY8lEcbMUe2EaXUturkydwO+d7cMJX773yZmyZz58rcUJWbrnLldy+YuSEq V15rfoUxw5tLjvzKtgijaYF3m+armxXIXHnc2Mw1X139rHz1N95cckarVa316r/YoMJter2n1wmZ npMtw19U+GqODNvnyG1n5Xjbv71q29mkxR0Xu4wDqemuhOvbdUv8yOGgPhLIXxBIwvebKG+O2j/X lZojzpn/VTxfvWsYwxwATfA0mqLjLEN0wkAMwic/81xk/8K8ESnzmUui0kJD3ISbURm3YA3WLjzf PMH1v5R4ZF/ixH/Zn+M74dq9XI84y3/euccoKslyr4dGeNraB9riJaTPpE+Yae4Ln2IUxlj7RSO5 L6AzhmJEjLlfdEdva/8YhhGImW2IuchiP8lBpTnsE4jDMrRlv3kR3ebSXiALObia/agcZsYa4hBC FhsiHI8soZ1CJrJRiLClhuiFj5GKbJleThpd4hnDoC+mYDF2JbCv4t1f+ZuRs9YQp/HIb4aoi/s3 MiZGXlZ6XmpS6o7UjYSrU+MJ87LMnMWOe3yqUD/t3KRUMY9kvLrvsArDuUrra/W3TFhn+dQ2l4W8 0VCUKmum5GNWjnMFOUJGHMu83tXgq9i2c/W3DOnaehHasR791F9Zz2ctYt6ACpRdRcyItcvyMNZQ lmtxBgVoFMffgamIRijleiZXfSHIoQP7khLlBSHr1/yaELfo55ipP8iTgocM/KxPr55vdenAXKCU 7CXn2710+FnZ67XXuWY/20Hlxuhcs5+dpfrZfd5ceRRF9bMJqoddYc8IYrPVuH9xttxKs5M8f579 G5uflLnzdK75G+er3PE53lzzN07Ikb+x0Skrl5zGp+TvaqLCp1XYVIWRapTymQq75cuwuwoPq9Wt NBXuLvSOecyRwDo1pklVR34OqfCwCtNUeESFcxiHiGrBKqcwtKCuPYM+RepaHO6kjlXHaWfb5Drf M5BHTvh8xHci/SI9EkjCNbQIZAPyJr9f3NHqzxeOsX9Ykf6g4p8puwlrGOdh+XpDxOMR2sdH0XEz /QBex7sYg7GIxjRMx3LE454thrgXLdEdUViHbJzEDb8b4kY89gfjUDRCG7yN4fj5D6tNSEtN2Ss/ JnDzb+tWr1i+JHbB3J9nTJ4UNW7M17JZkKsF8qLxrqp2q9qxWYUZKszVNaWzqj8jVG0fqcK5Kpyn wiQVXqleU1uFL6iwlwo/UOEhFR6224iljlUDc7mV37NcPWujCjep8LRjvaD8ceb7RkXCy0OZr2TJ xxuocOlJGS5T4X7VBqSo8AU1y2mrwhVqeytVmKj+Dg/bNKrnqrbqn6otaKfq/IsqnKb+5+ly/n/X xS7Xv2V4lOtM5PiX8HMRwc+/4EhQE75/j76Fq2peNnJjqFn7rWsT9Ozfag0qyjHOQxvNMs/bRPls cpe5t7xlOcvyrY3H0BC90Q9fYDhGYbRV9jPwI+ZgPpZgOVYU2R+8dTwFOTC2GuJKlEVVPIl30Qu9 EYnPsQgJWI212xjPYQ9SkIajOIGq25m7oiZ+xlwswyrsQCL2YB9K7eC5O5kLoT6exmbsQzZycfrE 0UNH9yRuXSf4Ke8JDnFmRsLRE9wT1MPOmCnuqFDPSXCNBouO5C503D9MP+fGYp5T1n1ugGPEWMaK W6cXNLlQW7sdeYjgfa6GO1DfKo8o/LrVfM8v5/27x3p/V1rv617H+xq+43x139WHuSYzvhOuvtKV 8HMDvmdQKT4fcSWSnAnf/4KfT/Pdqft+38xaHhEZGeaNbaTt98Zk7bfbAavnl1F7/lch2GV81067 DtXDm/gaK3EIBbhuF9vBC/gPhmE01iMbBeiTyPgSM/EjfsUqhO82xHt4H1G79fyAwQDzg6StSUly ipCwLG7R/F9m/zQjWo4IkhgSkC9HBb1F0VuEcV+hd11sn3xH1bXg4epMrHDjgAoPqrCJowffoUJz vDBOhStV+LsKC1R4o3rOPSo0VyD/o8JRKlyiQns0ckXoZSLco05Ok2uYZ719uXdsX6jCTBXOUaE8 fmuOYT5QzzbPd1ulwkIVVlDPq6jCWipsqMLOKhxKKO6+2GXme18u8QVjFyvhuxXys3L7brlKPNKR N1c9L9pCqJYg5DJv/a8o+7RClKP8auIVq3zfQFf0wGB8jbFYY5X5FmxDIo4jH4X4JNHcDwZjJH6w 9onpjn1iDftB1T2G6IAPMDKJbWMCJmMGYrAAidiPHIQnG6I8GmMIvkTIXtotTEK1fezLeB+fYjIW IGy/ITzogQH4nxT2c3THp1iCeEQcMMT9eOAg4180x/OIxDCMQhw2YDO2IRVpOI3wVH4/6uAR1EP+ Se4Z+anc7Z+mvfm7VU5G/smMk+p5J1NlTOZkWGGGep5QMfMR87VC9e5XFz3zz9n7Fx1ROEcB3pGB eM7bjq7ebZfLbXgS0ViG5RjA+/+FVU7RqMx7/xQm875Pw3TEYjEe5z2vj6sO2O+paw7ve0Lvu9L4 3oDvrflOuKbtrsRB/x5xdequxE5nIrgtj/dmr99fsK578/Tav+vYoCh/Mcq+tnTQrle9MBLLrLoT ZtWZuladeQ01DxmiFuqgGV5Db8zEVhzDqezjRw/usRYFl8XFxspFAPOMgbHffPXl0NhBsbED+vWN /ab3R716xso3LlxdTx+uvrndexTN7OPLOPp1s69NVWEPFU5S4eKivbVcjhPe9bjuai7eQ4XfqnCc CjuqV3VS4VEVHtM992vqGUNUWErNysup8FYVVlVhugqPqOODao1TjVXkzhhhdNTpAyr9uU6nqP92 gBoHmGuZKWrlU/6f5jP2yzekxl9ZPrcfNsQ/cddhv+f9vgcBgcwKXI/s85nw829zvWZ3AIkS/6Gu m6+RvZWSzUAxbUKEu/8v7y1Pb1m2QHu8jQ/RB9OwEEsQjy1WGafgOCofNsv6Tqusm2FWGvN+rMIm NEynL8XL6I/B+BELEIfl2Iw/sB+ZqH6EcSnuQS20QSZOoUwGj+MhNEJzvI+PMA7R+BGzsRwrsAXJ KH/UEJVwM6qgFYZhKrpkMv5FYrYhjiALj52kTcMgDMa3GIcpiMYu7D4pr1nJzEnL2YdMwkz1My9H EJd5RXPTzsndo9JCJralbZQJ5uvyvP3jmd5jQzK115vyWD3/+Xr6YtcD7BFDy6L1VJZdc8Sk2WW4 Eg9THu0Qg+04mm6WTU1H2TyLY44yupL3+l9oiiiswp4M873/h+O9b434Y4ZIwAqcRi7KHTfENYg7 wb6HpCzKD7uy7fLJwGTe+zN5eXQHeenWgSJvyuwb8vLyzBnhjOiJ40eNGDa4f+Sndj1S7bE5t7JW ThuYK6dPqZXTx9WaaX11Jkh7ec7HAsfRJHXOh/zGKDPXPLZzdYE8tqPO5VhgHtuprlrgF1X4kgpf VqF5BsdvKiynwjtU2MLR68Q7eql49aodKgxROW1U2F2F6UX7J9mRiXPnkWbfI/s3ce/FLHM/21nX UXfffYBrbObnI76f5lrycSWC+1f7+ef4+TTHrdiR4IOl3LO+c47/V/gr6qJsF+87Rd+AE3jodJHx f5bPhJ/vVYkHA4E84juR6vORZJ+JXQEk9M1bvpX0al+l0LKRKQVFj/0tOPeMH/dYobyv8qoDkcv8 Gh/iI3yM2vmGeBAVzlCn8cJZQ7RFP/SH/Ituws1hHlEZdVFPxkt5xC342PCI3qhzuUc8jDn4HVux 6QqP2IytV3rENpxFISJKe8TVqF/GI55AZoRHHEeDqz2iHz5HubIeUaacR1yFL67xiIFofa1HPIs4 LEWF6zyiEt5DL7xzvUd0w2RMxdM3eEQzHMQhbL/RI3ZArzEWWxbF3fZa5fYHfhOrRbxYLOYRv+Ky hbKbUGdkW3HDEQ93xEs54mGOeKgjrs5vD1fxcGOXmoUkqvA7NaOYpMI0FaarcKqaS5grnPJ4pmgo xy37kIYbc2gL0Ald8TWicsx942EctvaPUyjN/nEV7kFNa3+pj9fQEVH4/rS5/xiogbvxKOriKTRH K7RDd7xv7WN9sRrrkY4jyILIM0QoLkM51EBNtMDzeAkd8TkGYQ6Wogr76+1ohhZ4FR3wGrqgB77E KMxBLJZjHfZgH0qzr1+N6639Pj/Lvmfke+9Z+an5yRk7rLi8J2dsWMmPDMUMi2Rxt/YaaxwXwjgu RA7OrrPHfo7c840InaM9f84TEk0vZl33feFHIB2CawN+9qS+XxNIwrUgFNyey8+E++btFTqG2HM9 s/139xJ270H/T7nuwxE8WsD8Hi3QEq0xBCPR6qy7/A8gFWk4gj6FhohEfwzAcIzCDPyEmsIj/p+9 OwGIouwfOP4sh4OWSImGoqZp3uGRV5pKnvwzSTxTSdNQ0TKvPPMtM7xNTfN8S00tyzzwzAMxL96/ R4Xoq7gvERKaKfryhoKJ4Pt9dmfZmV2Gl5DCjFk/sM/O7gr7+z3HzDwzNMVETEN1eqqGJmv+jMcU bMEJOQLn5y3hqs+rgQhFOHbhOL5DEn5GRTXn2uF5TMdMLMZyfIU9uITLyEAmirkrQnGXvaYi63Ty pfjTst6eOHpwn+52gpulQl/K+OqopWS77bOQt/B9zjFx2GJr+/yjRvticzsanN0SeGlbglIOZeu7 elmP89r+Xy/NM7X13/q0NvL3doMXfDAdM7EQS7AGn6Oaogg/DMNIxCIe9T0U0QYLsAQROI6zMOM6 bsCP+t8IYZiOlViDz7FZ7f/70zGGYAEW4yii8C2+K2EdH5zBBVyUnShjAxeUhQ+6oTc+xHLswm58 jUOIxmnE4QKu4j+aMcYLnop4xdM6tsjCXXgztkhPvZqaFC+/Wm/xFvGW+9bHzTHcTpiPmLWrbN+v pkZKuy3tmq6F1kS8pD3C2lY91+jpjuvr8syovXfsYUTAHzkGu+ejW/dZwXh6uG5eoq470j3NeI2u a7lgWJCLbQvP3uqHmrTbAHuFvTfQzApSt/9kfldCdTREMEZjihrX1UhEMsoT3wqohvpohOZog+54 CRuwA77kQGX0QjDSkIFQcmIYhmN0aWueLEAszEjEJVxDoJo7IYiFGb8gDS6M3z3wBOrDHwEIRFf0 QwhC5TgfR3AWCRCM9SdhJjYjAtGIwRVcxy24sA1QE7XRDh0QimEIe0y2C/J2TX5JTI87w7e4VOtj cZZ7cdm3b9S1calnLP9sa62PfxMXhdz39TnWXG3dL2N/pnYvYA57/hzbBRF4r9tG88oTP0QjBh18 iQNCMBgjKtBfVFByGe7lcYBm/JrCX2M84NTVY13B+N10RxNzGe6x5Dyuy6Ge59AeyBZDlJN5PBMf YgW2YQeicQZmJMhcJ9aZaFaOuoaBGIkYnEFdYt8EXdAVr2MkxmGymiMrsBHhar4koDs58oqaK1Mw Fa7kS3E0QSsswGc4hhPIhHtF+nsMxnCMwWzMxbdIQtdKtD1Yh89wCFGIQzKqP07dRn00whQswy4k IBGiMuMjeMEHfRCMNzEBYZiNdYionPNYwVqOt9xiU2NiHYYR1u/ySdZSvO0V6usMj/AXQP/f7bfU 4a7qZz4O4zGBz2cSYmGGP79/G3yElfJzq8L4AeIJtv/QCmuq8lkhoBrjdFzCZfg/yWsRgUh0q0Fu YBTK16RtQjD6YXVtRXyCdNzCu3WIG5bjRyRh21OK2I6Bfop4FeMwHxsQidM4hytwr2drn+SkX+v0 3qviIhUx7qyIpnBcHOHrQREpIiLELhEurwyxXlsPP4Vlr7pl1ncJj0jNHpxIzR6cyOw9OC4mk3C3 lN099stHPfZpXhOheU2EZq9PhGavT4T9Veoz92meuU/zTMt96x6j4ta1lvuEXzz3R8U1P1M+jCdp FOxZJMb7/o0PEejWGM/wNH5NfmatOC322R3aFj7CaU+AbOudewI2V8vJNuskomFGPJKQghvIQiCx fgXDMBvFiHclNe6BeAmTMVfmAT5DAi6jDzkRgnlYWdWeJxtwCGcRixTcQBY8yBsflEcbtEMIBmMK wrAAS7AZ4YjGGZiRoOaeIO/cUALeCMFgvI2pWI11MCMOCfhF5irkbC3Lv5sZF3HhX5bbacvXYzxw 6OY1Vhy6uS/7nvy6c4t6Vz7h4s3/vbWXw0jvUfU12mGa4xagdktfsW8l6l6U24gxe/9f+5za3IJu b41TXXfgpFDW6OZXGNfjgi3opoidNizYF6M53dZzOzStQEl77Y4U8vkloxRTqMkU7VLMuf7vF8JH 5vodFK/OdjsqoQbGYDIeJx9qojH80RfB6IchEOSHGzzhjWqojnYIQCB64jaK1VLEbuzFERzHJVxB Cm7Bnfx6GK9hJPbjsJp3r5Jno+rY80/mXvW6jD1RD40QgmEYjtH4EpvrWnNyuKbfv6D2/RXo+6uh OurCDw3RAkHohT4YijewCMuwv551rGe7JcVfjdeO/ZIYyNnXm2PM4qTm2VHZN16m3jPeN/Q77v8J NBoP2T6PXjn83ofwSH0+J/TAPKzHd7iOsg0YF2BgA4e6ryvoTqPK44lPutfoKnV+1ugKuoZAt0Y3 h+uez92K1RZOiTwstvlczdxyPLJfWzOzy3neZ5ir/oivviURjxVkrD/A37EaW7ELe/ALslCzIfUU gRiN8ZiBufgA5/E9ElH+adoi1EU9NMVL6I0hCMXD8xknoBxqohaaoyd6IXQB9Rbh2Ip+HyiiP6Zj Brov5HfCqxiBtzEXG7EJ21F1EeOHDxXxEM7DjJ9xB16LaQ8RjJcxAzOxGp+g3BJ+D1RARVTC4xBZ lpt94X4G/7IsJypmsc6ypGXJfQQp1+UzUuTY0UYul7NfLO+lZD/u7hFkYpuC7X62ReQ2hmWLxHqe KSlTnA7DpQqPFueZJEmwjPHXOALP+tZYe+MpNEYXNe69MAencFWN/S/4FXdQuoE1F3zQSM2J1nhZ zY0QzHPIjx2aHLnmkCcyP8aq+TFbkyPrcFbNFZknN/HY09Z8qajmTBWHfBmk5swU3JZ504g2v7Ei WiKgCe08ajelz0LtZoqog7rwQz3URwO8iNuW2XvylqK5Z/0qLPP6rGyPp6Ql306+kpRwNtr26PG0 lMP8S9GebWo/K88lVH8k6KH/cU6goj7meG5g9t9+NTzSZLnb6fest8aTeXU7v3Rrrhs+zXgMd9Fw jXEh3rBwXmiWGG3hhOGaI4ZP0605IBwWWmn9rN0c5/Bmr6ttn9H7iLZlt/QMwlQlx75Crham4tml ZDdb35DsJsrm1r4OVevMr2q9qdrYWm86NrHWm9mYg1pN7fWnPd5FB+pKRwSq9WZIM4d8uOdrueku CZzHwYRx959gWNA9rWDP485PQfeBCHvEQ02a0UH21r68GqnTld80WVdexqYLXkUIBmGwGq+hGIbX MA8fYTf2Yh8i8R+ky/vPMFbAnRa0Ac+yLYn+GIpRaNmadhYT8RY+xAYo/ooog7WIwH78EwufU8Ri bMZWnMR5jGlD+4MJeBcbsQl7cBlebRXxDFZ35GfC9gD6GezvZBmvJ6Snmk+bU0+oX4+mHkg1p1rK OJBKDeWxo9zf+eUXa1ctFjx2IHWnpR36La1vTmdm57Rdn9dztxz6B02b7u067NDT1usDtQ+Iu9vD w3JadynXYdfL9m5ZwsPEAz09TLaW30t3NSEeaC7jHKrGdQ+ycBflmhNHZLSwx9QXP7Xkc0bZVvS7 aIkwTMNhHMEpxEMhvh4o5m+Pc1n/3/U4sPE10wr2/zGeknPPb5CfdzMuOJzv5XT9LxmPQMzNoQ6e xZvUqbG51LefUaqtvd41xxQcR6l2jMUxDTMxC5Ht8hx/3VU78njgPY+F/Fwh1PjHuZ8LQnfVDzk/ WHc1oAoyHqb2jNcxFtPwD5yEGTdwG6U6MAbGc+iHj/AvVKSN7YNVHe1t7gFcQBJK0/Z2wESsxfoA h/jfcyzz+AZ/mmv5FXT8dYtT/Zfx+BxfYAO+xEZswmZsQTi2YluAvT+NR9n/I7bohomYi+/g9Txj P8zCLlzBv1GOPrgJJnd68OYC/dkSQo1/RRmLqYjoZB0jReMUUpGGJ1+gDccUHMQRHMVFVOysiLbo gtfxDvbDFKiIJ1ADHTES4/AZ1uNMYFH8C62gLrb422Jui8uvL9Le42qQIry7KqJCD7bt8D3icbEX uYHxfajfaNBXEQ1xJ5g+4mVFLBrA2B41hiqiJra8oYhjWD2CdgRb8cIERXSG9zuKqAPPqeQSWiP+ PfIOt6cz9kTV93kv1EQDtEJrdEYgumA0PoXLPPoxbMW3EPN5DK54aL59f+GTqKHZZyj3F8r9hHLv THKa/muy9X6itSD37SSnJSQmmM+ejBKHIiy3xN0JYuvtL24nWi8g5imv5ak91tdYvfamj7on3se+ 7760bb+M5U5+9/XkdWsjh5nGbWTM/4l03EYtYt8NC3EOaWo+ZOAOMpGFuxBdqOtwgSvc4I66CMEH WImDOIMy5FQL+AcV1f9CK6iLrf7LWAzBJmzHlSB73S+DpmiOoViEGDzWjX4cz6A5BmA5onAaaSje nbEBXscoLEM8kuDboyj+hVZQF1v8ZSxsbXwddEYXvINwmNV2/wck4AIS8SOSZH+AS/gJl/EzruAq knEN1/FvpKBET0W06VkU/0IrqIst/jIWAzEC07AU5+BLHx+MAZiExdiBvUjqZR8H3EDZlxjbIwBv 4VN8ji9wGBnw7U1/i1YI6l0U/0IrqIst/jIWc/H/+AaX4Mq47gm0RyeMxbg+9jHfbGzEFsTDjfGf X1/7WPBpNEJjNEFTNMMzaI4WfYviX2gFdbHFX8biWbREK7SGP/pjKSJwDElIlzFlnD8Oa7AeUTiJ jGD7NoAX/DAA4xGOrYhBiX5Fsf8NhXvea+WwOO3/kfGojGC8jPH4HN8jHrdQqz95gTcxFnOxF9Fw eYX2AlXQHcOwFusQgWuoxfbgAHW7cPGA3I4D/o6Fe/5PC/8NjN8t9z8IY1+crgZRQcZjCZZiGZZj Bf6Oj/AxVmIVVuMTrMFafI0b8B6oiEpojRexAOdR/VVFjMFBeIaQY9ga8oCfB3if7Wd2WJzqv4yH MkgRvfEuTiIePyATfoOp01iDH+AzhLEe6iEYo7EW6xCBq6gayrYfumMytiAcX+On0EKKf8HGpWCP WvyOOeOwOMVfxiMz1LqvrhZqow7q4in4oR7qowEa4mk0QmM0QVM0wzNojhZ4Fi3RCoEYi8VYNTS3 60D8UZ3Bg1Yw/kT1i3P7L+OxHYfhPkwRHTEH0Sj9miJ6YAVOwfd1cgJ+aIdRmIHd2IPv4TlcEc9j Kg7iEOJQ/A1FPIeJbzwQ7f991poYv5vD4lT/ZTw2v2HfT38cP6LKCOoz2mMkVo2w7sOX+++3YTt2 YCd24Svsxh7sxT5EYD8icQBf4+CIP27+xwOQZ/dccFic4i/jcQiHcQRHEYWzuAGXkbTfWIqLaDJK EWGIhvdoRfTDCiTCZwxjAwzEDMxENLLg+Sb9BAa/WbT9VyCFPGa6w+IUfxmPIZiI5ViPK2gwlj4b kXAdR7+AWTgFZbwiPBCE1zEcO/EjUlFBPb4XiBfRBUHoim4T/rLxL5S2yWFxir+MR3f0QE/0wkvo jT7oi2C8jH7oj1cwAAMxGguwEomoPZHtBWxBOvwnKeI9fICFOIfKbxW1AYVWUBfb/j8Zi0FYj3OI ReXJihiKbfgVz/2NNh/H4PU2Y380xt/wJfYhCaXfsR/Tr4tumIoF+A6lp5BbU/5K1wG6b8JtW5zq v4zHUsThoXfZzsMIhGEDolFqKnHHI3gUpeGNMiiLx+CDcigPX1TQzOnwR1sMxlB8NLWo/hdaQV1s 9V/GYhV+RM336KvRDVMxDUdxHub37HNz0tEyjP4dozEGszAbEdiPMtPIDfTCIhxH2rT7Yd+PrqCb CGz8BrpzTf4E0bUtjmeKO9V/XxmTJ6cTc8zAdlzEJXX+1R1kIgt3IWYowgQXuMIN7igGBR4ojhJ4 CA+jJDxRCl54ZEZR/S+0grrY6r+MxaNoiBcwAivwDyTDe6YimmEQ5mAHTqPSLHIGo7EHPyABt1B2 tiJaoD8W4xxiUWYOY8k5D0TsdecS/gnCLRyvIWHr/2U8RmAkFuFLROMyis1luw2DMAMbEIdK7yvi 8fetczOr4clc5me+qM7RXIhT7/+V6n1+/uisrmD81rruSFdwWLQxr5+pPRPE1v7LmFzCT6gxj1hj NubglDqH1jTfOo9WO4c2v+fc5+eyRwVb0F2bU3ey1TWhWYwLunfTXdMpP387oGBfIxcZW5OLet6P 5e/+aiKuzwjhK2O1CVvUmNlildM1DeS1DHzV6xlUwQtIxy3cRcmlitiITdgB72VsP6LycnIJMYjF TXy8QhErMWQzOYPlWIGjiELQFkX0xViMxyTMwZJwxqI4to3+CZO283x8vEMRB5CGdDy1UxF+uINM DNnF/4NTiEGTrxTRFOvwKdJxC0G7FdEVm7EdaUjHU3t4P9xBJkQGA8n0myRDejLf0i9K6fKxZIt4 y+1mbHSsSFdvx29GOd0OW74KN3lFFzk/+2H7/Gzr1Z0cZ5M7XUUqMvsqUtZzO3t4mIYHCLdHdGd6 ykdcQ+3XgfGQ7yrvd/6jr4ORqc1UXUHXXuaxoKuX+XkDXSE/P1sefwLdu+naDN0aXcU2/nGMC3JR 6//DJIs86zPIVCpspIe8DlS0i2m1ezHZMJQKW+0uWwbh63htksqaut0ZaWod/xW3kYE7Mo7I0tR7 z/+ydxcAUSx/AMeXPguxu1ux49mK9ezuROxu7M5ndwd2K9id2F3Y3d2iYvy/J3veHrcnC3cI3H+H 9xF2LuDd7O83s3O7c2Lsr8N6eMMHG7BRkg/i4fPMP+0HCjcClN3tb22E/5+jcFf+tW8E7iP8nOxv trmuL0iFs2KfcAEXcQl+uCzpIz5h7uzAvmIBvLAQi7AYS7AUR3EMg+c4CUNwC7fxEB/xDfZz6buQ FMmRG/8gPwqgIAqjCmqgJmqhNupgO3ZgH87iMm7jE/zxBdHn8ZogJlwQC3GQHhmRCZmRBa5YhMUw GN3pf/xisGU0qv+kLR+k/5qq1BZbBgH2djYOUX+vCKRdIUhwD492iWCBE8EyiWU3TBRd/Ce1dJyY PhNF4cbqXpKNFdJbDDYMHmP6bqs7K7qb0meTbiwTjIrNr3mV+Iy6K//6liCtje309oKDX0J7bpKj 8esqOEz9edb2Vayb8bclbpZecCxsZ/S8jsljGte9tjeuuy7z2NXRjOp+zQLaaP/OOJbObab3RIUf 4Gx6Y2VryYbBq2+wYfAY03ez7LP9KpGs7bXxH0euP1qJddiM3biIS7iMj/iML/iKAG2bI/V8JyEd vKW/a52yDYOwCs2G90xFdzNosT882yZFd5OJ/9+vrbgnaF/hiL03xDG3vdMjAzIiM6qhJmqhNuqg HiZiCqZiGqZjJq7iBm7iFm7jLlIv4PmRHhmQEZnRGu3QHh3QEZ0wDuNh7+UkOCAaXJAAKZAP/6AA qqMmaqE26qAeeqEv+qE/BmAQFmIxlmAplmEFjuIETuIUTuMs3uA9PuAjPsEfcRYyHkaWRcQbsiI3 8qM4yuK7tgQo//dXKyq+4697CpLRYDNLt6HpScu1u0zdYrBh0OH+4dmkW+Y/W1obJXcz/Wz6os+v ETryxQwVx9JxZ9mX1fDZElr02aQbpjt2hRuBRfv3RbL2t3SuNH/8P0iyYXoornBj9VxFd1P6bF6m bvldQjsGLBv7T23fS6btp1lk/G/p/s10wP0hFL0U3S18nk26YXowGLSEauT3N/cBXfwrGZM0gTs8 sAprsQ7r4Q0fnMLpRaGb1zU/ZxSX9AzmP5t0I5TTLKFo+2shbPvJMm1/KyRtr33N4oS0fUstdhJK w2WpkxAL/ss4PsAX/ETR5U5CI7TBIIzCRCzDbuzBPpzGLTzBUzzHC7zEK7zGW/yEywonIRVSIx3S IwMyIhOyoAAqoBEawx1N4YFmaI6W6I4RmI4ZmI05mIt5mA8vrMM+nMN5XIIfLuMKruI6niMALit5 PRAX8RAfCZAQiZEZBVEFVVEDNVELtVEH9WA4XNeW77oSYKGfBOn43xJtGobTl2YHc2g2rL1I4t/F nJgcJl3cfLD0N/ytjWFPFN3NYCNoEV+NPooz9nEhytSfSW13OTWMETVuiYSxkxROnjh1czL3KFuj J3f0clBWt87RuC6/TIY/K/M7MstkfbmeoLzx8zmbk1vNHlwZbAyWLnNu2ac22DAq/5ctL+71zub0 kX9oS2lchmFbhmZvMir/1+1vzljnr7WldEuNf0md+e1vzpg1/NtSbX/jupC1v/TYow36YCzGYSIm YTKmYCqmwQenMEx69YzpAVcYbgyTbgxUtmFQbP7fx3+hafeniLXKSciKbMiOnMiF3CiAXpiBxdiB /TiG2/gEf3yB02onIQ7SISNckRXZkB05kAvFURFt0B6d0QVd0Q3d4YlhmIhlWIk1WIt1WA9vbMA+ nMR9PMITPMUzPMcLvMI3aNY4CcmQEmmRDumRARmRGflRCi3RBh3QEZ3QGV3QDYMxDj7YhG3Yjh3Y ucbp99G+9KSkYI7nQ/qTID3+t1R7/q3zmcw+iyQ0G9ZUDM//iGVOLA57IHles3N5P2V3M8z/LjZK 7mawIZag52qEIv+viK7L/3FDlP9fyOR1DyfjOnPy/xWZuqoy+d+cnGp6jBWaK+L7SS9kMXuUZ/ov EMv/Z3sH3eudzeobpc9sOMq3aFsaZAaFjzH9F4hFnwf/L/cEXfubM8axbFz+of3TSrK82XuTWNT4 /9X+5oxVDd40UbhSYT9XSVtadt1DhY8Ry/9z1Otzn7O2HXdhD07jGp7gOV7jDd7iHd7jA1zWMi5E RbRBW7RDe3SFD87iBt7jK2zXOQkJkR05kAvFtdd5rgu8BrQNOqAjOqEzuqAbBmOMeI3oHCyAFxZi ERZjKTZit3gN6RGcwEmcwmmcwVm8RMb1TkIVVF0feK1pdfF601ZojV7oLbnudKzk2tPrkutPX4rX oG4Wr0M9grmbAq9H3RPkmtTPcNzsJERFbMTHjwBd+f2B4PqaP/8k3v3zr6t+3v/6tGTtf9qO743u aYTA63wCr/mxs40piJ8E/utKII4Cm5jT/sNuSHatwdL9LDQbBr28wscYzP/0UbYhBDlP7/97/G9O HKsH85GwGB7/O5uTj4fZS/pys0M+VPF/VNHdDDbEYoH418//hiz+/8b8r9L4N6dfNT2wD9UoX3rp kNmHFmFx/G8F7W00/g/t+OgPR97SDYXvyYRmwyBf9Da5YVTsBP0qOL9y4P/lniC2f4y/OdY1vc8Y HMcZ9Naml0cKw7sZrAqocLWmVyZvMVjuw+AW6Vkywv1QbPwuQeI6cB8XHOyEOEsEIS5+X/H9a/WH mIJdzF/3SKxtl2Rw3axfMycPKsETYzAZs7EQK+GNbdiLIzgNP9zEw836NXd+Iu0WxoooimqoiVqo h/poiEZoAnd4oBlaoOUW/bo9bTEbK7ETe7AXB+GLwziCYziOkziFMzi7Rb/uz0V8gcNWJyEuUiIN 0iIjMiELXJEN2ZETuZAHebfq1w4qgMZoBU+MxyRMxnTMwCzMxlzMwwJ4YREWb9WvP7QcB7f+ev9P /06d8Xt3f6hSdCdtlSB9/8/c9jd9Fq1BDzxCela72dM+lt34XbpIOwK7PDZ/7As2CZqpP5PHXBQ7 ffxVibIl25AyX9qOGQXH0TF/iuX30zoOk8nIf6Muv73079D+bDT/E/NPMWz2VKvcuEstEaKIe4Kj XK52XWOjv2Mm6aNMb+iL+MznFY+q+tjEmvrzgM0up9nRkse847IodvO46eM/SbAqUfsk2ZK9Sb4h ZffUgbGVTWYE9FVmRCV37otcfByQ/G/+P9TJjCrtze2bQ3M4Fv4b/7eJKejxX0y58ZXrCjX+rbFO Lv7NGU+r4R7pitH8j9xxketUNf6tsU4u/s09Dlb7/0hVjPp/ubkM121q/FtjnVz8mzt3pcZ/pCpG 8R90/vGCNv4rqvFvjXVy8a9r87t4gId4imd4gZd4jTd4h/f4iE9b9Wvmf0WibYwZUBhFUQwlUQpl 8C/KoTwqohKqoOo2/Zr7NdEb/2EW5mAuvLAQi7EEy7AcK7EKa7B2W+Ca/evhDR9s2Ga4hv9nOG53 EqIiNuIjGVy369f3z4NK8MQYTMZsLMRKeGMb9uIITsMPN/Fwu/7zAX4i7Q6eD8XghhIog39RDuVR EZVQZYf+2h+Ts/cyNdpG/Ky/asj4DgZbguBg6yg4OPye//cwp+3VdB/pitHxn1wMu7ZW87811snl f3Nythr/ka4Yxb9c3+vaXY1/a6yTi39zxlpq/Ee6YhT/cmNmV+kjMivbMCjafU+N/whXJxf/5h4j GZzPb/qTVAxOr3tv0Q2Dpx4iPc9I6QUB1n/ej/EnEzgGRmlMc45zLXt+0N/aUIu26PK/3HyFq7sk eajjP6vO/yGZn6qK6qiBmjvU8V8kLEbjP7l2rYU66IPRmIcF8MISLMVyrMAqrMZarIM3fLABG7EF l/AQn/EVAfgJYaeTYAs7OMARGkRBNERHDDgjFgqiPBqgERrDA83QAi3RGm3QDu3REZ3QGV3QHZOw EMuxEquwDuvhgw3YhM3Yim3YgZ3Yhd3Yh/t4j9i7nIS4iIdESIykSIYUSInUSIN0SI8MyIgy+Bed dwXO/yqa9A1dza9hT9D5X23u17W5rs10r7nuNdP9P+v+Zu3f2wVeWIjLuIJlu3lN4bKH9kJv9MFN 3EL5vU5CBSzCYrzFeyTf5yRURhUMxwjU3M/fhD3YiwwH+N0Yg7H4jC9odZA2x2Echb0v+xIKoTCi HmJfQi/0xiX4ocRhJ6EkvLAQLkf4m9EZXXAMJ/AeqY/Sdqh52kkYgHVYj41+TsJZnMMTPMX2y07C Y5y44iScxEu8Qtyr7Pdf9F8fhbdfAoJ8yVQ9N6rhbs8fB2h9/CLwNB+/3P/y3DGvZrD2E4GdxI8N ln6CsJP4s+6zf8XPAf71ScNCfbl4d+2l9v/WWCfX/5uT39X+P9IVo/5frp92ba/GvzXWycW/OeMy Nf4jXTGKf7nxtetYNf6tsU4u/s05nlLjP9IVo/iXOy52zaHGvzXWycW/OfMgavxHumIU/3LzWer1 v9ZZJxf/5sxfqvEf6YpR/MvNQys8/yODYFTsHHl69fyPCFonF/+dg8zlL4I3NmEX9uEI/CTz/Lfg r80Lu52EvCiMUqiAGqgPD7RBF/TCIIzEhN369wlW4jSu4gkC8B0/YLvHSbCDAxyhQRREQ3Q4I+Ye /XsNcVAS1dEcLdEK7dAeHdEJXdAV3dEDPdFL8l5FPyzEWuzCURzHCZzBWZzHBVyCH67gKq7jxh79 +x134LCXvxXJkBf/ID8KowiKoThKoOTeX4uA/uEtHKOa0NyJX6Ff/8ec9jf9SZ0Gtxik4ncW3TB4 6sHK1hgKWv7/zv6x+7UZuP6nuXEcOc8BUgcEYv8fUy4Xq+t/WGedXP9vbt9rOqzUA4IIWIyu/5Ub P7kuUePfGuvk4t+c8bIa7pGuGB3/yx33uE5U498a6+Ti39zjXLX/j1TFqP+Xm6tw3aTGvzXWycV/ SOamSqMMyqLc3sDzedX4j1TFKP5Ntav2PO1K6IxBGIcJmIipmIYZmInZmIN5mA8vLNyrP897KbZg N07hBm7hNu7jAR7hMZ7iGV7gJV7jzd7Ac8Xf7Q08XzzZPsNzxquiMTzQFh3RA8Mk55OPxVKcxn08 wzt8gc1+jnHhggRIgfTIhrwosl9/Pnod9MNITMdKrMYaeMMHG7EJW7AV27EDu7Bbck77fryFcMBJ iH1AXP9F2YTurysYTd/B1BywIH4emP78f7m2Vq//ss46ufxvTmyr6T7SFaPjP7kc7VpYjX9rrJOL f3P7ZHX8F6mK0fhPblxl+vyPtCZvMfysIUE9/yMC1snFvznjaIMoMv3ZP+H/lr/BRtDy/7j6hyB+ Cp7gbM7xkPp2f+QtuvGf3HGt+v6/ddbJ5X9z5zHU8V+kKkbjP7m5KPX9f+usk4t/3dxjXMRDIiRG UiRDCqREaqRBOqQ/ELgehxruka4Yzf+Etu21a7FkRhU0QFt4ohd6oz8GYBAGYyiGYQRG4j+MPqBf z2U8NmIXTuA+HuIRnuE5XuIV3uAt3uMDPsH/gH5NmABkPugkFERVVEcN1EFdNEQjNIE7PNAMLdDy oH5NmbaYCC+shw82YAu2Yid2YQ/2Yj8OwBeHDgauSXPkoH5NGkfERUKkRFpkQUHJejWKpvGDq5Jd /Efyo+T8b7m2VM//sM46ufxvbuyq479IVYzGf3L5Vz3/wzrr5OLf3P5Wjf9IVYziX27M5LpLjX9r rJOLf3PGyGq4R7pidPwnd6zj2k+Nf2usk4t/c45t1fiPdMUo/uXmKAze/zeIcoMlHwxOBjB6Z1GN /whXJxf/SuakSqABhmEWvLAC62Hwtr/ZGwZROyIUb+6HZuN3sf4zAcQo/Z0FhJjBte9W7MFhnMIl 3MADPMd7X/0a284ohApoimZojtZogw7oiM7ogm7oDk/0lKzR3RcLsB57sA/7cQiHcRwncAqncRbn cAEXD+nX+L4Ch8NOQjxkQVZkQy7kxj/Ij4IohCIoiuJwO6xfI7wM2qIP/sMYjMVETMI0TMdMzMIc zMV8LDisX2N8CS7gPr4gAN8gHHESbOBwxOgzQMNiQXj2Bf38b0jaWD13w3qKmAmiysWu+vnv1lkn 1/+bk6vV8X+kK0bjf7k+V/38T+usk4t/c8ZYavxHumIU/3JjZfX9P+usk4t/c46N1PiPdMUo/uWO cdXPf7LOOrn4N2dOQ43/SFeM4l9ubsp1nxr/1lgnF/9/mot0hAZREA3R4YyYRwI/L1GN/0hXjOJf STtrPxczLgqiPOqhARrCHU3RAi3RGm3QDu3REZ2O6D9XsztmYDk2YQu2Yid2YQ/2Yj8OwBeHcARH jwR+LufxI/rP5vxwRP/5nGmRC/lQFCVQDnVRD/Xhjt5YhK3Yg8M4hUu4gQd4jvf4CttjvDaIhYzI hCyoigZoi/4YiEEYhuEYiVEYjTEYh/GYiEmYjCmYhkPHnEK0nkvoVoAxXv9Frn1dB6n53xrrZD// 60jo41nN/5GuGOV/ubzs2lyNf2usk4t/c/phNf4jXTGKf7nxlLr+i3XWycW/OeNng7BS13+JlOu/ mHMcFP7nA6nnEIW26PK/3PGsuv6LddbJXv9r5vyF6ThTB4QRsBhd/xd0DuriMXX9F2utk4t/XZs/ whM8xUu8whu8xXt8wCf44wu+IkAb//iBNMedhOwoivKoiEqohuqoiVqog7qojwZohMZoAnd4YCQm YgG2Yjt2YA/2Yj8OwBeHcARHcRwncBKncAY/4HyCsS3SIwOywBU5kBO5kQf58A8KoCAKoTCKojm6 YyiGYwRGYwwmYCImYwqmYTpmYhZmYw7m4Tiu4Q3e4T388RnfThid/23BFUB+/0Sz68//NqvtpXuS mu4jQzE6/peLYXX9F+usk8v/5uZsdfwXqYrR+E+u31XP/7TOOrn4N3ecpcZ/pCpG8S83VlbXf7HO OtnP/zoR+mMjNdwjXTEa/8sd46rrv1hnnVz8mzOnocZ/pCtG8S83N6WO/62zTi7+/zgXiZ8QTjoJ trCDAxzhdFKN/0hYjOJfSTtrEBXZUBSVUAVVURO1UA/10RCN0ATu8EAzNEcLtMJULMEO7MJu7McB HMYRHMNxnMQpnMFZnMN5XMIXRDnlJCREYiRBCqREWqRDBmREZmRBVmRDduRAbnigK0ZhNMZgAiZi KqZhBmZiNuZgHuZjAbywGMdwFU/wDM/xGm/wAR/hj8/4igB8xw/8hHA6hOeAh66G3UA//y/Xvur1 /9ZZJ5f/zYlnNf9HumKU/+Xysjr+s846ufg3px9W4z/SFaP4lxtPqdf/W2edXPybM35W4z/SFaP4 lzsOUq//t846ufg357hXjf9IV4ziX27+Qr3+2zrr5OLfnPkqNf4jXTGKf928ox1SISdcq6rxb411 sp//GqTti6I43FAaZVAW5VABFVEZVVAN1VEDNTEAA7EO6+GNPTiA4ziNS3iAh3iEF3A4wzEFSqI8 qqMemqI1OqMnBmIExmMa5mETNmMrbuAxPiHKWSchOmIgFmIjLuIhARIiMZIgGZIjBVIiNaqjKbrB Ez3RF/0wAAMxGEMwDMMxEqPwH0ZjLHywGydxBddxA3dwF/fxAI/Oyq39Hpo1Xv5UY7z+izltrub/ SFeM8n/Q2DW49j+9dMPg2n/jos030jUA1Pwf4epk8r+dOfnaIKzU6/8j5fX/5vS7ps/9jsgbatEW Xf6XGz+5rpEkj782/vcIVf73ksn/MnlOzf/yr4u9ueNl03GmDggjYDG6/kPumCd81v9Q4z+s6+Ti 35xjXDXcI10xOv6Tm6twnarGvzXWycW/0rmpx3iKZ3iBl3gVNAeoCSGiF6P+/09t+xpvEf8cYz1k QxmUQ3lURhVUQ3XURC3UQV3URwM0RCM0wRBMwVKswEqsxTp4wwcbsQlbsBXbsQM7sQt7cA3P8Qmf 8QXf8QPCeSfBBnawhyOcEAVREQ3R4QxXFEYZlEU5VEJlVEU11EBN1EYd1EN9NEBDNEY/jMUczMcC LMYSrMBKrMYarMN6bMQmbMYWbDuvmwM2e42XP9WwG+jP/5Zr5/D5/Ec1/4d1nVz+Nzeu1fwfqYpR /pfLzeFz/a8a/2FdJxf/5vTFarhHumJ0/Cc3pnItrsa/NdbJxb85Y2g1/iNdMYp/uWMhNf6ts04u /s059lXjP9IVo/iXm8Nwba3GvzXWycW/OXNWavxHumIU/9K5x4t4qI1/dzX+rbFOLv6l7f4en+CP AG18Q7jAcQDsYA9HOCEaoiMGnBEL2VEclVEN1VEbddAADdEYTdAUHmiJVmiNNmiPUZiF5ViF1VgP b2zCZmzFNuzATuzFPuzHARzCY3yG00WOWRANMeGCuIiHBEiIxEiCFEiJVEiNdCiN2miB1miDDuiI ruiGHvBEL/RGfwzAQAzCUCzFFhzCURzDKZzGeVy4aHwOeBisA0Oz6+f/zWl3Nf9HumKU/+Xi17W9 mv+tsU4u/5uTr9X4j3TFKP7l+t3w+fxXNf7Duk4u/s0ZZ6nxH+mKUfzLjZfD5/p/Nf7Duk4u/s05 PlLjP9IVo/iXO84Nn/W/1PgP6zq5+DdnXkON/0hXjOJfbn5K7f+ts04u/oObj7wEP1zBVdzELdxW 4z8yFqP4D66N7+A+7C4xJkQapEcGZIErciAnciMP8uEfFEJhFEFRuKEbhmAcJmISpmE6ZmMO5mE+ vLAQS7EMy7ECq3EM1/AML/EK7/Ae/viMrwjAd/yArR//H7CHAzRIhVwohhIoiX9RFhVRCVVQFdVR A3VQF/VQH43QC/9hJuZgLrywEEuxDCuwEquxBt7wwQZsxFm/3/P/Ybv8u2T+X66N1fGfddbJ5X9z YlrN/5GuGOV/udysXv9tnXVy8W9OX6zGf6QrRvEvN6YKn89/UeM/rOvk4t+cMbQa/5GuGMW/3LGQ a001/q2xTi7+zTn2VeM/0hWj+Jebw1DP/7DOOrn4N2fOSo3/SFeM4l8693gOT/yCrAGc2eRGWumG wdq/2n1Pjf8IVycX/9J2f4ptl52E7XiMJzhxhWMDvELcq05CPCRBOhRGSVSAB5qhBbpjMIZiGIZj BEZjOVZhDdZiHdbDB/twCmdwFudwHhdwEd/xA2mv8fuRBXlRETXQAF3RDT0wDLMwB3MxD/OxCHtx AL44hMM4gmO4gpd4jTd4i3d4D8frToITdmIXbuIWbuMxnuApXsPlhpPghrpogjbwxDhMxyb4w/km ryt+5SkxV335Vfxlvym4xzfdXcQasfye9xfXgRc8LNHu36V7lOkNg5Ss8DEGGx9M3vJW2cYLkxsG d7OKEiTT2/3aNMrSLrq21cWvLlZ1cXnOROzp4kwXU7r4eSuJE7n40MZGHvb1vJiEJdiAjXiLd8h9 i/vAEz2xHwfgfNtJiIky+BcjMBJncBaud5yE4qiMKuiH/hiEwdiF3XC6y/EuKqAiZmE2zuE8Yt1z EmKjPhpgO07iGq4j0X0nITFaohW84YM7uIt0D5yE9GiLdvj+Rfzyf//y98/C05dPvzzUft1++MXo 67ZsfZAaQYiaVzO4ZPnoQmuNIDiJP/A9lvZ74G0uv25z5Gftdzu+c7uzttJOW1HXknl76VjJ/rdI ujOa3phncsPgbkuXmLpF4bP94alD8Vf/KkHHUvUUj3hGCY5Tf062Hxb9W+z08bclbp5ecPwhM2Z5 52Rc18vRuC6zzNhmsszzrYlmVBfbUv2twfL/pj8LwKAZ5oRiY6bJWxQeCyj9Q9cIskXMo9rcGQnb W9xTf++5QixLjpUMDrNMbyg8TpsnDfnQPNsfnlrauKH5q3+VyBjvQXNW7NCOcUMT4tNM3mJ6Y7LJ WxQ2vAWKibGTNcR/DHOOV5LdDBzLHcohOQg/IP19kXPjb5fAViko3Z2C+xyaMoLd1J8NY9xxacy+ dDRGcJ8+8+s2xwHxtN91T/KrzkXajtox+T9oi97og/4YgIEYhGGYIBm7r4U3fCTj+E3YjC3Yim3Y jh3Yif04hzt4jtd4c1M//n+PD/iIT/DHZ3zBVwjaYwEkRVbkRK5b+uOGvMiHf5AfBVAQhVAYJVAP rdEZ3dFDcrzRC73RB33RD/0xAAMxHHOxGjuxF/tu6Y9TDsIXh3AYR3AUx3Ac5/EMX6DhuCU6YtwO PL6ROWUvaIW52+wP+vP/gmv3Ep9t9LtRMek+ZfaG8Dsf7VKcSSvbxNTOFXo5DIgyO1rDGNr5wm+x u8armihbsn2phqSZmFYbD3LzhHKfCSZXl1TmsebMuSW1NYjLX3WeMnW37JTVTbY3rjtgY1znLFN3 2rjOKSSxrXCkFIYbarFUESMvanA52036+heVPoPZG+LfsCck/Z6C+HeXiX93mViXrzOOf3eZuFZe J5dPPM3IT3LjPLm84yxTd9q4zklpv6yGu3UVMf6jBDfmctNIdppIEf8pBeMSkeoiVvwrHVer8W9d RRf/wR0zuUVX49+ydREr/pUeF6vxb11FF//BzXm4uarxb9m6iBX/Sue11Pi3rqKL/+DmLN3yqPFv 2bqIFf9K56XV+Leuoot/3TlVLoiF2IiDuIiH+EiAFMiBnCiOUih9W38uVlmUQ3lUQEVUQmVUQS00 R1cMwjAMv60/h2sU/sNojMFYjMN4TMA0rMZ2HMMpnL6tP/frPD7B4Q5/O+IhIRIhMZIgBTLf0Z8n Vg4VUUlyzlhVVEN11EBN1EJt1EEjdJCcWzYAA+/ozzEbgqEYhuEYgZEYhf8wAfOwGluwAzvv6M9N +xFgWEK6reARtH7gOaC2djbNgmt/tzuSnUbN/xaoi1j5X2mMq/nfuoou/weXv90EyU6jxr8F6iJW /Cvto9X4t66ii//gxl9uadX4t2xdxIp/pWNsNf6tq+jiP7jjJ7dvavxbti5ixX9Ij5HDJQ+oGcLi RYz/aMHNe7gdlTwoUsS/ev6XEIL4Vzq3pUa3dRVd/x/cvKXbG8mD1P7fAnURK/6Vzk2r8W9dRRf/ uvcd9mAv9mE/DuDgHfX8D2uP/z+1vS8O4QTu4g1s7nKMCMe7+nUUoiAqoiE6YsAZMeGC+MiGIiiN cigvWX+hEiqjCqqiGqqjBmqiIbpjKKZgBmbe1a/bMAdzMQ/zsQBeWIhFWIWd2IUTOIOzd/XrPVzA RVyCHy7jCq7iGu7gNb4j2j3+v+ByT79ORBzERTzERwIk1K4TgcRIiXwohZqoi3qS9SUaYRDG3jP6 /FdLX/ul3Rak138pbWc1/1tX0eX/4GLYzUXN/5ati1j5X2meVuPfuoou/oPrg93yq/Fv2bqIFf9K x1lq/FtX0cV/cGNo9fwvS9dFrPhXepykxr91FV38B3cMrJ7/Zem6iBX/Suc51Pi3rqKL/+DmsNzS qvFv2boIdv6HwnlKNf6tq+jiX24Oei7moZgg2VELSx8dmg3DEvj790lj32lqbBs1/oOps0z82+t+ cpS2txcWYhEWYzm23tOvf30JV3D1nn4t7Bu4iVu4jTu4i3u4j6f4As19+hgkQML7+jW0kyApkiE5 UiAlUiE1MqIYKsEdzdFCsvZ2a7RBW7RDe3RAR3RCD4zBbKzCOqy/r1+zewM2YhM2Ywu2Yhu2Yz9O 4TSu4RZu39ev9X0P9/EAD/EIj/EET/EWdg+cBHukQBqkfaBfIzwDMiITMj8I+v5PWLz9Y/j+T2ja PVz6ArXLsGgR83/04OJYXf/Nus//U5qr1WC2rqIb/wXXD6vrP1i6LmLFv9Kxlhr/1lV08R/cONot oxr/lq2LWPGv9FhJjX/rKrr4D+442G2f5EFq/FugLmLFv9K5DjX+ravo4j+4eSy3uJKdRo1/C9RF rPhXOlepxr91FV38m5qHzgLXB2r8W3v8S9s6K7IhH8qiHJqjNdo80H+eaXt0QEd0Qmd0QVd0Q29M wHwswyqsxhqsxTqshzd8sAEbsQmbsRMXcA/v8An++Iwv+IoAfMN3/MBPCA+dBBtEQSrkQDGURCmU Rhn8i7Ioh/KogIqohMqojVZog17oh/4YgIEYhMEYgqEYhuEYgZEYh7lYhW3Yhd3Yg73Yh/04gIPw xSEcfmjw/k+YvPnzPcj7P0rbXc3/1lV0+T+4mFY//8PSdREr/yvN22r8W1fRxX+7B/p+Wde/6vpJ XX+n67ecHjkJGnigM1I8dhIKohCGPnESpqP2UyehGTo9ow6lnjsJ1fANeV/wvPiMBC+dhISYh/nY +4q+HgFwes3vQTwkQEIkQmZkQdw3TkI9NEBDeL7leeD5zkmYgqk4g7Owf+8kXMN1fMKSD9yGs2j3 kbyHzuiCHuiFUUj1iXECyuIYjqOQv5NQGKdxBi6fnYRYCPDXf70X3r98H/BY/Pq15c/Xw1sPr5y9 8lB4+F44IbwP/HqpveHlQ/9fX8Lvn/hZ0OQon17Qfo674Kz96dcnuSf89UnuUSU/x+DnfL837X5/ 5nt0yT1ddJ8NH0v8bHhn8XvgnaoGNyZzy6Hmf8vWRaz8r3TcreZ/6yq6/B/cMZX6/r+l6yJW/Cs9 blbj37qKLv6DmxNxeyB5kBr/FqiLWPGvdN5LjX/rKrr4D25OU73+09J1ESv+lc5bq/FvXUUX/8G9 J+GWVo1/y9ZFrPjXve90BKdwH29h88hJcIDjo8B5PzX+ravo4l9J22vnfNOhBJqgqWQOuAuSPzac C3ZDQ4zEfCzFWvjiFB7iG+yeOAnRkBppkE47f4w6cEdHdEJXdEN39Hqin2tehpVYhdVYg7VYh/Xw hg82YCO2wxd+uIbruIGbuIXbuIO7uIf7eIBn8MdP2D11EuzhAEc4QYMoiIpoiI4YiIMUyI/CKIKi KIbicEMJlESpp/r3fgN+tdDnX//KvoNroiL4LUFwsLXD7/d/Pf7Uvm7SHaaYuRuyhYyk5n8h/PK/ o6Xj+Lv02QOUbXw2ecvHyLIRCUpgxudfO/K+dk/Q/hxHae6tk1ay09aUPm8YbkhK4F+/IiS5IrVN DG2u+OpwJYptDF/nES7ecdLHb5x4SYqWqTKmaZxekLlOVHDMLxNfcnGYWaZOLg7l6jLb/aQY1nna GtfltzeuK+NgXHfARlldPuPfG0Vpv/q3hnw1fQXZYsmWl79C2Ljl5a8QNm555VcDy+01cr2B3F5Y xsG4Tukel8/o9+rGf6EdM4XL8YB6DGGxIrZ/DKXj3zpLJA+2ivyfUua3hFddeGUBIYrSYxvzE7v0 jaSQx67a8mGT/0Ny3Komc+spYvtH/dN8RGmUQXnUeSF5sJr/LVwXfvk/aDvrzt/shp7ohd7og77o h/4YgIEYhMEYiUlYjOVYgZVYhdVYg7VYh/Xwhg+2whcncRbncB4XcBGX4IfLuIKruIY7eAHHZ+Qv REN0xEBMFIcbKqI+GqAxmsAdzZ/pz1GdgumYgZmYhdmYg7mYh/lYAC8sgw8O4giO4hiO4wRO4hRO 4wzO4hwu4wFe4A3e4h3e4wM+PpNc/xHSqT2FNwcEuf5DaZtbNo/X3KfobpKiRn7Y9P8hjefwHwOo AwJLFLH9oynN0erxX1jWhV//r7T/NT/lP1F0NzX/C381/4dkbKWme+spuuM/pWPmWjkku2l16TOF 4YZYAv/WVdIMoGStaDULBKnTZwF73a1RlB4P/a0IV9//Ef5q/g/tsW749wVql2FO0b3/o3TeQh3/ h2Vd+I3/lcxJfbJEvKvj/wjV8rr8r2tff3zGF3yF8JwxP9IjM7LAFVmRDdmRAzmRC7mRB/mf66/5 b4oWaIlWaI02aIt2aI8O6IhO6IFBmIzpmIGZmIXZmIO5mIf5WAAvLMNG7MRe7MN+HMBB+OIQDuMI juIYzuA6PuILviLgeeBaBQlf8P/zQr9mwb/wD7J2QXL8A3f0xACMkKxp4IVNuIon+A7hlZNg8ypw vYN9eIO34toHJidtQzIZLAQ5c/T3zYEn1gU9/zMkba925tZTdMd/SmNaff8vLOvCr/9Xmq8tG8cG R3lq/29U9/f6/5D2xeHfB6gdgiWK7v0fpeMr9fgvLOvCL/8rHTubn/LV4z+5uvDO/yE6LpI+gZru I3XRjf+VHO/Wkj6whrKNasruZrBhomivU2KfDvL+zyL1/R9dnRnv/2gsMZ9hEKJfpRv+YbcxeZTk 1bHsUxuV5tJd74/73Hz2TPa5+JrK0RfFThjvSYKmJq4zq+loXCfX3nL3k9tXzsrU9XYOWiVGvc2v n7TXAbr8aT5KuhZn0DU447wJXIfTdK6eId2YpmxjsnRjgsm7jTV5y2iTt5jeMC42toJdTO3rE/gq 2dn8vmbS2vaEmErbWbvOaiP0eKtfb3U+srxzElzR4538+qt27wPXYI2KbKiBvpI1WW/iMT7go7hG qz8+Y/EHw/Va/eDw0Umo+VG/dmsHdEQnyTquXdEN3cU1XT3RU7K2639I+clwjdfKaIGxWIxV2CBZ +/UkXsPW30mIhXwogIL++nVhi8IDXTEYx3ASpyRrxp7DRwiff8XO11+Z54NIm4e0399qy+vAf39V /95+LdZ9+F39+55Bf9De4fc8rzjv62BrKzjY2NnG5Gcbga6kcVi1bWiuAw/NY0xvfDF5i+nf88nk xntzN8K1BEa7mPPJbr9ymXY7niXi0Luz5Fetlf7e0Gx4SzdWK9tYYfKW0PwF5hTda/w7w1ZW3GN0 FRy0PcaAKK4u9ombmegtdjkZ162T6RmuRDGuaxLdqM4lLPLozriS37BN+usUbpj/BNKNLSY3Nim7 m8GGj8lbDP4CfdHtEYFHMeJeUVLxXtFQsNftFc3N3Cfyxzeqi2upfs+yx/kzjkoOX/7W5MKMipLX 1sS0QyjGfyuit09yL5lfypCM/+RWefE1GsPJj/8+yNSNMTpqFPfDWCEds9giOpwR83PgGvhh2Saa kO8IBgcRofmlRsX+VwhrXy9ra38XU22q/VyDOMiIPMiH4iiBkiiF0vgXDdEaPTEF0zAdMzATs7Ee h+GHpF+chORIgZRIhdQoigZoiA7oiMNfnYQj+IGfEAL4OxEbiZEc6ZAHeZEPhVELAzAFs7EIK+GD bdiHIzgDP9zCQ7yE/TfGN3CCK/5BGdRDQzSCO5qiGZqjJVqhDdqiPTqgIzqhCxbCGwdwCIdxFMdw 4pt4/of+fA3jH7QNZ7gsmNG1fzI1kirj8z8s0dazz0p2LIPDftMbBkGq8DEGG7MrSjJDaJ7A9IZR +R3/YtRYTRYQXGJJ2lcXrynFeAwai9I4jGKjEdLaaYT8KIDmaIGW6IjOSOSgEVwRoNEI3xEzikZw QX4UwB7sxYmoGuE0skXTCNnRBm1RIrpGKIlWSBZDI1RBVTzHC7zBW3yEPxydNcICnMQpVIqpESpj Pw6gpotGqIXpmIGTiBpLIyTFwNgaYT284RBfI/TFQizCTdxC4gQaIQne4wMSJdQIZ2CXSCPYYwG8 sARLsRKrsRO1EvM6fNF+ffwifPn4+uPzjwL/BjwPeP5Q/JEv3ffAf/Xb+i3tfY3vpW1K6We/6D7f Re4zYOwknwMj1LdUrv5DFy5dOeyvjeWkGwrnAQ02pggGRRy9W9/4z5x+1mAexfSGwTsCBrcYzLq/ s+iGwVMPLmz8zvfv0iUk7yxvEjRTfyaPuSh2+virEmVLtiFlvrQdMwqOo2P+FMvvp3UcZvw7/0qd 4apxv34O0n/p5ygEZ0uNl/5WYIfLhhUWXfzLjXVdV0iGVpmkjzK9oS/iM59XnCn72MTSZspdTrOj addzXRS7edz08Z8kWJWofZJsyd4k35Cye+rAKJPLnl9l3g+VW69RLlKUvm9qLXUy7yrZm3tsYzpo wvC9X7M3rD26TZagRzIx5Y5PXb3U+LfGOrn4/9N8xEmcxhmcw3lcxCX4BY19NdwjQwka/85K2vky ruIHon53EhIhHTIiE7LAFdmQHTmRC3mQF/8gPwqgIAqjKdqiNyZjGqZjFmZjHuZjIRZhKZZhJVZh NdZgHfbiBK7jKV7gJV7jDd7hPT7iEz7jCwLw7bt23o3/Nwg/OM5FdpRAGfyLciiPyqiCaqiOmqiF eqiPBmiIxhiKKViM5ViBVViN9fDGBmzEZmzBjh9Of5jYC3VV0BpBcl5AM7n2dR2r5n9rrJPL/+bG szr+i1TFaPwnl5Ndpe++qvFv1fFvbh+sxn+kKkbxLzeOci2rxr811snFv7njZjX+I1Uxin+5Yx/X Xmr8W2OdXPybc6yrhnukK0bzP3JzFq7D1Pi3xjq5+A/NHNVO7FLjPzIWo/iXtudu7MV9vMcP2P50 EuzgAEdERTTEgDNcEAvxEB8JkBCJUQSV4I7maIFWaI326IAu6ApP9ERf9EN/DMBgeMEbB3EER3Ec J3AGZ3EeF3AJfriG67iBm7gDDV8JkRnZkB25kQf5UQCFUBhFUQwlUQqlUQbl0AI90BcDMQjDMBz/ YTTGYhwmYCKmYhqmYwZmYw9O4yXe4h2UndJpVg27gX7+V67dXdur+d8a6+Tyvzlxrub/SFeM8r9c vnadqca/NdbJxb85/bMa/5GuGMW/3DjLtZ8a/9ZYJ3v+z8/Qj6vV+I90xSj+5Y6PXJeo8W+NdXLx b87xsBr/ka4Yxb/cvIZrKTX+rbFOLv7NmcdS4z/SFaP4l5uPVM//ss46ufgPOv/8Cf4I+BXfGuEH fsLGRiPYwhFO0Nio8R8Ji1H8h7TNtdf9R0VR1IcnVuEw7uEHMthqhCpojwXYhddIbacR0tj9ed2A TuLaAZ6YgaO4jUd4g++Ia68RkqEQBmAa5mIJdmIX9uAVfuAnbBz4f4Ed7KFBQgf9GgV58Q/yowAK ohAKowiKohiKww0lUBZ10Qpd0R094Ime6IXe6IO+6If+GICBGI55WI09DhqDz38xajntuh8y7+oE 8+HfQbaN1/+Qa1NX6e/NrGzDoGhzj5r/I1ydXP4PqxhWuDZABNswvUzkZ5O3fFS2Ee4lMOPbidf+ 2wVGaTxL5NtDOSRBeED6OyPnxt8ugS1TUJowg1uHooxgN/Vnwxh3XBqnFxyPxghu9YlftzkOiKf9 rnuSX3UuwfWXJT5LEkkx6XOavSH8PlbYpbivqGwTU9tXeDkMiDI7WsMY2v7iW+yu8aomypZsX6oh aSambWxilRW5PkGuLqnMY83JuUltDdrlV52nTN0tO2V1k+2N6w7YGNc5y9SdNq5zCsmYyPS53n9r Qy2WKmLkRQ12rPtB8qCi0mcwe0P8G/aEJO8piH/5T3eW+yRnuTrj+HeXiWvldXL5RG7VJqX5SW5l KLm84yxTd9q4zknp8Ywa7tZVxPiPEtyxqlsOyU4TKeI/pWBcIlJdxIr/P81H7MN+HFDj3+qKLv6D tvNB+OIQDuMIjuIYjuMEzuExPsHRkXEjoiAqoiE6YsAZMeGCWIiNOEiCDMiEvPgH+VEABVEIhVEE RVEMxeGGEiiPhmiM3uiLfuiPARiIQRiMIRiKYRiOERgPLyzCbuzFPuzHARyELw7hMI7gKI7hOM7i MT7hh6N2aU2Ol2ALO9jDAY5wggZREBXREAuZkB9lUR4VUNFJo2SKz9xtWl9//ndwbe6WUs3/lq2L WPlfaVyr+d+6ii7/B5ez3XZJHqTGvwXqIlb8K+2X1fi3rqKL/2DHXC6SnUaNfwvURbD5H0dl42o1 /q2r6OI/uGMmNf4tXRex4l/pcbEa/9ZVdPEf3JyHm70a/5ati1jxr3ReS41/6yq6+A9uztItoxr/ lq2LWPGvdF5ajX/rKrr417ZtJVRGFVRFNVRHDdRELTRCDwzDFMzATMzCbMzBXMzDfCyAFxZiEVZh J3bjJM7iHM7jAi7iEvxwGVdwFddwHXfxBj8QXaMRnLWfJwcXxEJsxEFcxEN8JEBCJEIK5EVJ1EAt 1EYd1EU91EcDNEQjNEYTuKM1uqEHRmIMxmIcxmMCJmISJmMKpmIapmM+VmMtNmM7dmAndmE39uBH gGEJg21aP/Az4W3tbJoF1/5uedT8b9m6iJX/lca4mv+tq+jyf3D52+2B5EFq/FugLmLFv9I+Wo1/ 6yq6+A9u/OUmvfBFjX8L1EWs+Fc6xlbj37qKLv6DO35ySyrZadT4t0BdxIp/pcfIavxbV9HFf3Dz H25XJA9S498CdREr/pXOcanxb11FF//BzV+6bZM8SI1/C9RFrPhXOketxr91FV38B33/YS/2YT8O aONf2iBq/FugLmLFv1ybH4QvTuIKruEDPuMLviJAmxPwHTGjaAQX5EcBFENdDMZMLMBy7MFe7Mcl PEcAokbVCNERAydwEqdwGu+RLZpGyI42aIvOmIrtuIcS0TlmQWnURgu0RCu0RhskjaERkqEKqqI2 huMinuMFXuIVXuMN3uId3uMDPuIT/OHorBGcMB8LcBKncAHP4BJTI2RANuRDJVRGVXTHSEzHTuyN abD206/Vn8Tlngyu36L64+/6AF2VWBGg/0dcrMbw4dpVnwQHmyDrPzVV2t5q/reuosv/f4plN+kD TK/jUsTkLQUF2cLvlqxBpOZ/Ifzyv6OlcrbBklhfw25jWh7JCxCGv8dgI7A0l+6of9xL5zOuZi+N r6kcvWzsPXHHJ2hqYlWimo7GdTKrtMmucie3F52VqbvgHLRKjH3t3hArtP3tbOkTzjS5MV26MdXk 3SaZvGW8uRtmlMDXSZqtbANXTbOaPUGIYYmxk7e0YddKnz40G97SjdXKNlaYvCU0f4E5Rbe3/I6y yor3la6Cg3Zf8XCaHe1kvGYm9hMvmfaX209yRTWum+FiVOcSFmPfnXElv0E6f6R0w/wnkG5skW5s MnmL6Q0fk7eY/gv0xXC0I+4VJRXvFQ0F+8AM8ipW8xDkjitRjOs8pS9rYIkbmmOVfdiPA/DFk5gW OD6YcVYyOvlbBxgzKkpeTiXHISHO/Mc1DWMcTlI4uV9KU5lf42RcJzfKa2ucvWUz/2yZujFGWUPc D2OZas/PcHJhP0B11EBN1EId9MUIjMJkTMU0TMcMzMJK7MIeHMVxnMBJnMJpPIcmlkaIgqhIimQY EFsjDMR6eMMHe3EQJ3AGfniIR3iMl3CMw9gFpVABNVAfHmiDLuiFQRiJCZiO+diMLdiGm3gCf0SN qxGcERNxEBfxkQCJkBhJkQwpkBKpkBppURPN0AM90Qt90Bf9MQCD4hp89qfMD7+azeDIXtGHfhpU Ga//bIm2tnBMakKeCCYru9sffqn0bU6j8nvVdKuLfxdLxKrC19j0kvyhaeWJ5m4YHCUY3PK76FZJ tppWN1r/38WcXGt6HW2Do2eDWwx2gncW3TB46sGFJZMnBrcELV1CMv+0SdBM/Zk85qLY6eOvSpQt 2YaUgSvTj44Z3ArMf68uv8EKwb9+DtLq+mMUwdkSfebfGq39rY3/h6KLf7kxj6u3pAdWP//Haurk Pv/B3DGuwu5e/UCgiFGC9v8x5Y5TXOeq8W+NdXLxr+S4dDCGYhhGYCRGBY19NdwjQwka/85/at// MAbe2IUTuIyruIYbuInbuIN7uI+HeIQneIpneI6XiB1PIyRBZpRAGfyLCqiIqqiGWqiN+miAJnBH U3igOUZiBpZgGZZjJVZhDdZiPbyxARuxGVuwFduwAydwHvfwFu/xAZ/gjy/4im/4jp8Q4msEW9jB Hg5wRBoURyP0QV8sxCLcxC0kTsBrgFQojbYJdOd/BDN9Y7JK7k6BDf7516cQff91/od25ifwLBD9 +R9y7ew6Ss3/1lgnl//NjWt1/BepitH4Ty43u95Q498a6+Ti39y+OPzjPzS/VI1/XfzLjadc66rx b411cvFvzvhZ7e4jXTE6/pM7DnKVrvmkxr9Vx7+5x73q+D9SFaP+X27uQv38b+usk4v/0MxVTcF7 fMAnaBJqhARImFDx536b/qDtLyZv+WTylvfmbiyRnnMemicQIvZ5vobv+9vpz2SPE1x7JkJiJMFp nIFdInI/oqIARmEBvLAQi7AYS7AUy7AcK7ASq7AaO7ELNRNzjIlhGI4xWISjuI1HeAWHJOQpaOCK YqiMbuiJXuiNPugHL3hjr/ZxSfl7EQ3REQMxkRtFURzlURGVUBlVUA1N0Qld0Bf9MQADMQhDsAw7 sRtHcAzHcQIncQrPESUZfweSIhkGJOd5MCi5/vw/5Rf1KfxB+0BxHa+g5/+FtI0Nek6Ds+bNPlXf Kk7VkJxbEwkyghAtLOJWPf9fWqRZN+Kd/y9tP11+1eVQXZ7U5UJdvtPmNF0O0+UuH2zAEzzF1hQc VyJNSo2QFqMxBi/wEk1TaQQPnMYZZElNTseNtBrBM51GmI058MNlxEqvEWLjGZ7DOYNG8MUn+GNy RvoxzMBMzMV8rMW/mTRCd/TAR3xCm8yMZfAN31E0C/0JOqEztuMLorlqhI5ZNcI8zMeh3BqhcR5e L4zAfhzAd/yAX17+XgRgdz6N8Bpv8PXTO8kXY5lXL54E/dJWfwq849ffdwz6wK8PntwV7urvJ9iX LB9LEJxKlncRWmu036Nrv9tpf86rGaytps5ZvC2W9ntUsZ4f61mqnzX7pDv1+g9J3d+7/sMSYyQL t0m4nP/vK/yhWPH5/5YY4yp8jU3PwCht5Rwh3zNC80uNihWf/x/SYxRdP78R+3EoeZD2nyHdmBaK jSnK7mZ6w+BaDoNbDP7QMSY3BMPXSTJ6s774N9Wmp3AOV/BYMq57DQ3jupwog0qohYZojnbohj4Y gv8wCTPhlUI/LtyB23iGL4jOmNAFsRAP8ZEQiZAESZEcKZAKqVPqx5bpURst0BO90Qf90B8DMQhD MBTDMQKj8F9K/dh0HDZgD07hKq7jBm7hNu7iHh7gIR7jCZ7heUr9+PY14jKuTQZXlEJZlEMlVEZ1 1EAd1EVDmHFxn9I78Tv0n/9ubluHZjkNg5w8wuSFOn9r43ex/iuBxKjXj2diKolXy47vQtDvqiXM irgnaOTysXr9j3XWyb3/Y27/q3Dkrb7/GzGK0fu/cmMo9fof66yTi39zxsxquEe6YnT+l9yxj3r9 h3XWycW/uce6av8fqYpR/y87X3FRjX9rrJOL/5DOTzVCE7inCnwPV43/SFWM4l+uTbXvyzfHFCzG duzELuzBXuzHAfjiEI7gKE7iVCr9+/rn4A+n1BxTIiESIQmSIjlSIBVSIy3SIRMyp9afF5ANDdAO gzEUwzACI/EfRmMsxmECJmIqpmE6ZmAWduMUbuAWbuMu7uEBHuIxnuAZnuM13uAt3uEDUqXRCDnx L8qhPCqiEqqgKqqjBmqhNuqjARqiEdwxDFOxOI1Gf9bXn2ZwzathN9DP/8q1t+smNf9bY51c/jcn vtV0H+mK0fGfXJ527a7GvzXWycW/Of2yGv+RrhjFv9z4ynWNGv/WWCcX/+aMp9X4j3TFKP7ljotc 26vxb411cvFvznGwGv+RrhjFv9x8htr/W2edXPybM3+lxn+kK0bxLzcP6dpZjX9rrJOLf92881Is wwqsxGqswTqshw82YAu2Ypsa/5GxGMV/aNt+O3bhOQIQK61GiIO4iI8ESITESIpkSIGUSIt0SI8M yIyqcEcndEFXdEcP9EQv9EFf9McADMFQDMNwjMJq7MRRHMcJnMJpnMU5XMBF+OEyruIarqcNvP70 Jm7hGxKn0wj5URvd0SPdn69PTYjCaIrRkutVX+I7omfQCDEyBF6/GhMuOJgh6Of/yr9xE1zN71b+ veirdEUB+fVf5drSdZua/62xTi7/mxO7av6PdMUo/8vlYNdeavxbY51c/JvT56rxH+mKUfzLjZ1c G6rxb411cvFvzlhZjf9IV4ziX+6YR13/0Trr5OLf4se40mc3eyOiLRMpXVrCOtZ/DG5eQrrG1ne4 ZmQ8mDFwvS2Fl3UbbFj7koG611iIHOv/OQfXxto11aZiGqZL1lebhdmYI661Nk+y3to6lMlkuO5a X0zGNpyBH25J1mP7jKSZNUJ27VpsaIZWaJ1Zv1Zbe0yEF9bjE74iQLKO20+kyaIRsiEHCqIwimTR r/HmhmpogqZohw7oKFn/rSumYyVWYzO2Ypu4NtwO7MRV+OOzZL246OiQ1XDduAVYCx9sx2744gIu 4lJW7dofll70M+jnhRuv/xkWbayu/ygt0qz7O+5KKs4NYbz+o6ViMjSZ2GBDXf9PUvf31v+zRD61 cJuo6//9xfW/LNEfKnyNTR+SK23ljCHfM0LzS42K1bS68fp/lhjPGEaSdCM0y/eZvRiguv6fUZ3p +P/TePQ6PiBZNo2QCwXghrKoijrZ1PXfIvv6b0rbuQlaoiN6oD+GYSwWYwmW4QT88BCf8Q3fYZNd I9jCHg5wggZREQ0x4IyYcEFslEA1NEMLtERrtEE7tEdHdEIXdEV39IAneqI35mMVtuMQjuAojuME TuE0zuIcLuAi/HAZV3AV1yHk0AhRkBA5kAd5UQAFURTFUBKlUBblUAmVUQVVUR2DMQnLsRKrcgQ5 D8TggO5PVYrupKtiX9Bf/6ukbS07vgtBv6uWMCtiJtDIxa66/p911snN/5ubqxWOvNU3BCNGCTr+ jynX36rr/1lnnVz8mzO+UsM90hWj9//lxsnq+n/WWScX/+YeF6n9f6QqRv2/3LGt6w01/q2xTi7+ zZ3LUOM/UhWj+Jebj1LXf7POOrn4Dzr/uAZrsR7e2ICN2Iwt2IGd2BU09tVwjwzFaPwf0jbfjb14 iI+wz6kRHOGEKIiK6IiBmHBBbMRBAiREIiRGUpRDPXRCF3RFd/RAT/RCH/RFfwzAEAzFMAzHSKzG ThzHSZzCGZzFeVzAJfjhCq7iJm7hNu7gHmLm0ggpkBf/ID8KohCKoCiKww0lUQplUQ7lUQGV0RVD MAlTMBXTMQOzMBtzMQ8L4IUluQzm/8NqGVB2A/38v1ybquv/WWedXP43J4bV/B/pilH+l8vF6vo/ 1lknF//m9L1q/Ee6Ynz9Z07jMZS6/p911sle/5kz9GNmNf4jXTGKf7ljH7X/t846ufg351hXjf9I V4ziX27OQl3/zzrr5OI/NHNUS7FMjf/IWIziX9qey7EKV/EUP2GTWyPYwh4OcIIGURENMeCM2IiD uIiHhCiKymiEJnCHB5qhBVqiNdqgHdqjM7qgK7rBE1OxBD7YiE3Ygq3Yjh3Yhd3Yi304gIPwxSEc xgPY5tEIKVEUDdEIjTEcI7AfB/AdP2CfVyNkRCV4wg+XcRXP8AVfEYBv+I4f+AkhH68fbGEHezjA EU7QIAp25dPO+5q56J/smn/SIr/+n1y7q+v/WWedXP43J87V/B/pilH+l8vX6vp/1lknF//m9M9q /Ee6YhT/cuMs17Jq/FtjnVz8mzOuVuM/0hWj+Jc7PlLX/7POOrn4t/TxsNUt+TdV0d0i7fp/lpzD 2J1P8bXioVkGMCJvBC3a1zYyrP8XR9dur/EGn5DuH43QHWMwFuMwHhMwEZMwGVMwFdMwHTOwDMtR LL9GKI4O6IjuGAMfHMUZXMYrvMZbxCtAbsE/aAh3NIUHmqEF/sMsrMBrvMcHfMQnfEbSghohAzIh N/IiH/5BfhREeTRCE7RBO7RHB3REZwzCBCzAAfjiEA7jCI7hKh7hE1IU0gipkBppkBbpUBJDMBRT MQ2fCmsEf3xGxiL8rUUsvf7f7x+0z/BZ1+5B1/8Li7Y3iHTTK78o3NgoXbUufJ5AumHw/2OwMqDB LZKizbclFeeCMF3vT4x6G0G3KmFcbbvr2lrXvtMk7SmNYV2s6uJRF3O6uNLFji4+0kj2eX/Jfl6k uEbog76oXUYjlCvLmANN4I4pmIppmIcFeFZOIzxHmfIaoR5aohUWYwnu4wHSVmAfRgd0xA7sxDu8 R46KGiEneqIX1mIdruMGElXSCInRA/9hOmbAF4dwDMdhV5m+EBVRCeMxATdwE3GrkM9QHQH+2i/B /61/gMEXNS+f8t8j4ZH2tqfarztPA0x83TG6VduiUfNqBpcsH11oTfqwL1k+liA4iZt8d9F+D7zH rx+1dbHE25x/VdS1RK42PZgzCAmDW8LwaG+ydCXJ0DyBUbGyVb9040AqXCzV1yoc9xlsKFx907Ib oVleUl+sbE8QYllinGR2Fz/5iqK7GWyY/0ubm0oTRsXaWv33LJDgYolxrunAMXhZQxOtk6WXIil8 jNm/1KhYTfsbr/8ZmuOUzMiPwiiF2dLfMDMUG9OV3c30hsEyoQa3GCwGanrJzz+t/xlk5kSwpv3B Ra49y6IKGqMJ3NESA7ECu+GLk7iA67iHZ3iLL9pj2aIaQYOYSIBsyI6cqI2m6IyhGIlRGItxmICJ mIwpmIbpmIlZmI05mIdTuIFXeIf3+IhP+IwvCMA3/MBP2BTTCLawgz0ckQX/oAyqozbqoB7qoyEa oQnc4YFmaIGWaIXWaIsJmInl2IuD8MVRHMMpnMZ5XMBlXMGNYvrrP0O5xqOSO9Hs+us/zW3vyLnk q3x3//+4/mtwMRuGI3G1hGMR9wQnubwcPut/eoTq/T+ls+Lq+3/y7/+Z2w8rHIZHsI3/2zwUdPwf U24s5bpEjX9rrJOLf3PGzmq4R7pidP6P3DGQ60Q1/q2xTi7+zT3mVfv/SFWM+n+5eYvwWf9Tjf+w rpOL/9DOU93ELTX+I1sxin9pW97GXdgX1wjxkAFZ4IpsyI6cyIU8yIt/kB8FUQiFiwee31FUco5H P4zGeEzHbCyEN3ywAdtwDl8R000jxEdypENW5EFhlEQFVEd9NEUbDMJgDMUCeGMn9mIfDuAgjuAo juMETuE0zuMCLuISLuMjHErw9yAO4iI+EiAJkiI5UiAVUiM9MiAjMiELyqEeWqM9OqATOqMruqEH PEuYuA5UEEI0LxxMDc+mn/+Va/fwuf5Lzf9hXSeX/82JczXdR7pidPwnl69NX/+RweQtgUVyZpEa /xGuTi7+ze2fwzAHGDy1wXuGYfQ+lPW//2c8/gvpGCsM3w9U30P8i0Vs/2hy42bXqpLkoY7/rDr/ m3OcpI7/Il0xGv/JHe+q8W+ddXLxb878hhr/ka4Yxb/cPJVrTTX+rbFOdv13hfOSvdAbfdEP/dX4 j4zFKP5Nte0ADMJcrMVO7MU+HMBBHMJhHMUxnMBJnMYZnMU5XMQ72JXUCLEQD/GREImQBEmRHCmQ CqmRFumQHhmQGWVQBy3QBm3RHh3QCZ3RFd3QA57ohd7og74YAC/4YB98cQhHcBTHcQKncBpncQ4X cBGX4Ier+IKopfj/QDIkR0qkQhqkRXpkQCZkhiuyIhuyIxdqokUpjXQBR5MT+GbWsBvo5//l2tq1 opr/rbFOLv+bE9tq/o90xSj/y+Vo17pq/FtjnVz8m9Mnq/Ef6YpR/MuNrdT5H+usk4t/c8bSavxH umIU/3LHROHz+V9q/Id1nVz8m3MMrMZ/pCtG8S83l+HaXI1/a6yTi39z5q7U+I90xSj+5eYg1f7f Ouvk4l/b3t3RC73RF/0wAAMxGEMwDMMxEqPwH0ZjHNZiD07hHM7jIi7hMq7gGq7jJm7hDu7iHu7j ERKWJtcgF/LhHxRAQRRGERRDcZRASZRGGfyLsqiANuiD0RiPCZiCqZiJWZiDuZiPBViMJViKZViJ A7iAO3iAh3iKZ3iF13iLd/iAj/iCrwjAN/xE4jIaIQsKoiiKoSRKoax2/UtUQMUy+vVf/jSBb2YN za6f/zen/dX8H+mKUf6Xi2N1/GeddXL535y8rcZ/pCtG8S/X/7pOVePfGuvk4t+c8ZYa/5GuGMW/ 3LhZvf7TOuvk4t+c4yQ1/iNdMYp/ueNd9fwP66yTi3+z5jekz6TGf2QoRvEvN0/l2lqNf2usk4t/ pfOSlVEFNVATtcqo8R8Ji1H8m2pb7ecy1cE4rMZRPESSfzlGRB10xyTswH1EL6sRMqNs2eA/02m+ +LlOS3EY/nAupxHiIQVcURIV0RZr4YsTuFBO/3lQL5GyvEbIjhzIhdzIg7wogFLl9Z8b5YHmaCH5 DKnWaIO2aIf26ICO6IQeGI6pWICFWFRe/9lTS7EMy7ECK7EKq7EGG7APp3Ebd3GvvP4zqx7iUXnd uf9Bm+zXR7fJzOobzfIHd4cA7dR/0M9/k2vr8Pn8VzX/h3WdXP4Pq9g2+3Ng/9aG6c+bNdj4LEiK wS0flW2EewnM+HbiCj12gVEazxJ5+FAOSRAekP7OyLnxt0tgyxSUJszgVp8pI9hN/dkwxh2XxukF x6Mxgltz5tdtjgPiab/rnuRXnUtw/WiJN5JEUkz6nGZvCL+PFXYp7isq28TU9hVeDgOizI7WMIa2 v/gWu2u8qomyJduXakiaiWkbm/h8HbnPBJerSyrzWHNyblJbg3b5VecpU3fLTlndZHvjugM2xnXO MnWnjeucQjJWUrgmTxhuqMVSRYy8qMGNgd0+SB5UVPoMZm+If8OekOQ9BfHvLhP/7jKxLl9nHP/u MnGtvE4un8h9XpfS/CT3mWByecdZpu60cZ2T0uMcNdytq4jxHyW4Y1g3QbLTRIr4TykYl4hUF7Hi X+k8hRr/1lV08R90DuoxnuApnmnj316Nf8vWRaz4l2vz53iBd4hSQSMkREqkRhqkRTqkRwZkRCZk Rha4IityozzqoQ3aoT06oCM6oTO6oCu6oTt6wBMDMB1LsQnbsB07sBO7sBt7sBf7sB8HcBAncAM3 8QJv8Bbv8B4f8BGf4I/P+IKvCIBNRY3gguQVtWuiaIRsyI4cyIlcyI08yIt8+Af5UQDFUAvN0A09 4Ime6IXe6IO+6If+FYOc/61gRjcU2zS7/vxvpe2t5n/rKrr8H1wsu6VV879l6yJW/lear9X4t66i i//g+mK3PGr8W7YuYsW/0vGWGv/WVXTxH9xY2u2O5EFq/FugLmLFv9LjJTX+ravo4j+4Y2E36YkP avxboC5ixb/S+Q41/q2r6OI/uLkst6SSnUaNfwvURaz4Vzpfqca/dRVd/P9pLnqANv6vSB6kxr8F 6iJW/OvaeSAGYRSmYBqWYzXWYC3WYT284YMN2IhN2Iwt2IMTOIVLuIpruI4buIlbuI07uIt7uI8H eIHP+Io4lTRCAiREIiRGUhRHFTRGEzSFB5qhOVqjG3rgP0zGVEzDdMzATMzCbMzBXMzDfCzAUmyG Lw7hCI7iGI7jBE7iFE7jDM7iHM7jCh7hA37CprJGsIUd7OEARzhBgyiIWln6/k9I39xR/AhB+v6P 0rZX8791FV3+Dy6u3bZJHqTmfwvURaz8rzR3q/FvXUUX/8H1y+r8j6XrIlb8Kx17qfFvXUUX/8GN q90+SHYaNf4tUBex4j+kx07hkgfUDGHxIsZ/tOCOh91OSh4UKeJfvf5HCEH8K53zUKPbuoqu/w9u PsvtieRBav9vgbqIFf9K5yzV+Leuoov/4Oaj3dJKdho1/i1QF7HiX9vG0RAdsZER/6AsyqMCKqIS KqMKqqIaqqMGaqIWGqAbhmA0xmIcxmMCJmISJmMKpmIapmMGFmArDsMP13AdN3ATt3Abd3AX93Af D/AQL/EDP+Fchf8fxEFcxEN8JEBCJEJiJEFSJEMa5EJxVEZVVEN11EBN1EJt1EFd1EN9NEBT9MRw TMMMzMQszMYczMU8zMcCeGEhFmFVFcn7P2Fz7Y+2CNL3f5S2v5r/ravo8n9wse2mUfO/ZesiVv5X mr/V+Leuoov/4Ppmt/xq/Fu2LmLFv9Lxlxr/1lV08R/c2Fq9/sfSdREr/pUeP6nxb11FF//BHRur 539Yui5ixb/S+Q81/q2r6OI/uLkt9fofS9dFrPjXtb9ujvIMzuI7fqBwVY1QBLOxFjuwE/74jBLV NEJJjMYYbMN2BOAbilbXCMUwAANxFMcQrwZ9DiqjCsZiHC7gIqLU1AhR8Q/ywxM90RsjMQqbsQXf a2kEl9o8L/xwtQ5jGSyvqxE2oU499mc0RQd0xFiMxwRMwiI0q8/xD7ZjB8o30Ah90Q/zMB+9GvI3 QGikEWwQ4K/7eusf8OevV8KrJw+4W+DXK+GWcO3i6QfCA+EYHnATXzSJJkf59ELJ8rEEIWpezeCS 5RMKrfl10bS14raT+F17e77AHwUn7SO4Y+BjXH49xl7yLNF/1TiJP/Dd+VdFFaXz12r+t66iy/9/ em+imPTar8LSR4dmw7AE/v590tzvNDW2jZr/g6mzTP631/3kKPce1GZsxTGcwmmxXwiXHKAmhDAp YvxH/VN7a8cB53AeF3ARl+CHy7iCO3iJ1/BHgHY/qaIfP/yEwDjBBrawgz0c4AhnJEZS5ENBFKqq H3cUgwc6YgAGYjCGYCiGYRRmSsYoW7AN26vqxyu7sBt7sBf7sB8HcBDHcBVP8B4f8amqfpzzBV8R gG/4jh/4CYFxjiOSIYt2zIPicKumHx+VQmmUwb8oi3IojwqohlbVdO//htm1f9oiSN///VM7F5Ne +6XmfwvVRaz8H5J4VvO/9RRd/v9Tni4mfe3V+LdQXcSK/5D0x2r8W0/Rxf+fxlnFPkt2IjX+LVQX seI/NOPp8M8DaoYwt4jxHz244yP185+s+/ovpcfAajBbV9HN/wY3v+HmKtlp1Pf/LFAXseJf6RyW Gv/WVXTxH9z8pFtKNf4tWxex4l9uDtoTIzAK/1ULfG9fjX/rKrr4N9Xe2nM5xmIcxmMCJmISJmMK 5mA5VmATtmBrNf05IDuwE7uwG3uwF/uwH8dwHTfgjy/4Wk1/7sh3/MBPCNU1gg1sYQd7REdypEBB FEaR6vpzTorDDSVQEqVQGmXwLyqhGbqiD/qhv+RclUEYjCEYimEYjhEYiXFYik3wxWEcqa4/x+U4 TuAkTuE0zuAszuEq3kKooRFiIk4N8f2fsLv2T1sE6fs/wbW1uv6fpesiVv5XGs9q/reuosv/weVq t+iSnUaNfwvURaz4V9wfSx+lxn+kL7r4D26spca/pesiVvwrHU+r8W9dRRf/wR0ruQlq/Fu2LmLF v9LjYTX+ravo4j+4uQ63jGr8W7YuYsW/0vksNf6tq+jiP7i5SvXzny1dF7HiP7j56Lg1Aq/VVOPf uoou/qVtrL0eNwESIhESIwmSIhmSIz3+QQGURUVUklzHWxXVUB01UBO1UBt10Ajt0QejMBpjauiv /x2PCZiISZiMKZiKaZgDH+zFGZzD+Rr664YvwQ+XcQVXcQ3XcQMP8BpvYVdTIzhBU1N/vXE0REcM OCMmXBALsZEYGZAJOZEX+STXKRdAQRRCYRRBURRDcZRFTdRGZ3RHj5r665vD+s0ftgXp+z/Btbvb A8lOo+Z/C9RFrPyvNLbV/G9dRZf/g8vb6vo/lq6LWPGvtG9W49+6ii7+gxt3qev/WLouYsW/0rG1 Gv/WVXTxH9xxk/r535aui1jxr/TYWI1/6yq6+A9u3kM9/9PSdREr/pXObanxb11FF//BzVu6SRtE jX8L1EWs+Fc6N63Gv3UVXfzr3nfoVdN4bVU36QOKmdwoYvKWgoJs4Xfb8btt+M4eqca/EH7x72iq 7bXr6u7CZdjW0giJkBIZUQxl4Y6eGIARmIf58MI5nMd1PMUzvMBLvMK7Wvp1e1MiNdIgLdIhPTIg IzIhM7LAFblQBFVQDdVRAzVRC7VRB3VRD/XRAE3REZ7ohd7og77oh/4YgIEYhMEYglGYirVYD2/4 YAM2YhM2Ywu2Yhu2Y3dt/ZrEj/AET/EMz/ECL/EKrxGY/b5Ii/+XIMWwQvlW4Obv9/0EB1s7CB7m tPV36Z70NbJsqEXM/dps4Kw0ZutIFzKpKX22MNyQlMC/eUVI+orUNjG0fcVXhytRbGP4Oo9w8Y6T Pn7jxEtStEyVMU3j9ILMOjGCY36Z/CqXhzPL1MnlYbm6zHY/KYZ1nrbGdfntjevKOBjXHbBRVpfP +PdGUZqP/9aQr+YuQbZYsuXlVwgybnl3mZZ3l2l55asBye01cqMBub2wjINxndI9Lp/R79WN/0Lb 14bL8YB6DGGxIrZ/DKXjpjpzJQ+2ivyfUua3hFddeGUBIYrSMbH5if2GoruZil215cMm/4fkeEdN 5tZTxPaPqvQ4to70PFA1/1u4Lvzyv9I5CsvGcU3pu4pq/jeq+3v5Xzr/9AZv8Q6fYVtHI8RFfCRA wjoRbtyvllAWsf2jKW33REiMJEiKZEiOFEiJ9MiNQiiCoiiG4nBDCZREKZRGGfyLSqiHbugBT/RE L/TBaqzBVhzCYRzFMRzH6Tr6z3v7jp8Q6moEG9jCDvZwgCOcoEEUxERiuCIbsiMHciIXciMP8iIf /kF+FEUF1EAt1NZ+xhzqoh7qowEaohEaowlaoAvGYBzGYwImYhIm19V9/ovRZRt/2grmZqMtQXr9 h9K2VY//wrIu/Pp/pXFrfpd/R9Hd1P5f+Kv9f0hystrdW0/RHf8p7WtrZZTsptWlzxSGG2IJ/FtX STOAks8KUbNAkDp9FrDX3RpF6Tjqb0W4+v6P8Ffzf2jHyOHfF6hdhjlF9/6P0uMddfwflnXhN/5X eixrfmK/o+hupmJXbfmwyf8hmadQk7n1FN34P+j80xRMxTRMxwzMqau+/xO2deGX///U5suxCb44 jCM4imM4jhM4iVM4jTM4Cz/cxXt8xCf44zO+4CsC8A3f8QM/4VBPI8RGYiRFMiRHCqREKqRGGqRF OqSHK/KjOmqiFmqjDuqiKTqgIyZgIiZhERbDo75GaIYd2IlyDTRCefRFP8zDfCzBPryAbUPGx4iF jMiJQqiOemiKXuiNvhiHuViNU7iEB3iExw0l877Bz99Kt4TA5Tk+Spi4u+Bgays42DjY2ggO+vnf pkrb2bJ53OAoT+3/jer+Xv8f0hgO/zGAOiCwRNG9/6c0L6vHf2FZF379v9I+1/yUf0fR3dT8L/zV /B+S8ZSa7q2n6I7/lIyTa0kfWEO6UVW6UUnZhsETGGwYFrtfV4kyUP11raggBHn/Z5H6/o+uzoz3 fzR/6zjI4FrBAGUbln2MdCFDw1s+RpYNs0pgxNsJungSbNjlEik9Rq2bUrKDGiSEMNwwKGLGWiZN A0riX+P0KKqry6tY3nGuxV+V6F6yuikTp76Rxt3E9X9y8SV3/Z85cSj3LuBZhfEvlyeU/t5hxo+N opt/eIIXCMA3/MBPCI00gk2jv/j+7z5BtoRm/Geq5eXf/zVuUfn3f+XuZ877v+HT8rrxn5K2t4Ud 7OEARzhBA2dkgSuyITtyICdyITfyIC/y4R/kR1E0Rwu0Qmu0QVu0Q3t0QEd0Qmd0QQ8Mw3CMxCj8 h9EYg7EYh/GYgImYhBnYiV3Yg73Yh/04gIPwxSEcxhEcxWk8xhM8w3O8wEu8RvTGGiEJMqMiaqIZ WqAlWqEd+qAv+mMABmIQBmMIhmJY49/zgCE6oVPhlq6C1tef/xna9g3/YwH1kMGconv/36aRPl51 8aeLJ1186PZ33T67Ht54gqfQNGEMiGIojnZojw/4iLTuHFuiERqjPwZgEzbjLh4gVlONEBsv8BKe HhqhJ5ZhOW7jDn5CaEY+wT/wQDM8w3Mkbk5MogZqohu6YxVWww+X0bEFuQXzsQCXcQX++IxsLdnf 0QANcb8VYyG8xhu8x0/YtdYILoiL5EiNAP/gvt4Gew/d1+uHt/2vaL9otxh5NYPzaQaXLB9L4LdE zfv7RyG2+HOV8rZCNWjr7H7fx+XXtpN4Z75H/1VRS2mujrzv/5kaBaSU+S3hVRd+4z+l/bD5A7tB iu5mKnerLR8247+QjLHUztx6im7+T+nYuc4NyYPV/G/huvDL/0qPi8zP/96K7qbmf+Gv5v+QHPOq +d96ii7/K53LqFNRsgup+d/CdeGX/5XOU/2tCFfnf4W/mv/l5iCHYwRGYhxWYTXWYl3jwPmf8O8L 1C7DnKKb/1Pa3tr5Ph9swEZswmZswVbsxn08wCM8bqyfH3yG53iBl3iF13iDD7BrohHs4QinJvr5 xKiIhuiIAWfEhAvioyAKoQiKSuYf3VACJVEKpVEG/6ISWqIV2qBtE/18ZUcMwxQsgi+O4Qqu4Tpu 4A5e4w3e4X0T/VznJ/jjM77gKwLwDbbuGiEFUiI10rjr50bTI4N7qNZ/COnaEIJ0/l9p26rzf2FZ F379v9K4Nb9jH6TobqZyt9ryYdP/hyQnq5259RTd8Z/Svlad/wvLuvDL/0rHUebnf3X+T64uvPN/ SMbIav63nqLL/0qPfeqkVef/wq4u/PK/0uPavxXh6vyf8Ffzf2jnLMK/L1C7DHOKbv4v6PxTRmRC ZmSBK3K5q/M/YVsXfvn/T21eF/XQAA3d9edvNoE7msIDzdAcLdAGvdAbfdHPXX++50AMwmAMwVAM w3CMwXp4YwM2uuvPD92CrdiG7diBndiFA7iBm7iNO+6B55Pew313/TmlCZEH7trzStEfwzEXS7Ee h3EKlyTnoL6Go4dGiIe0KIMKqI+GaITG8EAXdEV39PDQn7/aC73RB33RD/0xAMOwEIuwxMNgHYiQ LANhctkHmQpBOv+rtJ3N79gHKbqbqdytRn7Y9P8hiWG1M7eeojv+U5qb1fm/sKwLv/5fab9rfv7f pOhuav4X/mr+D8mYSs3/1lN0+V/pWLmO9MEGF2kbrNhtcEsVczfEv9Lu9zXrahawdP5Xehz0tyLc YJ15w6Je+W9UZ37+t8Qxbvj3C2ovE9Iitr+L0jmKOvskD7aK8b/6LgAlStD5p6Ue+uutV2AlVlki xmtKJ5BDHohqzx82+f9Pbb4aa7AW67AJ13AdN3HLQ39N/l3cw308wEM8wmM8x1cE4Dt+eOiv4beB LexgDwc4wgkxkBO5kAd5Jdf850cBFEQhFEYRFEUpNEJjuKOpZI2AFuiD/zATO7AXp3EW53AefniI R3iCp8306wu8wEu8wmu8wVu8w2fEa64R4iMhEjXXr0eQFMmQHCmQEqmQGhlRubl2/jfsTvwViyCd /w1JO6s9s/UU3fGf0vitM0jyYHX+z8J14df/K83N5vf/NxTdTe3/hb/a/4ek31Xzv/UUXf5XOp6q Iz19V83/Fq4Lv/yvdKxsfv6XLiCq5v/fJZzzf2iPg8K/L1C7DHOK7vw/pce06vxf8PeLjPN/Sucr zM//6vyfXF145/8/zUVVQTVUbx64lqaazK2n6Mb/cu2sXTO1FmqjDuqiHuqjAZqgIzqhC7o216+x 2gOe6Ile6I0+6IvBWIplWIGVzfVrsq7BWqzDenjDBxuwDedwHhdxqbl+DderCEDUFuQuFEJJVEdN 1EJt1EcbtEV7dGihX/+1M7qgK7qhO3rAE/0wC7MxF/Na6NeL9cJCLMJiLMFSLMManMcFXIJfC/36 sldxDddxAzdxC7dbBJ7/GwZzvtItQTr/q7S91fm/sKwLv/5faSyb3//fUHQ3tf8X/mr/H5I8rfb/ 1lN0/b/S/led/wvLuvDL/0rHVubnf3d1/k+mLrzzf2jHzeHfF6hdhjlFN/+n9BhInf8L/n6Rcf5P 6fGt+flfnf+Tqwvv/B+SuQs1mVtP0Y3/lcxJ3W+hzv+EbV345X9d+77De3zEpxb6z8D6gq8I0MY/ vuMHfsKhpUbIhMxwRdaW+s/MyoGcyIXcyIO8yIfCqI06qIf6ks/YaowhmAQvHMBxXMV13MBN3MUb vMV7fMBHfII/PuMLviIA3/Addq00QkqkQhqkRTqkRwZkRCZkRha4Iityox7qoyEaoTGawB1N4YFm aI4WaIm26I0+6If+GICBGITBGIKhGNZKt/6Dxed8pVuCdP5XcdtL95pQ9f83FN1N7f+Fv9r/hySu 1f7feoqu/1ear+tskjxY7f8tXBd+/b/Svtj8/N9anf+TqQvv/B/acVb49wVql2FO0c3/KR0zq/N/ wd8vMs7/KT0eMj//q/N/cnXhnf9DcqyrJnPrKbrxv9I5DHX+Lyzrwi//K52fMj//31B0NzX/C381 /0vnHodjBMbCGz7YiE3YrOZ/qyq6/K+k3bdgK7ZhO3ZgJ3ZhNw7iJm7hDu7iHu7jAR7iER7jKV7j DYRNGsEGmY8w/kAJ1EV9NEAjNMYULMVO7MJu+OEyruADPuITYh/VCHEQFzmQE7mQB5VRBVVRA+3R AR3RGbeOaYTbuINYx3kuxEFydEFXnMJppD3BOBl90Q8H4YtoJzVCdORHATSBO5rC46R+fWfjBZwF 4bPw6Xd5//79pz+Wt0G+Pn0y1dK2GQQH2zRCDBtbGxt+gn7+v4HS9lXn/8KyLvz6f6Wxa37/L90w WDPS9Iau2Kj9f1j1/3J5+S3ew641eRSpkRm5UQyV0RyeGI2FWIcjuI93sGmjEWIiIXKgLNwxEN+l f4jBRoB047N0472yDYPHqBu/C/uTXVq74um17c4PAj2BNqqEpNq2bYTG6Ca26VcEIBVtlRqNxLbr J7bfBEzGfTxC1LYaIQZSIg2KoDhqoDbaoSPGYgLWYwP24gBu4CFit9MI8ZATeVAeFdAKbdEZXTEO E7ERW3AIR/EMLxGAb0jZnr8H1VATPTtwnIMlWAo/XMY1XMcXfEWaTvTtKILiKIGJmILd2IfneIUk nRkfoCO6wAuLYddFIzjgHxREM7TEBAR8CObrVbD3+BDwJODDE5nqqHk1g0uWjyXQfELUfPqfY1Cv 33TSVTccKLblPpwQ2zOG2I7FxfbrKLbbBrG9tG0VADuxvbRtVU1sI237DBLbZ4vYLto2sQ3SFuF/ LPF/uiEWMQ8k07bFCKzGDrxANGIgNXKjIrqJceOF1biFu7DvqBHyoSU8sRJXcQcunfRxpIuhZmIM qc2geMM/FLfINbeuBO0Hkk4R85k2l2nzWCkxjw0V89g2HMHXzoH5LCFcxZymzWeTsQin8Azxu9Lm qIoaGISp2Ir7eISAruo+EG4bYtHF/wSxDReI7fhYbMfUQdqxv9iWk8T23BSkTT+L7Rq/m0ZIhGqo iTbogCEYgbnwwjbswkVcwRt8QIzuHHvDFTlQAVXQFZ6YjfnYiwO4jXt4gw+w7aERHBEXCZEBWVAc JVEfjdAVnhiDCViKlTiIw/iKAMT31AiJkRYZkRO5UQil0BFdsBN78Qwv8RE/4N6TvIehGIF5+PzB cl+vPjwRfwr8Lu3zpWMBXY9vOA4QGmrbTNte/4rt1UFsJy+xfa6I7RJLbI8qYjvMF1//e+Lr7ii+ 3lnE17mR+PpOEF9X7Wt6Gzbi66mGYsSI/8RB9usm4v78H9aL+/QlcZ9Oyr6bB5XEfVq7P3thBy7i DRL00giZUAQeGIDpWI7tONvrT21v0Kkp7OHUDQXNrStG/f88sQ23iu14TmzLl2J7FhTbsonYnn3F Np0itusSsW1PiW37b2+O2+COZhiOUfDCYtzFA0TroxFiIjtyoxXaYjbmYR18cAKn8QTP8R4fEbUv z4GmaIYzOI8P8IdLP40QBxmRBQVQGD3RB/OxELuwF364iqd4Aef+5DxkRCY0QGN4ojdGYwzWYT0O 4jBu4w4e4Qm+9A8u37/iS7/15MOtP95bes/YYn6vUt5WqIagOV/aF5jI/3W1bfYTTrRJUmQQ26+Z 2G7aNjskttkHBCAdr3/JIO3lI7aTtI207ZMSeVBLbKcufdXcb7QRhpkuSDGKf217DMVy7BFjSBs/ ccS40cZMZTQX42ahGC9XxTj50S8wTrKL8aGNjWnYLMaDLg6+I+4AjZB+gNr+od0IzW4SpBi1/xex bbTtkhH/oCAKYyhGwBdHcAxv8BYf8BEJBzJ+RCa4oiIq4Su+w3kQuRhxkAAZ4YpSKIumaAFP9EJf DMRETIUfruIjPiPhYPIUSqEMqqAa1sMbz/EKWYZohGyYgunYiC04g/P4igAkHqoRkiEP8mIypiLO MI0QDz8gDNcIaZAO6TESo7EMK+GDTbiGG/gJYQQ5FVFGaPM/Gf5Xkn/1IWgWN87qf7xd1zlon+iV bP4P2fi/rq7ddW1eCjXQRmz77ZK2/4wApBDbuiBKoDsGYywWwg9PxfZPILZ3WbGdtW37VbpHKtww PTJUuGHZZ4s0G4ZFjPrfWUBIOlCMsx1inGljLDrxkweFxBjTxtdQzMcOXBRjzFmMsfoYJsbZFjG+ bMW4Ko66aIfhYmwtH6r2AeG2IRbd8Z+2LXxxAf6IIua9fGiNofDCJhzGY3wQc2J8MR/WhTs6Y4CY G1cGyYm6XBhjhNr2od1QOBn8h/g37v+17ZEE+VAFfTEIa+CDW7iLaCM1QmwURWt0wkBMw3qcxEO8 Q/pRGiEnqqITxmAmNmAvzo9S94Fw2xCLLv61MXkN1xFTbONCYju3F9u5stiWHcT2vIJriPkfY38k QwpkR04UQCGUQmmURTm0RTfMx0LcwG3EGM0YEWmRAXXRAN3giRVYjdu4h8Rj+J0ohKKogdpoh44Y ihHwwSYcxBG8HMv4FdHG0cchG3KiIiqhGzxRdrxGqAB3NIMnemMevLARW3ACp/EG75FoAmNTZEUO lENFNEVz9EQfzMfCCX98H1jJO8DBfCl6/7fxebEtP40KbMsUYhsWEttrsNhWp4O0lbSdtG20SGyj y2IbuYhtVFRsm45im8wS20QNxYgR/5vE2LgDO2LDCfGRCrlQDNXRDBMxG77wwyMxnmKLcVRDjB8v HMFTxCYusovx1EyMI20MqU0RMdrfS8xlp8UcllTMXRXFnNVHzFXbcBYfkXwi4wXkR1OMwnZcwkek mcTtqIG2GIJF2IDjkyJr20fOtyOCFKPxn7ZtN2Gr2ManxHZ+J7Z1komB7Z1b0ub10QDDxbY/hdN4 J7Z/brH9q4r7QCtxP1gg7gfrxX0h6WT6CKREGhRAYbRFO3REJ8zCbOzBfrzHB6SawpgBJVEKzdAS gzEMi7EM++GLx3iGClPZvzESozELc7EPB3Eel3ATt/AUL/AVdtN4PZABxVEOzdEBIzAaa7AZt3Fv mraff6brlB+Y06PzdUvyZfK9Xrl5IRP9f11tPH6eFPj6a1/7lugBL/G1fo2AyYGvc1Xx9R0mvq6+ 4uvpwOuSG9XRS3xNta/nWvH1vCS+frF5LfKg9jQ1/4fbhlh0+V/bFv0wG4dwQdxnv0AznX4dxdEW HTELi3EWX5BuhkZwRR10Qj9Mw3Icx318xlc4zWR8OVNte4tsKHyrPEgxyv/atv4ktncRsa29xDY+ JbbzJ7GtM4ltXVNs7yViOx+EL27gJj5K2tx+ZmC7T8UMbMY2fMIXFJ2lEdxQG/UwDdOxEEtwEZdQ bbZGqIWJmIoVWIN5cziewrG57G94jheIOY98g6zIgabwwAIswjZsx3Xcwht8QPz5GiEBSqMs2qAt ZmA2dmAn7uMRvuE70izQCOlRGEXQCm0xcIGp4zy5Q7wnYpL/Uxeg/wrJ/L+p/K+NxxwohtpoK7aT to1uiW2UXmwjbfu0xWCxbXbhBG4jDm1RCmXRFf3EdtK20XbcxzvEo62SzlFzQLhtiEWX/7VtUQZN 0EuMJV+8wEckI5bSozjqoy9mwxtn8W5uYJxpY6wx2mO2GGMHxdjSxlUqMZ66i3GkNkXEaH9tW+wX c1k0MYdVEXPXCHjhCF4gthfjepRBWTRCB4zCUlzCA0RbqBEKoTy6YDS8sA0nF0aitlfYx0aC5tYV o/5f2z8NwjyxrfdhP56KbR6N9oyO3EHavr7Y/m3FfWC4uB8sEveFu+K+oFkYuD/8K+4PHcV9YqS4 X8wT943N4v5xCIdxC3dxH/kWcWyIWqiLyZiGAziEh3iEGIs1ggtKoDS6oyd6YRpmwg9X8QKvYbOE MQrSIgMKoSgqogoaoDHaogPiLdUICZETeTAJU/ETdsu4DUmRFTkxHjPwE8Jyet7lhueD/eGMgCA3 BXNmwIfAcwdCev7vScnr/BoOvI6Jxddb+1q3DPJav1hk+Bp3whjxtT0pvrba11X7mkZBQvF1LSq+ ntrX0nSMRZqwspr4byzu1wuwAffwFO+17bQkcF/X7udl0V3c1zdiJ47AD/fwQtz/k4r7fXNMxhYc wX28QNTlat//NzdMFV37a/NRlOWB7RIdVVEdEzAZJ3Aab/EBiVbQxsiB3CiDfzEC/+EoTiDmSsYL yITM8MURXMIVPMFzxFhFPkExlEBN1EE7dEQ/DMJ4TIYXlmAX9iLFao2QGmmRBdmRDwXxLyqgLhqi OVqjC3pgGEZhBuZgMZbDG5twDdeRdY1GyIZKqIphGIWN2IJzuIjneAVhLbGAeEgIV2TH51dPHjx5 8Fn5l+I76/N7yOYBhfq6dk+IfJL27yS2/yqx/bVtn1Rscw8MENt7NlaJbX4fn1YEtnsOlEUTTMIK sf21bR+as7z+T0/fMnvDsBif/3VFjMPvKwPjMJMYh3XE+Bskxt0SMd4O4SIC4CyJvexizFUQY621 GGOjxNhaLsbUpdXWl/8j8hAmSDHq/7Xt8RmJyFt5xPzWR8xvk7FIzHEXxdxmJ+Y0bT4rilpoiW4Y i/24iCd4g1TrNEI6VEZzjMS4deoYINw2xKI7/te2YyGxLauL7dlZbE8b2skW2ZAdcdfT9kiHTMiH giiLimiEpuiFvtiJPTiKEziFi7iC27gPf3zWPq+3RkiCdMiIvPgH1VEbbdAe/TEYUzEdi7EM67EB e7FPe38f7o+hGIEFWIQt2I6TOINHeI2cGzRCLuRFUTRHayzEYmzDTpzFBbzEa8TYyLgDurWsTE/X Bs73Br4BqJv7NZ4DvhUQ+CbfK/H2B376NVFiBunMpcd6wV0LZGL+t4Y2FudgBTbiBB7iPZzE9s4k tnNFsX21bTsUa8X21bXtFbFNte2ZJEg71hbbT9t2Vh1fYdgZhOapgxSj/C+NpWViDB3GF207ISux UVaMpRFiDG0XY8eW/T8NKqIXBkniZWeQOIlGjERH8o3q8b+2hOZ/2/QoL/Ttr22PJxsDc9dy7MGE zRoh5RZidivj+G0aYd52jsN2aATNLsZwWLybYwLk3ENeRLq9HJft0whj9tOXHOB456BGeICyvuwj hzhWQ5zDPOZw4Fp/Bn+gwcBeXbEpjNZ/0hebdIj1u/217W4He7H9V2KVuB/sE/eFSZgs7hOpxf2i rrhv5BL3jwXwEveTARgo7i9RkQ8lxX1ni7j/LBX3obPifpRb3Jd2iPtTBnGfWiTuV+PEfauIuH9l E/exR+J+Vl7c1+zF/W2PuM/FE/e7s4cN15ksiVIojwqoiEqojKqohjpHDNejbHhEvyblBEzEtCOB 61F+F77y38d3v/7Rfukqnr/7GMyX8FS4d/vetXu3xW9PhctnL+uaK4Zd2yr5BKGWxqZD2Sgae+0/ giZH+bRCh7IEs732J+19tHfV/sz97Ojpo5cs7/x7KCDYa7e0j0ov/PqJbRdB+9j0QrWgr4n2/7+K +BpI/3/l1uC8huv4jC+If1QjJDgauNZmXlQ/GrjOpnZtzS5Hg6z7ZhD3Bre8lW68VHa3Jybv9ki6 cd/khuk16SLyhq7YpSGabQWbNILDr5+ch7W20Vb++q5JIyRJ754mrW3CYZ9/JhrGDakD780DE2vb cc8Rw/VUr4rteuOI4dqq/mI7fz1iuM5qPLHdEx41XHM1t7gf5DtquPZqNXG/qHnUcA3WTuJ+0hX9 jjHWx3hMwAJ4wReHcPiY4Xqtd3H/mHZu6c3zr/x794b23/OntP8e3KP9d9N67b9Lvb4Ks2dM+vXF 5sghX7UfgtC2at9fMRbHru1/A+oViaqxYaO2NuYE+6hR2toIW9/oIod/f9VcCKzhsQc8dY+91j/I Y7m1UQfdrXFkbn3fSndrxX7Gt9o30t06ua/xrRvddLd69jG+NaCw7lYXmVu1Ow0VQm7t6z0Y7rx2 ayWv7z3x9XwAf3xGvOPEOBIgIRIhMZIgKZIdV75WbuSMN8tumE6BYXgLxS4D8W/zK/6T3Ze075dj husex0U6pEdhFEFRFENv9MFETMJkTMEl+OEFXuIVXsOVNs+KkiiF0iiDoRiG2ZiDuZiHEziJe7iP B3ioffxJ+qOTkvWUGe68evqZfz8/Cu7fR8I9wRqL7mje/teYgOjePUQX+8+DZjN97NtrH5Vd8brV 0l9o2d3TYOPPg1e1mF20Y399/EfJI0TJIUTNYeOcwzZWDhunqtkEDZJWtRFSeJ/NntL7TpFU3l4O qb3z26eZON4+7UQvh3TegpBFCPbOk3/fObv2V+jubHzH/L/vGI0nij5xE8/+xwd4OUgfkEHpndVn VZ81Ajyr4jtHn5jSJpjQMXxm7QPC9tmt9nWOAM8c4j/DPVWSN9/sBOF5wIC6TwrvrFS/8b0z9hXW PW0YX5/s7RwEoTx5vvPgegwTEgjHub/wo9fcS3U6jKpYLeGA0wVyt/Ss3b69a+mrE33T+4+MvajS wkqbhh+IuTlNvtuubdpNWd/6vU/R2SmWJPsyulKWLxmbLGxfY0WlrNUvPpox7NPyaW9v9HxVxPOI 85xkG1s+m/d+z5ki/rtev9/zuoh/8uG2+6bGG3K/7La9KZdWDbhWfHfxWSkf38mSc/CXLKUH/ZwS r/nF8icaLp1yLG2Ji3u6LFp9cM7yHKPu143jm7GUTxnfha9GzdtRsne75a/Olv0SPeqjdQ8D8uQa cPdD6vHzvjbq6n2ywLPsVQu2OnGt1vMX5X/sSv3W7ka82OWfnz8+r8HW0peblWzbuPijkbVG9ywV 4NO6zOvxLVaVWhf3SpZX117NbjYk8fssMyaO21t9WT+Hvkfr9BkxP1eag9OyOPf4t32xDDdzu7yo Pbx9jtZnog6tX+ZnqV9/RxbHGKuyR9/x78oLr6pquiVt1bDwiP8Ktuyf8tSRQU16fVqbpuDVGOvS rsjge7p00ce1B/jOKdqjVKf39U4nz96q8sZZu299feX1evyAd8keT4lV5/uhQmXKfZsy/uXZaifz rMt/MZlPt812wyrl++Sdf/HPjPeq9vQ9HW9og3pNvTO6HMoUa+SONJ7rEq5xfuBxudepZPkTHX11 4f3GH/PW7M4S5VkUHvk4n//KH7tPNY5SaIfvhzO3LpS4nfX7g76FFgx9We/V7Fvvx1fL9Xp7o5e3 /VuN69jy587q/+6u/OJDxh++pY59PbRrY5k9G0dWv768/4tRhxK7eh73qOPqedBjq+unsx5rk3tO m7TMO32VLH6tsnqe9HBy3XLbo0evp017tPa5UmTMTZ8recccyhp/45VyYy41WON30PN60hcfN3n0 v+LRytXzmMeMlS1WNXvm+7ZAoum7li+oWHDHpbuvPcemTN2551iXfB3G+dXsMHdss/wrDg5x8G7a rNYH2y+ejX7697/U7XXCK2d3Z0mVpN5/H7qX2vOmzqq3M5eWabYp8eDXCcdvLVzh1pGEeTxif3Iv WKVvvER9ij54+KxkrvPN1p29cun17YeZ53w76Ndg0psUKb/VWZ2p7pplHiNmj4jSNt/ei7nfxrg/ 8OH919Wq1Ft98uPXgfdTpH+bIIf/y4y11s5ckfxsQLyKd/17zLpWsm+ct9N610vys163M+XeVx1z KP+QePnHtG24/KNm5JukXXYdqLSr2fdr78ffLnu3TsbHC8vUGnNhlU2Gi72T1tz6pV+6qmsbe2R6 Xn9d0Td7qqy5+3jX/bquSQ8WjlbrTpGllbKXKlHnXZEtSS/3Ltr2/Jwukzot6Xc/XqzGI5ocjVf4 9drHDXYWfZ0/eiznVPMnZc6Rxztqh5bRPFommD6rz9gcRx4umdRp7jf/Gjc2NR3Ze/DwR4kOzzlS 9lmSB91eLXiXM/aFmHVuH0+rzQHr7AXBPvHZo5Xs8q8Zl/z4tDlvP8QaEVufAzaQA5LYCkLKLS2E upPSCf3sA3PAoTpnOiUpHXdAQBafJKujbC3bOeHclElH2Q1fVepA6ZxdVtWP2nFJqbkuzw4XGl/n 2ovZN7skOTi8QYHYtTrf9YiSqstxmy4+cVMtKVug9IpvDmVHlYxZtYtjzfeP1l7uka9yhdmHGrUp 3Mmz5S3//p0enRofr6xd6xOfu9lMdyvqOD1K3g25nr1/1vNw3PoDV+/tkTvPvW4OBzI0+NDhgk3r 51eO3r/e+UbcsTX8i/auVjPvzltR7W87/pN0+aA1NcqP6jy4zLF/2q5v5TZr2fzue//9Wrnp90UL 9389njnpgQlf7TdfmLjTd9eqOx7Orw5u7TNs0JA72eeuL1Oz74CLySeX14y+9tLzv5fF8le9Fmu+ YwKf+Zeib7PtMDNf80xejbw886eJWjJ/yddNE3+o/HV0jhirfpY6udE78eH7qab9Wzj1g/yVtznv 7Z5h5PoZRUd97f584afLi3utjV7oTabCmd41++m2+GLPFUerp5wXs8ql/I7l2macsWSE/9S0ecr+ ODdgUsHmAW8T30maWOi6ZKH99hZn4t2IZ5N76L5bXbcfyteg4sUCubOeePz59E2PljUuFrkdP2vL Bvn91l3Nf9KzTULHwQfPHI/24HWtbS27HZndatkYO98TDy6tvrZsXxS3brlT9N7QO4dTz863env0 LFy0T/sRJZ5/mLzsQEB9mxMfizr65jhcpdTnny0uHO7qP8t94NIE3g0HlrnSwfXYs/Eb/h2ZpsXl iaVnRI97tWjWvgdqvBrQc0jVe8tvDHUauqLKjEbN3mRrcdC5Zsf2a7wLX99X2Kd9txP/bK1X1b+j U/SBOfq+GDQtZ0C/y3G3PJ7t3CDBzPzLOvlc33Lfe8RTp7mT12yo7bpx7oo5Q666zWy0+0Pz+Wcy Z0kydmetM88yvF6T67/HXg/uFD/4OO+rgA1nPCvtjec8rc3LS3V7f3ds0O/9u3vtSp+o36tZx8Gp 6jS/9KbI3VpFRua1S+4ydPbJ54OaTt12bHQqT8/5LU4sbX80w5gmV17EvpctTsdo+Qof3pqkR27v YtNTT+xT6qpnu/l7K82u5ry6T8eU31rWmh+r5eZnX0pV7pWz63vf+4uX/ec0sXCxtJ9mL6laf3nU vRlTxWudakxhnxWDktY6nevCEbtTUQpH3RuwZWyxvYf6v7u6qPHlOGNf50m6s2205emG+w8p4DJ+ ePaz3b75nvcIyNvjUcNy845OSzNzcE/v6GemXfT59KZBuc+lfuSemqGga9OG67xup5uZvtD8NMvb lF9Qr8bXYcsuT0v02a1ApRpfc86+l/lTzsfO5y7smZyhb91lGfzHNRla587lZnsmvxuXJEH/Jn7z Ny2ePOrHmnx2xdLF/t43YY9E3/uuqHRt8Y2SCxaOzpQmSrwE49rsanfKfV6Gvp+TF7ydLEvJ53MH 78/9XrOnZvqn37tN3Nni3j+tLtw9effV9BVn9qfo/G+iUoWzD+1SonqXBCmGrPLvkj3euukVhq8e c7eJV/EfTm0nNE/g+dF5XZMMkz5eP/jxuXv/4p8y9rzrv+JeuyJR4t1+4tQrwzP33f9+ylhr1/Bt PeNU8xnzYunoRjVTvqy26nOj5/tG1o+duWNbp17ZXwfeqZ+Xp9fkUaNrNc9ea80i2zYTqh/KUN6p U9ZyK+oOsdu1vLv3rTSF1qVu/jP7xlIJ3LRZy8dREHz3vW3accCwFysf1G8YsLPVp/HJ9VnrMiOV jPCaUkoY1Si/MNBRzFpXY5ad2irpvrePe1d+X7FO7Y6ZsxbsMMmv/o7EmfNWd32XsfzjjIvdGvc5 0cBz9o6VN8qUHzq2TKIY1ROfaL3wfMqDKRu4lTk41iORY6ZoefzqdnDzc1wdb7t//9e3Ou04X71d sm+9FgTsGjjf379vv9f9+zXJZDvc2zVR9mG1Ksb9eqTJmJQttgyptenh6HTF2xWpWb1XsQH1T/rt ad139MBNWaedWdyv3RKfmte6zt0yt+PbBBNKDW89rU/Fc9dqjH396Na9Yn2z3E48sGTA1691m+Wc vvtal5KbHtr12J39ypVlx9kLH5SYkabK1KkzH9+9ma2UfcLVVRLvLrd0Ua7jo0fPSzL8+s55C7o0 XP2hZeHaswpkbpL+9dHOzSqlbPeh2YRL0yf9sPHYvnFb2r2dh9ZN7dHCq2kzX4+ePqu3udZxncr+ s6rljyor681sP61PnjYv09/fWW/h4I9vEti9/76704saz1O3DfDPe37X2jLjB6RucfXdWGef4rOP RM/RMOqcbVnTH788ttP9UpuKNDuUNOBe3AYNX/SN8t/W0ts++J3KfD7p1SRJn8/L2ezhrsfrzs9c XnNlg9UTkyf/UvbJuSJlpx0eda7V6zMrsnfb/nFjgrzvvrt1LZK5ycDUlxeUmdVuXttpfZas+LfE hIJ5u6/rWjNNsuZz+3uVPf3Fd9LL7q1m/Je95sWMp29XSTInfZrC1370KdxuTZmeP/Yf/uL0X+nT izxmXK/24njPMUPfxWjaeOmtJoNrF2gwtvDyWasaeCa6Oyn3uF7xCmSt+qjWrIZPum86njTvu7FD XG++c0pTONfRUTPmTOpdem33ePEHrvpePtnU91mr/Hi4+XjGE0e7rarRo+3S0hPirl165Ge3h/3u dG/+uKDfwwKHyvSoPmtW+scP4hYcM9rXuccA+/tL/OOvenUsWpl2k/12jG10aF2zrd57vUfOXJAn a93Z8Ufv/m/38N3jTh2M7z7Gu8WVkVf+res8fWS8ZguaNfFo0rRJs9vut5vebvavz5QrE644vMjl GW/n+Jvv6q1fH29VR/cidTP4jd/cNGvd3H6jLjXbXDdv7eG1PB7WzVR70EOPenXTTx+x1KNcXdv4 Y0o3y+eaNNr+NTP3vYryLMOKFH5De3i8rJvEb0jeZuPqFqk9plazWnXT1R4/zcOhbrbpw1t4tKmb efqwdO4+dfO0PHjAx+Xk6C8f2918s/ZjnND8wgt9HD4e7ONdeU2y3AOrrN1Te0W+XMuGc3viMYdi e6d1jVfhYC4fV9cEWfaV9+m6JvbqA6t86q9J3s53tk/8NTHaHSnok/yFo9+Ymwft/dOsXjKgbv6W Bxf51HW1qXCguk8e1zgnDnT1sV0TN8uRzD6Z1yRefeiZT5k1idrtv+btuSbO8/0d3Xd/f3Uzge/Z 9xMfL4jVfWWU430vZou3sOIYXw/v/K6xKhx+UbfglsTd3LO1j1N7RC33696N6sbYkqLdvvHuR3wu XCnwIrbf8EYHO3r09A6YuWlm/NYLB9S1j//fIfcudVNPH3vVp3v7vI/2NbySfk301fu2NN3pnbh9 Mb9ByfaPb7bcp9uVdGsOXn72ZnOJzbNWtmnlHaduHE9NoUEvD3k2u+6TdaZTlgP53K9eSexq12D0 Uvf3PtuvuLZPnC/RnGEOTeO/GJznZZU211JcyX7lTF0nz+SFhs7bN9u75BWb9tm3JLk+vsP+wnVj bbE5cdjPPdGV6q4OcyacOtSy6QXvY3Xr7vUrfftajt7xCw1PdtC5WY8rRdvH3BLn+ugOh8t792tf ZEv8BsPX7pvuHs2nV3vnfHZzRg9vet9HWFNl1qetuV7m+5TEb1yj/dk8WvnUuJLzRY7aI18e/ORe yGftlZZr7E8c8WvWzqfWlajto2xxGXPkkXtu75V1E7a8tTZ1v7VV4yl+PaLtHHHT95W7f85j84pU nZXPZsy+1D4JXZ0r+E7OWWj6+LWHk86Mdn3YtKbxruRrn6D20JdHEnunudLlRR5P550XO3nmbnq2 1T9nZmfJ1Gxd2mk/au8PqHwwYMT+fl3j7FvT7s67tw0rDDyd7+Yi34L1Fpa+4LVx6925x94EOE95 vqTV2eVds2993XHt66kJctkefN13yI6AIWUGbut/+9KjRGcubH249EGHGVmyfmo13v/Ek75LD70/ /vXWwlOdPVfUudBznXeF3a/WL+s04WJAiq/FDp7bfeT87Y9lvo4cU/r0hEYdW40/9XBLkQF94xXr 2XHXtx773v57fYH/7tLedR99OzmrVd/LWw7MqxM/+96HX7ZuHf/T9m7c1Ju0Hdd5OqVh3pppi66l ueX2aFfcVfky5r8XTd9x+TLUnsYh98xmOYU3RZMKXuIh96HpFVpPrRP3yE//imUypC/a+lz9hZN9 ox6aXDVG+hIu5ezLJbhWesuOHCnzbE5c8cLn4qNSZx6azTHtuWfR67vsv5clRuxzVxOWeHM947Ta LqViLRk15ErpaGvvfZ4T8GVc+vR+h/MM6Pz4RrfTPwu/bjd39NIrKbq4tZv6c+Yq30X1VvbYbmO3 eODE3jmbDB/9eW33dxfn9l6zsWG25cdOzrc9eeaj7eNdr6s0S7H66E2/fz0bvH8xPfPLEW1frHrW vniFl7aLx/SOXS/DDuccc/Zt8biwau/mchMuLrx9aeXO8s/G70iYYGbMlDtHv3Kc2eDWwJmD+05q N3NwpjWpXrX4cmNRYo/5RR2L2n31ffWwfJH08QqsWNGpXb2ADvtrDJtz937Zerfjtqp9btPHnZ96 JNmU0zde734Hhvef61EtW5l/3m06furT7HtD0r9rlPxn1Sb5+tfa0vxcggrHZ+/pdGvbuv7d2l3v M2/pjqP+rbPETtG09KK8K961y1Ejq2eJ23Xrr/UsnmxLk3lb6pS7vtbubPRvXR5kOPfT/tWSj/ua lBqQ6HvKbVnuOPnsHPu99LcPvQZWmzHyU56izReM3Zwhyu0pM6fX6bDY6WW+5EXqri2/9lzhvO3G 1/8w+FqeStdrrSpyNu43twdtPiTq3ObSgctpOpXaG/tG5jdZfNr57klebPOt26U+eC1sOyb+8/+x 9x9gTbTr3vB9TUJHDF1EkdBUehMUEBNFxA6IgGKhSZMmXVEEQWwo2LuCYAPBgBQLahBR7IAFFRTs qEhvKkLef1Dv+15r7/Xstfe73s1zfN8ajh+ZSSa5ZiYz5zkzmesa/222jDsvFO+H3teK0N1SbBpX uydj2sU/3qsbx5m2tKHbd/iF6Na7uWeuX1VkiS+uqy/rdDszKYzT4/Yw9uO1yomB+xM78j6Uz6ZW q6ZVj92w4cb+TpcTngt3nL8/mjsioXTuoY/PvPTGZreW3Ry6+31RxdV9l+gP+pRurixLrrvZKh6y y8T5W8cEx6QLNmeabJ64bDjfukkxTfvViB2cXIfWhu09aSzh5t3l3G+Xb9TZxSammC9hPOZsvHS8 3JzD7cw/arjlxSq54llaIX2VpF+xvfEjJ6FYaFJrpH1nq/Wa7dptEV7iOSKuD1wjr9bsyDvSf6Fl yaoXIfVC38M2nTqfY2xdN6O93lrJ4rSPcERT+lX1iJNpG18Z30o5xhLSo/dvPz/CL+Wyv5LEZU3P TE/5M5Nqkz/L9K6Lnf7y++G87askzrmEm0QKXR22Svn7pBVXXlWsLOZlJL83z2mPjdklk+HUHcrj zTwV+2jSy8dL574IeplQt7GCUxITcV152lqBPvcVL0ex2vttL3uOWvijR+rUvpWWZU0aa5VXLTvW 15pwi5OmLPC0pe3tvnLf8Q7puaOr7hfslov5Vu//9f5uu3s2a4Zq7nWfzd+yjcUIcRttvbq/xPBW iZRs2pXLh99/0Pxzy7bAgXMYtubt22aR3AOWhBL7uWVfcZGwk3sqN6nhRXnLIyK3xW1q/Hojxff1 sQVvdg3fk7VHIGP0EUn1O6cn3k2Z5hlQPs9i1wTD4cb9J94qmOS83Xoj01xpR/jh6bPHvHI9Pdpj WiBdxfGkgqHQ6T1ri1uahFYxZat7vM82HG45HNaz1qflyuqoHZpx0wvXS7+b/3DtJN9Iw4LJ87JH 10paNb3J6LUwNx+7IaDypsGneQs6F8jfbxBuunrhzS2l8nFDjZys7XQtjluNlD5tpD77xN0Ve0Yb Lt9dliXlmzFhmnXbCrk77ncerLuzz6LsZmHAW9tn+7SfPyifsPuu2RZGx9gCqXkPMt4pnJqhceru mMMqLryzUgYX156V2qS5ZDG7pmn8hbHjh1VfXO+xtTDbzyqt75BE9vUy1Rsl05LWeR18NkVG2yiv fv+zUTLa4/Ns53zJ2vwyzNO4zPZi7pD5D06cyFirpyvhGH7DUlft5X6nOfvkP1ZPObFN4oviiGcL ZXrzN18J9jg0J/txmfyhZzoyI/w97C8k6Ons3lhsYjFCTeKd8sW3axa82C/R86xS8eWawDXPy+Ye fKYiU7vcY8QcnYoy+f3PVsokGRsWby7MX7fEx3N+w4v9+t6HDb/PPC9fGhtSvq1kZLh7jU64n8xL l9P3TPPWyCzy9GjZ/2ySTG9l2YMDz7izs1+WlZaVvHlne1OkTGGWolP8rEOqY57vN0s9aFy0d9vF 4B9bLwav9rWsv+nyMXBP+NK2m4qxU1zfTtp9K6L9bJ38ZNfjtQxOqfJZmSHflC/WSWW7nniosOhe Z3r8iz2di7wWP5Eblt2iN21kUtkyjrbebVfrxLMTlK+4xkY2LVkXvTsvy8Rs78bPR8mjjK6crm+7 GY9oivfNAhYYax4adrB6SHTOrmD5poZhFtZOUVvuHds7t3q24mjx5wpLbB27mqwcOWFyR6RzrNkp lU3NZz73Vl75HOxICxe62vni84mLGt8afU+He6n0ublniJytOmT6Xetl8+bExqP1X0Qec9qL8o4V NwhZR11dzlvwfV7ag4ep3l4VSUf37z24Zs/oA89+qPpsNq642G5x8MPNHx99Lq66Ky7Wobn/lH1w V2ujg+VnO/GcPceGupxpPDZq7TJB1+IHatvPzXLVu6e/sFHHpW3UmEtVJPQd54H+4oOLFkwpN3sy 1XiWeMdMscOJN8LXjVlYFn3+8cf76xaeKHxp+UWyOrd5zb4xx5NtF6oejVq1bWXd+/M3OvSilhTH vF59ROaxZpXLgcU+ORqnbTqUntWYrFxmnlT9QV73RLRo+4Irfa8NFz1fVjDHP2ll0cODOft6vQUZ sffuXo73uFcic3naQkOex55dBzvlj6XONKktPqO344N2heP4jUcdj57RS5Vfndt896Xx3Dc2KaM0 lKMOc9feSXG8ninns197gsWabcY3lMxu9Xjp1z6OHGoXnLvkSnKRUDSVO+z13Wn3RpZ5q5Zfy/ny atHhzWGPRl4te75G3vY6N4RKfW3iy7GKpT+L/Nqt+oHpwciPvPLA5Oq2vInJZp6Pzc+krbAOjxQ9 umRusmzY6Pd73109vOgwNyGjt1D1Esfv3NJHKy7dtjpuv+GWkuiOXqPpAQuUqSylwoBpuo32d80f txs/btd5cOnJml1n7FPzTz/y+Xp+aMQZm76DKrXute+kGaVLpVRduHXZR1bXjx27uLpk8qjCETpH CxsrtO7Zi2rdOVloftvepTHQuaB7YeyiotNnbaniaJuIGLEyKn9D8J6pzws+CDjnOFpWnzracDZ/ oWlEfuOXPfdffjEfY39k3UTjUd6jlxjt/6GS6hTfkZ1wdP7Q89zGQ5vqrSJ7/Ku6jL8rH3eunbZj ufRxeujZs1E54baHf/CC5/aPOlz3fkmnmUvP4R/K1zK1k2Zdlju1ccl24fCXh3SWnz7w5uJzmnzI 4pTzJd63TJf06CWFJo9PtaR7hsTJVDmMTHWb06Mnfqos3yHbbYf+5o+ayU83n1wdtWT33QZfp+wk RusynXKZ9vW+l8YvPLwz9MAZjHViUolD2uJzj0WrwlvOlTw4rbpHTid+/tDoO/PyZj66cvuN7mWr qxqm4k5RBw5b2ToWyMzDk7RT1uPern7AXjBkV2TnMk/W9Dk9QknsI4mlYVrzdMfkNOW7Bf6IH3or tEbXevvBZonR9ua7rs1fF9arIqdnMX/i3Nlvl504qFeRtdBo4f09CiYMn+8635yM3m85ftdvRuna 1t2CW21nrv9hr/o+bavcnJY7zzSEQ0d/+abuc0Nn7eT4d4LP3SZrLN3R9TFztjx7ebRtz9VGzR/2 Om86r1p9HGuU8uj8vMnn36l9V+y1ubJ4w2WhXu1XEq2x1uln7eMuzU5wlBDMTGFquykLn30fFeWz 1m1CrkNx4908u3lamQ6jenJYW0ec3qKYufPgxwkvT6h1xt0xzFKTvVeuuVVb8/AZpr/bUxqP1q+9 qZfWVnjrTFWHMsvzpHrWSackhX0haoGvRmu9Ly44qLx9V98qE+EwzY1tQkMbjG7p5p6n6kV5emVN U3+Yvgt8LdQ368tbn8Ozg885blV6ON3h+OaH7/Q0btNnSsbO3ek2d5fBUdXXX+LuxR+R+LHq6zC1 5lVlPmr6sxQ7ObkpqSFi96X8FbgVc2vK735kcqfarBR1bFU1l1go0ava6vJVv93l2Yh1wfHcISGH JLlSq/y71gQbzD0xz/xz27C0fsM6rd6vUaHbY3VtvppkvuoKVTyn2G39qrDV9Z1Sbg+pZ/Cosiab H6PeNUnq1o/Y+si3eMH1C/ItW2Ib9DOT9atY32gmbau+D23n5u5ZM2PSPMZzgWLBldo/Ajf5W68R bz/YibJG2Zw/fU36Zsu6qpZrAamL061C1yXfXvVdst3z2ZOSilJXiZvKs8Rbnb7WSj7d8lX+ncmn b3VuE0dtZfR8l8vV38qZLrBkj+QllXWd274+VOqMVn54ktZWJqFSvCVuaorWqK8KX2Ukxwu1td1K quq4cm0lzdphl8bWR440WweW+8YtH3RMtobNF+AKXBzZrfVq7lfnzLbcU7SKuPp1F4aU2VrXraxu x5tUT7T9WMpd050YsnPLnmVdx2fbubc7yOnkO25fZqW37oj4REb/4q4hX2RfybxKXX9BdJPt5Drj 9PestTcnhGkk7w2fpbDx1rzh8cZf7FbNTX/fYDTzwwytd7LPHq2riIu9lL1+yZAfjl+fqjU7lg1T Cz7h+22p++GCKek6B55ErVjKTXoUe2i32BnXLUvMNIaEXtC6YfFIaLOj1/ZFbsH0qzL9LzfVbv4a eKtW1eWqs8IYrqaSvGHQzVsjrr0S2r9YMMPcoFhsw/iSAqmth1S4G/vIhXmRXg5Dno9mbO+5MlBO KEfm7QPn6M567QcrdGr3VMd/HeKvW3T3qnFum0RV+bDJ4odPaHwTTLyb7iN39Y2Oy54zfX0q5mrn J6Smfzu0lNeyVa6lt/zx7Elp81aOeNY/MzFsXXT8sLGxR4+vWaV+fInEh9Xtnv0bt77r2HnvVJn7 tWGnuFm3Fx/70Kb8eGR1Z/OHUnZ9z5In35Vfmtqc5e867lEkxMdqH/tsq5nYlyuny+r3+bo9XPbn ruNEIUK6cWD4cXEw2f5qHPFU/Lnr+PiQ+Mo5zvLlPbFHwlS7Pm6aaqKpenxUzMqtV08+HLsleqr5 UiXzeY4zRU4cH/0kU7LghIuu3PzpmunWvqKKWZnHC+L3RssN7zorOUUq3aixLr/7qJ9Nb8TJA2vq 7/fktGT3Lur9kq/sn3Ol5/5Fu/GaXjf67dsKLWR5Zjpy0/3lPklbfw0ZHrFnYuoeLU1N+8I992te Lq4L09h+XueWp3Z5jUnoXU1N4a4hrtdzRmdxY8Rv1MhL5FW4H4+RfPtl8ezCp+7HrsgeiNSKfPYo pOboEFaD1+PInZKftlrbXr3Z0aD5YJlO5Em1uzNuBPlozjVvtHv3rrTbYtPMtQ2SH33sHbmLxlZy KMf2JGat/sEth+vCHw6fWXykavf72apXU09OCNOsW8i2PHJD9tNl28Jvn8tTbWvDNqfaHuhWd/FN OZnZbafo03NyR+S48+Pja1/GTWyKWv1RSeeRlZFzVPbuns/fHnl63V5wzcJpcrj40/dVtExpidwl 3XQhcYuNKulHbtrlNZfWJwZeX+B+YP9oHXqLyKL170s/uBfmLgsYZnqk/NmTk+4pC1yvm7nL2KsH TMyaoDdiY+3IfdtuXCm92X7vh9GsUtf1Gm1fPrkclW7UVnj/8ZSG6GqZfKWXWT3r718zd8+c2HDJ 5rnHkuRgpZcdVqWmr+NzF3cPca7dou1hGR+6Vu+ujSBr3/MvutHy8eufGGevq1K0j1tQu5Ob69ud 6+od80nY7xpba7v81vS+0mn5NpdcVGPUqm8XLH0m66IRIH9CZNax84n3Tw1L1HVjVdeI5OmNtnyT 9KmitO5Ur4T/2AApQdFF0+XWn3i4qi3h4kiJs6Yb5262mX2Kk3jF2lXkEFtZbMQsZZERcx8lSrxX CC28Ns4629K3IPdBZ3yu9/ErVzRviIobtr3eLKvk+N3WZk/frtnhc9O/PDV+VJ2zaI9XutHNQwea nTKaJBU9ex/d7faanZeidqNu24lu72XPD4wco23ndupa/YGN5g9GdnfIdr5qFOmf+HzGdZqPoNGR 2QFhpmoVz7etaZigZ77P/svXRylzReQsoqqsx+xsP+J7J8zD95DxfqMjAi6vtmbcfrDsaHHm4+sz PgSMS/jc+iSVNezZLr8Uy+RzXwRcljNOylpsKDc4WDvsdtPlpIlNfT0vOjhXed0jZT0+qMZJe71I aj2Xe3eaxcYZHn3yxolNH6RCC4MNnLOff53+TGiNToBGwdPs7WtkbuUVV7zLmuIuvsJxgVaBzwNr ibZ7sr6MuTt03laNMj2QfuriWz/3lsk2t6dslSkaYn7QqfXwxQCl8MdeB160m3SbX9q3Kr3pGqss WlGwVG/6VdF0sYnleuLp/qWKDx3de+x35I41b/o4e4e+i7O5SnV/wd2qtnNNzs/Guqh90XDR++J4 UOWLydLXi7vlt8maOrbTG5yjnbJvP56zwChC1jSh33cB3f3RR8ZJ+diMbweyI6ZxlMJne68YFyhn uiV0vcSx8F3ie7fIz/LzaAoKnVZwW3a8B6Nypfs2v+y++gZyRfnA+23fh2qxT6jZaagt0EhPVoy7 mWXskiUS7txlMFXQQ7V+/0mxx/u0bI/Y1zpKnnt28NjRa9Jdo+scUt2S75TryM02nr9o78qDJz48 Gll4pM7hRsHUl0Fep8dqz5I4X3RmmbZtTp7Y41GzXl+W29Qeabm+Rso3IGracUsS2DR16vPbm4oe fftuFvvAc+2OJrmxj4dmtHfHhNd9Zq/OVnDxtJx120lV4vzSU2P9TV8G6aZ7uEyu9dPlMEaMPWra nrXb6prOt2fTU93onDz/T8Oz00RWNJcHmGcsPaXvqHoi08cvfcsxlSx6hHOP/Sy5adtWMRbYLHkX cvtt27eRR0O+u0aZf1pzPrlMq3Tpdd3Sm6+d3ENEZEzjGkqffH8TmRc5xcE9sG2M+5yqpc9erpy9 IGKibraikFhHua+7/GiR4tPe4trzW0QtTholxpwyFavN6BavzUwW6Z0nJ157XOdCQELW0H05zq9L jR5blTplVZfuzVRwn/UsSV38XM9tkUznxPsOHYknsjRK560crd6T2VTqndmSeN/D9nHNqrwH75Qu 3/U+naVueFZxeHec+5HE+/Ntt581W/rM4rPGQ939KgHJ0c7PirUcnk3cM+eSzarSh49F3Wd9O/76 XPj74IsBe8Rk9l7Le7P8jCM9b226i1jv/MJh3Ymf1XScJWSLZm2TK7KdIxs59b5M5JQr+l/i70g7 HTcVD9s+Jntisqj4NUf3Y3HLjo4W2XkvjDVlfUTJkWj96/afz1Ej8/VGbJEvXWpt4R6cnpHLmPDA a9zWonkFzLrXUQaNARbuPieusi/5Hg0ZzthcKG1yrkvsMXtBzCXHBVZZql/ctXZcLTyp+il4vLlW 9hilgs5L+TOeMWuYAeonFppzTokdYnNEVu+R1r3SPESy27RL3nRjjdisEx9K5e2XuCdNr+j3yNKs Dg9dn5Pm/8bqzMfcr0+Wf3daMDpGK0DJYV/MnV6vtpFLuYuLdiyVLNrxZpvp7OznnRdyR35W19nY bPhl7nXaeq9d3MyL5NIkpYTUKsOPRQFSResmyRQlP1zv1X70hteZb/fen3PsjHK/+8nP/e5HUXe/ x9LRj1XD69KEbxyc6W5uY5ebe36G6OokS9c1O4fOGHqIvTpx25sJYc+nu6gFSJafv/s9LGjFQsZM 6eo9S2WrD34X959rK1p8yFz0jE2K2NuvUk6bD4oUb11xwnKRT3/+6RPGBlmitclZpU63Z0p/XLJk bf3CtPSF5yfWx61flPQkbLG/aouUq+eBB8VPLl4OW1wmVby154z2tyGX9np7WqYez/8osaxjVaSM xhvxmWw9ieumW244Pxa2WHU10mH8mllVtzIiJ0zJCYl3UUkdddNseXJSp+SWhbvlKNbemTrrdFR0 3KutTgdbp+94MrJnIUPt4fJ1pk6zpi5MSTv0RPFKdtFHH8stE85YSmcn73eLKJ3faHiv0Pwt/Yy2 06KXbQe6hgUURntwnohvzBmzI7jrGsOJtTjfw702YVWP4ZA9TQ32T0YlutWtmn++vCNomWrpF83T nrY2FyxHRDSt0kmyT4lS7/oyZG+XznOdRftbSpq6J+2l66xa3G+xN0On/Ft/y8J2+1o9N7PyiKVs 3brbj9/kO56OETRp8j/t7trgo3Xp/ugs730ZpFjVMVd7V2DH0JqsaawF13YHJ1ZGOUXU3D93I+va qtNCMWXntrMqlh0oa5e+m69jqGOvc3+B4ooDixbeWWjySfXJcU/ZmcULQhcYLXi4/4qVyUeJrLlv v8mO2xL03sHfse6AUCXpvrt25POYzV+jJfo+CQ95dWStjpwHc/V7ZnLXhEn0IScdFKaMadNRKjdI 7mr4KLLhUZTCZB57olJZR0Gql/K0h0t/bMv/Wv/18G62xYKrHs9v7rx7LtHLuHZSQ+hzndS2K6mh SqkrljQumPQh+umKvuE62gsnLVs4NCW2vy7f1fzpm2mVoVt3TiwaGTzCdMm4ScabI0b1Xr3rHSZw 6wEbG1n5e5FZ71auKByWtzDbNmz2heyUqqOvFEJyAtPyo/2TZZz9E2XSC0t65unR1LXjx3gXOE2u Tpr+0UR9Z4ZNqJTilkKNUXLdIuU7qkfJ+FuUiflX2L9frmQwO7tqv/oXw2TjnDky/s46MtVKw0uP ljiXRocIXMrWF0vsejt992HsgmwrV16Ws/bo23lOC5PnLrQ3S15sekTt7hPvkOyL1XtG7tC7a1AT XRUfdKt7xb1LAalVQxV0K3w33jM+u+LdpS+K5ZwzSxrGRppYP7FO8J08P/HH/eQy+Rwti2z/K9vm 3lKY36Dw1OXo1mkSd+SdrCKVR+k6ZD/5tCSsfHbGfYPqfUOSxn8RvW4+ojsu8+KOVUGO7iaZ6bkH w5dONNxdMGZD+4xZ+RUz9i2a8r1uXMb9MS/rnRMTVzwIKXRTVKs+5Mf85BgS59t/OHZxzmHfo5Zp es4lB249mRs2KbTQ4fCexU3qDaN7htreDHnuPK3Wu2BxRqBhzbB0wbbP4++9o+esar/Zsig42HR4 ZlHUlRgrrzMtT0ZH7LR9Pmb+WfMHDV/efvbfe0SneEG3QX35udS7I9+dW/V5t/nx9ifuES5K78O+ LYxYZ7vM+o7yjSyts2fMx9rPWXAwP/xNxZUVc268zoqWsl4urXdm4YXTdeWChfINjqZi33QcT3fn jXxfIahjHaA2ScXp+Kw1y7XmmWQueJKh/O2FwAtbU9VvU58f1Dqm5jjZZ5LPpLkmrc5ZCXWPia2D 58TrPusXPJiSMCH1hr1sxczxe5fqxHwLG1nxWqQo5U3ojMVrVet7Rten3uu6N3nYg/yqyxW+Fb3b TCfWMMIeBN80XKOcY+25VKY5TUKkISJ99Ps0RY4S1alx55HTgssWWmV6I8vWrllntSAxY/qNGbOn THoTImT7RudS/tS8iaUPt57QvKs0lq1QmxCiSE1IbF/DeK2Q8s59VKbVROlVE850vy2oSdq1fFhy ptKEe2p7T4XmuQbenLQn4aWWuMWT6HdZjLaLLptsV603frIs294zd+a2Epss1qT5lgvTF7i0Ngjn zTOxFlp9bbnjvruJHjliN8uzxOqd193w/rbD9u0NHWudfY/Nj76NyLLLaXheVxJ29EZHS9uh+uKh aysKp9/LZVyqEe2e6mzxoP/jXovrRz+cm9Jtvm/J+8hL2ftjbM9lZI0tbpZuPnB35nw196eOFu5P nxsXVg+/dHWCu/P8y7mzPku4D3syxL1h1eElkUdjFvgf8NB9t/Ch7kufgol5S91aqrs0N3doa+0P Zy3f2Wyzf4HSjxk+6t1rnLUr1n5ysap0XCDxUWa+bqdsY9+Xt9FzkjWujC7fUrjxtvOVrdU22Jgt P1rsnK37dqr4myM2jL4561c1T0we9TRarVvq4K6lGoc2Fwl9H7E9YP2n/FGdCgFTchdwaeubSuSG 3w42u7O4KDVjLufY6hvRCiPWK91Y7j5mB+1I5ilRi4Rh649Mvly1YXJDb3niqnRn/yNbu0ZdPziF Ix61pUu2PH+pxJ0RTaPzRr2beGpRrFPBlQmBBWva2kYmr9jnFXK4uGbM12nZfpWG+dvV6p/MO8a1 WJ2oVuPlmTutYOrHXV6xD+h6Sa+zX52zmdrx5XtB9ew7gvaBDrNOV8Wbhd06uIbu5HG1qrfK98Y0 baMajar4tTfX+p149NyaN+tzw/P30+rN6rMnnjmSMfT0d5GNNlqv49qn96XGnP/OaZj/wd9QSTfz Y8wd2T7bhhrdo0kxWsnKaamf9575ssRnj0tDoPym5VEzFCal17uZlOk2rGzs2tjL7Wuvm2c+Ivqs xPviZ4e23nA4f+qBwcb5jXoRK6Z9OrjWT+DH2kciZStaLB9uWd2yY7+rAsVN3drY0jI5ZV7jtXFB V2ykL3SNOuA0zXLlld3Rkuvo09tnyqteDk3bGp07Qsle0fJjaV1HsvPnjCRnlz0zGDURm8tK5n2e LHa+Ts3zYteoGZoZo9T3zWMUMWUdb6mZFpWoHfN6nCC5xlnLMm5PXOTSzdTlnXbTLBXWLXfy63Tb Uii5+oqRqMPlc7lbVc3kWvbOZDxsMr7wbs+R6T13DhgdTNh1K29WhvDt7iu7G/ZIzuy+c2W+aVjl fvk9MxmXLDSmt92xD++ZOWP4/WuOZWYnqhIuzV2k+GVP8emzzjV7q0YWHO+ddUJY88Ubz6UXk+Zd nhdpuaBb2bIktiohtWjn2kjh3SzX4PPTNXKdCxuOXuxObTkzK8OZx+v2+baiN2qF9/1xwcnflvbq Pz96L1z0ak1/WLX90pfJ3wN6D7U2j71v/iq/iXcwMrQ3JupH7cK+i3271hT1XfvC8te861MbK3zC U7V3O6eIu7/C58b+D/lNPYf3pux3ONdSGCuupSLaFVPUJ/WiX0R5FG9FN0+kQylRv4g74jz3EON8 rPT5+qinHL1J9f2jX/SPnlTbr/7Ackkr7yXrx+oj3JzCS+XyrjIyMryM8u+x96OqJn3rm0qv0eam ntbg8tovz0gvVCxwyJ7cfiiFnTVlkbV42uK8vadGuvfv1nUxqxnrZHcyVzr7m5zT1nB357ypC6Q+ iBZvvZgcnNytMUnz86TwHWuXTLZ49NS09OxbFfc079Ifn0a5y53OPJB0szTLXs3dPV1wXmBGYphZ /UjDiuePm66L6uzpKXigMmeBivzmSEr8xne1D4eirg2orWHVyzlV+e7BNmz/OGp97odDaqajDrRf XSBdfafXQ/+NlbvoAr2ACZ2HOq7nsp8xj4uM2LSw9Oi1Qx+Urmmmd91o9GhKCCk9WqrgfsVw3rNd CipfZgyRrR7Rl2iZuPRD3dEP28pYh05FnFsTJvTZ8/jlWrth348cOKigmm0uJFos+H3O96yPujol l5dIudWdFWE75zlNW+2+p+qBb+ANF8Hv5y0dK2cXsCf6Hq2eusBknHST07hxTY+ChRJVX9g8PZcs sm/S1GNHO7VrOs1rLqdI67acXpm9Y0OhpHzi0FLzg+ddRpnkPxSyjAkPdxnOCfC8bKRolRghz7ts 2Liuv7R/y9rKHfXi5iM+1q8b8u7I9rtvWvfnxjqFfcizd7RX4NbHGBfYiZncyAk5MJZmaprXZxVy bc+WbQrrxBQN3GbZZJfM91+odTZBImnTlBrm5lseJRIqp9OsMnUTH5vH73gVv0WbGWT9hua0I7ru SBjD6+ExcQfPGUEXenr2mjWs7jkSVd9o2bO0OTXo8MV1/jcU7i2adSH25GfNC7ufj1tmcCi5Uy+r W3qrp/Le21f6jJ7O6zpTavpqqLfK54V5C02mGZy5ueLsk1d7eXnmzdwFnw8n2T7bGNaqsnq/0KFd uzdEe/u8CfT2KX2gMVG8cf+RbSb3HpRreQ97tcp7uFF+k8fEWuuIS6MiT3qZfrg27WK5hrfggZcb hA+81Cus2n9tUbmn+RfjJzfjii98qEuNTK7vkx42qnS+d8rDtUscikN/lE7SYdN7TYR7D9wvXeqd 4j4+36ZVM1+4jcof/uzBFypAyknNPNCt22Cpj3zZ3XujypPuHS0J9e7IK7j72a8hTS8upSHtwTRX b6+PUTRT+rDlmz/eo13Y9Hzq2YtqpUO8PS9++HDuWd+G694Th14j3glVqc/lJqQ8Z+e1eBw3vFsy /N53lcSFrupRn12VLFpcvrwbMiqqucVmYmhdcqCp+PAWo9XCJvc+290IMK7LHX5vQXn2vDpB0zvF JdET736J0PEumlYn6HR3RIn4WM8i6cned+3ufDGb7VWksOuAbvz9nUvJIbM+2ZuGh5Ls73mrPc3r eTwneZvNePMi2yVqLeMSXJYt6aiZS55tnDLOb0QG792kRVtZ+/e8iStq++gTGFEzpuNRz50fnZY1 0469rJmmcihz8bXhwZnfh39xK5J1976rsahZ47HRakETo9UxavldK5MWyi31dNpWuKSzuUZ3VYLr Jl59rnnm90Vrbn2xWHMtgHXVu1vGR+iSmV131o94q3tD03c8D17xVYsnxHi6tmHIlB4Le7H869O9 qjflH+gTVM5Xm+4TKTD8Xv+1E/eS34R6z1G4ly1qtV5iWOSZ3LzS9vVzZOXdImUfvR/vfaulZkIr wzspRvxA3zaxNk/N/GnZbpEKZw4olbqUa8l6dGubmjndNvcWHnsz4n5d4bATS2t3nYwOTBE36B2y a3/Mepq3hdeRcz1ecvlNCre/LBni5VThKv1yyOYzBwJv7LlXVHI2w0G8N2eFsd72PRseeDolGF/u /rYi68s+9V6NO9+S28+f052gWsj9NsvlSHZ659ChBuKeyvk9rbr5jJUvT8y/Qlfm2XIvaBSGWo/I dW5+JdScOepI2VoN30MWtUtqXzx36NS4N6+rcOch86MLxTiW1RuTY7YcqE5639gg5N18OfPB/C/L Pkh0t9dlTzuw07pL59GkpfWeRdOMrNcGfHZfq2Gesaym4AO3xtD1ksmh2lUJn1sCV6fm9r/b1Ucv vqiR9HnhyZjLrDE+rraerrZ7ZMa2DbPtHib7Yc9XfYddV15KtJxUXWh8cWpNcO/Fo8eyHuyeneVz MHJioK2Rabfd83U017IHAXua/YqPjNly/D43T33qyyjPPUqCKY6pFnubZLqv5Lom9qlkz9jfvaD6 kefCFoUopyn3ilWPKY2a1uvJ2/vsrkVy8/4Qrerg8pZM2Rwvu4IhW/ZOrjIa6yJkfTfNd7isbkI6 /8miyXc/ioxg6EaZnZmf5eM4xnf4XZdVFjK6UVmWyV5LU7w0Dbt8bSdeSvHYsWiafcxuv/KOo81e zZ/qtKJmri1xNco5vTI9eMHS2y8/Hx1qnbamJWxZ5iLveTEn/aKmCdy5ff/W7a4li75ULHo82SJq 57YgUXvLZTVHjn3elK6p0V9aIlD/Kv32qkTKcU51t0Gt9JMIawea4KobJ1IjDKrrzww9YLTzs9oc i6Oj1Edor84MyOjMfZO+M73NepdYrVxLynOXsw8vB2meiM70K39U7bA151Tmsf7M/hlXZ7sej1rQ lPol7X7wjitBC6d0aZx8ucrUx/r55bMJpi0ZY5IWlc5nHMKCnmto2rN56xKx2SnySdwA7xCbo4er Ny55YGccFFKuX3x49qNJdRs/jlVMbfOIDCpavqKG802hghSWNO5dljXmUFHheKO6vizNG6dzZ7zb tDUqOOTgmYeGvTLz1Q+q27EOvmLILj77PWt8bWWYi0vKBHuv4alzT/Ub255Y2XDa4Ur+44V1Rk9S VFfJ7zlz+p3dbQ3TDUUvZ/S+e3Q1KrrBodfvjbjfarMm58m9zpUh78N/TDGveBR+9duHy/c57yd/ v//RJ6jz4PDN9hUvVoXvvdURMfSI8bxDJ770+s8KOHku33OxfkAgM1jXQW3/nszFZpEFS244Lbh4 afPCxDuypiVnp575Yl54NkaX1SVTW3kmeck6l/bjB9ecVhXUnnFb8vkoVS+r4ys2ZWep3zgz/dvy S7TCTp7T8qdSnFNN7jX6s3s3frpgoORq25CZ0RFo0rDNpMZvzjcX+6su889K71nkoWI/Sf3Oxqnf ZtpfnYdn3jcmJlp/yx2rLP/+/Kb2wjF2V02Uayf1Tzw5U/l9MkvG8dLS5MnRohvsbz+9a5funD6b M/niUPfEs0ltzszaEW86Poyy5T7c6jpj+ZW6xKbvwl+ebnw9waX3cHP09l3Z5XYHmjsr5QSemm17 9uHHj9SvCn3jzHakmJq3XHO5sErm06WRq1/t/Vi4/q2ff8e9h/sqny1PXrlo4soqv5LJDi++qJwv u2ObfF64/m2Tk3F27Ztri6+MsJj9fOvFk2UuTSp1o9Zs9fr+1edY0JNdm142L19be5ieFTv+/MrT zYZNC/omtlf36R+5P+I7/8epTBFCSmtWLBwnPSxvePipSVumNnNfqf/549RngZ8/TrFLnQd+nIoS +XXFYg1jtuNTJeHWDouednaeY9m2SPmNsf5LTPqfH86bIrRJxEv8oVDtnqF5gmusR8Uqh+Scm7HI avezkxnLStIfss4VWtU82XbTLU/Cwz/cuLDp8YOL832cZio6H9pwKejL6ua3awVdHHL0Gffev+gw 43Y8+Payt7m44bukyTTNM+HpUw6k3bNVKJre1LztUeqnpSMMP0vfc/8x28F0bYXc+90uBTLa0W5u 7ETPFnGBgzEmCmMe+FfkejzxiJjaVJhy+mnT9c+nY+z6ntRxHjzjnA6LPGMePN590da+Wrc836Rp s9U9LD96ZnByghxGyZ1RdRzXb+1RQRctGOfOlesWc+nOeM90GWrxVtBbPSGMcW/6GfZc9+QDFy+Z LZy7inotY9dvkzpyU6SH+YE1HhfHB1+ZV/zCU3KThbFBnd/aeVfNH4zaeujVvfIYy6romiUszul7 +k5X2Yv3G69dL5DMW9D0YOHbsQdDj754V7DVPelAwvDVyxfsvnOLc8dV+bxBsx6vRnjWlo7Lkwqn XlGx8jEw0Yk2WD558aq1fkfPTzw7jhN6JHphjKqVz6tRm1/7PLVMHW/e8Ghq0eeOoucelbUBOTWW pddTOvfVW4764LU0dqep5f2l47pHV52s/FC1t9Lp4Tlff79GvxF+i3wlCpYU7PPt9d3o11L5oGrS yb4UeZWzL9XPzsnQPa6b4VV5zk+wYF6Nvt8ivzkFDb6r/ThV/bMtJvcOa5I5WH1226OzL6ccsl40 u1dKd1e3Q41Vwcwaz4KmAqWC+odLT1yZvPpQ93gX5Sbjg+WhgfHvXUYGDg3UDDRrCqqp8J1UI+Si 26RZY1xQ/8jcz7Kgx5eXtiRtSTp2Bw4tKzZNME3Zy140o3hj0V6nubXTz2SYVEY+WpqulKZ08kj6 kYwjyi/8R744dDw1rS/+w6n3j5ozXs6YdVw37eXMpGMv2b2cC5H2iy1mWcxYnVRt7X/K0nb1waJt 3SI5W/faLJoz68SNRx8ennzkseFLjMEzRbUxvsEPl2Y0HbO0OXMq8ITlbO0TOce8HjlV7q0KOjUn Y85x68rvuk8nFS3utWhSchkfqNwkWKNXs6tAt0CrJtplqG7S3qmLphyac2hK8Q7vR5OenO1a/nRu VXLV0Mr+qbVzeiVykp2stE/lZLy06hXVXdcdUzOkJsrX029L5OTFFvpnr9hYTGk83reue0jT0wIX F5P7Nqu3R47XPVK02zRV3qbX9L5V75SL1acW98Z1mzbNqTlTYIllG41lvNGPUVVdaeSn7Zvkd/5R 0LE5xy9qHzgk3HMvorlG1WViU3nBk4IpLsMDjQNH5BzontiUUqBX4+o7xk/5od5DnaYaicU7bjwM OtG3fe/0RdbFKU5TOx6NOmU5uXazZVTOx/4L/jdapc6EVTw9q8Vd/sR81gFH/9137ANDudFOo+zu zzuuWMb5fELxvfzjxle1VUtPmdu1xEdlXBEOebmpZQp3qGHfRk6ofsXdJf6xHU8uN01UmS0hs2dT 3uU1JxrvTrCp55zrpGstGZYp2+R8+9KfHyJm13NNu7LZZrHgm5iPzmlzeHbLDq/Pi99l2Cx+4fu5 TtkZT/PVrSv2Lbsi6yX9ObN1XMGpmdTnSSsFa/o2nWFfZvSJ3YvRUB8+Ru3tcOmtW5V3jL0yozRi 25BbThfVux7qW9g1T+uzXjmixnX37ejzs59aLCs6u89s5Zb9275++jh+4aH+Y7dWXjyY7Z+wM2Sz 3Im72SuWeElML4yYsTxn7SoxL5nPFq91fev95lTPqQ7PrvDxLJxk45yRPeXKkKDvG1Xfyi67fFts 7k2z/avkjabbjNa8NXb4gRPM6+HLDiZuDbOTT2tOcE57mXJBrKy3ksMeKEqw7smTybef+Td8VLWY ta/mU3TCkXT/L8sm5hz/GP14xOv7vsEF4n9dHBttZSzGDT+l6slVOrw1/8StByUzYy4G5Mocv5m8 z3x31+nxpYeq6nwb0peK6E9bLfpmi5TrprUXPfjTtmf5tvmCGm+lz9jcyZ6b3dzzxjyoPOLFhsYL Sk/bli4uP/IwvvtIteFj2xLbjL4hb+aq9Qt8V5J5xJIdfirTs93Xru5Jb3bApwKjdxH+Fy97adwK 0V46N+PHmM9XWicV9LhcPD2sNKlqafwFj7Jh6a5n92PWJog3fLWzM0reYXpx4dE9mg918o9TFVTX Si3f7eqPHV77+druGfq4+NVL35bJi8e/Ka7kWM3mf9GbTZ7ea7xkIZF6YlSV1XyBOwf2Onk7+lW7 r+t+lb2CExmQX1d8uVS06Zn3e8ekwvKPW19uaHi2dvgRzzrTd0tG1uTdl0l2VbLPMCy6yDpQ3O27 NbC5X7f64+WK+zX3sifY+HxZ26BnpujJ2lbco+LfdBovH9r3lHVMqfjGnceOKzmufl+OdZ0Z8Wk5 1yyp9NKk1tix9pcqQ3VT9s4q3le0JXKM7ra9s4sTuuk1qjWLa2bXRPnlFSjUrKxRcJkwxzfV/6ne 8qf9c3o3Re6NPNg9qWlJjX2NSs1kl2E5Cd1GOUe6LVzEcw5UT++VCxzRFFKTUTBnHCtnvdNs7ePv HzafyDmZk36iaqff5gIL3yTfML/6jPvHbzz08K1P33Yq8dF6U+bZGL2J+wpSfJUfPnhYd+rKLIu5 FjMtpjemN52KqKyx+v7coOpbgIjz2obe+CltjcPsuo8tPsn4aP4yaxFnZezX7xXiPYu+jhJ9ZFIT ELPA5JBuQJlxS1fOtvs7Dih+sJ/xXsP626RtYeM7n5wNSr7QH17kVTTJLOu+/AuzaRPCChw3PHU+ 3nXqe43PhfKsqqW1AUuvlBstkvBR+Fq7rW5d3gOLt7Ni3xp+uRybP2Ti8sO7Jh+/c0+b0+kUPWtN iPiTaTF3LnXPNj2j2FB7UqHt8/07ASZqyRG5PpeIceAH/0vOO33K9siG3HeeJ+Bj/ODizgCvoyMa 7ppHvDBa9EPu7AcRLzM1nnKDeNR6/g7LODoh4wqmRM6NO3tEZRhno9CpXQtOMv7cYdkkSMgQipBb NzwIO0ea0P6oYlExS9ZdoZzbYmHcfFbPT9B9iWIhO0E1IS1hlLyOwUSBmjpVJyXTkEXuUdKXdVae 3qsnOGqibvhIjlX4Z9k3Jxy+Cq+v0hTZEqQZUNF778GlB81ZjcmNJdc7Lhu3XK5vMK7o9RTwiCtS oi6FUJ+NbkUfV77htVh226Qtke9TQg+vvizTevba1CCVPdfiKzNDdjVH932XfF2eulJW5f2rzpl1 RUfVGrtk7CZpTUwMaj7RfOvOrkXpqallWbaPn9m30zds+NTr8Kxk9ZWNtYZDUg7OCivySnklvuUS hz3/q03LLNaTOxPOpasvnHwr9OK95832NnK90YoPdnBPDr+w1eTL5zsPZU9dbLryOlaoReJKul+r pclejl8ub87BnGVPxqYoFfVNXPM+Ldl5Y/D7ug1d3y+5nIk+F31ruaU0Y3SbYtiEz3ejlBLs2wJF vPw+vPC78yzRYPjoMbLXA6WEEu7Up+pvsSpk+LBHDOlt9PD4LrX0zdnqodevTewqGRFfeNZ/p1Pk QR3nJ2y22jyb6EvPs3dcMZNpojleTNM/sqPb/HmtWmGhQ+VV9Z0K7HOZkYHFbUGNS/q/hiy1NN+w Pf2I7oy1W96+uuN3UzbwgKZLebj96LbJpp5bRpXKHl/xXvb+LfVvsuWTxYJj+xc2e2941T/E/tDr 292JY1M/0KexRjXkrAqLvHFvwV2nm5c9P+xd+qx6immfQEJ65I9HVSNyqortz48XPKPgf3FL3iWt gy7Sh+Zg4NiWRfMtHW/oZqVtSbEYdj3tQnqF24HsGLFFsdOLy4Z8OzVyvHlSjWXCm8W9E6TNtL1G f2gIc5rU4sG4soY3ccM+h3H5Psby97cE1Kw1jQ/8YZ72LEhIymln+M7iBU+yLmV4vt0l4/m257Jr 2eWHV2p2LPy6JKp1X3bf976qWZ36r7dHmTW/01k85qXzMTtZzV7atvnqNLmonW8yPlS6iCWUnvwi lzhHIHKjf9502UNGQ7bofnp49cN2/ZAXM7ZUlB4zNh0itu+cs6ye1OkLu2QtVnxsGTNki8qFTu5b jDLyeOs5HuNelW8h+R90MTD1vxzr/9yJVN7+vOrbpQdSW+NJFpmVKU7jPwlDwZXMJ8HEk4wjZsSI GIAZMSHGeBzEwo3JIBY+jgxi4SZkEAs3JYNY+HgyiIVPIINYuBkZtMLHoW8QCzckg1j4IEa4cYMZ 4cYNZoQbN5gRbtxgRrhxgxnhxg1mhBs3mBHOZDAjnMlgRjiTwYxwJoMZ4UwGM8KZDGaEMxnMCGcy mBHOZDAjnMlgRjjTwYxwpoMZ4UwHM8KZDmaEMx3MCGc6mBHOdDAjnOlgRjjTwYxwpoMZ4cYPZoQb P5gRbvxgRrjxgxnhxg9mhBs/mBFu/GBGuPGDGeHGD2aEGz+YEW7CYEa4CYMZ4SYMZoSbMJgRbsJg RrgJgxnhJgxmhJswmBFuwmBGuAmDGeHMBjPCmQ1mhDMbzAhnNpgRzmwwI5zZYEY4s8GMcGaDGeHM BjPCmQ1ehOOfhRu0CMcvfNAinOnA4yAWPmgRjl/4oEU4fuGDFuH4hQ9ahOMXPmgRjl/4oEU4fuGD GOEMBzPCGQ5mhDMczAhnOJgRznAwI5zhYEY4w8GMcIaDGeEMBzPCGQ5mhDMazAhnNJgRzmgwI5zR YEY4o8GMcEaDGeGMBjPCGQ1mhDMazAhnNJgRzngwI5zxYEa4QazTYDqYdRpMB7NOg+lg1mkwHcw6 Daa/6jRso/ELX/brY2h/86FjBafTP+KP/MOOfxN4/nv4owiAIPBvtSdMfpYuCvz7nPDvcDQEJMjP KeJXx5MEKeDfbFQGZEEO+DcgHgYKMBz4jV2PgJGgBPzb/CkDE1RAFdRAHTRgNIyBscC//4oW4d/7 mRAd0AU9wr+pPBkINPztnb/Z8dd+/krIXxf4Xwl/yfBDMD8SmoMFTARLmAQsYMNkmAJW5OdXaA3T wAamwwyYCbNgNsyBuWALdmAP88AB5oMjOIEzLICF4AKLYDEsgaWE/40S4gbu4AGewP8OvcAbfMAX /GA5+EMABEIQBMMKCIFQCINwiIBIiIKVsAqiYTWsIT9X1bUQC3GwDuIhAdZDImyAjbAJNsMWSIKt sA2SIQW2ww7YCbtgN+yBvbAP9sMBOAiH4DAcgaOQCmlwDNIhA47DCTgJp+A0ZEIWnIFsyIGzwIFc yINzkA8FwK8EVwTn4QJchEtQDJfhClwFLpTANSiF61AGN+AmlMMtuA134C7cg/vwACqgEqrgITyC x/AEquEpPIPnUAO18AJeQh3Uwyt4DW/gLbyD9/ABGuAjfILP0AhfoAmaoQVaoQ3aoQM6oQu6oQe+ wjf4Dr3wA/qgH3jA3/gpoAEdBEAQhEAYREAUxECc+lnnVgKGAgMkQQqkQQZkQQ7kYRgowHBQhBEw EpRgFCgDE1RAFdRAHTRgNIyBsaAJWqANOqALeqAPBmAIRmAM48AETGE8TAAzMAcLmAiWMAlYwIbJ MAWsYCpYwzSwgekwg/p5B/VZMBvmwFywBTuwh3ngAPPBEZzAGRbAQnCBRbAYlsBScAU3cAcP8IRl 4AXe4AO+4AfLwR8CIBCCIBhWQAiEQhiEQwREQhSshFUQDathDcTAWoiFOFgH8ZAA6yERNsBG2ASb YQskwVbYBsmQAtthB+yEXbCb+nnru72wD/bDATgIh+AwHIGjkAppcAzSIQOOwwk4CafgNGRCFpyB bMiBs8CBXMiDc5APBVAIRXAeLsBFuATFcBmuwFXgQglcg1K4DmVwA25COdyC23AH7sI9uA8PoAIq oQoewiN4DE+gGp7CM3gONVALL+Al1EE9vILX8Abewjt4Dx+gAT7CJ/gMjfAFmqAZWqAV2qAdOqAT uqAbeuArfIPv0As/oA/6gQf8xE8BDeggAIIgBMIgAqIgBvzdkSEgAUOBAZIgBdIgA7IgB/IwDBRg OCjSft6BfCQowShQBiaogCqogTpowGgYA2NBE7RAG3RAF/RAHwzAEIzAGMaBCZjCeJgAZmAOFjAR LGESsIANk2EKWMFUsIZpYAPTYQbMhFkwG+bAXLAFO7CHeeAA88ERnMAZFsBCcIFFsBiWwFJwBTdw Bw/whGXgBd7gA77gB8vBHwIgEIIgGFZACIRCGIRDBERCFKyEVRANq2ENxMBaiIU4WAfxkADrIRE2 wEbYBJthCyTBVtrPvc1kSIHtsAN2wi7YDXtgL+yD/XAADsIhOAxH4CikQhocg3TIgONwAk7CKTgN mZAFZyAbcuAscCAX8uAc5EMBFEIRnIcLcBEuQTFchitwFbhQAtegFK7Tft668wbchHK4BbfhDtyF e3AfHkAFVEIVPIRH8BieQDU8hWfwHGqgFl7AS6iDengFr+ENvIV38B4+QAN8hE/wGRrhCzRBM7RA K7RBO3RAJ3TRfjbm1QNf4Rt8h174AX3QDzzg7/RTwG8/gw4CIAhCIAwiIApiIA5DQAKGAgMkQQqk QQZkQQ7kYRgowHBQhBEwEpRgFCgDE1RAFdRAHTRgNIyh/7z/tyZogTbogC7ogT4YgCEYgTHw2w0x AVMYDxPADMzBAiaCJUwCFrBhMkwBK5gK1jANbGA6zICZMAtmwxyYC7ZgB/YwDxxgPjiCEzjDAlgI LrAIFsMSWAqu4Abu4AGesAy8wBt8wBf8YDn4QwAEQhAEwwoIgVD6zxtThkMEREIUrIRVEA2rYQ3E wFqIhThYB/GQAOshETbARtgEm2ELJMFW2AbJkALbYQfshF2wG/bAXtgH++EAHIRDcBiOwFFIBf6t cY9BOmTAcTgBJ+EUnIZMyIIzkA05cBY4kAt5cA7yoQAKoQjOwwW4CJegGC7DFbgKXCiBa1AK16EM bsBNKIdbcBvuwF24B/fhAVRAJVQB/5bAj+AxPIFq+s/71z+D51ADtfACXkId1MMreA1v4C28g/fw ARqAf9z+CT5DI3yBJmiGFmiFNmiHDuiELuiGHvgK3+A79MIP6IN+4AH/gJ8CGtBBAARBCIRBBERB DMRhCEjAUGCAJEiBNMiALMiBPAwDBRgOijACRoISjAJlYIIKqIIaqIMGjIYxMBY0QQu0QQd0QQ/0 wQAMwQiMYRyYgCmMhwlgBuYCP2/eOhEsYRKwgA2TYQpYwVSwhmlgA9NhBsyEWTAb5sBcsAU7sId5 4ADzwRGcwBkWwEJwgUWwGJbAUnAFN3AHD/CEZeAF3uADvuAHy8EfAiAQgiAYVkAIhEIYhEMEREIU rIRVEA2rYQ3EwFqIhThYB/GQAOshETbARtgEm2ELJMFW2AbJkALbYQfshF2wG/bAXtgH++EAHIRD cBiOwFFIhTQ4BumQAcfhBJyEU3AaMiELzkA25MBZ4EAu5ME5yIcCKIQiOA8X4CJcgmK4DFfgKnCh BK5BKVyHMrgBN6EcbsFtuAN34R7chwdQAZVQBQ/hETyGJ1ANT+EZPIcaqIUX8BLqoB5ewWt4A2/h HbyHD9AAH+GTwM8GOhvhCzRBM7RAK7RBO3RAJ3RBN/TAV/gG36EXfkAf9AMP+Cf7KKABHQRAEIRA GERAFMRAnN/mFkjAUGCAJEiBNMiALMiBPAwDBRgOijACRoISjAJlYIIKqIIaqIMGjIYxgvyzl9j+ QQu0QQd0QQ/0wQAMwQiMYRyYgCmMhwlgBuZgARPBEiYBC9gwGaaAFUwFa5gGNjAdZsBMmAWzYQ7M BVuwA3uYBw4wHxzBCZxhASwEF1gEi2EJLAVXcAN38ABPWAZe4A0+4At+sBz8IQACIQiCYQWEQCiE QThEQCREwUpYBdGwGtZADKyFWIiDdRAPCbAeEmEDbBT82c7aZtgCSbAVtkEypMB22AE7YRfshj2w F/bBfjgAB+EQHIYjcBRSIQ2OQTpkwHE4ASfhFJyGTMiCM5ANOXAWOJALeXAO8qEACqEIzsMFuAiX oBguwxW4ClwogWtQCtehDG7ATSiHW3Ab7sBduAf34QFUQCVUwUN4BI/hCVTDU3gGz6EGauEFvIQ6 qIdX8BrewFt4B+/hAzTAR/gEn6ERvkATNEMLtEIbtEMHdEIXdEMPfIVv8B164Qf0QT/wgH+inwIa 0EEABEEIhEEEREEMxGEISMBQYIAkSIE0yIAsyIE8DAMFGA6KMAJGghKMAmVgggqoghqogwaMhjEw FjRBC7RBB3RBD/TBAAzBCIxhHJiAKYyHCWAG5mAh9PMunJYwCVjAhskwBaxgKljDNLCB6TADZsIs mA1zYC7Ygh3YwzxwgPngCE7gDAtgIbjAIlgMS2ApuIIbuIMHeMIy8AJv8AFf8IPl4A8BEAhBEAwr IARCIQzCIQIiIQpWwiqIhtWwBmJgLcRCHKyDeEiA9ZAIG2AjbILNsAWSYCtsg2RIge2wA3bCLtgN e2Av7IP9cAAOwiE4DEfgKKRCGhyDdMiA43ACTsIpOA2ZkAVnIBty4CxwIBfy4BzkQwEUQhGchwtw ES5BMVyGK3AVuFAC16AUrkMZ3ICbUA634DbcgbtwD+7DA6iASqiCh/AIHsMTqIan8AyeQw3Uwgt4 CXVQD6/gNbyBt/AO3sMHaICP8Ak+QyN8gSZohhZohTZohw7ohC7ohh74Ct/gO/TCD+iDfuAB/0c+ CmhABwEQBCEQBhEQBTEQhyEgAUOBAZIgBdIgA7IgB/IwDBRgOCjCCBgJSjAKlIEJKqAKaqAOGjAa xsBY0AQt0AYd0AU90AcDMAQjMIZxYAKmMB4mgBmYgwVMBEuYBCxgw2SYAlYwFaxhGtjAdJgBM2EW zIY5MBdswQ7sYR44wHxwBCdwhgWwEFxgESyGJbAUXMEN3MEDPGEZeIE3+IAv+MFy8IcACIQgCIYV EAKhEAbhEAGREAUrYRVEw2pYAzGwFmIhDtZBPCTAekiEDbARNsFm2AJJsBW2QTKkwHbYATthF+yG PbAX9sF+OAAH4RAchiNwFFIhDY5BOmTAcTgBJ+EUnIZMyIIzkA05cBY4kAt5cA7yoQAKoQjOwwW4 CJegGC7DFbgKXCiBa1AK16EMbsBNKIdbcBvuwF24B/fhAVRAJVTBQ3gEj+EJVMNTeAbPoQZq4QW8 hDqoh1fwGt7AW3gH7+EDNMBH+ASfoRG+QBM0Qwu0Qhu0Qwd0Qhd0Qw98hW/wHXrhB/RBP/CA/wM/ BTSggwAIghAIgwiIghiIwxCQgKHAAEmQAmmQAVmQA3kYBgowHBRhBIwEJRgFysAEFVAFNVAHDRgN Y2AsaIIWaIMO6IIe6IMBGIIRGMM4MAFTGA8TwAzMwQImgiVMAhawYTJMASuYCtYwDWxgOsyAmTAL ZsMcmAu2YAf2MA8cYD44ghM4wwJYCC6wCBbDElgKruAG7uABnrAMvMAbfMAX/GA5+EMABEIQBMMK CIFQCINwiIBI4N/EYSWsgmhYDWsgBtZCLMTBOoiHBFgPibABNsIm2AxbIAm2wjZIhhTYDjtgJ+yC 3bAH9sI+2A8H4CAcgsNwBI5CKqTBMUiHDDgOJ+AknILTwL95RRacgWzIgbPAgVzIg3OQDwVQCEVw Hi7ARbgExXAZrsBV4EIJXINSuA5lcANuQjncgttwB+7CPbgPD6ACKqEKHsIjeAxPoBqewjN4DjVQ Cy/gJdRBPbyC1/AG3sI7eA8foAE+wif4DI3wBZqgGVqgFdqgHTqgE7qgG3rgK3yD79ALP6AP+oEH /It7KKABHQRAEIRAGERAFMRAHIaABAwFBkiCFEiDDMiCHMjDMFCA4aAII2AkKMEoUAYmqIAqqIE6 aMBoGANjQRO0QBt0QBf0QB8MwBCMwBjGgQmYwniYAGZgDhYwESxhErCADZNhCljBVLCGaWAD02EG zIRZMBvmwFywBTuwh3ngAPPBEZzAGRbAQnCBRbAYlsBScAU3cAcP8IRl4AXe4AO+4AfLwR8CIBCC IBhWQAiEQhiEQwREQhSshFUQDathDcTAWoiFOFgH8ZAA6yERNsBG2ASbYQskwVbYBsmQAtthB+yE XbAb9sBe2Af74QAchENwGI7AUUiFNDgG6ZABx+EEnIRTcBoyIQvOQDbkwFngQC7kwTnIhwIohCI4 DxfgIlyCYrgMV+AqcKEErkEpXIcyuAE3oRxuwW24A3fhHtyHB1ABlVAFD+ERPIYnUA1P4Rk8hxqo hRfwEuqgHl7Ba3gDb+EdvIcP0AAf4RN8hkb4Ak3QDC3QCm3QDh3QCV3QDT3wFb7Bd+iFH9AH/cAD /oV9FNCADgIgCEIgDCIgCmIgDkNAAoYCAyRBCqRBBmRBDuRhGCjAcFCEETASlGAUKAMTVEAV1EAd NGA0jIGxoAlaoA06oAt6oA8GYAhGYAzjwARMYTxMADMwBwuYCJYwCVjAhskwBaxgKljDNLCB6TAD ZsIsmA1zYC7Ygh3YwzxwgPngCE7gDAtgIbjAIlgMS2ApuIIbuIMHeMIy8AJv8AFf8IPl4A8BEAhB EAwrIARCIQzCIQIiIQpWwiqIhtWwBmJgLcRCHKyDeEiA9ZAIG2AjbILNsAWSYCtsg2RIge2wA3bC LtgNe2Av7IP9cAD6eTzeITwehiNwFFIhDY5BOmTAcTgBJ+EUnIZMyIIzkA05cBY4kAt5cA7ygRqC 9Rtl/X/hLj7/ASSJY9vHYyW8hyZ4CI/gMTyBangKz+A51EAtvICXUAf18Apewxt4C+/Efi6rD3hs gI/wCT5DI3yBZmiBmZiOGeI/57cdwx3QCV3QDT3wFb7Bd+iFH9DHLwN4wL+odx4Jxl84YRJrEoTH 0IErRv/5Tp4IUrxf3UzC33egDTxf8vPlaQP/O6bcfSZTQsVNGlK8QaGEus8v2+bnCFOJO0p1/w+f +892YoT2R/n87r9+B/IRys/Z8LPfGXMfSpZhOvjXV0eQQOI1sBz+2U4R5c/A43+nfH53z1hu4NGW eJDlKNMTZdoNfBcB/8U7/7aTJxTFvy6ZX/bwfzCOG+PrRf5y/738//qa60ClW6OB68rHDbRd87NB 43+2U0D5v+edf0qJ9uA/fv9/lJ/Lu/j35VNYAgEDVz3/z7r/yffP72R/PVLECss8kKz49U38dztp lM8/lc4/nP5ny+cvAO9f/fRf5c7AWuc9cFX3f6+T/jX//N35f7b8Xz/9D3T8eEP79cgn+Jd+kb/0 8/3/4/X//Pnmx7X/7Pr/38tlHvnb5fSPrv///frSvxvfg/zn1///fn35343/r7z+n/p5+ud/3FGY Mv6+I3/d+/ttn78OzPHzDA0OC/YOZ1qHRLiH+wUHMY31DAaqkkx1+OO5geolvwf0jEmn2bmQf1Dg f+jo//Uo/4eOv07SiFip56/h/R1y5Hj/z9hMpyg6JUZJJzgSug5FxNE3lb/Gi9E2WA6cMKfo2BTw 7Nw/Xp8ysEWIUXSJ3y8wfr5gNfACf2vB2/c2f6Xt/ca/PH9g+f+nE/ZPdn9d/tKKf7v8+dun0wyH GbZME+bUUPcovyCfgSn49ZyeAdPB1xprUMRADvbDOhWEbXLur6HIfyoqMzH5vL90//U7fsae2F/9 f80//CY5DX9VnfxnO37+4X8ef774K9HfLwP+P+ax4ZcG8s5yrUv/N+Qffp78V+Yf/u4UPy7/s+Xz c5Xfr373FV5hA4HcyS/ML1jv12qiZ/LPb4L/77a/fh5/ffifbwL/6P38L/lVYmr7N1tfyTM7RIj2 mPzn/HzBr7Mk/Ot1Nvm5LvLjPP874dff4uc/N/JzrgJ+jcuPo/wS1v965F+nM+rXZ/C7/zf9vx/5 +ebw0J/fIb9sEXKS5SbJfx0H6nT+L1KCv9YZ/hQOVA4c6BtCO0p8+SfwBq7y/f1pqgPzxa8rw3+k UbSBcSkafwXhzxH/SuCfK8u/av/jv7P+86f29/6HE9bEsIHY8z/bAx+Jb4SfTPj7I/9s+VXYYNaM +dn/Z/m/l0AopuDPePhfdar/g/jH315H/uoXJA4D88wvk3/s9d+dirFY/vz9Mf4m/M+Wz4+TAb/u pziw2TPHzp+j+TtF8M/w8DvBn8toPYX1bh6RPc2kTEf/rBvF75qWfW6jK3xqR5EJhNfdzuvobRWm vraRzXGf2+QF4uSRGYaTOB4pKSkhHz584JH79++T/Pz8FnLw4EEV7Ht487y9yZw5c4hxrLExUVRU /DV1An888hQwS+RhKgkxeMETYbz+nkqGN7bWU9hOxRpblyGHMCeH+rkHaJIrlK7QO3wZ5oK077o0 WWO69Hy/QC9eGHOuVxRzXrBzoHuQJqHr0oYa02Jp85wxl8s2EnoYMZnf2Mr62FHJaucJCNV8bmN+ 7FjI5l+uMpzSJYZYRDzFgUkYQy7KvuA1to4hMxtbKf35AoSJWR8p9qq3R4D4NrbSMEmN92gfO6iZ /E2XS+PX6eq3JVS7gwDNgWpsNVgte5Zn8zp6PYtQ7JEfuqwoigy1I8uFnOi3yRLh9YQeIeRECXg4 0hxpgnsFhPYKCO+l0uKoh3RbsX0itoS+V0BAwEGgmMb60CWmPFL+IbWemj9S/hhFmSrSTBXppsNE vkt858VRZC59H32P8D66XRf+FTP20UX2CojuFXAU2ysgvldgyF4BCQwM3SvA2CsguVdAaq/ACem9 AjKRysmSwnbE/Qzpt2JSNmo0GzV6lo2agI2aoI2akI2acKsN86HyO5nYUaNJH2/6SbX4EbaU2z7Z EnVaifoVeonKJFof79KYUzyyl5ZBltLW88gc2nHyhUrjkXHURlJGNvDIFpKI/f1dk8YjAhyn+a0j k6iYFfU/JMcQA0c9o4QbrGTJncrHlfdS64mgtcrHjtbttOu09URY17Snn+wej+jmQzYvt8Pbjr/v HqmcaWqgZHzZqINrkG86Wt5A+fEU5dOCjAyicnkcSyb+GCVQZupmJG9Tgi9nz9WNRoeJP6Fb0kYu ztW9h4C5aaORlARxekjm0+SG0Flsev2PRJqZ0IsK09mMpQx+1bqIITNMtspUC8w2ymTxbOMEV7xk tbBclAtGbCQLKIMj0wRNBcitbQayxnbsfaytrsWsXKen9Os0Ymq1x0aC0KQIFWgbO5ciZkLm1FHb XNtS28e2H+YsX5hI97GbyWLXuK5R7l+4/Yd4sFIwNhWjkeUSIY/cslkPg99568m9856vPa9/Oa1/ Ob3fZ6PwOBsaWS9BNhn4T6W9dS1LtGWRw2eCrwT7ULYjlD8WrJvrHyr6wSp4Qu6BqG9C74JrYyla TKhgUAEW/WI/361E2kR03AjWu/DLJoZRhrobvKmrG4w1yW0iKMWvWqqaIk2NR1hgnLVmM4mSsMGo hXHKZ4iaHFEXNtCQIAzVVd7UrNg9wSyyeOOwZ4yps338hKnjsZsj+2gCgqbONDJXgjClCF2OJkrf lvL2K91MqIRZMd6Mxdb0fhe7KrVaoI9mFDVfaoPmxETFsQmh0TuvmWy4tUdkQ0h8qM0Gw22m8a6C nJOuIvfM9azvL1AZlqqZapE6J5W4pkanFp29oF4onXYg2pXBEVHgaHFKXW2k4rYbF6TePCgSG/Ho 0Kf9MxfGzed4c1ZyyBbOYc55TgnnIed06jzuMm5cJLc1lccR4SpyJ3AqHdVICvcYN597g/uU285N SN2TSpQrVgmZV8SFFJJHhwwql1UwYys2VRysyK64t1D9bsXLCtJSQdXL1OvV93IlKhbVB9aT2Pod 9Rn1V+vL65/XN9ZXOFEawi3DW7RbLFtsW5a3hLWQxJa3nO8tdJ4cT5tryT3VQi623G15+Y78peNN 48eVahpJZCJ6tLT+6HjB+9rmexXRBaHkY0Pn5KKPHSJsLYkS1kRBbtMMbAysuUICRGRBd5s3YyWD UJ/bhn5r1dIS6t9BqD1itIlCR6k+urVQvwihCXkUY82khD1IBU1ktYdIBU3Ug0mOUp8E5mIswSZh spMcEUgi9cQriYyiZM82dAqR6Z/aE4SlxSjSuBafzexoxfFlf0s7D1vdVmOKNyFhUwqP9rWjN7l4 CEkophFx3uZi4a8dxcW59bzWzcUiIykGr4EnvkmdoU2L74hvLBZgEoupKEW8jz6VEi6+UJxUfD7X YuMioWK6NyWy2B1pLddigzURcCeuFxKKKXosJbqe4hZfSMq1SNxGXVhSvIs6XUw/SGEd1hdKupC1 j6zPFDlBos9T4oHUhQubNnmSrgRrIuRONhUnrecVD6ET8eKOjrXuZEvShfXFEkzS30BdKN5yunhT gkOxphbVQ896QZLG0Zo/kuKkTZKSxRc2HZWRu7CxWKiDvokkVW3gkPc0WXLhFaE2TTpPrS8WvLCJ KXmQ0t9QTNs0QTJ+KPGQjDWmOlJ4VEefZ2OrVXBQkJcnL5wZHhXMDPboW97dGsYMD/bx4ob7eoXq Mds7g3mhTE/3IKaHVw/Ty0+MYrozPbl+oZ4RAe6jSWivJ3MYcWeGhYfy3P18fMOZAX68IC89EuzN 9BSOCI3Efmmfx6f26aN33V5mtO85d3ZXB6uzky7I5c2uvRd8hlPD5V246V15NPU5y7pASZwrIPjj R28Xlzd9YN0SJk9UG1tFGlt5/e0CZLEA9eYbRYTliK8M1TKffzGFAPuYaWz549P6X1nsjx39xuRc jPgPpaq2j+MEtQiL/nqasN1DFa5x7JrntBI5QvH4B1k0EiHGc4sY4kZ/50HrIUL9IYSKEHdbHSER LahCaLSVZEsEEVhDCW8mG8gROp0XJ8XuH0po9D4krn7sLApERNHckGZfsQSvUT2CEfRbovJYY39k COwTiJNmY/XtoQl7cMkwQhOJjqCLbqCLisdN/k6LESVSIwmdJuRPHRIQamwVJbrSo6VbXbHjQ6eP kRbUleYfBtOFhcgQZ0IJ2UqKOMgLOcj0a1LGREd4ypp+HovNX4wHZq+NkmQEeqQz3loTXqDpofve +W0sNYoUkOBh+RS1Sh7/aPHy+bQkeVUpI8kAaoy0yGgZb8kAIqIm/1T5k5S/JDuAiKq9VJoiw9D/ 3iqiLtlGBRFJQUwx3Z2qVpShk15KLIb0S/AITTx8rpsQcY4OY/uoDAlQjQtlrpilNn30xrE/COVB LVX/eowpJv6D0OJms/uXsmSQM8Rvqg5hSVb6SzpKjgb6XNG5o/ujpW6zjEJHlofwRpa/Zhmlds5Y TgwqujSq+jW4LA/h5bNVxUNJqL5USb+mAfaFDKmSfsXd1OxYt3WULttDUMcwli5cIriOJnqOvtbK IELZLU6PfY3+RPnWUOYt0ZENlLAbK0LELU6VncZMY/Jk4uTZEUJugtOvqdSqO0gL2ErmGgs2tqb2 8fp4/eUGYuIK/aHETTLMFwePPD3fgBUqakamXAMDQ9I/OYG48cysglesCvXz4WGVzmQampnxxjN/ 7mfyrIJDVwSHuofz+Od5mMzJAb0BzB9GYcxQrzCuV2ik1zK9LGYGjxygHyaX+DsR62lpxIV2nEfk aUeINXXoqiCOX8QFAvwpRx/ESYagPI5tHJl69kzKnQROpoWybYQ7hwqX/ryIS7BfYkgCRXeLoc0V smY0jp1h96HrtkDrLsnts1qryO70GZoGNN3x9AnjCohA58Vp+ZTgy2n928lcLnZVRvIvfac7kGd7 pJmU6JtvQRWSRkxqtrV6meEP3r5p0vS+EbWGMla+7kE+PC/sh4YGR/m6erkv09MzYLM6DGPGb5qP KMB03+7IYYb5RWfbBRXZhceuCvBiegeHZtrx/MKYnvz4UeEZHhxqwJay99C0EYiLj1O9bhCydLqW 6YubJIYST2PoGOHLJJLiO+jpo0kaT5R/dJqhRHi73ORcHbzCmbGTw5gO4aHufUa82X5BXmR7v9a5 DkNVffdKJ2YA242pHB6M8FNiN8HTgN1nWkjcxBG2wnmhwQFhegsMCc9N2NlvWbivvqsRiVvLDvdd GOfWSBkkudPXqWSStean3QRCiSW1QpAwKaqy2LZF3Y7h5xBEts+qpKYfl27WODaZJrLs2GT6Set5 P7DPLvWDCOqFCxGp/hoDETfJOcHL/Hjeq5hWCGfuyuERoV7kPamUcpQcaiRJI2ITZF1WPFHzl3zs vWKKdOvntqwid3KDg4MeQWWaAfYMx48hRl9VQy5foGzlI2iNrbu3hGoQnSoph/nUfEkxcV3kThVC yTe26gWz3WNON7ZqEF1Cw675+QplIocwWMcPeoLMF7yBK96mkZtEgBmrQvFrRxxCZFQjU0i4ugrF 41/Czm92okvMgizTH7hyNMa7sVWMsMk9ffL8qAP/AF3bgvzQeKpCpTqQcfIMMv2qNnmhp0I9ciBf +dXlqIGTA106n9qpjraxi1NKeV2nh7PZF9KKOBv9vrMwrZ/axf3JSCmiII6jo76Rr79T+PwphBe+ kknZ888Yar5oNRyLiWV8alf/NYI1f4THGGEHfwSxF63fol/w+C8IklE8HDzqYArutuAQOK6x9TZh 84jACiY1S4L0EkRJFo7cOjmrmFS0NhnW2Dp1kjGRjWZShywE7BkDVU7+skfCX1zkEZO0TW1sbW39 wSOt3Kyr0pSYFNvJcQTpCpNj9/M+dDHJtMbWKGo+nX9CHTsua2bTtRj80wi+NlT9fH4d748dM8by MPf8mZ/B488+f+4LcZhVkiTEnSEmwJpyVIhyYpQyGjpzaUNnkJnRQv2vCZUg1EzRtgp9b6boe37u xvTgIEpBCrsx5GEzJXAUrwvqDiPMEKaK0HRlFSERkckfulYEybso55LhksSDqSw9mTog1UepCIlJ ZyoKZCqKCmYOGy4toiz7RvI1CRym1UyJtimKZSqKZw6LVR6todHKmqCrO9auSvw1FZ+pSGUqnpYb J1MkN05SrJd/dEgRSkB6rpZkBM1tGvWpXTBdJYJ+SlUwh4m0la+Z/poILR7NlB8uKdKkLtqvIUUO EQ51ntRXYPdKwIck0T551ZIgalmuAEWmq35qp6kZZTDVjATEDXSMXwqqGUkTITUjRfJeWM1Idbek uqEWEW1WMzIiQ9SMzIlEqJrRlFdE3XAmYagZRc0jkmpGLkRKzeiih42BuuFyIqNmFHqXyKoZRetj OJ68F1cz2tLUqm64k8jjYw6SYWpG6URBT80oiwxXMzpni7GiLpERakalZKSaUc8doqRm9JAkkBNv RNk1omyRyXdE2aVZouxLouxzomz0pMNBUfZOUfYWUXY8BqJF2aGi7OWibA8MuIiy54myZ4qyp2DA XJRtJMrWEmWrYkBRlC0tyhYTZQvMpdifye0ZWAhaukaOtIsG9KZWgdsGglUGjkLPDYRfG4jYGoi2 GViLfTMYQk3JZFoRVRva1K9tsym6DyllVonRa8n35YICuQJs9utoWd5Zmycstt2FUZzERvtOtsYz tkalIlvjFlujhLVYv8tmpVo4cTw+/NkurUpWf462MPYxQu3vjV1nX6vfpD+ZpKtmMrOYXJVr8wRz xfqo3VIDWVeAQ9aTespAYAbpXk0CZAwdCVmQKxhD2RvQiDvpF3U7QUl40iTcZupTNga0GSRPO4dJ 3dc2MKQmGySK6RtSLh5rNBhOesGtJN7BJkDEdU1wcmCZ+6jAc8G+7ODq4Gd08RkklNI3uEv6R6+g tEJGSRISm0QkqSTyzHJFRJrlCl+uAdKNuIGtEDGnXlNBlPjbr+IzHNQMaMW2923rbbXUaMSho99W 0lXVdZlmbsR0V+LiGuC61nW7a7prgUvYirL5tOh4wTCBZ66fXX+4Dg2WjRVpDt4ebGBIW+Qts9Mv eHUw2RacGvwpeGqqRKxvanfK1lSiFKsfOznWIdZr9aEVkbGbYsnBWB2V1fQu9sXYu7EvY73HEL8T VIpMikbK+JQZKYtSClxE5h+74WB8TnBq1r6UzJTiFMn7KfUpOakzA+mLvO+dU00l41KnpS5ITU/t 495MVangcNnWFdWpH1O/pw7heK0WmEyO0Qw5Vmej1y0XLDu9uht7ZKkrLMWeZkh8YWsIsdffH1s5 X7+G1qfSj0NvtwgxN54AdjKJcIRElFuEePBjepxUE+1NkYK8omTk4+WPsbe4qF/K/ZqY2/JKekiV oFBWFbWqMrKy8PF7Tg8nbhj3vPP7krL5Em8eSn5nv94VvVvz2WraWPNK7ScUWa6u/G6lmvaT4zIG 78/JOH1QkfchEm/Wvh3yVmj1qyFv49c3URJvst5uaZB/m/tZIJ8cYRO3/CLKt3C3wBPBVQXUOu4u rvuDVdrG9cdHV+j2JS1iltygL8qdnjbZQI/zrWIe58zqNJ2Hr8gqThLnCKd77e2uW5wazuP6kn6O JDd3aUJr2fwtNEFBMpXrxPXlRnMFebN4ARV2PpTgIm816VruXB6PK1WxqILMV46tWKkspHxYOaXi WEV+heyNiqNC1sEhQh8q9vLE6o+32UaktT7vbxYqmfNMIVZ36vxelW9ct3oSWr++fm/96fpL9RaM OYxARmWsyETmNoFlRoLdc9pZpNvG7AvbNd5w6dtUsxVflhmRJ8aextvfVLNOvV5mRFm9Hi8QaCw8 U+hxy4eWry0vlIuUmXq8bToxyu68sD5hS31bfeKunxWbqL9PP1O/WP++fr0+adOns+RYY1hmrFms sPU1bIFtAjQPQU7MeoPcSLMv32JJ3nhLv/KJNI8wT8pz+5vwYPap1zSPVM9YH3HPE8uFtW2Jpa2t rbttmG2i7T7bTNtiW1rkd5Fa2yZbnq0nR83VxJXYuC509XeNcU1xPeaa73rDlf3U9ZOrTsHKFdsE 0uIFfXPIegO/k2ZfznHyxtduLp+YFk+kdqUmbH8jnXrqdVq85S6lfQKZCVYHRW4H1wY3BfOCpWKZ arEmsTaxC2Mjv4uuik2KFTkSe4mnV/nxRuzT2E+xvbFEIkU5xTDFKsUxxSdlVUpSStxGIp+2TWDS OSlf7eqSH++ISfC8loX+ywuj30w6x8m3zCfb3+RyT72edK42v/i8Tf7rS5SoT+qq1KTUI6mc1Gup j1LHvk/tSY38LjYsTWBE+qG2SnVORtf515wunZzoseJkfIN5WUX3a/x18J5u6C4h67hqgkp0Q4Yg 15Hhw/hRt7KgZJtA8UNBMYPVym9S1rOIgPlN5rFTdI8QAbrKIUaOII1KLBAQphNFqZvlDJ2KSRUX lWkMZXqXpIbcmjdGchXddi1km7KPguizoy3lys+VH7d4tKR9bfmk3Kssoa+s4qeuPm5tcy2RxJ6X 4/72GYVPXoXlCe/rbqraXVv6RDMslz5aVbbt2YownlfEsmDdoOBlcl55JeLD0gRHpNu2aqmqCF0r a63dTU05EcBwdfHgdbHY07O0UsweDesOOK1L/7D2dMQalv4KW1+RkvJzYXk/ik+nPvE3sB3xscBm 3Vz/x89nHXv3TGB3weR+NS9jsjhDtHKhZ2dIcWL/1OXdto9zBHkJRYL95R/9RdwNVEvan56L+aqt 2ftwkvBc/jEyz+g/HCWZS1boy1VNkOOy7IT7FboOEyFqPelqIcfJG8GSeJJYTFwZb4TIHKmbywRG 3BrHoywFjRkaCqOrNbv3UWS7AnOLekml1fwkMlZd3eBTZ3OtuOSPFBwjsxS6Sq+XXhcXJyuudE4s VNaUncQ4Umre05lVW2pIgsSv2aQJ7ZXr521Qcby5ZOwm/auvT2WS4YXMIdcM80qGzBuWRh/B0T1L Z50WyFntyLiQ2Cn25JlY3a2R9Uy9OiGDt5u7iP2zZ0vqg+vj1tXvqj9Rf76qjHn18V0jwbYhrfW0 90Pf0kg3YSu0aLVMbDnYMpIX2jAk5gNZNmXfjeGmE2w/tJR8HD5hgy1h8ox4l21n2r6yncKbz/Pm 5a5sC8+bdkxi+AyHvBIJtxv6T/U/6c/JePBwvowIiyiydFh6zy85zmMtY0WyNrFKDrKyWWdrYuyu Pl7vIShBXrCaWcRW2lbdNt5WwDW0gZKI+aAU+nuD7bAlc2OHuYbGkti9sWNczVxnua5f4hq8aOiv NLXgMSV/zfWR63vXnqUr4wbOeuoHTw52CPYKPltjGnf1seVOuuDQPcGngi8G3w1+GWwRK3AlNrRh aMyH6p06sZNi7WKJR2x2rDCnMlabczHVlvMq1q49ViBFPiV4EaOwhGaRsvzuA5qwSNk5F1nZrw8y hNjJOXkKp7eq8CojeAP5BOmEN5BPkE7mripAPpn80ENEXnb7mriC8AL+2Qcp/2NnxNzCc+mr84QK 8iiSkBuXyy1oSaFSVVLznrak7b76eFipoNljia+3HjzcrTL8a/lVgbE3ptTTzG5+ok+ZXi0vkDus dNN1+etCiSUC8teT71PDSguu7y5nXr90J4cRIkmo5buKhn3YLZCksGEHxQ8K/mcXle4tmm7JNeCM f5nklruiiy78Sng6kRyfQuMi6S7OESKJKfx8Swt4LVqd8jHlDbdkSOqoVLE72yoVy3a/EZQkc1Pd UkNT16cy6h3rIzn39lGSXtN029+nLqgX5YzgeHHIUt5mTjxPkneSd4BzhnOFI1vBOf3BepW9VCsn rV6We7xXv520vq37+qHE+cIfWWQ5l6zhJnPTuOe4ZVzrFueWqJaSkgnTiGJZkPToMqHx7SwRMt6q Ys6k9rHvModH3wuSJvUygTIHS18p510LkhZXaxwmECUjpSVVV9FaQav/wCvhMSfU7xuykedfH/NS 2oaxkEH8GQWuKYxjjHzGDcZTxicG6WVIKCsrGypbKTsqxyx7xxRQLBsyRfDikmTJS04HR9KDSfEw mxnR94ZMibEStzpYutaWnXdtyJRMq802clacmdIm+sRGf6G+v36Mfor+Mf18/Rv6tLgamff6Pfqi rMAUXRaLRexZnqwI1kbWAdYZ1hVWBYu8ZnWwTHfH2ymWZXmMmLpyI9GxXrlugi03edHMa+uj72V5 kBFhmZ4HS0fG5l3L8rAJGxMlkO85J1rmke172x5bUdcRrkxdV5arvauna1yNbILrHleRU65l9eqv Pla4vnbtcBUMJsOCNYMtgucEuwaHBCcE7wmOky1hxuUsm75zxHTDuxVP3xGW7eIKz1nhe9aXTt95 cZfNLnKw9FJq3rXpO9/vurHPflfjQUo2JDYhdk/sqdifu2djW2KplLgaueRKQY14QuyupE3J1V1/ olGw6NnK1YLdtxy+s4pkEXyFlZs43oy1z6vjiER+f8QmOzGvvE4rHbpwSVpphtSNTTp7ZK7dO9Yn yq1kD0ThFERhlmsu/WPuOw9HAQkiUCTbTyvsTr66o3PmjY2FTX7dY99xL9JHHSvqRxSWLdFJO9XQ cS7GRDT3DXsE52HsdF/xChZbfUgpj/MzFo+M/RWLR5eYVIy4UaV+g8syOH+7q/4wkabWa6cdJzHN jLRkkkj8St7sEyILR5xcpnF6Kod6pVQoc1H8Aa+6phuROFSVbKl9lfBoPhmrJ9BmcPt4492eXP7Z yhDW7S69BL0EObLCJG6KIbX4WIVc2Sju3XjeaiK/4ITSKLequkMnZG8MxRFxVukritiTIIXS11Ek /kY/b2fVre4Zzw7vrg9uQ3i+Vnn9taFYcZo8N0v+Pqee03bKe4NbemF82ZHbwck714uyzbjMWcV1 VUu4wdx1ed/LneU/EO+EIyXp3Lvzmvxe5x7ceeY9ecJt4H7jBiePrNCrmNIws4IsrgiqiKvYWarc YthSXHG/gll/q66quYLU6yXID68PTomzHDq3TnLf8jNR9Zvr+3780DnBuFJPhnGzhtXXt9XHteXs zfVO8N3ukRGwYdbJZ2RTihw1t2XuhVYquGVdy7o8SaVReR9SudyLVN3nu9yWFl+KJ9M3Q7JfP57L 1eMRNm/n5qW8Fbx43m7eye7xysRk7D1eHa/1WytFGNIMvQRqmDZDX2+KshsjVHyCxiaG3UHGwfoL rEqGAjdLoY3RSVemN73PfP+ZxdZnHX+7OLC4KXKTlVXfy5kKy6pN5+sdphoOrvdUTveiTV6nvEt5 XZ5rM/9YbUnck+RCcsftltOZ93XLrlg3BbfI3X5778ye96+YamL6I/XZBTzTRYsTsutY7NjwSZqV kz5dZ+nT7PVZ3tZjTCP0N+of0N94n1jZTl5ap9+q3/qNNlmapc4q1UtQsGRNXjrfdm5d5WVq3R63 KKGZjvw0dZV1J3jLG9ZwbtZwuq2cbVt2VV9v5vtPLLZZe7PtvecjWyI3OYbVz1SIfagycEZ7AvfV zMuyIbtsT9iuy40TZLPGDpyyeM++OVtsby7r6pSXmYUVES22LUrJnyP6L68d6arn6h3FZYkpk5vT 7/G3dYq1MirOdafrcdci152ljrHEIbnVlRbc+k02RD3YNFgxjBpuG+yQ7B0bylpvsTgxO9juanBl 8IvUzmBF4WhFudiPY2LbTlWEDale2bHQ3Xaq9rMXshd8Mu4FrYw13l16tCRQIC42beea0cdOxJ6P vR0i9SBsrNTQ6oiRr15niFdHSO/ojBL4kHa3hdZ+8tvw268UXSelrBUpEXzqu19PUqoktvjNzOkq BkUjKmgRKawtp3amHE8pSrmVsrOU+HC8rtJSZVNbv40+Zpo6PbVUJ0PRPdXr6krO3Lo8GUGLiyWv t5gEFV5NrUx9kyrbXCHEGSEcPWIMx4xDbzg6Ou519G7J6vBFJWzWJDO5rc7XU1+9LPqx6hHnq12q vmdgNr1QaCdn55oJVec5tzknpArlvB9LfzwrwTaY2rz9vlzHExmuRqGEXsHQ9/0dzZVs7jwuu8R4 FM/IcNZzFvvGyNRZ+4cnrfVM2chlkcNPj3OLuLe4Ndwi1VX1Uc1xshWjK1q/TaiaXuFSMenRiNaw iqjmLfV7j4b03usRXqH+bItJ3PvKijcVnRWyhKFQP1I4eqRZ/az6JS++zf9WHVnZbnNoqMKj/f2l Y5PozUErL1xSLhh3fpvw8fqda2ZSvrfra+tvhyh4P5KV/14/jM1OtZjyRe6zmKRGy6vxTUw57RT3 Fve87QYbei6ECs1gH1PoExlT8ujcxpYDLayzwkUt5FZLTcuXliLVJMbmUaN5E3hMmtlMyoUXwLOj j0zkbR61+DBj79Gr7xe9ZNZtMWHvlHvD6+QJMaRZWgwl4ejXSrMYSxhL6g2mfmCxWcIDATv2+RHj tTue/4zWPOm4S4y9Kxcb1jKaGE0vpBzexNObP8u1pLkzra2VGY6fK1j9W3SWKUcqs2fWp2+98Zra UanDSX2IYMyJ4J5RZpESk5vKz5Q/K/9Qfrb+COvQ3LgJ+jP1Zf0WGwbor9X3MFbK3ad/aO5Z1t6j Qxmt9vXkYddx6059IZYCSz14ouXPSz762J/axfnnxP44u8eO/XVy71M79qvoRIAI8tsVECYiRJRf AWZIS6dBR6uCBKGP++vZzt0KKpSWKiHUpH9wtrMTI8Sq/jzb2Tf37VcKnyxHeNfJ1vNMSnQoj5AR svyWmXlssqaYSamr9pDfJztdv2QyKd9h/JOdMVOVybIsJrV5jMAfl6gJkCsKja2dtMfUC54sRer5 LXpKNCIU8uzcfbx0DfntI3T98btecCihkdn83+R03UM9mZ51gkhPXhSDEaoXZmTY1TqWoWdkZMnY OZ5m7MgYTxsXiH8m6on4b3oE/8YX4l/fhK5WZ1+/cC/mkQD+NYoJ9/GkWX9jWzAhUwIIqbdaRYiN Cpnj/pSQeW1kYRsxMUDveF1JM11JwxXOhBibSZqZSU5XkeQ5+FKEf8ULL4Dp6RUU7hXK9VrGb4Z3 plw4L3gFM8DLO5x0kMNLhne18q9/SQyzV7i8RDJOJnq497DXHMqYZOdJHsmT3JqVJxmTJ+mXJ+mU JzkPA3PzJGfmSU7Lk5yCgUl5kuZ5kqZ5kkYY0MuT1MqTHJ0nqYqBUXmSI/MkqTzJTg4xJi8kmGUS zOwsCeZuCeYaCeYyCeZsDBhKMEdKMCUkmALKRJVcoXj81mIFsXbwKDKEf4o5loEvUeAFT4bxrud7 KzFiTGU4MXwZ0YytjKOMXMbUUga+kJuMz4yGTsl2xnp55cZWAW1JfeXJyp/bFHuJVGOrNBlBlHmE SVSIOJGR9pMWDpZ+10P71pqgnDys/12PGBlJRhGlrK5WWkerQFurULCkiDgRzZQc0tjqMSxZ+b2y 0BcZ/gXrPy/zVR5YtUUwif/Jqt3YiukWxwcqkdhRGBWFNnQ6U4QmQbQkiIIaf90WDHj9XegFbyiD yTBivO/m8dfyL4oqlLKgBiEs/lXnRRd55M9V/e/H56/0s0dg/OUYX2wiJqexVYRIoTSU7TxjroOd Lc929s9LqXkD11JPc1+pTKZNXmD+gjdahMdvZ5v/Ii/414t9K/k/eAjYkd08Ek9kYrEpXVUin8WC RZYpEWELckuJdovQKcY0xsoFjOWYBBs7Z8NwxoVDjBxGXR9FjKr4DfWNpFNkoiZpaX1LY00jueS+ xC3he3QhfmuCYY+pD10tHRSh89rLRYlPd5ck3jj2Am9Uon/Pq9fssayRD4362Z3mZNzQipEhTKql TVzkQkQfs6VTjsjzt9MhK5nUhMbW+Y2tjsMaOrdihhNEdqcI8BTIQyJgoEJ1HcZ31dg6GovGdesS Faq/sVUF27TiKVK2i0kpt7Ty+K3x8YgbebpGWaWl27Kh018Q2w2+YqUosjUqlkmdkyBkVmPrCfWG zj4eaafGRJHLvFNMKg2hZfpxrsDnto/KkjspzfPkXUUFk2pVlsRCM+KRaeRLPpPq+6wsuayl9c55 Ep6v0ki5C0kebGydSNhcEoCY0yskKfYdISeKwvc8VQNbKbOx1aqhc1mspCNC0dQosma1ZHisbMxI G8lbSdPI7ljJLv3G1hE2ktnp04jg9VjJMBXyf0P38zpRaqBOhzpdEI/8K7D5hqN/+MDwzytGqb95 B438vOb0529I/AsPf19zSh945LdN/d+5KvXvp8MD5W4YMBz9wweGf5f8ryynCJ9bM2A4+ocPDP8r y/nbz6L93TuogXtsaNBpSDQziBg1448yfne/yxD4Fy/dVViyfO7odx8YHoy5ZmJpMzHn/8p5/GfL DkfZ4YNU9i2UfWvQ5nvGQI3Lf2XZv9er5ZQhSR4wHP3DB4b/dnr+NeVcxee+GTAc/cMHhv+/KEea ZkhMBwxH//CB4X9lOf/sd7YUkcGb9q9dX/5clquwHPnc0e8+MDwY87gG3+EaanC2iUqUXTlIZatj nVL/F3+3//x8z4B/HAv+Ovx/Xov0KEespXyW6LccGP77qfg5J/R/OCc/P03j//hp/5Np/O9Ph+zA dIgM7BFkYE98O5Ega3AY4ItHRyJNrIgi9pA0/len6fey4U9TJhlGjuBxBw5LNvwvT8fvdccD5f5v LwPJgbKFMM+BJJm4Yv7tYDL6jf7Xl4P0wLQIE/4+jAZhEx0yl4wnLmQq8cQBjh+WT+D/6vT8Xmf5 +xblmJ7rmJ5isggHbt5YhwPJHhKKZRQ2KN/XckqDuIEzNYbYUbpkJjWOTMN2/b85LWID00JHftPA /sk4xBar/9Xyf2+/0jQN8oEyJhcx/1sp64HcPhjTcZXyIScoL7KNciMR1EJMh+0/nI5/XMfzH9W/ 5D9De3L/yWG9EZK79okQbZ1vZ6fiOcG/e45/TzD+fdL+WicTXRy/TiZ/Svn32ONXVVv86zN9yc/7 EPLrB/LrvGb/ep5fJ5N/Sod/v4J/pt7lEMmfS4T/HL/uJ//8X9jAfFK/nuXHuTnuYeFeoX8+j1ck f5Yn8us9/HOG/C2Pf+3tz7OEAycP+ecOB+6fJ/irPINfn7Ds52Acv24p/3P488H/9Lhfw/x+/lbj 6mQ3Y6qr3TxrpxnWzg4/Xxt4nv/07BlzZ02Z7GBN/uO8TyY/54vf8efxv+oE/0O9y/9efcQJ/4P6 jzPIz3t98bu/r/9t9OsGsv9s99f2R/jL4D+r//273vcrI4v/K+p/89fpf2X9b34m4p/K/GfL59+z 0u9XP0UGt/2B/1+tf/7Pxj8D6ud9HQcr/g1G/W/+vVJ/x6h/Rf1v/rbEb2vkny2/DevrC4+f/YNR /5vfzsC/sv43v70dfls7/2z5auLIQ7N+9lPopwEdBEAQhEAYREAUxEAchoAEDAUGSIIUSIMMyIIc yMMwUIDhoAgjYCQowShQBiaogKr4z/Zt1PGoAaNhDIwFTdACbdABXdADfTAAQzACYxgHJmAK42EC mIE5WMBEsIRJwAI2TIYpYAVTwRqmgQ1MF/85XbPw6ANRMAfmgi3YgT3MAweYD47gBM6wABaCCyyC xbAEloIruIE7eIAnLAMv8P5V7ko8+sFy8IcACIQgCIYVEAKhEAbhEAGRv96/Co9bYZf4z3bi1uAx BtZCLMSJ/5/r/w9sI7/q/3eGMal97j/vj8rv/l3//9/1//9d///f9f//Xf//3/X//13//9/1//9d ///f9f//Xf//3/X/B7n+/4r/uv5/bqzq39T/n5+n+mf9/z4xC/LinCo1QbgHx2E/GwBInZqvSv1s AcBR24LMdiU/GwDoJdO1SUGBKvVolMPAvTZpv87g0v6vS++Cf0nv436n99H/KL0nFlP561cbr5ek rycUXVHAlmIk8NQYJqLxMqRekMFL5c0SJKI9B4j4bGpjMbVLcIMXnR7AWMvYzkhnFIiOsiP5xruM hxMXoVmMNGuxZsYLugrxpCUPkzJm/b/MnmE8rOoDubI+AGv7QP6M9fydUXmhnj+zJwurGxIpeemB b/4Vq/MHdwWPXxelvIo7gVfpRz9i+ooVLi9HZ41XonM7eULiv3Km0H+WM4UGcibnV8782PH1BEtH ohVJUugVUiRP4Vd9qX45/sk1forkRYj9TJH1HrRfKbJF3O1XitREjvwzRfYjR/5Mkb00uo3QQIbk RCBD2gsiPwqu/p0fMwT6f+dH2urf+TGCfuWP/Ch69Wd+FPSnBO4L/pEfCeeP/Ejn8fOjIBlCtP/M j5qMrUGSJgx++tMWRuZbxs9/tIOK5wVbWapS7J/574/0J8DPf3jid/a7M5D+BrIfES4qJO7Ur+zX z09/A9mP6yZIfma/+IH090f2u85Pf7+zXw/S38/sFz+Q/kSZv7Jf/1wchP9t5qtG5mN1qw+kvsce wn+mvmhNgz9SH2/2r9TXr2P4K/X9OEf/nfqyrtH/TH2xbr9TX38a81fqkxL8S+rTlfq/LPM5D2Q+ yk7l7zKfRKcs9R8yX5C8NcNZVJKf+HZKDeQ9ftrT+CPvXRAuIH2/8h7Z0vIr75Fnu//Me0h7f8l7 SHu8n3nPi8n7mfe83J1/5z2kvfpfeY8Z1vg7760KqP+V9/zCeL9/Iuv4nfcE4uTi41R+BLlSTa3a JjdJ0B+Jj0jyfiU+Ud6vxLeL9yvxTeb+TnyzY38lvg7D538mvvCUPxOfaf/vxBfK+5X43Hi/Ep8R 54/ER0X8kfhOux35M/GVKRTbXg1++7WPF0TS2bsmb4+hHVblopfW7ZXOph8/af079amGC/0gUr9T H8/vV+pjuf+R+kY6Sv5KfXOR+k6LMl3+TH2nLhK/KikVwk99Ub9SH6uxdbmtPD/3rUXui9n/Zxs3 t4KYRPrvcpzQQI5TZyPHOUn8meN0pqpST9qMSSIymgU5PhkvRw4lxMeG5swmh/XJSwdCNbbGILsV TFGl6hxIl2ZjK7Lbj1nIjcKMn7fi/tWyTVDaIyGeeZMye86FUYmcRvuh7L9v2eb/MCIdI/YOjIg4 yaRI38TX3+lkoFrIuO8qlLYsId80X/D62gW+qlDzacJEe8hfLpz/S22RgfcN1BZZJqhKZfDfJ8Z/ 3zu8L4cIC/xsJYf/i/lAKzkCSNMDreSs+9VKzpfVWKslSAf/TKI0pWOrStVzZAhZw69GwptHDreo ULGyTwlRb2ydakXKeoapUOdnERVRAa+/+b3pV6s5of9Fqzmh/FZzXKn5dPJzf+A/bTUniIcFxl9e M3j8JcZfYIH8VnNYWwX5zeYksv7abM7uGeQvzeZ0bhX6o9mcFqHfzeacIH9pNuct889mc1596PpL sznxytJ/bTYH/tpszvzAYX9pNmd2rPJfms0ReE39TbM5PWK/m805Iv1nszmf01X+aDZnar7mX5vN 6RP93WwOl/xuNmcXbaDZnMelzEgcbWK/ZbqakRixUTPSFLAkOsbWakbS1kTdcJ8iQfBVdTZQN9Qq Jmr8hnPU1YzMi4mGmtEUMlrNaGYxGatmNI9oqhm5FBNtNSMPoqNmtLyY6KoZhRJ9NaPoYmKgZhRP DNWMtrzwMeC3nGPMbzjn5Th+yzkm/IZzXpqqGZ0j49WMLpElE/gt55ipGd0JNmhWN3xILNSMasjE ZjWjN8RSzegzmaSnZtROWGpG3zWY6obnadRkbWNqipUxFWg1y5ia6mBMzVxkXEvN8jSmZvsbU3OK woypuauNKdsEjGKXZEzZ7zKm5h3CKA4ZxtT8M8aUY1G+MeVUbEw5X8coC+4aUwsfGVMutRhlcaMx tbTDmHIt6jWm3OhWlLu4FRXoIWNFeY6wopapWdVSPtpWlK+xFc2vSNuYttzKmOY/y5gWGOCAf4uM aUs8jT1pQf7GUgZrjGjeCca1tBVJxrSQXca0MUWHjGlaGcY0vTPGtL5Fb42pBBJPS8hKtUvYZ5eQ Ypew0S7hc6xdQpRdQrBdApmSlWNnnmNnlGOnlWOnigHFHDvpHDuxHDsaBr5n2rVn2n3OtHuTlWlX k2n3MNPuTqZd6bxMu0uZdqft8WR6pt2eg5l2OzPttmTaZ9pF4ymkieWZdh6Zdi4YwKgzM+2mZNqZ Y8Ao004r0041004RA9KZdmKZdrRMFELa7ULcPoe4vQlxq8kKcXsY4nYnxK00xO0SBs6FuOF/eojb QTzsDHHbEuIWH+IWjYHQELflIW4eIW4uGJgX4jYzxG1KiJs5BoxC3LRC3FRD3BTxodIhbmIhbgLE 3pZsoQ20ZpTe2BoxxocYihsYEcHbBo5CVQbCzw1EXhuIfjJwFGszGPLNQCLYYKgo25EhxZYczpZS YUtrsp/IaDBlIyXlogzkyVMrMqyrlRZroEDqZ5HhZLatwRziPILMdTawdTew8zNwtA8xmLfKwKHP bf46A0fHzQZOrgbOOwwWHDCIWXjMwIXokRWZBnIhGuOYk4mQs0Exs6dddaDZpBHjnggJ1ZLlgn38 ZpPiRh/3mcKL7mSxBZjjz/DShehs9qf0JJ7epY/VLHbGU+4n4QLWNVZr+E2hrxF5rMX6L6NWqn2M OC7zsS3inMz3iP4c7VcsQabLuntj/dbxm1Ei6arpKzbxm1HKjBcsGP2MPlySxhtoR4msJxG/2lHi N6PE+dmOEsVYQUvht6PUFkfZ9ayjjeuK+9mQ0kA7Sjuo+9oZTGsiqG+QwaRKp+ykWqMkU1MFtVIF +0lr7LLUyCPZO4T27U5VTb2QWrNp+K+WlEh/+9A0SvoY/2KcJOI60JKSRlqaRtqS3y0pCQWzO381 pGTtQPw6ffCtjRv4qcGINVArvfzhjlfUQuHwk2ppZLe4AbXZYN3yp+uCibrx57atApkcEkUMjMvT O7gGV0+aPxbdszOdRfyFVwRRjrL1PzbtTBdVM1DJiP1aGFse+3zN0PdmWtn0OsKvky+TopHsWDgp hdileKSEp2xI2Z/MyM1eL19KF1S5lHIvpS6lNYWW6pYq8CZ1wj4Vq72cUvtUz9SIVLIxtSr1VcWV VIH6nRUdqYIcMoyjybHgzOG4ckI4CZw9HHYu5yLnLuclp4VDFatKcr+qcsdxn68ZN3/VPH96YF9Q 4TJuJHcTV3dD6XtyhnuFW8F9ze3g7k9e8yp7PS2hXTD+tVbFxIq5FW4V3vUi6yv2VljsVrXaO5J2 taKygvDrzU6qn8PQqg9h8Hh/04LQvfq6+tb6OFqLUsvolgktM1sWtwQ1qrXGtKS0HGt516F67qEK T1vpB4t92l2bcWJ9Ts/tltqWphbeKzJaQ6xDX0OBp8WbyJvLc+MZ7E/+JLmhs1VVUG037ySPfYF3 h/eCZ864zJAWVrPaSzYbaTMsGbYMd8YZxiXWPgapYwWw7jPqGW0MurKc8hhlYqY8S3mJcrDyFuVd yieUzyuvv60c1KjOr9c6VN/eeAjPcande8F+Fjt2U/yF5afaqcVcMl3fRZ/3apejWMdhR36LRXE/ myzan+xkt6FziYcgpU6xZFgarPGsGaxTLE1bmrSwutXebo/9rCzWZdYDFlGwHRMrYDsr9nmwue1s 26W2Iits420502b8/k0n7oPt4hQxV34NcbbreymNVmdXP9fVrtsWv9tTsYYeVKjDPOF63vW2a+1i 0T2k3VUgWD54bLB5sOCD63EbOoXu7BTUCAqOC94ZfDy4KFhENnZvrLSwRu5Nz3TB2GGxRDPWIjYx djcnJPYCZxrnVCz52fzDrzUtZXxK3IyUZSmBKbEpO1IyUoIaR7eWpfBbCdHOuDt560he2S1s8Do8 cWH5Yx5hJdKp6qmmqQE3iVhH5A3X1JBU/i8gp1JD+xUMSjZ0jn8oOLo2tSmVl8qU4qhx1nHoXGnh 0UpClQ9JKGc9Zy/nNKedQ7XUcTRaSH69LHc0dwJ3JncxN4gbxyU7ufzq2lXcGu4Xbj9XsqK0dsQY wwqrCseK/Y/YMryHxipXBNjsiazha6rCrXslU1MqyLGKAGZN19Xrb7vuVfDbCCmh1cvW1+sdaTV/ fJwmOIZMr3epD6hfW7+9vrl+RUvseGrMFlNLaX6jCPQWuRbXFhKkPKtlpzJTeV3LrpYTLedbyK8V r0WKp8abxLPhSS7k+fNieNMXjT3Ky+WV8voFZVzakzS4CpJrw0tSIh+57+F95pEfvKGMadttTK6W 2Y8zY8xixC1hBDPWMWYHiRmYP5aaIkiNLWSUM54zGhl9jEXKL5VpX3zG9nhnTZmtvFR5hXK8Mrmn XGt7QZlnu822WZnoS+sTdX1Tff5qx69cvV3/jD6zQP+m/jP9z/qFSZriLCXWD32Wz/Xz3kv8q7t4 0mz27qcap0Kovk88X1Y0y3pHgdfV61e8yEnWBdYdFr/NnYtHo9zMHwutDRXUVLUdZzvNdoHtcluR W7YzXRee0lx2clj8Rdu7tuSlbYutmev0FA3XgJTvsYtcmYGusa47XDNcK52sua5VruSta5ercHBM qnawZbBtsHtwqc41rZXBW4IPB/tcD7HlkR6BFTJstgjr/dNvWyy7y4Krg8nH4PwSlRNXr2udkInV iB0fWzIjdlHs6Lp3280fN6YLapGU2GOx+bH81rJMUs6n3HxKaVVVrz83OmVCysyUxSknU0ghd2fK c64P91ZKTcqXlP4UIpla6PqzmbjlqYmpyamSaannUstSU3q1+e1iiXKERpzOVRjLMefM5iw9u6vy jzXvEuceR2CmfeWQUwIL3ghq/+AM5TK5RlzJqdx0rnqF8TDtSfJtb3ZxyQnuee5trkyFKo/HncZ7 3EJMKmwqFlb4V8RU/GxBjdyoeFrRXtFbIVGvXG9Y/0P7mM68+mX1kfVnfU12V65htW+efTym9Wh9 bj0prf/uRST3GwvINdXz6qVaStRaTFrI3KtEduoNaUEd4teyumVbS2pLXguDt4OXZkPpnJm2VJXw pHnqPFNeHI+k6Afw8vUn66fzCng3ec945DNPNfVntd+pDFeGL0PyZ61nP39dLqOK8ZbRf9Zzc3b4 rZnCI3lstpvv+rk77lOd4spKyvrK3918resfhVgTF+UA5bXK25XTlQPXarPXhQsZzRPUrVb+qPxd eYj+KH2RNfr9+hIbdRU23J0XqB+rT3boZyBv/3B9rs8MPuvKYBEVljHLmuXM+sFbzdrGSmXF5bHu sZ6wGljfWOK21Yf0WnVsJ9na2XbRg+5fquZl+4uz/4js/w97/wHW1LL9AcNrUuiY0ARrgr0cDUWw uzdKsQdQ7BqqiIUgxa5BiqKoARW7BrHXYMGGGuz1GOzdoIgNNVRRhOxvdrLJufd+59z/befe9/2e Lw+LveY3s/f0NWtmz541R7xcvEUcmQ0PEzT3XyVcEz8Vl4rrxTyJy7PDG2K+7lQkcbsOkARJyEjJ XEm65KNkmnTeya6pJ6DH6meSzxKdhC8dJ41S+EphpaKZYoF0lTRbelTKNLVaqZWspaynrL9spGyy LGWObMBz0UbZAdk5WTXbnnre9cgX22YkKcstnd4/qNnXEhnUyMzlzRL752nuD8nrJveVJ46RT5Uv kPt95eaOf2t1kYtEufKL8gfyd/Lv8lGKJwrW+/eiine7LvopxiqmKRYq4JrikfqYoladpv6o+Kmw VoJA6aqMIoKUkUr65L7dSqFSeUF5X1mizMUqhcpJZdVJVW2W0GKQarxqhqpHSzhetEZlaHHPVV9U p5qaxRZdt59bwXV711bdXT1IzR+vnqHurclUs3sVBbe1ZcFx9VX1E/UndTfNAJ5QE8mDamqUZopm nmaFhm5yFzXwQPNO811jp22u7aoltYHa/S2GuMYVmc1+Y92P75qzr4wre7u8fst7718T7mgu3e3T fOXA3GZS6mXN1i/lBNmOyCM6NP3xoJNplzb1lzuZ+o/0nJm5or0ju8A9YLgt+6bJhG/1LSL9Sm5y G607/bOS8DoZYJf3eleyc9k0OChObNeoMv00e9Lqdro1L81E/uhk9ZxiUVYFIXJbVdyjkcv4d4S3 /V3CutsjB4+4C0RA+54OW+DN9jLqLuyE87AVzkl2VXChIzpcHW7Whasqu8lDtW27iXw79nToqjJB kGHKX15QZmGjYMNI6GBnr1zsWlQiusDp6ZBYvPi1K8TkdLLvs4poJPZ00n23338n1NYVoqfaSz10 VNFEr0Mm3QZKxH1t9kETzgpyb7lrB77KznBUFCvSxmS6oERM94rjTuoy+4uClXPcipq66QVyeyLb /OPGjPOLhG3byRagDtqVls9bDKzdNuKWX4cHO0oGh5t+fa2yWxImShAtFSrfwRrRLpF11fePN0Uv RF87504Ca0JAXAiq8u1PjCQmE3N6CrdJciV7iTPE7R5uQdJPBOtHNzeO2GRRqqyneIg4QQzXZIvF 9NEyJ8U3xM/FI+XZlNhGQp9hWL/Lvaipe9kkSYzEtn3/o7FOJKlSlbrsWD9xqXAi0WPsjl99C1sM bLSmvsCvg9+X/TdbzP0BY0XjvjchZ4qhpoaTy8pY6Tf29GN5x+rvIz1YGeVygdlKRWa5RcSYLKgs CsnqMEWa0bwyLkvnMBn8pGOlAsVCqVzqup7eLJKolr6WWiueKxxlHWW3erqbXVGMk/3o5h4vm3W4 WrlPBvmyEll3VbmMLXeQt5f3lCcOkV9WSeWL5Wvku+RTS7q9KWra7Y68SG7bvm7hGZlmz/imJJke miV7yt2yu9peg8t00SW1X4c+Dy6kb48rvHZDMu57UzJtrjMV2YQkX3LZ8vsrXkdmjFntnyHsuUyg LF49s8oi4voVnPC7VxpVPrvSvLL4is5pNpxU3MAKAq2JbL+yT9pZCX2VYuVil0XqDHWacpPydg+z xeeuKX907/ZW+e5VhLaJCjqrglR7tCGqOFWqar1qnyoxX9WN0qjKVWy1g/qxg0dOUVOPfmp/tW37 2LGZ/ITG6utpkyAn/WuLgf2/Vr76oplRlat+E2D/fsTP9vbq63olYcB3R/U1y6i+UKtmDTKx8gyD R5uo9pqeGoqaqOFINTUPE5drtmgOawo0Z7hC+jgXnYav7R/rsYvXS4tbhMdI7aiWDwXLtJu1V7Tg KLqrLdZWa02pJlRnaqcoW0yFUHFUKrW+2jO71rPsMFVAJY2+fnGpDUlSZePu/Zy9spagSO9HeeYP bnyoajFwkvuTk2OWfO5Vviex1bt96udj+D9GBFF8kjxaXrN68s/FuoGcU1iX6EJcPhi+bOM3i4i9 HgXL1xzxmGOmcvEMu+She44ureft40n1CvVij2UaMAwsdwsnETHEFME8Qas+czwdxPsFZ+w9Lwuu DgcfyQ+BpchDtFTiJRohihDBbNEy0WaRvVQluisqFlWLlq+v7p5d270l4UJUrFhde9hFdLkbuWXN 3LZ7PvYtXznnTtjr2T3OEe/cx7ybmLeMyL9OWZNbl+6Y2+MZZUWSi5NG9VrCDqg51WOElVPC8jXO CR8IWM6zEt/ZXBRNnwVaHhElhvlYq1KI7xbekRZJn4g/iVsd3Ns9VdZUcsa+ezeJ5yrIk9O69i5J jfyI5JLkoQTeS35ILKUpioazBXEae2TX9qBHmv7d30mEvo1CLwe6HDrqISv4XIaOBRTV763rt2Pq Xv83RzrtbTLC8vEPaf51G+v7hYddZAHRQ/oFl1OnesjME3a+n25T/+lKYdquwXGZu8bI2Dm7da3R /tmyZTKx8pBMJQvZ9VQGpbJ6GU9+t7Cf0l85UD5O3qr5hx7VyuXyM/Y9dsp3n4e26qfyUrmDIlLt rHBX+ChgtCJKMV9RpVYojiguKR4qcHJ7Ztf21Cn4yv7dbaixHzOy7ljjJjH1u3+fuO0/cZNYaimu adOyuGrYmMP378/u8eLbc2f5gO/sgozcGUqFZ63qZ7xKfJKn7NGBOjEx9HkJHr1lztS+EtmF7/t3 Xf7+8BnBMn/3zd2uRLcN8d8rfyhVmhYqkeru4yEq0B9spjqkma+lh7T0JjY9I7S1qjP2Pe3VjXVZ FAxSj1enqh9Tmeod6jz1NTU8VZeqw3k8jbPGXeOjMfW40ovfq1e0JlHTv/uoGMqXG2lvRpKtfe3f kmeyzre0G7XvZphSl3DYhKRVi4NUZxOSvDK/PuPnXNfxLoQdniSw680Fsw/snOIwOG6mw/UdTvMc vrn7z2qeNlobpRUJgNa2vBwGqW5pX2q12sxcYUuBi6AD1YuqG9jroWAqxZpf1SuFWtKVS5ymblHV FPgRiGfHa8vrzhvEG897QGTLeJm8Hbw83uyI3olTe39/xSvjsRxTO4n2VlD98QSlhBuhog4lAUkO HNlXfOyQ8s2wMasG3FvZwfiar+qZZsEezny/6NzbCdodT1jkfL/TJ2p5NjFj6/bvWuAzOO61T/z1 Hayx7Apf3ZuSawJ4KlCI6wU80RG/ziL66FwyRLRSPF5CH507bVlvHwnnmWh+Ve8q0bdJCdKORG8C IoiT0plEMpGFp6OniVsE6S3TEkhsJ24rfp/Vp2xTeZ/h4mAxy/HNNviqMi9CJBm1++EHIiedXtTZ +l0X9/pqvWRhfIE4aTuQxwVvHYcsmplOVs/aco89nF2JS3dgqsWI6gRcuuNSfYsTl2x37i4ZJOHJ zegJg2lE4ibJQcl5SaEEbqbSp2s2kgqlb462uEJIWQHSPuHSydtKFBulB6QPpdBe+VpaKaXnqfQ0 9bgyWyIznFI4+mHf4Gd9C8/LCmUsxym2pekkS6jtfiDHJDjRKeyjOGnFvCdbv0cfuz5jg+zJo36C DaTJU42uFBfmFlo81I97TxZEzxqSnbEoOFG/glVrWkR5362x2LWARUK6/ak8ixEX8vba3czzLb6f Z6qbtWKP/LRcpnop18oh86SlooVCpPBSzFD1Vs9WeC9TDPnRt636jGJ+Vd8HCnh0J0h/LqaPcr0m QBmmhATlUiV9LmYbrVr5WlmptOeqrnH7FVr066oiVSxH6kpf9MKO/EHIyHkJ6qqDuemkrOvN7nmb qHdbv7u8Kh634Yh4h0r349b7Cyf4t9+Frbhd8knFCqjdJG+uhuHjy74OU0vUmZJkdZZ6j5p8OuaV tkz7QV2rPtuhXxbF6aTp86Cft8a30RXeXE26BvI0poILmvuaEk2NxlzbTEuuFRDaAG2YNkHb3Ycg B5cT27S52li/gOn5l5UnhnwnivwSR2fk2KWfXzhleOvDw3gd5bcGUjXky00Jh8aORjUDOtx+xw/6 6b2hrYVker0Jf9T6r0upjZREdI5SU4AUlRSX58h7Oma4KFg0hiecyvtlys7GGbzAaOI470Q/8BB/ 5P3ktRXMFhsULYgUzBWkCzgSpeCC4L6gRLB8TwKZO49sJBKK3EQkmvOoZCdxgogVpYjWdcgbRd5+ lxeUL1qYmBf0RMQmItkPttMncaol9EmcAQQ0nMR5RfJYoiZeE/wdmf6DOeKrm8g2Yk/xQDGME08X rxN/kOWIj4uvip+I4ZO4TpwgF0rcJN6SURKn41e8hGe8DCfMkuYyg5Qm7GRwUkYfvZnVse262+/a ZnWWTplY1jZroJStXN96f6QU5koJxVapUnpBel9aIq2R4ns9FH4KQhYgs7vrVaLgzJP1eeC1VrZb dkp2U/ZCBibyMSpbeRu5p5wW69PlZIkqQ54jPy6/Kk972z/jU3n/r3JQ2K7vxfOrdIzpVivbkJF6 eNulLfvesCrNpf4TFC2rf5KHiaIVFnc6/JQpMrfBhyv7FWcVdxRiTU5N7h395OPCtYb1vq3qaZq0 PcrTyvnm/YM0n5QHOf2BozL5mqrtqRqiSlBd0y5WwW9zj5H688I7tFZ7qGscBkCnAZPUMWpdkpps XtEqe7cQhgirNCbai+oH6nfXuSZNJ2dzuZaavsFcbgcNW246CnXy04zVCHgLNXLNds0xDVzRPNZ8 1DjwrLX0qZWVrjYDrvDGaZt7D4jXLtFu0MJ+7VntO20PUYWWQzWmOlDQixpKXRExx0xSU0Ze8Y4Z 532HKqJs169PrnHqmfbtIpbzc+tdVxcs0Y9fH++3OLXI/dJCJzx+KZzp8asXb/p6ijKsWNfS2/Wi 9ENe3deCD1cNA9ji7xYPr3v0CrvrsYFt+5Td6I2nbhv/JO8GT0584QHF2969maCLgBAECBYSQ8Rp SwUbBePnenuIbwpWxHvDW8G74RGSJqLOoiDRHkmICOJEDQeYd5NqROWivfQB5o9TfYoSuW+TuJ2W zGKb5LJ7DeWO6TEPdK2O1bm3yBunpXDCyj5O3flwp+5NsHS5Zeu0cwjP1Tt1Nm02i+xS/TminPgW XuKye+z6xGeRte4lERvYXyN2s2sidDL97kdW8K2Rs4sI7uiZ3AT2pLk5/GCTGt8Z66IzzFbFm8fG Zlp0IBXBgDg5MfXs3bFcHxeXdXWy0Bui3QRYqHwXsgK7sVihFlDruhVOztLxbQ64qmNRaajN9NXc VfEQyqdAtwT4KBVeanL6s8Flv+8LztnhnrJgeg1eFoxquyazuiaSL8aNsqt51/GU2iXp4KiN9+uq zPzHxMCEmetWSnZ6W9/aFRmHomfK8kWNigo3aiNjXuTEbAtuBBaLEtlINz8JkZtr591TUFFXCHLs 4t6t3r9eW+09+UfQyr17CO8ckRvJnhM8IlV2tENZl1fiY6Fpsl+u6+JWEWVz41xZt0btZr1ezhEe Sv0WV8/um9i8zxPFgzfUS4IMHTn4vbRya7n35ICl2qqa+TU+VTdD06YtOdTyfbMln56tapu7d2Ml lS/eU0WQkjz1j462GzYvDVhaH6jZarMt+01o2sWtasWaaq+n8ra5g5O0R6/4m0eCg8VtKnhLSQVh KXfSdjwe98I/7dPNnPeTx3pvzoxIHbw5Uj7EK/7zs9QLWRMyF2m+z5h33DQSCp2pGAtF3lOi7pEi qNXrGIt5MCJ1iebRmZUl/Z9uVAQLwnzbj7//LNVm14RMVesy+43JDqsL7lPHnjX99PUscV3lXFW4 pZ2j097rqq0W42KWvA9N4xFPOPNl1/OepYbs0k3I7DVpGy/xkRa3JbMpe1/WjKYyVEd+DnJ+PrFe 6LT30VRpt88n6l+Epo269CzLdEtxmup5yhEc1YIZP6jjtkOfEOQmB2rDjm72sUS/aM3OLQMTWjvt 3bNSU75T8/FKaFpmpcDZtbzHtGepKG9CpkxQZj11/Yncmmwqahw/QvuQeK4y0wym2B2c9sar+u9M y2u7LTRtOjHnq+3x5MJnqQF5OH0XnDU7Lufvo1Tk+dPCl9Cb+ki8nly6cuqd+k5Oe6t2z/aVefxY /yI7IlV0NC3wUbluWebLpO15ung2qZK6Lv5546JvbiD16d3K66YVhL2q5HT7ljt+cdp7SDPMgn2i d9Tp+jmKU5f6tCt9llqep6M4QGZSk8cNpT7vIshGrOQfVPyGKmJwu/RrNY3Xujjt1c7u9q3m1JU1 oWnDDpv/WmzCjlv8Msnriq456Ah526qRc9S3XJ/NA8u3/rFoUSLopm4uQIoL6HEsS5h5hdLthnGc 3WBx/mLBGfZumHqzoOn5mwU3Wbth3qOCTucfFTxDu2H5m4JeXd8UfIZd41yWW/nbBQh4sIUT1edt uYQtBQdp+5D3dq5Sf02QNFI6NyxNMSJVerLaV792Nd1FV1V9uXV0mV8BHwuCBe+Oeo0bvIgF/sNc u2sbRYJsajG1ZrRHBauEY1dkXfyGL9O6VDysdf/5EDawOSW72dYlo2VRsvmylTIXRXxe4b74s2+4 vidlN2S5z+ftdyt5w5KDcL9vtzqh3C09oYX9x3nV1BGCRI2y3Nb9ZL/xTxs09cDrtz/vKULTvCtP l6zqvVcTn+ILVotSFldQiPxhvvX+zRTqDUGyj7Ud0/xn2cstq+Y9XX/o689erseXV1iXZU7/MWX+ kYjU+19fTMq6NPwZvU57rNpkvV09dTm26d1HBPlN9f7u7W3rqmIUQlnAUr8NAd0v4y4taibnhTpW bFFQQD5y7bdpTwr1jSDPFh7jO/2IJ0YHLO3yOmVB1s/K4js/9r/9OPdTXem6kRs/ZDya16qpzqLI c93Vfc8LvlLEzNMvzC7P5i5y2ls7RhD72fzpRqJG9n0y26TZ1WvcRRMyPaukzVTtLIqo+WO2J315 /5KQFR8d86Gqpa3TXtW+29f4TRyebiwW+F/YFO6n+ebogPvjx+igovC0quAqarlLjYtmF57c3Do1 /lFMM6e9PxSWfX6us4lbHJHag9jcdGPTHjte7Ip0wA1+j/+wGT9tK3GHXB7MhvttqJPE8SORkx8v r3d22vv5TrnzlHd1C95OSeo5N7tnv1Hlx4uqT+K45iuc7lABT+6pSPfp0ZRTMXFO1d31dk2uvYnp 6RkpUf1roo8WnDmleP9yw7X8Y6df7DJtOyEzcp52yPHC1asTdw02o8a0nPuM0GVVamf2ftPeae/G tF0148Utri2Lkh8WXus84HFR9ei2n3NasCjHn2V7CbK8ByVv/+VcEREs0xSM2H9M5LR3/DbNFmG3 JutC0zYtFSwa0Xv6y6LqPW1fHFnkqxMsaXt3zHa/C4mb1Yeu1rQ9X3BD/Vz95Za1KdSxKbWNprXG Q+OnKTpMTNMYBv6B4PfhhOa65vL0KQ8ibnutoJpfnoJnaNfna/HQ7YqKnCbGU3d9TjqQ5EtL8SrN Vr9RZOgAbpQP+tZO2yrG36dL3Fif3nGhPomD4qb5zNDKtJnaHdpL/q067IixI/fF+L31t2ji38p/ B9evE9kmoKs/t7E/O7FpYGeM9fbvMKq3f7cAv+BftRrt87ldhiQEJA7tfOFcyr3gVOAhXvIoVvNv px6Ed6F6pszwWOAbsDRxhkfY0gd+sxf/EpiY9EsgehIybDrEDzUhU32FFURobcxhF+rzpKcbBz8Y zCoczn7jt3kt531Nl8YaL1bwG9Jk8pTnEojzm+ExREqJDlxKlmZNqw+oo40P0EbCrVDfjLLrHMhB EwkpAYuJNcQu4rrsBvGc+EJQxPaB52McxO3Fz58v+PTwpIp+k/Ow6US+nNIvxhHkCvoFe066jiCJ j4UZk/YIJmcsSOZ+TU59myJeR05N3T4gLhUCihekSopTU2+J6Vc3SHLdbmSXxBb+A50De63mDoQu gb6ruwd2W+2T4R1AbgjKSOoWMHC8xPBSp147iot2jOX4krQdlMfj16eSXyRS6fxK39XNQ31Xo/kr q9+uWFW1balwyJi1vBSfQd8nSA0vGWGndKjs+lSJ8r00eQ9b5iADlbKnrFg5USaVLZatke2SJZ6U 3ZM9l32RUTIb+YHHg8q6ykl5D3H4CqH0Zc39rV/mJi5M6jqBn5gmeL18/cmavVfmJh67hN5vk+eu 2n4loHj/FUnxsSuJJfIaubmimcJu5PiCFv6DrJwDp9zjDuoSGH+ve2DoPWFcoXdA9JPkwm4BgxIU SxWwUXFAsUNSrKhWPB175UozZfZW5fzK+HvNQ+PvoX2/vq89c6dmzt6V0+47HGB3raE/8jqs/8hr ngquT52rdVBtfe+qGqB6qo1UQb02XbVVpVRdUN1XlahAnW2ubqbuoibU5n6DJxSYdQq+aP2gbPCD MpMpl++/rE29tjY0Vf/OhRrdgiR9hh8NpbYMqiDI+WseiA/vPPO0S80lzo0u32V7JjfjenqxD98t LK78yiKftwhmJSNz0NhZkC42TW0ziaLGfMI8/0VTB5+7KNRO5/2YjBVDDadMdwr0i+zOZVi6GBai qeYk2XOZsng1e2bVzqK1/cc5bB8Q5nAjec50h3MDEhx0TrPNHP1PI07J/fKjCy3vvyRlWs7h+wsO 374IlAvlmhyWq3I7uaq4Rxn/HfGs6m4eobV/VONwgXjPLfh659sW6FqY0QLt1LUJ3goH6YP1J0Ll XRNIqH0Uzi1JtCq6FTn32iXeS4E20rwafdpf1tzfxXSkGxtGJkOHgioPlIxu/LzJr7vW4m55U5Oo S1GXBkNqDHAmxIs+2D/ked2j6orL9pRo9pwKN3u067XHffSucWX5/u8VAe4QPZJz+KGOinDt965H 8x6RxH36XP21LkFgCa6eQu5F6gH1jvr+DZmweF+IdrwevMFmjYrG8Ja3Shsyy2JICm8db6/pOwW9 SFcVk5hvMpOoXXHw0PEHt8x2D6i//NLMwYrFSvdio4Lzq6t5po0jvOwF7QTHewgGt5g53sa/WZwj SejXbjfEJIY5wEL7PkG93Q83vpk0PIh7f3XjyjUvTwtuCciPJ/jUQvmhSwT5oFqwKatX3Elo+01g 1hFu+rYQiUT6xc5Wu8UFkxJXihSiIx0jvC6I7ouiLg0p+ywqmHRS7NzvxIagWNMJUa96etwIGkSM J2YQMEiWSewg8ohrxFOiiqgn/HliZ7G72Ec8dJbF0Mniujnivaa/9NiR5P6MciTJ9/QbGOp0JUFu Cb9VuWf9/ru3zNKSL7w0q5QteDrJb1ud6p44kdXMb/E3sZmkqWRwi+GB33ULEuk19BWvq3FDql94 RrMnH0Plcr3MgQUOLbN6u7fPWjDCJYt7v2fWe53D5M2SQxJyuD3VOOp+m4sE2Z7YPq9+WYaiUPJG gogDSymJjbS11EMa0SpNDjnbpNLF0iMd/RbvkOZJoy69HnpHmrNto9y532eTEY5vj0V3e4D2r+ss 6ysDsayzKk6WKlsv2yfLlz2SZWtkDe8Mhs2yGPaZniHDiowrOROeUB08qm1IEj2jTp+NO4XlYQUx r9HaVjVvbplNvVR/76WZe+MusdWW4JRzUs516njhifyT/GLhIAcdlU4+iModF9GUsiPJIz4dei89 JqvfSY63KeSH8KMF+nXZBQ7fr/R2B/RwwQiLh8tH2j/YIFmheGajsqkSjZwcfJBsSux0sYDTZ74K Liv2ESuv1I9t9znDoSyDZVGVsfP7hhkcZWNleOupaljwil4IOtKx44VU5Xql6NLrYbnKBa/mq537 Peg+1NTrmksPz9SH1iqBylUFXCpIFamaq6KFzCksZPxpKVOjMlcPb35zeCd1XR/18GtVNR8XKQ5T tQT5lAwld1L7WSR57UZc4Z5dr5/NvO7NvvnSLJ/YdHrOcl+zLPWe20VsdEZ9W10nf3OZtAzS0ltY Igu879bQ611eQK/kUGNH1xBkdO5tQQK95NjswT1ub/ei59wFI95yp6/5wtWt/1o3WhOlIVveGXKg BZV/nSA7dVDFtH9dfIp+sUhEck9r4JbmpUarCWvjzRvVkv5aVXikIxtJtDO15uzhy7WjWtYF8Zz7 zaQNssWgl80SJA7vtT+0lpRGJKLAixpBRVCzqdXUZuoQpaLs71LFlLj5TTGH15g3/Bqln7Wf+UFQ ZPfLjbL296LnxHa71h+QDH99f+b1lgOu+qdedduHBP5rnC8Rx+Vvh7x0LVrL2807xbvJfWuyc+TO GskBq2bkb3uJbrrPFd/cNwVVcZ2aoOO+iQtGnPeZvuaazzwFKTgb8JwqietwzvcqQcqynOrNCu7n HFWw5ggIL78swR4B3cn9QqGl2GUSV+QoWhP10rWnaIjoYrG7OFzkMkkkVn0Nay+YFdp+1ptmCT2D LojgvqhEdFpqTjQjDAtT5PS/MBHj3/xmmSaAthLT2TpwXe0y6vBIIEn5Kjfx/CC1Zub173Hq5OtU eZ3jGXIFpwAGi6+mawKixYni1eKbja756IpN9a9oFuuKmj6ss4RRdoLsJbrAJnWWkhYSkvemh1cX 6nEhQR7T3Rvf/uy4I5MFgRKi2VKpBBZL1kh2SU4GfpdZbNNIyiUuCftOr3OSdpJS/v2kFts45nLV 17JJOXW77bI2Sw9JQSVdoyyWVktNZU1knWW+smyxLERm6KgBzW8GfKeXsoZfO0yvQVEdfhINS+89 YMyOyb1X3998a+b1e8fyk6/bWwloMYtay/fczjxSZFjwusk97xv13b+mT9z2q7k9eX6VP2O69QD9 wozdhe9NH1YMQlOufh4Qe2WL7/35V3Tb+LQGQMqK8kqzGjU+0ROIL6orbRUHmyp+USCi+uQgxXjF DIVMcTLwngre3jmtuKV4uTHzCP3Ob/2xkAAn5ds7xSrV100be75GTx+XfLliWKWdoT2nBMMyLVcl VHVU9VYNU62VqGaqAlPOBNKbkKA+heOzhF7Qz6ltRvq84NaKXmialZe1GXSw0nOQ49rBI6+9vmlS r+LdnlZuDq+h7XVdmbvaR02OjlH7ciMfvIYvXPK4Rr9qXh3TvIJHL6BVmrhxOXbtGsd86e/NPXxp GFc3qpNKrburJjM2f37YPJu6TJB7rJRWu9fcP0JKTDSEuqb145a9uhZauxXWwtZOhb0fowhfzRjN iREHqRONaItewpcbp5XTn5DPrAys0JxoVHeOav/15X2zW31XQvhuFVesDdHGaQnReu0+LeRrabXY 8E15e6onZTGEGpFyZsR0ahGVUWPVv752ReK5dhkjle101TFrvPnHmix5WHVpzCL3K90Hzh9WeI+3 XKtTPaE80/u61lEb6A0o72K/UivTliwJIdyHn4u6UZ90hePz6ZScpVzObumrC4+uo9+SkJ1/+XD5 OFV/gyCfr4spbp8u2X+V94RHbO9ezQNTQRNBZ8HJwEVE2vAIwWwBzk9f142CA4IB7iMuC9KG18mJ 9l8vzun8s3kgKk6PyPRxFrmLfEQ20igRzBfpB1bRbdFD0XvRDxGH3hQ1MuVMRjBJBBKvElQk/S6o hRec1pyotYkZO7ng1AcF/X7jWWoP/7ibOps0w9sY88XkfsIznTfzDlFEVBC3CK8VzS9fZ/vM8TYh /RKSLz9KCGf7JcTy2NZLK9+UhIkTxOSyrmcmBcTcIUhd41jVBjFrv5iIm92wjyVzNfjLxq2iX4e8 3MibSdsavOgQN3KdZNyqEFn7r6vbcAcdzngTsSsslbbq5CiFYsVvVp22SfdI+QbTZVppUMqZi4m2 sro2slN5tfQbue4U1/B26VB90mCw2XSFnWpbXpzao9Wxo9/9JcfUvOurxtfN2S6T2V1/vZ2fLTsq uyzzZh1pnOs3q18s+xynp2ny5b15ZnIvyD9+O3DAVJP1Xz3kfnJyiibpNTtHcbRskKvC65Td9IIq 9QI5AT55V8S0ic5f5VEPWql+uZNI6+Ljx77e3lchVrzfEVQ2RfHLHXdV+6/Z4b/sZ4fM4rfzuHJF 8VjxUZGnAWslvQ9mgDJIGaPfB9Nhq5LeBzNqUu2oN8oqpS6jht6MwBHaYiHftNeeybM+0kNd7qn3 Ra3uH/6c2qOq+MX6Hh+SBSsjn33lHLgboPryvezY61hVimqd6s6lu32o5ofs9O9/qV5LAvC4Zv+c 6nrky2r6XTZhkJTtfOZVF4Szk6u9B6yoDhyQVa0L/NHEVN1ETcbbbf9KVfNfEWT87d7iNgVJa6bK h6sJx2qo5M1Xr1Qr1EcuV2l1uudq8ot6/Nhjr+mXk6eLR/XSfNfpuNTWbStHdztUga7w25ly12v2 afI1SwUaDRj2FLbX9tcO0U7USrX29J7C0S69Rh/XXtWanP3paO0zp+7aupTQ8uwOp6+27nXaLvHW ed6nVayCBbKzvVOdvam6UdQUSi93LlKNSFL/6ri+3MLwpnMaZUmSelnJvvC9nc9Qj2X3gzy8B0zy 2BI4INIDC8unVClFUgXvLrC/2BTiUbTphl2NS7+ncOi+Snxsb9gUG8eDYxevigr7HeKpeOPHpjq/ 5qVU8tJbj7YSFPZ7LNq6TUj8qOyU7v4sL+upB0QJ5gtWCsZKjgguCR4K3gsSfwjsRUb9VjQmhzVv zBLRBtGTz4Wry15SBs0ST1hLx3XoutYqK3igb+2GsJLep1itrR7eYS86EnWhWpQ5Z3RIY6IDoetF FG+Dr+bBVrgJdNHvOCj9RrwujkksW+k3lnea3p6S0DLh5Jr2CTGNk10SNrn3TNCN7X2A0J3DDaXS N50nW3Rb+HBSm9QNe3uroZyQFJwN/zqqsbiDuJf40UrYIM1ZJBNnirtsHB1yTHxFfHFi2JhX4pxF +6Rbt/nPFNzgH9zxMi/rQEJvCQyTSCSdFbTVtT2S05JbEvKdRCtBUjtpW2l36djBU8vHjpFOlT55 TyvMKv2OFVGHhDsE1sZ2vf7088PUHfXPep86p1fGFpsJKMnZjtsNW9GWEYadeCunvHnDznVaXHPr eNkuKlkeMWnOBtPcTe5HvzVPWyiTy0iqlxrlzHd9QsjIR9M1t2d9PyKDSzJJwaqd1mKDXnzkMkxV xp8PkIfJqRsdt9P2/C6KdozNlcefn6/0avnrbdaNCy/qUxfmWSsECldFvRqCFA1WQ0/9ZjXUXDlu 8NRxnZR9lN+efOY37j6bdDnzQYzlYvnPD32KX2s6FJl92qzs/u3n3TM72Fs95YVR7EPXlE/3ry7R ycjO9Nzjk+ccGanfeOphlgs9F1wsoZJjZ+VXPCiZLvNXLQpVNZkYf9fH8XY7m+t0Z13km0gb/3uk gg+qFHYfra+OfsN01/znXbPR6ig1Kh6XpPbVDdN6tWSNuP+6PlVcrVGXq9kaNQ/ojTJDNLQFy+V6 A5Z7T2poG0vjBwdzF7Tidrrjy04pYNs3RRZ8x/f1Tq1KTrVPnM+aQzUhSXvTgiALaqE5SbYMoWwo PDEjSd+RfTXHDikrCOs23wlW4zZvFvlNeVfrSCVz265w79Co7SZ3x7a61cBZh5rZ9SyqT1wN3AT2 oo4u/ACT6m/7dj/NNjvcxtzC47CKD4jTyIV9tRW3frzpF5b+3IWyATZym8c7i2EJfIPZKaDJrmCD 2d5vM8e0qz5TxuGHgE7Bb4vaubPauZyjUKZJE4eLaa3QqvZjXYuCz/O50MVilgsbxbkh6/ZehBVV PZ7g6qxFWcSevi9ds7t3v0KMID4SV35Ycvixh9AsF8DTIDTAC9XDETCYgQ56MorMHkVOsYLmfJaC NgIdtdPbRgDWbu1sZ579pbHcp2+z1EsQILgsThAsFWy0U7F3Cbwidk0YHGxyWfCopUnjD5xFrUoM U99J2dSLb6t+ON20JH+SH4ki/Zce1I7Hhi89LGaPvCoLOuIicsydHEQlgzSIVTkniF+5OMiwuUd4 SPQyvKP/jTYuodz0K6+6stgeLHDhEfSm0UzCTmwb1X1CvOeNUDR79HrpYwKO9JgzqVTqKC7v2Uy2 T0rIEukp72hxlN/r7Se9uv0YhEaY8VMvGXbx+Nmo2JAvdpVrxOXijXaWdjyJ3a7XEztJ+kiGS2bt eCf0pRqFhtuT5JYjvPZWcD9BslSyUdL4CNxPxUNKKv2S+KPkp8Ra6pLXdV3ijTZbV3Mn0pt8yAjp bOky6XtplCyq+8R4T/DMeSL9JK2TNpKNkUUqvWWQrmyinCdbIdsmy5VdlDk1Rj6vZGUyltxe3k6+ RTVYzp8gj5Ynyj/enaS3bL2i/pdWJfb0jtOjqMWMMR8SieKvSwIvjSwChVnv9uSVkxJWwFVSEagI VxTMUqQpWpWxC260sbjHnUTRB33R53yl7M3d8o61+30xjM4/s5lliVI5nk0bEfQK1whlm4fKKT0m xXveuocCrm3UwCblkR6Bd75onimPK1trj2iyPymZDc6nm9+bG03FR8TOiAiPCsGMcMTcuPgI5xlD VZNUMaokFSRc26saeER1SXV6jUnPe1l2fkWqixXnJRx1Y3UH9Te7ZQcVWIpda/ws7eW9M+afPqcB +9k0NX/j1+o2CsSivh1Sq9R31cXqavUlodORshttTrG4kmaaLhpCkxigCdMkaJZqSjSR2ojeEk68 51xbRNX4CUTaIz2gEWwWSLWDtHcFEoFhqbdbntbttB1xOjq8VFuvBR7lTLlTw6nRVBQ1n1pJDVZQ wUfLuCeo6zrus+91L1ihAXpR5KN7mpixs986bqYFHk2Eegk06H6m485ulzIdW1s5vwUqgbHfSoUy 9lsnWhZ1YyfaZFxk/2hcrGssh/fdnnczWAR/ZGMR/NyF/caVa9LMC31yee/SznsqbwGvaAuvXeQo l3zOov5cF5tX8v64OVs84LFCb1mA4gKs8g3xQqH1dr35tIrS/FC93aYe+tW6V6yNPVBjPPXMvLTF Q3HpqU/KeDbl23ijcFH/9iMWDjAxa+O/cECXiWhR/xEj3EcvHXB+7Lhg2Ao9zPiQhaztvto3Xnsn r509gq4CUtCo6+qLa0x2EvcFzyZ2TNcIZ7RlX8mIuv02WwRHRZdF6Uc2tc5SyaQc4paK//KY/Fgf YrhHyGgiipjfp/7yrVRDD6fwIHbn467klty0HJeygYfc4usTC4h7BLwlvhFm4qZiwwbuUHHZYdO3 wfkcqyQu2T9L4zhy7usmHebMFAuw8ubfrMPsT94tUiHzUqcExSVR6nh20JI2AVZJsDDZMrln4CK5 P3bsS1629K1DsnJ5yEL/lBEsOAErJQrJEUmN5KHkfYD7ojoJ0NuD3KTe0lHSKVgJXiHlb5PmSi9K t9eH0vsqzBf8+P6ueo3n5/alnyzZzub0ClmQLFJGG9uGrTKl7ILsvqxEViPLA8/sgfmcSUdX+sEG MdbKrwxMXLD7qe+CXZ/EawsW7DKVsOHRyTYBk45SxyYe6xkIav+A7ElHO1+yvBZ5zPVm6EJ/F9bi Me808nI5WzFI0V7xXgJb1RMVUsVixRrFLgW9pTR4jIaeX9Ift0BYd+X3QcrxypV9hh5YT9iyj5jS n1jtYb6wAq0SqexUbVXdVYNUeXC2sC6f8/YN1wWPqoUCPKoSUHot6dQYIWQcrS65MpD17qkvq+Si KjCRwyrRqNgTatoEvH2TWllcDD0Dl1D+2HGkMrPmS/HJWhQWpI5Uz1Wn416nVF9Qw311ibpGba4x 9LlxGqGhz23UHHgVfk6j1tS91qzss0gs7di0BHHpHUFdtA0bgoC2P3hAe06r1pon9ucv9oaprSo/ zFEtP9WMWur41DfNgT+QCkxMc4ig2G/atwmY2gos3aNa9wy0Ivyxo7u7Y3dOXOu+vcKfU18oirLh jeaBB482zDuNt5BnsMubeIVXxKP3ANF2eQ+8ivhA7wKKbL6gScKyg/E11wefbB/DWbVwhqzdWTxM n/nQbSb1jCBF9Paox9QJovHImy2DdhNwvHlhK27Q3WONgkpbOwZ9OcYXBnUU9RbdPWJyvPEwEUoJ aGWeeJ3kJUasFFrc8fd97M+N0JBPA4r9ubf8EVsdWOT/2L/M/+WoMv+PAVQEvSci9IbIdXeSKO2M TYSO39ptyVE5hPLB16tkYNqRRC39PSKP9EdLSoGMcOFFuXFgMmum56km8cPIVLdMNzmx3cXMLegg kRmIyM7hudfIYv9RxcFs9DoQNZ64u/2k+hM9Rws3rlncs8mADba/Ct8QN6UdYlipkwaxyfZl3Th5 nuU23HcuSaTQ5GOPndIOow+2bDHH8kTr4FhUHAy62zEosXCmXdlQ2aT5Z7vFyVIXAKF/qZQxg2/i w6NfK9FWtOkdTgXjxJnyReIMMb3DaSDcnUxvGI9sPqV+OH+EIPGzaK2Jg4Q2pg1DJvXJCpfMkqRJ 9PvzJoV/SwzJnfwokJ3DnfwmEHg5nwPrVzfK/hFgvrdltmXI4sl8aStptyh/aWhEdCSbDaPmS1dK FdIj0kvSh1Nw8JJQXo5WimSGD3uA/rBnhsxBninbIaM/aoSnMqmqXrZG5Sx3l/vIR8shSj5fvk6u kB+RX5I/lB96sSuyJtHkp9x6m0n5wF905Q8N42ULLML7zOs9XDBOa0GSXTesLv9L5WPSg9eTHx6J VNwTDnv4sjWMeljaWvLwR+spDw8rChT3FEVvFS/f8gvfv3V8w410kTFDaV5BziAl68Hr8FsTprEi XDQOMNW96UzPMQrlEaWC4D9Uvt971vVFSGSTwrdhT94gNOnxbu1g1YnukzS12sBzifvzO1GntMOp nR/fqb4fAYrRuZ5U5Jdl55cNvUarW1WFztsuOEVeH5EQGk1FxM+Wxk4T+puGxE+xIbdcClXHq5eo EzdcKLt03DFPTX8umdnaZK3vm3eX/L4UcMvVHk2nlDGvU19Et7TrwW6/yt5fopmpSdZkvQAHOKg5 rynUvNFUacZ2PQMz2phcsOVO6aDtpR2qnaSN0QqTtGu1Fdp46mbplKfvklqBYd21BRVJHRONoB6L yAjRMmbd9W6dnbkZNWhEl0EjhF6x7IiQn5Q1T8Bz5Q3glRPCSN5cXjpvK09pFpXP+5VXp+H5vVhQ 7HDSZTL0zzAX6HdHNd/lM0owRZA4T7BCsE1g8lVCNn07OZCLou4J3gqwsi1qKvpF1E9ktkXUkojv HPX0XftQ+gsiyBNdE9kQY6T1ogVSC6k7UUh/QhRF3K1zPtwjUEolxEdERUcKvSnpjJCoaGF/KZEQ HR4SOzebOErAZeIR8YHYKbMStxS7iPuLLyrNpgaLY8Up4gNhA7IoPDB5OZJknaDbg2CTsAmac2K1 GOZkilMH2o1J/Sm2lggkrpLgAZKgSbaJTd82Wc2dOlsCyyT02w36w7ZiiRdu1Kz4zlOfvnu22lM6 UDpOOl0KJ6SWyhypSHlOYVAGHzSS3a1zDJnjs97NP5aQxkvDpNNHyCJkQG/h3iwbplLJ7sqKZdUy nLpphm8rJ+24c0mLlYGtQYljTiU+zrOqNOGvCFlsWcWZkmZx6e08+Ypl3/MG2qErcDjZ4spZOf1t RIWcozjPd8rPbb724kXutE6KPorhCjAYaF+nqFLMUsZ33niEs6R18j1kfi1A00/ptNfiDuzSLFKO UT7XRGlWKbOVR5VVl5UPfggsTg2NmBXBmy50Fa5z751AK4VAf/bmrdJpp6jmqVaotqkKlGaCwvOq QtUbVdWZE70FXSzskk3N1E3Vv6ih352j1fRMzbAyEjTJSXC3xZo4Fne6YdRJbBh2tmoE2vjO0yG5 XTfb1ZqdGnoXgK02QgA6zTKBo6Cb1lc7RjtVu0DLWvXZjd6AelH7QPtOiyjSgmpOdaVIKpA6ljdj BvVdRmVSp+z0ilP9oqDEzxpOVdOT9NqXI63X2TlWTkmb7l78gFqxbJwHDLoU5nE4ebpHY14HXi/e UF7wJF6YfwuX5mvb9OfOSOHBOt5e3hnebR69S3u4oFBg22TajA6TS/qjad2PiTcIwGnv9H6mkieC o4K+klviD4JCwydwj/a1mN5hUDQPq83hPnGjRFNE80SwQrRNdFp0UfRA9E70XWRBXIJo+ruF/kTU iLSDKqwjRzYhJYnziZM/+luTpNRlhov59ylpzeI+pBIrlpknDLoEtgmHk5sl0O/3Sol6gid2aZxx O7i99/1YbrSH2E8MY8XTxAvFcvF2MSVeLLm92Tz6+bq1Sajp7FD5IInTXmi26IR8mSRM8lk+T75R ckDy4ZxELXm0j7/iU2RE9JDwXtaT+5iltw0Nur168RXXEF1sXIZH6O2s/pGurGGTB46WWijnS7vu 7rk4J2wfsU+6/3zMr8Fmd0Otl7cOjmkdbPI03Gzlt8iURWV5NvQ3A6tMC6gA+hCRu/S+5WvLo62+ se6XVQ1bd27Hg4NL/X8M6CDp3mzhfdX7b+yh6z6cmCX0WrDd/Hgi6eIi04+tuwlebk6Pfehzhe2J EzNR/kxSpl/I6mxydCcV8JMgj791HOK4qNxicN531+AvFQPyCgZdGpp32j0ob1bcpDzdxlsbzVQF qGdqq5CjC+stzVaSWY2uv/pGjb9HkMvWzJpPvak7QdBflU16mvuOcIvtFXr3cd6vj4ryLhBFu+x2 wxYKWqIUsEY7RVALW60LUq2DOyx2NIEI0ZJwZapX4lDFBfTrrkv7rp3vN6tmCYKSjGUZy/snrsg0 vMb2aNN1+4LtTtOO5db5tbhbbrf7WdizsJgZ2f35YRMmqu8ev6M8Gku5BevKUk8/bLJvw/iXgbvj kPoEd/F+v9CAW8FW/mH9ruio4XdbjeI+8desahWyD5osLPQPrs6IShm2s7EUKk+4RVTl9Z9mAj8V jzT69dK9gxMDlCHfI2ZK989cqJQrYUGgB5Uz4UkHj118kiJLFiefTGn5jSLIkpDRG1tEfFhRRFyV F797tPeXis08/4xBRz8oaw8Of22tqhOoXE+Qe+8H592kjluS5NwhHz7+bFG6oki/7GoZYzc4rzoi z7o64Vjj6u+n3QXVmaerCd3kyXU5quMqMugtcbv/z9YvF7gMbz97tnLAddUT1SfV0RLOjcY2BUFc h4KKJgVrW1yf2FENvdXDLsm1mbpZ9JG3N4a/NtuvPqt+FjbzoTpTl621eCXzuoBO9Ln7oNVD2FTt pvHWjNI0FRi+VQT6Y8WX+m8VLehvFb8YzgWvX/CxogN9AozxMJthMuYsm98zEk1ZgBVY46kkxQM+ 2NDHGdmBPdA2YilHcIIm0BSoZtAKWkMb0LSFdtC+sqwjUJ2gM/wCXWB2VxC9r7KEqSFg7WQNMX9p Zjr8uzMSTwBAiX9gZppT64ze0QH+1sz05eNCRDhQABZ+jJnptxohGjThL8xMv9UKkdpoZvqFwBmV /bGZaeoUhz6cH2hzvgabMfSTDHamKYOtGBZQDRZkegvD9HamG7GdLLei9lZdPVyqy/pYu54YxvNw C+F5uCfwPGZ0W8bz8NjK8/CsLpMZzEtPt4GTAMlHeB7dH/I8DvX4yPPoWc/zHMrrOsMzmNfVMx5T Gu95V88tmMnFtOEysm/xATN1XHvLrqh7msPtFlsw5WKqQ5T+ZHVhWARF25mmzUz/zEDt2sbTZqYJ 2s40bOnZsbpMQp+zHtelw9mewusTWo/q2L/9655Cvqhrdw7f4XbzHm0cDnbpgWkoVoK6BGMmHtML wYnWVYLEE62tRCdaX8aOnSJfVs+6s/i/q6sbgP0P9mGiwM0d4Bf2aHd4WOJytsRlZ4lL0IoSl/gS lwklLt4lLrVvXe1LXOpY7vB2vzV525o8bk1utCbTsGOuNTnFmhxrTfpgRzdrsrk1ybEmP9P2rx94 kQVe5MH9XuQGLzLFi4zxIidgx0AvspsXKfQirc57kd/BHV7PJB/sn0kWzCQPziQ3zCRTsCNmJjlh Jukzk3T9NJNsPpO0nklywMUUytmUCYeucwuguCDCFZ07cqkAmWvL2DwH3rtqClEtsXoWxGvQzmSN 6dP7oGtNGWVo4c2AMrTw9qDpAB2hU2mZAJYKwflHGX3qQBmy0lWWGfoJj2L6iR2P7idKzhlUyPMQ HPZuZgHmjvy2Nvxmq9vaW9rxp9rojWJz04F9DCw7C1bZv61hUwbD2IA6LeZzqvV2sUfzOQ6LWa0F LwR+LSmBjehTOYLGol6ioaJJouIfU0WrRNmixKOi4u/xTejjXyisA5oJbQlPYiAxjij+bj6ZWE7U vq9qd81E3yMv3mps6dzoV2KD4FM5bZ7EYGE79jcL27/JBZVBLnwtRxRjYLulqsHANjrwm4Htbuh3 DWzb/3BGgshggH60gW3vUNH/YWA7ng5/K/j/3Qa2vSlvb06t3sD2slgTrtdfG9h+8pcGtocu/DsG thOFf2Vg2/tlq78wsL1g+V8b2M7vFjOdC0Bb2FZyGyxs36YWCNETe4Dx40rL2ryvcncoY7efDQuP zwfTiQADVZzAT+Vixr425zlUjxbwrUvL3MAXJJxcIQoX8Iu0ZTU36ZPsvCV44Giipa1rQ918mRBN DNZbeFhIzIYqLKR3SflBBvPaV6R8k/E252dD+E9n9FBm3/z8SeiW7gvVUr6otrSs2UmgzWu34YXg EnSG///v//79kf0iejgvSlVU/BBP4R/INIPO7Y89pe1yZcBf2yqirXXQtopoG2q0XRva3lkwGKwy TWfCzgGDjaIU+M1W0T9io+gf4RuueKSGtYMNNnDouM3AVbypLe1vjhPj1VafMn1gOoWWrAbOijUd 6VgGq3kGW220EZ2/Z2PVYA3dEK7BQh/SGxprw3aGFixAAlYFtGWVQFfWU+jNugNDWFdgIksFMawz kMI6DRvw9QB2n8P4r9j/GQ5XjMN/xPeV4vs/shqhYlYz9IzVAf3KckfnWL3RAVZ/tIHli1JYfigG Xydi9xCM98b+XXG4tji8AN9Hx//79tobrg32ZBvsrDTktcHKINLn1R4/p4W+ROxYddCSZcDKQMhg n6EVg72GDgz2Cjox2ENwZ7B74Mlgt4BksBvgzWCXQcxgF2EEg50HCYOdgzAGOwNSBjuDS7GBi2N8 T4OMwU5DsvEOuTHcGgY7Cwrjk3cwWAEojSk4xmBXQcVg1+ESg6nhjjFHdxnsGTxnsJfwksHew1sG K4V3DFYDnxjsJ8PZs0xRA2aJ69uAOaISBmuG6/+PsbboBYN1wG3EgLmgQgZzx23mj7Ge6CKD9ULn GYxAxxiMREoG80Y7GMwHKRjMF61hMF8kZzA/lMxgfkhmDBdnDBdj5KSM7wAUxmD9kYTB+qERDNYX iRmsO/JmME9EMpgIeTLYL8idwVqjzgwmRB0YzAG1YjAbJGQwLmrJYAi37IZe0PBr6AUNti8N/aOM 6RV/XxLQlo3Yxl7UIAk6sFioE657EW4JPXAvGcB6AgGsQgjBPSGWdQ1LgquwDl/3YPdJjF/B/oU4 3FMc/hW+rwjf/wr36Kesprge26ArrC7oJMsD7cE1tw6XWAqut1h8DcHuAIwPwP49cDgRDt8J30fH /5d9/7e8/OMygIUa+rYOOjLlWAG/MNhXLOEM2FvwYLDXOK9/jD2F/gz2BJeHgXsMPozvXfBnsEJc UgZODSMZ31sQzGC3cBkauJsQzvheM8qFa7h0G7h4xvcqJDLYVVzuDXdkGMOtZbAbkG188k4GuwO5 xrQcZ7CHRgnx2CghXsGvxvwW/h3sEzxhsFJc1wbuKzT041pc9wZMBxoGs0AaBmuEXjFYU9Rwbwv0 iMHaoYbYOqKbDOaCChjMDZ1lsO7oCIP1QIcYrDfazmB90FYG64cyGYxAKxmMQIuN2EJjuJkM1hfN YLBeqKGOeuKxyoB5oIZadUfDGOwX1NAiOiKCwZxRQ8tpidwYzA41tDoeahhl2MbWSbfTf77/Nozd tH29NmwPrDOo8SROhWdYSjwvU0A7yARPSIbBMAvrNNNgLoTAWhgDR7B+rYZh8BX7WKNB8AsaDEPQ MIhCgbAEjYHtKATOoGlQiGZBMUqGKpSJY1SABUsJfDzu2+KWxGdpsFuLcR32t0bFqBkqRO3RGeSO tqO+aAnyQVFoKBqC/NEvaAQOMRJ9hRFIDf7oCAxFa8EHzYW+KBjcceztkSc0Q+1wapqADqdfi/Oh 0efnXx391fhuQ9newvcYMBV+qgHLxzM2A4ZzxGAH8KzUgGWDE4MpcDkauK14lmvwXYunugYsE5fw H2PL8FzagC0BNwaTQR8GW4i1TwM2C9eCAYuH4QwWDWMZbAZMZLApMIXBJmPN1ICFYt3UgIXg2jVw wbCA8Z0AaQw2HlYw2GjYwGCjYAuDjYS9DDYCDjJYAJxiMH84y2DD4TqDDYPbDDYUnjDYUHjBYEPg A4MNhs8MNhi+G7E6BhsEZsiADQIr1IA5GbHmqOHeDqjh3l9QQxw9UEO8fRhsGAxEDekbYuSGMr5i GIMacjSBwQJhCoMF4tbfUAbTGd8gmIMaymoBg42FNAYbBysYbBJsYDAJbGGwcNjLYBFwkMGmwkkG m4b7VwOXz/jOhKsMFgc3GWwuPGSwBfCEwZJxnzRgS+Adg63CksKAZUAlg22EOgbbAhSD7QEuI3H2 gykjhfLwHMKAnYZGDHYFbBjsBsPRY0YD9tSIlTB32LE+Mk+xZ1UxT7ZjfWdio8dhHZMWLvrJpKUR qmQwG1TGYE3QOwbD2iKDtUJPGKwNesBgndENBuuCrjCYO2ooUw90gsF6ov0M1hvtZjACbWIwEq1j MG+0nMF8sOQyYAPRPAYbhGYx2FA0lcGGoigjN5nxHY7GMZgYjWIwfzSYwfyRL4MFol4MFog8GWwE 6sRgI1A7BhuJmjLYSNTYiFkYMRPjvbUN/Rd9gwbsEzTE8a6hT6NnDBaAHjGYGN2EhjRfZbBh6ExD P0cnGvov2g8NpbGbwXzRJmgotXUM1h8tZzAvtITB+qJ5DNYXNUipPnhsMfh2R1MZzANNZjAXNJ7B uqLRDNYBDWWw9qhBYrZDAxlfAerLYC1QTwZzQA0S2Bb9wmDmqEFSmyAhg9UZ5f0PaMxgX43jwido xGCvjOPHMzym/Hv6tpVx3KJn9W3Yi7BkU4MHKsRjYiEMQHewLLuNZdcNEKMrEIgKYCTKh1G4Pkbj 8XMsOgjj0R6YiHZAMFJAGNoCk3FtRKGNWHptgBhM8Wg9ll8bsOTaAIsxLcF+6ThMBqYstBk24XsU aCvsQtvgEMqGPLQdzqEcuIKfeRvtgvu4np+hvVCEa/4djq8UHcb5O4Lly3H4hk7Cd9xKatE5LGUu QD1Oow6nVYd+xXQX0yNMzzBpsF8xphJM7zB9wPQJ31OK6Qumr/ATlWEqx8+qxFQFP1A1fnYNjqMW KlA9fEUUfEQIywMWeonY6DEmNeKg65gKMH8KkxLTbkybMWVgSsF+czHNwBSGuAhLfjQckw9298Xk iZ/lgp/ZGT+7A6qDdugHpmqsh5RhtxY64nR1xOnrhD5DZ5zWzugjrp8PuL7eY3oHXXF+RDhfIvQG 02twQUWYNJheYnqB6TnGn2J6gsM+xvc8wvQAP+M+pnuY7mIq1Nf5vzvHUTNjIq3fuzASoZAZE+mZ SF+jL8n43jSOjjeY0ZGeQwxnfM/ilmbA8o3cKQhifA/itmfA9uIWaMC2QQiDbcEt0cBthnDGl26N Bmw9bpMNWCKD0W3TwG2EFMaXbqMNT1nLYFshm8G2wU4Gy4ZcBtsOxxksBwoYbAdcZrDdWJM1YLtx q27gGsaS/biFG7AD8JbBckHLYEeMI+sx3BoNvudwOzVgF5gx9vcxui8YsLsMZ896acQ0Ru417hMG 3y/GMfurkaN7h4Erh4ax8/ewn1gPN2D1TErpOVg548tCJQzGQsVG7jXjy0YNegYH3WUwDjOy2mHf C8ZweUbsiBHbZcS2G7EsI5ZpfF6qMY4UI7fY6JtgxGYyGBdFMBgXhRm5EKNvkBELMD7Fx/gUL2PO PRgMIVcGq8U93YDR/d7AfYOGcZfu7wbso5H7YOxltAQwhPs97AXTB+1Yz40cLQcM3BOGs/8b7N8b SxoZJcMjoMeSKJgEMXjGJ4VQPDcMwxSht8oeDZEYoy2yT8X+02AmnkfMhBkQCwl4hrgQzyWWwDyQ Y9qAKQfTQTyrOAGzoQD738ShHkA8PMf0BtNHTGWYajBej/3ZaA6Y45G+EVoAdkiG9fjFWINPBSFa Bq3RSmiLZ5HtsZ7QAY89HfF40wmPMZ3w2NIRKTF2HPudxmHO47AX8T3XoAXWTJriMdARy0h7LC/5 WH5aYTlqhmUqB8tWwDK2Dl7i+F9BKU6RBt7BPTzzuIxdJ/G8Yx98gR14jrsV03pMq7F7Baal2C8J h1mIczAX3uOUv4M4eItLohiXzGtcHhpcNi9xOT3D5fUEl90jPG++g+dhV/Gs7ByMhuMwCg5AEH76 KNiEKQtjmXhevQL7p2FKhnGwCNM8THMwzcKUgCkOxuOynoBjouvn35X7MfgphhYkxXVt4KJxjRt8 fw+LxXkzYPE4DQZsDi4HAzYXFjPYPFjJYHRraOAyjb5bjdh2BpsLhxhsDhxhsFm4rAzYLNx+GrgL jG8C/GpMy10Gi8el3oC9NmJfjFiZkSs3xlHPYLMBMT1rPlgzPWsBbosGbiFuPQbfZGjQqVOZ+SU9 j2rB+GZAGwbLxG3RwK01yoVs3FYN2E7oxGC5Ruw4M0ul1+QbnnIRt2YDdxlaMb6/QhMGU+O2beAK oUG/fwSWRrlgZuRMGd+XzNyZflfxnSmDN8wc2w5zpQxXzMzA7VnvmFk5LaOeMNhHZvZO67bXGewz M8un34ycYrAvzGqAHeb2Gbm9jO9XZv2AHqs2GO9YYXxKmjG2BcYUzDVycxjfIiyVDJjG2Dpf4v5n 8P097D6EM5ja2LIv415lwApwPzNgx2E0g+VCwxxiJ+61BmyHkctmOHoVZxSDZRrvzTDem2Jck0k2 conG2OIZjp69N3Cx0DCLmYnT90cyvqG/N7zv+tv+/nsrfo2AlvNcLMdX4RKnaTHmF+vdfylX/nPx 7MVx0LQZ85v17j8nnos4DpryMJ+nd/8Z8WzA8v6Mnh5j/rHe/WfEswOX1RU9rcL8Kr37z4nnKo6D ptOYP613/xnxvIDlQOlpIeYX6t1/RjwzUR7W/Gnai/m9evefEc8JrGM80dM5zJ/Tu/+MeAgsGUP1 VIT5Ir37z4inG4uHRumJhbrpiYf+jHgyWNVwVE8fMf9R7/4z4pnLckKb9WSJ5urJ6U/Jz1H83Ad6 skRH9fSfjeevn8X6mzsQmOFrWzYLtuNyXI7jN/j/Z8aKfybuS/+juANwf/Axvu/978Ydqm+/5fC/ iPst+ohlwcf/SdxpWKZeQA3j3n837nGoCMf9v8n3WnQQx33ufxL3QlzmYvT4fxK3BZ5H98Dl/r+I uxLrCZVGXe6/GzetF30w6kP/3bhfYJ38jFEn/+/GvQHHveF/lO8VuL43GHXD/3bcO3HcO/9HcZ/D cf9vZMuO/2ncq3Hcq/8ncZ/BbXwH/LFM/Uv3PxZTQ2rxHyQmJv5/pbZhBc4SqZk33RboDvOmm2vc w8RBtxkMmN1MdiwKbjDYT7jKYLVwhcFq4AKDfYMC49v0swxWBWcYrAJOMFgFHP839g39q/kuN+48 K4dVxjQtM6YpjcGqmb1qdH4a9rX+MO5k+wkN+y0BLWIwlnFPlinD2bHMse9/P4+0XmaI/xP0Y9L0 FfowmBZ6G+unlzGPvYx125PB6jH33097PrN/hN47fINZOTxh3F2SBw07Jo7CRQY7Ag1veJRwjsEO G3emHDTuWzkIeQy2H44w2H5QMtg+aNhtsY/Z/UJjO4zYduO9W4z3bjLG0fDG6CDW0P77ZbYKjoMh /pVwjMGWQS6DpYGSwVLhAIOlMmui9JryLgZLxpLIgCXBNgZLMq6XJxl3XKUYd2GlQMPOiSVYfhqw pca19mXGlfjleGz575eKwrieq8BajAHLhjUMth3WMth22GjENhvDZRvvbXhPsNVYUltg9/8gP5uN tbzFWMvZxlrOMdbybuPK9x6mvulWu4fBDkDDDpjDkMNgSmMejxjr+4ixLI7BegY7BlkMdhwyGCzv 72iIf15ZXDWu6V83tuRfoWGXzx0jds+Y7/vGfD8y5vsRruU/J+3074/SvhzeMPEvM74pSjO+6VgK zxlsKTxisDR4yGDLoJDBloOawVbALQZbATcZLAOuMVjm39Gi/7w8bja+NdsCKgZTQD6DZcMZBtsJ JxlsNzTs1jpgbOeHGI6W9scY7Djm/vv5uWh8k3fBuCv0HHxksLPGN1anoYTBTkExg52EVwx2wrjL 9ATW+Rqwh8ZwhcZ7G+r2jLFu8411qzLWbcH/pG4vAgc1lAUXNZSFKWpIZ8P7vpNgbhy1LRgs1/iG 8DDD/T62z4jtMWI5Rmy78XlbjO8ZNzGcPWsdkyo7VhaTUnvcC1gMlmF817rS+P51BdT9D8qxCBr2 hmrgMZOml8Y9Pi+hYS/LM/iVwZ7CLQZ7DNcY7BGjG9mzHhg1ogfMPiL6q46zDFbI7Nqlv6k4wWC/ GjWiW0aN6KZRI7oGBxjsGuxjsMvQsF/mknEnU4Fxd5MKtjHYOWjYp3oWNjLYaaOWdArWMNgJkDMY Hkf+JM2J/v1RHRyEmUz8h5idXnR7nMFgR4y7qY8bd1jnMbuu7XEuGnb4nDbuFztr3E12DoKN5TOR wS4Y925fMe5Eu8rs7Ka/f2nYE3ST2btG11UAg9HfHhiw+zCMwR7A0P9Bmb01prMEGnYKv2f209F7 jSYy2CdjWXxidtbR79gjGeyLcff6F6Zs6TlKNINpQcpgZcy+O3ovWcNO5nKYz2AVxr3tlca9eJWQ bMQa9rtXwXIGqzK2uGpo2N1VDeuM2AYjttWIKYzYTiO224g19JIqOGSM46gxLQ17+yrhtDHNDXOT CuN+v3LjHKbMONcpg+sMpjVKgK9w539Q4x+h4fukD8w3WvTu+S0M9hY2M9hrWM9gRbCOwV7BagZ7 xcy86X1mKxjsOaQz2DNYwmBPIZXBnhjn209gEYM9hrkM9hhmG7FYIxZjxKYZ741isKfMF2t0HKHG eCca0zKBwV7CGAZ7CaMYrAgCjXkL+BPmxXRI+vdHdfAFXhnbxRumXXyHhv2dtVDNYDrjVxIUWDBp p6Apg+lAwGC1IGKw79CNwbTGLwTpN1p/lMd/ZT2s4V3lfRQLdSyaWJhn6d1/XSL/mXhmsNri1kaT E+ad9O4/iuf/rrOGp2bhp9TpyQnzTnr37z317z/lJ2oDQ1g0OWLeUe/+x5/yR+3n/5oxdTFqG13g GWrANEbstRF7Z8Q+GLEvRkxrxKqMWPUfyqQ/c+10Bo45A9Mfxf3vleXvpbahLPsZy7KfsSz7Gcuy n7Es+xnLsp+xLPsZy7KfsSz7Gcuy3z9Qltw/SN2/U5ZPkD+O2f9PKMs/Sm1DWUYYyzICXqIG7IsR q/g3xrvf+q0n7rM0dcR8R737r9P7jz1lKH4CTQTmCb37X3nKZPwEmsZifqze/c8/5SfyxCMYTR0x 31Hv/lee4gdxLJp6Yb6X3v2vPGUMfgJNQzA/RO/+V54SjXs0TSGYD9G7G57y74wET1AbvYSlJe0T Pf2+tP3nWpQjyw4O6skE8yZ6938itcNgKlrEomksGgY0TUX/fGp//2yEdvo4bHAJDwApywvXFwnz cDtejGkZJjl2r8V4FvZfy/LBbl+M+2F/PxyObiW++D4f/f1/mabf0vKP7/8eADMYTcPLeLqIl1F3 I2ABgxGMBmiP09agM5LG00VIo0bpa3yr42v09WPusMdcohFbwGA+xjMLfIwpoFNlSO+/Im1+K9+J +InjcXmNw+U2FpffWFyOY3G6xuFyHY/LdyK+SrA7GOMh2D8EhwvB4YPxfRL9/X9d5/94uU40lut4 Y67GG8t1rLFcxxrLdZyxXMcZS26csVyDjeUabPQNMZZriLFcQ4zlKjGWq8SYgol/p1z/r5z9K6Ma H+hRzQQs0HVwRFehNboGInQLeqG7MAA9g/9mWuz1aTHDM/U3eGb8FWLQN0hBP/E8sw4Oolo8A6zG WvDn/zNN/4o0+UCfqYBouoj5i3r3X6fzPxPPBfQF3uqJ3hlVpHf/GfH0QG9hnJ4eY/6x3v1H8RjP g/x/8I8L3iCFMEiAGUB/5RQPI/T8DAiBWJgLg/RfPkkhVo/E679+iv6L+3vQR1f+xe8PI/qLXxCm U0zhS8AVXMANemLqDt3AA7u7/d27//rnBAjR9dkRUzNMtk0NmnOBwdtXz/8ccmaJUwFquP7l/QjE MB3n/F/9WeD28s/mfwIme4ZHgEdCXLYxOB2hMPXv3fa7P1scf1N8bQGGs8/+r/D0byKmKIanz1Kj z26jzyWN07dYxKC0Xj4sJC4+ItaAG8q1Jd9wtpsZc08XV0NeGk4vFYZJo6MNZ5rqZSCN/yWWBr/p 4y5MbOEGZ+J0JpZ4MMSRyLhpnn6WZJT/IG+Jf6DPqEE+o0cY/PQ4DQ8dNHxIf68RPsw99Blzdvhq jq9e8Js8teLDX/3Qb1Otf+mHQEexLQxl/7dtj45q1KARg8RCD6F3bMjsqOhIsPkN6+oiHDElJAYX uz5gVFyUtCsTrKsHVPU8OvMP4vzr378nZdhMu2vo5//sz/ZfaP8S+K0+RuGWGKeXKn8rh/6xX3Nc fc3xVQD/ePsfaonbHiNkfov//5J0v/9r9S/Iv2AAfZrpH/eflLd/++uAy5/urUL4x/M/Bed/ZwsD r292wg4jh3VsaKLWFgYfrqGMUmj9IRCmbxCiD24AAxnp+SX8Uznb6WMFjjIZqG8VVOXPMlP0vRyW JX4qb8xJbIxT1AQSKSgoKIB3795R+pnAsWPHtLBp0yZn3LcnU5Mnw7Bhw8Bd5u4OTZs2ZVLHMV4p J/rU5HsKmOnygjLjva5VQJPSMg0aqT8dNBxkINSfUtwRzqEuJm9xZfTismq7sOzd2bb0ucRUnHB4 xGxhoHT0jJDojsDuwmrkzpKxAkfjXIYvBXYceIwsLSM+VBYSFRTH5NmncuGHyrFkUywPm6Au4MrD RdpUn4T2cNr+BVVa1h4Gl5Yh0UgOCHHWm1sU/azhwJTSMhZOUult1odKNJgWjSoWhGLBIAZUMYLD GoFKy2izUBRtzIIARDZ/Vz2AVin8YarJKPYNmGiaAuwEk1GIExrECmJx13FM1nFM16HsRHSPLbZY byYG9joOhzOCk88i3lVbCJo3vodS0Mjmjbcj5NmU5dmU7eloVmtdSyUiGM5ez84yXc/2r8b/8nnr 2WbrOObrOEEW6ziW6zhW6zjW2NFoHYe3jsNfx7FZx9llu45jN0uwim/qDyEHQDdAiPxas/xas/f7 teb4teb6tTbxa21a5ie8J3hrJ2vZDuqpgbtbJzUTo+D19gVtWAVtzrELnPux6qkz7fdQsI61Ayax UigYxtoJn1E2Bd3QUrgMS+jvnlLBGdb06441sJ2sqMXQDy2M0dTx24NLUFe35CvEKv5qwU7BOpQC XB/nD5VlGaxLrBQw7eJZo4O13bGsjYRlU/3xbTtLvjUX7PN0aeF+1q1S5XLMs11jF8GD/oK9XN4O cD7bjbBL2o44lz2D3Rr7FeDKyTq/1G0LTAN2X1bzCbldbrPMIW2pm401jLoHI1kOVmyCZGvqUlk9 TV6oPYfyJvFicDNPsBrkscLuEWeo2z6CEidyY14SWmKc4HizpTAGuWz15Xpy4PpKF3t3f3I9sUKS T+SOesy+xALPAVl+1sCyATRDLBuOoKdJL7RNnCu+KH4gfjds6thUdqT/YIJ8Jlkg0I3NqLOUtpDi ruLW/Jr1zPvBB4l70reTuzq8nTyyc6BuKks3la2LXGrazY8FKdaQ5jLNm1UsuZwqJmDLAek5aSQS NxN8OL54+LRY83cDpD1yN87+YfJW+lyGWAtjudHHcdFPiJqyAmw9zLs1I97Gn/Vwne3aZclkdH6J e0e4AVw8HpVCK7kt6g6WwDvsQwqhhalLy7GJggPQ2gHamLq0tQZeq7mT0RBZlpSACUsdn/C8h0ZG maKdsmWz6lkcrudoFgy3BqENsB1Y5uyV8uLv7J4mBUJ1954E2XHyW9lcxSNOPctt9kibJR37pDbt kBw7b/UFjyXXs8yWzEyK9VviutIzScJV7paY3e7V1efXMc6Oio6K3ophCpAo5ilOHD7VJs82e+M8 CU9p5qTspLwo8bNJzHA/rri6yUyWcH/zxw2DxyaOVE5WzlHCcuUW5UllgfKecq8iUBWuSpylKlNQ SjNVU1UPZWFQa5CrtquOqa6oHqsqVMmKLAUI1HNNeqkTZ+bB/c0uheFqoYw+DF99UH17bJtb6pdq 0KqRxk7TVfNTZa0er5mhAZkmU7NDc15DG+8t1ahHobam2iZa2qK2WDtVG6eFVG2x0mCrt7Oqr2qP Fk5rb2lfvv0LCQyULy1XHrEgVYilh7asrvIF9b18ynksXbAo+fC+yuvEh0ozspN1AdGHq/oyCHcG YrgJB8zGfCufzJvDA/SpvNGPsk6dTHSZgLIsWH1MtqF6to+JzgxYJqH5uGUi01BQs8zmh5qpWeah QtiGPnKG41DcL6awGrZy0kEDEenQEtkffl9lAgM/ViSb2logKF2Eny2sLAOI0WkrKNzrVrgjqkdy mpxifa/8uSrfCpLzWWBJLcs3/V6Zn5+rocqW5Zs1RzzqPWWZ1obXmZVUmVSazxFCb28ci2U92xuZ 5p/KT88/mdt76XiTfPZkZDYhBA9rub2X+AAnBCSnkvMRW4bMU5Aq/1R6bu/UlejUxPw1aG8+exPC bVhkkn5q/3pI2We2C+adRJYz0KlTaWlhUJ3sAyYhkJafnkLlW7HBMr+yclEILE8/lZJvLQTde3Qq f/ne/LTkEfkdO6Ea9v4XkN6N9fUD5Ken8fn5p9K22TmcWppvUslOg/S7S5RQwrKHU0WA0vqdRCn5 3FNpQv4mJFqSz0rrwU9qBKF8mTuqlFOosj6sVH9+f0QYFS+Mny0VSkPrp34rixPGSyMjVPFTImK7 CiuqpFSsMCwkWhgaUSOMiLJAwhBhmCoqNixhekg7iP0ZJnSEEGFcfCwVEhU5JV44PYqKjugK0snC MNOE2FkDAepDP1YMbLfmRrjb+qeqodWVRFUVm6uihj6/LT2gfKaiTl2dXLhN8ZTwOd7CUsXh1tX9 rFZRA/VtyxQetiotMysto3QVHJjAQW9+IDB1gCl2SIvb2C9mHHK7p+zag72i7wT5oVLnDkcXWta1 uFv+oRu3ExDs176m/vecVe6yBU9ZBQ6AsGphg5WdBAsqOMEqmP02lFUDJrqZgBIsg+cnWM/jOgOL NQeWJwBnATJdBktgK5tNJdqQukbAYtfjgUuHlUVOwmxWMB5miwjuBVTDTWBfN2+MW2zdDs56TqIt iZtvDcs0VEWfkG82L4FtvoRtbpnoVctaaA42zYHNMpmGNnNMSsvMoYttO9syCdad2ez2ttwutrQa zjY1AavRgEzEfLMRjU1G2Ok6Inf4xbT/Ah1FkHQxbhy6aDafNyM0h1fsA9QMz82/Tj5WTrRGcByk jscQmtsY/2MlNT7GSm/cysaNPx21tzVrZzeZPx3MWjd+LPhoM41PTgfz1i9b9LfjiWrLzNrwy1E0 8Lk4xewQ9KipHRt+IouFoLOmgGUZPzzYBEbPiyMjna2mt0qMFcYMaT2w3dIOdYBC0aQ237cLLSzr QG+HdBJhh8cMy6utrAh+4TR+EL8dJvZw8+HtdPNsbhBusc2vzaSaX3tNuCmqBk0FF3V127u6tioi 1HTq0FaWsRArsinQdXTBupArKtA1XYuGyoIXoy5kKPcXVxnbtIC7mGV+lL1ogEuCIDixK3mB/VBw vZHwunnz98g0mEgwC05sRWYLs4WUXWJjMsEkmDvwgvPzNiNsOWJ+rju3tExRT9VTumsuFpZOulgI 5sfRkxeq65TpMc6t3TxVLi6uoPNKhmCq5wBpzNzYqEgKN+l9QteePanuQoOeSQ2QxsZIY0PiqShp dFeh0Gv6z+nCOrc4YWxEnCoidlZEeNf9wh0UbGRvgTO0EpHCyoZxrJ0UNGZtBR+0+TwXTMGSM30a CorEcpLHbYxYECTsGiBEITDDixVL+plWNTK9CHDVFKuwOmurZMQOXsgabuLDK+0wyP9d9Q1O2Rp+ xpCyu7A2Z1BHF1aX7uwe3Y4Dp+q07zHEfemry4DhKqyqNIdlXGCPgCdZtkJk/uZHtJrvJkRDfdpc dq2j1vvasuubPXe1GzAlJDqSisB6aKx09hRJREh4164uJFHpurB72kgsBYQhGUFKYVzUvIP+0Sf8 42Vzp0cIJ0tj9/lTUXGGabGanhe7kDYBoR39OIlJia0uucycNLCT54ursBBZZvN+ccOVCXzLTHZO O8imzOnZw44WQK0JdpCMiIgXyrzihCPiY0Pq3fQWRCBD1+lopWsrUUjhKOF0MlgoiJdi8VPg3yPM haz3zINgSyy24qlY6fS4rmNcgQo2HR0VHj9FJHGDxEVk/JSxicGlyCU9hL3YeR8s6rU3mBMLfVEM F4QIFeaLtW38eVEjoiFjSCEauNP2a9vtXiyz8O1e7N0+gfQONps64HaNNwEb3TMXs2D+MGl4FDV5 rnAAFmchgviE2AgogUKbIH4jNz4LLHrYj4t52Hoa/8HkmP62ZZ/K958IgStKPOnhClguWDPs3h7c vreaefYUEjdOYJWWrV0e2xZ+uWszYiQaybew7ILHTmdAjUvLukrJkIV7S8vaQhfaogB1Ui2gbblQ r2ihxxXS1hooU/ClNytmy5zRbC7AZiwZW0N/GLndGVG2WOdvh3W+eove8CLHGfUwrQGYXFpmASQo vHc4o20j6CPmgzr3hqESUIyAbo15P2FgZzh+xRndbzkCvnPotQB6/l/9y8cKVFneYYL8oqZ6rwPZ qbbChjyDU/qxwhKa24CTiSWeG/2FoZrjw51RoDW+vd0fGKq5HOCM5HQAixdlP+a9oGgPLrSk8NRx pNIZ3dJaASwuLbsBJAWcGNxIreFng6WaPvvbw5zOtKEab3f4zNskRBt7cwJ4YQ1rMAZthC4quK+A cu/SsrKyOgrKVPvP2yILG3JUUDOojnMgddS7agX4lpZJED37KS1ja8sWDGV34tETNTwDUtFToC14 BjSIonNOZzx/UKcFLBsSz68KDhEruKpBFhximwmKGcW7yHtflcvCw8Jc07a614CSTb4i1gr8r56d xWgw8xE42WANBr5itWUb9uJ2cQShsIezyUCBs4mZmde76ujGp8YJcqEJH0KFAluUvdGmHjmbWNju a8rZ15TL2efYxNZMYP+G/xpmOH5FDublTS32NbXc5ygTtG1rV0b06NKlg/9dy9doX9MLmPY6dLM7 4dCNbwEL8cQQAeLYduLvSWAF+6KPFdwcZ3avPa24h4R4xDrW8TUEmExoJ2zchG/2pY15WxsKNoMS nQT1T1gdCWxIZ0Wefw6skXbAf6mzuw83/JCUnjnaQhD3OZi8AdNBYBYJQea9XSwIF6sBLtZr+dWN hrjwxC58rIYH2YxwsR3tYlcE9hKXIIcmLo0jXRx7uhx/DoFurtalZcfb1Y2A42+g1s212cruZUQd hayKWPs8dccHwXbiGGHp6n2jmzOn4IlnjeclF+5XggXi44QLbV19gCttGXaf2VJio7t52LDC+GGF /hdddwh3iU+KLcOGPYkf1vbJRVercjFbcny0S7p49Sa3RoRkozuPNnt2vEcTl3DfZigoqCTeLyfI 9pKLzQbJfsnxni5jJSPgdcQbiEZv4GPFQhh45mNFnHWoBcRbh3JKYZZD+GzrUFuY89U6tCnMtQ5t BfMw2wkSrEPdYD5me8EC69D+sAizg0FmHRoIiZgdB4utQ0MhCbNTIdk6NBZSMDsPUq1Dk2AJZpfD UuvQ1ZDW1Tp0EyyzDs3ZF9woZPZ+WGEdehRWWofOPgNy69CLkIHZm7DKOvQeZFqHnn5m7tIo5A2s sQ79lA9rrUMrIMs6tDYf1lmHstB6hzA0Y0OXMLTRIwxt6hv2HG32CUNbhoWh9ElBYSgZBo+P6T8+ Zv+4mW7jYzqNj2k1Pqbp/vExtuNjLMbHsMbH1O5PD65ID/6UHvwmPfgZdtxLD76ZHnwxPfgMdhxN D8b/c9KDN+HL6vTg5enBSenB8wLTg2OxIyQ0PXhcenAQdg5OD+6fHtwLO9zSgzulB7dKD26aHvzQ Nj3YIj2YMyg4EH28MQgXeCdWKAvSW4PTreAW8qKfA+2C+6PFrfxY38uHoqsug5LumXOqnsNUrksu hww41ZJKLQ2oI8iyPior9aUyFunMKcKa0Rb5hR9OWzzMV6YWrkv9QUwQzV86cE7rJak7mxStabMh VXeosylW2L4vvt3BNJM2A3QBclqRifuFKme/1dy43i42Y1dnErCgfRx6mzpizDpdoWUTPtZpakgd Z02wGUqF0xrkYuXaEk23cw16DDAml4sGuLBgdAjo8jOQag1LlbFpsAj1xNiRzoeESPhr5x1Cu+Dh uGkiq5wFbflZic8UCm6VgqvOykrrqkwkD83aXrh+kvKzIkmZ1sTyxBuIRWIX0D3JRiNfbG/JB8dE /oiYJ46JQdmOiVP2BTfPD+YQLvd7odcoGjUu/h5oofGxGGAxyDl3lMVjH4gyT/ml0Irf3hJcboy4 okSrMlvYWMZYTFnc2jo43ks+Qh4h79RaN59tSpLF0d5fa3zfNlqZWkGQAap827zOAaVk2zes83nP j8hnCHflzWl9OG9nE1Sxpk1B3ne5haK5oquCXOs0JXfwWulFbvwYxVTFAkXiKkW24qjisuKRYqey VhEP1ru73VvQ9lwuSxOjHHz43CkYpclVLt+3RGOv2a+5rXylrCpTslS84u9BMeEhA+IjuqgIVYAq 7GhClKpqvmrlWU5CKm0vlZpnb0uSQ3+9yXtwcCh/ZSohvJc3cg+r4Nitp6oZwqslc1qrS5aIWI2v PBeoXdUD1EFqImtZ0YrBazMquAl71WeuXL3EMoVvUKh+o65SB2oeaFisPQnWuzuyFrQd2GGVxoYH gbtffRjCe6I5qlnM4/E+aPxrNVballqzI1H1I/u06DMpssgNq6o+/LOx71rZtzb1brznwqRjrqMC pEn17Z170DZWI+IpvY1V74gYKiI6PCQ6XugrS4gOi8dqoX3I61nLtVu0h7WdWmfH9K2xeLwjK/Fy qf9ZdqMr25a80pZpwzoVO9xJhs8Obanu1CBqPDWD8ty2m2+1pupQK+6s7dQx6gr1mOJ/pPx4N3gC 01nWu33devBgMG8CL5p3ijeb2MnbTHQkEp/xPvN0PL6Ae/agTU+HQdQIsbCnRzc3C8o/1mAeVGYx LCRsSlT0sPfbu7kJvJuMEciPdlxSNLtsj+C04JbgZXOHPWEz2b0ar1jyU2AtEohc29XhAVs0UjRZ NEe0XOS57QS5psrkXCB39nlRoeiNqEpkQpiFE+8Igels692jQoOISALmEunEQ2Kp9AJxQNpTWkOA ubiZuIuYe3auIF2w1T5evHeJeIN4/6A5J0lufn/O2wvi+wO5marXTr9e/swbevtO1bU8S0kLiUgC ru1sUgMlDUaCPTfd5e8X3opZUzZnW4wpdLqTyL6XxH2ShJ4sviv5sOfqz9F5F6znvSmFnbbfc1OE GdcvtVCr2VIHqVmctFra0myO9e71qyOks6WwTLpZWiK9rrgr/ayYpzCVFTWRdZb1lRHigME9unX3 cg8V0wZUD8n2+80sDUjqyvcOOOCWeESxYnnKlo0W8qN9lhTNPSl+JXs+lJql+5pHpj04NPDlcpsP 1/KSn4h3vnFe2le++mSHsclb8yKXVcQvL02Sr5UX7JafkqdVj85dUzXpIncua9tVGPDwLdnmqEW5 9Cpn3ddHEixV3o9kQ0vSTeGtGKVopfJUtjSbu2EdtL63Oyu5sFz9U/Fw28FTPhrorXRQzteYa4Yo JyqlysXK2jX7+Pf2+kpjZ4cMiQ2/vPuXmfkvtrvMeO0XFHRlaGPW6yi71jv4F+aNUU1VLVCxknmV diT8HHZQdV7lvfxEibekRmWuTmym7qIm1Nmd5hbltkms4KJ5UvVi9Rr1LvVJ9Q31c7XZF3W+xkYz b8M6HxZtOBF35im4v8zibdNs4nXgPdAUGiwnihfY3NvrHWEaFhWn4PfT+mtDtfFv7s6fp12hfT40 ZUW+GUmRJ1sse57Zg/OKHVRLkHb3IN8263Wn1E8VDnc/aZ+dMDN7e/yNQ+Sy2viUKgdXagBVEERF UidGbuEXjNzRiju/aeZ3r8c7ColdVHyyqt2nJR25F1NMLqZwQlndQYeG8pHNg0THzK7VbdmhNqmt QOh6mjpfFDQGLQHPB984bIguoiooDi+U95Y3ZAqav2HdWbfdWeX85cQ+3sNtUO70ivjIu2TeSLyF cBNzBR8cBR0FvQXN7+3FkxFqGp6ZhMRHCGXeIfEhoSFxl/aYTRUsEEwrXbBVoBRcENxvLrO9dT+3 jzXVKVVXzi/3bCMdUPEo5afTrBFXcX/qGh7UQ8SGhFENHWr05Zb+IZfXtQ3lLjguun5N9LTzdfgg qhVZEQZTriOJyQR/DvGIGCNetnnBhnX9Ym8RQK/aosGzgoJlweJL5hkyaCk7LlsgXiXOFh8VXx7U /e3SqOjIZ+LPYp14WunC/gJ/VuvAwSG/SMYlsHI+1A+825Jd0V0oS9ZdeaczDJSjnbb8GJXw9Vvq R7nETND1XarDD51Pm++pjyQfJAW1Eivp6MvZiR3C96zmLlydWcPykoZMY6WFHPhpZt99wtmolg++ ez6VlkrrpWbjZS9lTk8WtnmUkrO5ujoRApU5suRG1Wm7lW9kl8wfKQvClbVKnYwvbyXvtnQg3F0k kByTb/vMOfz1eFtR1PjVJ2obl71+3+d4apG65JaNou7r7TyHH2WsVrXPRyuiFPMVKxUtIpbkrti/ duVF7qLvilvVjyv1ol2odFN6K3OUbVSs3qaLfE3a3dtc/Ty3Sv1BCRcPPz81UNNBdYm3SGOl6aEq HKyaoIpWeTVprbg+aARlEJBCf4oRkMIGCRm+dG63mk0LkmjBP7No2dlliw+Umca8OxSy2q7jxY18 2VLVRtUB1bmzYTMEgx/tDi+/rypR1ajA/M7Lklbqbmpf9Rj1VPXqrk7ri/av3VbBlW1T56ovqoUP 1O/U3pqrmqPdZec8u7PAQ+OnGauZpsnTTOFt16zgkU15jzUfNT811truK9rnfqcMg8tsKWUYXCKi KcPgkhBN6AeXuJHayVrvOdrlnxK3y/drr6z4PmIc1aGRfsB84IcHzC+puqIyq0Kxaa15nfM5eqUr waImmPM2Ldg0wTo4P8HSsw070cbuIvuq1kTXOKGsbxvXNom2J0mdzVpkEewqZFvgKcpMZ0QK+woX tPGnyFAqiWoWeZC/f+2DVlzPKcFaEzJxWPSC0GXBZMdPtsiqzOnSse/8CofhYfae9peEFQ591rT3 8Koc5tn4Av9BK+8E9/utTWJd7ree3xc9aFW23X1x95et9/RKhK1wyOXXYEBOO94Jdq/lBHLfVqHP lI663cjh4txvA2sFmbwOw9JbCDs7sK8E49az+JBAJbgrCBqLKJLsOqDSrZvIwfpL6hNW1+v2onai HiIYLJogihYlilaLdopOiJpEJS4i96/dHVgsqhaZ9v5oB5yLAz/asS/69ej2Psj+0mUf6LPmR5BX pWByrOvuQL+wXSNgqdtA6TbsiAsbEakcMXcqWnyL0Hc/sZ+4rfhcAv/+wMHiCeLoYUkycaZ4h1iX z/bXW4GswjooPcQ3uoLMfwgsRVoxkthJ2kq6S2CQZLxkhkQmyZTs8PeP2b8W5iTlSa5JTHuvjPtc tG7Wyjj0fe3sHt1Op9pfWpfQZ82tVPCqLF8S6zonqcma2clL3ZoqyG3Y4bOm7frFyUM2JW2VglJ6 QXpf2kRWI+0ubibrIrs4Y3hygCxMliBbusBhjyBsZq/GrK0ypeyCDO7LSmQ1MnN5M3kXOSEPkEOY fId/q+yMy4OPLpVvlB+Qw7mkKbtvLZmy64XcsWDKrh9yxL54MtZ18NHSY4OOLXX7rMKxDz7qeKnm 5IhjLW4mSxWwWLFGsUtRqriheK74oqAUOPaU1koPpZ9y6YJfL/M+4yF9TcxMZbIySwl7lKeVt5Qv lVolUtmp2qpY3VWsqoLtVc3fjFVNUy1U4dh7Pbq1pNfDw6oOZb0e3lIh9tr3sa7N35wrbla81O28 Fsfe/M3H4hvv2xZrP6V4qWGEOkI9W31OvVl9SK1S31Xj2FOr1aaaJpq8oeOTBRUeHSTatOr74hIx zNAY3nTkMW86oF5zrdPVssdtvrLolx1PJVAaaGXyY5QV10I62MWK216K2JMdY12/suR2X9hL3TIE OPavrHy7zY417AtNU+0oMChscqywmcsyqR0Ujn3JNeopVUrlDezAY1k0+jD4VTOzHjyDqlaQyFvN 28k7wbvOe8Zjs8gNwn0jC9zqeTyBc7OOs2zrrTydaI13nr2NzcCWyCdEwLL1XShY7wxhwgI3lft2 21DxKZsCt5UDzGb43XBfM3hJiaBGYC5qJkoMEREirc+XDuGiWaK3vy4t2yg6IDonUv+SuWXlDdOn G16UiGpE5kQzogsBBBFAhBEJBJ4xEweIJkUw1X9+yupQNfGaqCS4/XNHkXa+uUFtxAW5uUFeYrbF bFhhszrUPS4zbLttN9kpzPMlccTszWER85aeFN8QPxcnfhG7S2wkrSUeEj+JzeG0smmShRK5RN3R giSPaDzbThvhJktMtFLcuVa04MHgJ+nJl3X3xjh18R750/kHUpVIaiTm0mbSLlJCGiCFMGmC1OZD n8Rhx8NXb5c6323sm4hgYAa3k83ZaXOWUnMdc2Y7z7MkdXOWfgzaOyn1kxl5KG9u6rljh7OkTR6u YavWwfuj4au5O8LWbLc1UZ6yCV/Nd91hs2fGmu770wxanZlKxpUXy3TL5WbypvK3vzov6ysXy0Pk 6o7cRPlqOWunnDgpvyF/Lv8ip+Q2Cmit8FD4KWw+NMoVvPW8GKdITFWsV4iPFmQNPnk4K7Apl+/m /WNdjNOeS+wX61fYeF6Ex5c8Lm23faI+hR3s+8XXOMQl82fLxitnKGXKTOVjpTBPeU35VFmqzNMt 56mcVZ/czzb/ta047U0NQaoMyqRqlG40QS6cdPRtzsOvniXsB8SLCTG2opIDxT1KVHeRyYtRkReb v1Pdb1dSrTJVBzdRF5sVFZZz3r/hLvdVnz0ubdUkFTTgeZdlCfy+j57Qg4z7m50azonHMWXo3Pu0 u5M1czSJVNHqHz1KdlOn6s/eTYcVWkiHkcvaceDy/ixh+utCbsk9i6WF6YFLC02+PKh9zu1+au2v bXV2/dfySfJttDf11beNCUle7iTYFbWPU1UwJord753umb/7vtoL226akWvLJxUfO3Wr5BPqgMx3 lrUgv2sBOOMv2lLqt1vCLt4q4oRywgvtBthh+T1j0LN1O7/UBeQi33FrD/t8HLfY5FoWxVXdN3OQ 2nUexG7ZpLHuy2AzebB3Wd3jmqMLLWufmwH5lBL9KMlqUkyQlH/rdy3k8Q9VlP6tQvNrrzX6twrb +Gpi3Fr7u1scVMQKbkH9I2oLdEUp0AJRO8ECbYWDMDsVojpXmEBC30fm4X2/r6XQXK7UPLnli1Fd 8x4hyEgXLvctW9W6/UjoYFlO5Lq05YR1binl0y+W0o6k3vt6f/jX++kQU13Y78iEJqLrK+3n8W7c o2YmxlQnf1CUT+yR9urcwxUOutqlhfu7FyIIgGinLvg5tQ46ysJ18aMLHbZYEUvu7oMmPV26lrve jPRf0cxiRUdebx6sqBVbjJwIC8yfrc+mFtbhXKq4bfZo+d8Kxqx3fzfr1DJBdlqXickqftmFTbzE gyajXE/zbnGtqRuTv/FGyRRJ1R3H1BOf1uqOZ2yPc+3luONndnVEx2ZdfUo2Fq9hE766ygs/Jgli BOTuHmRNq5Y/+xX92vt+evvDfg/WCHYJiDPdLzoGtfuV73CXz3rI3/nUCc3Qi5vW64l9w91E3iLh qI6jXGk99uv9FZmifcPr9hJXuy4bsiS4xYzEl+2O+nwVAWFLuEk9iZVFrzWVGndV3LIlBYPvnplt f+hW66LrRQsm5Zq/CT91LuzeLNUJ+SbVQRWcVxWq3qiqVCe1N7RjNkYHQ+TadbE+anOKN3h/5CrP A5NlThs3Z55uUunnIzwQobq/yqNkY94ldvkslAPrYrsnZ8V9vNhDDnfXxYYlmw1YqoiLWr6yi4bQ +FFhmpQd1FKN7qw0mjqv0R1axZIGc+JCl4QskJpkNQ3ZFFHSbUeEf8s3Urh177jml2G32OTVlEKC IgP0CyK3LLqUFKzLyg/Q6mIWZgnWwJIsx2R5VnTxhqwgWaRswWfvebJfLrU6CmRGz4JVp2OaWPhm i7O5q4IyAraPz+ZyB2Sz/XLGYGhKdtDuqinZIdtXxbZgsRKHjiZ1nOeFvKwkVjnJ2pZ6apmPMuVc Ur58t8v+rMQn8lP1ptuPAJExPrs1sAPQ2JzWWVnr8hXbbh1ZTwmLO59/0/l8RYeSw4so052s+m3s bz+FGYM4r5e0mMm1zZgeY+KwIfeBMnv9k8k+KrA8HRP7ELVGurpcBBcQZNOLLB9SdqjyzsI0fyt3 lLEx2Mo0Bw322haysw16k+r2nL+2dbdlE/RvLc72n3nWj/w5c5/p9qv2IWubhHb0cZGXeSlGKCIU szeWEeQUQcCZxrumLePLFdsVcEzBeSRY0+jhC8VXBShtlRltlJ6Hrxd8KpIPz3l4j4vk43Je3wvP Ud8rKpy5/fkTTllhyHZ5mnKT8qDyvLJQCW+UVUqTk6/vORx9fU+gclXBAFWQKlI1V5Wu2qryUV9Q gUHjNldbU13UrlSA2ilMrQheP8i1W6p6vXqf+mL+zQx64vpFPXvLXEcePWr0JR01HTW9NXBly3pu uGaWJk2zSXNQ43k4PAA2xmQMz5lky80YlwNTbcNzxthG8WduD3eayw/ZjjL42lbablpf7RjtVO0C LZicnGrrcHSq7R6tfiOEFrRaRNlRbalfmdUbkFGZ1DpRHnVGROsCCbedXQ22u/NvZgbywnl1s3iz t/RoLr9U3gN9d9Dk8i7yLm0T+HzhUTzSRtBa4CHwPPzUZWNM5vAck3f9uZnjcir6h+cU9S8ncaI+ D0T+IdszNwoOCM4JQC14LagUcEUmJyv6Oxyt6A8uot8WbLaIDotgFHFP9Fb0TWRGNCVaSvsR/P7S UCKeSLjtvo7YS5whkm73Wv2M+EzoiJvJLZL2UsiwJOjLfttoG6+HeLBYl7AjBrf4PQkJ4qXijeID 4nNiz8MhMW7F5OrhOdFJ3NXjcuYlJYbnTEmamzhze3zassTmAavBWeIu8ZGMlkRJ5ktWSkxOwrwk h6Pzkk5JbkpeSL5KQAq20jZST+kr6TjpdOkiaYYUcqS7FVelNxWfpHXShNvWPDORzEt2q/eaUFm8 bIlswwJZX3aluwtR0U4MBbJ7sreLRHn1Mp7cWe4uz/CRn3/1MbuYXCNN+naUi9bMT2Jd/Hyv7Cgq WL247hTHpqB5wJp98nz5r3KNvFwObIWDYtV71kXP1ayLpCJQAeGKWYo0xSbFQcV5xWTlGwVUKUyU 9O6crprhykBNrDIlRbmkj8du5SnlTeXtXmvLPinrlI1UG+aysZJD6JUci8OygSrOONXbWeyv8SdL UlXrVftUwnzVryq/ljOLism10qRFFWzu2vlJyysSbOdULCtbvdgs5fvGsuYBaw0rl5FqmKtOV29V O7Y/WuG5+mjFdTU8U39W69R8TStNN42v5qsGpmoWaFZpsjVHNSd4jzTPeGb0auWSPp5dtaQ2UHu7 l3NWrDZFu067Ya5lnvaalvNUW6q11Gn5VCuqG+VLZYyh7g35wS8ms6RJJm5clDU/ydatvj+42bis XmzVg+Ps0jwg6zR1i3pJaSnEAzteW55itK2b52pbN39eKA/ieUt4G3j7eWd5d3izBBU84AgaCzoI egn6iScJQsVJgpS1gpafu58QXBc8E4yct66wVmAlaily6dDhUEz7MEGcm2d7G1/RGNFUEbxNuOQ/ +9i1oCzRHtFp0S1RxkvR6FWL/dku66RJq0K5aN38pE2hqUlpoRuDO7muncLZF9zHdZ0XMYKIIGYT ywjYTBwi2q/fFOq5elPoE+ITAXVEI7FQ7Cb2Fo8S68TzxLBCbNipdlX2TvxJZiFJaS5p+blHP4m/ JFTyYv/6siTJWsluiXkyrXf/nGf/q79Hp9E7YtkepnckRZIKyfRc36zZx0Cc1UIqknpJR0gjpJrz 5hlubJf1NUcb53DXbw5tlZNofZGf45zdybX5XtfsPq7r4Yb0ufSLlJLayFrLPGTKa9Aq5/zFVjnB slhZimydbK8Mzshuy17JlshZcnt5O3kPeeJg+XBVtDxWtVq+U97yc0/+VfkT+Sd5+KcNhtV2Hbnh Ada6rr1M471Yeb22dtckRYwiSQH3C9aveXxll+IkM/u6HqnLLGC7bHDM2XaPuwE2h+6/l1Wx4d6+ wk6uO5+cLmT1cd0QoAxTJiiXKjcqDyjhnLK76f57vqz99z4oa5VWKmipclH1V41UTVY1Ui9XbVHB YVWB6p7qkfabqlbbVP2LumknoSXniavLcHWwOlZ98XPTjavVO9Un1KfGmpAUuWdc1v6gfdX8V+oy NUvDmWyybm0wt4smkdAEaMI0CRpt16bAdtlo5ZjT3pa7cXOou20LN2dboRu/k2sXp/78Pq4bmYkZ T+usddf6aFXd3W3vuIG7bYw2SbtWu1t7SntT+0ILX7XrKFuqDeVJDaTGURKRcBGVLMqhjlNX610f Ux+plJ9U/LhNzXhdeAQvp3V7nVkojyRp3cEUKw+RvLm8dB4nuMgD1q/56GGYj9FL57Ojw3e4pAdv cszJ7c/dtDkUzvbfFbq/fz55NOTEwFtkbxu0KVQQL1gi2CDYLzgruCMAv9ln+4+KPdufnuS3EIlE 4CUaIYoQzRYJiM2iQyKVCO6KikUfJKaElbQz0Ze4Wu/sFkzEEilE3fLNO4kTRN114lmf5gst750U opIygiW2F7cbHptAiAPEZJiYlrjUtl9i7LI3O+aY9Ezibj7X3yepS457knciv9d2Im1kYm+bzaXi ejFPYpS46j0+Sa9yfJLA0Lj/QuLu1UvcgXqJO1ORIeVnKY5Lr0qv1rt/lP6UWstyUm5u6SIjZAEL fhFb7KXMSJJfQEHddt737HnJLwvObPnULusAbJVt5dZkn4n7uev63M73nyUszi+WVctM5U3kO49M LGJ9yMveXDixiH32KHeLy7D5dy6mECcz5qSyFi75vvPIwgOJ6SyEJyedOsdwbmY3Xb9kzHb5MXlB 3urqkw/kozaHXZj4egsgbvjbhRcts15eDVAHKsIuAFulUI/celBxXx2irvm1+mTdB0VtJuD5Ch+t T4cnwYXZwYXD95jwoBeKmrhzvnKlUqF83XETJOzI316dFyhNoOIjoqIjhYOiqcnS2Bkh8VFSWbSw f0hcBPPRVP3IjxUO9FvyDhTztr/TN3qfw8cK+uMpygRMwQzMgbIAK7CGRkDxgA82YAs1dmBfWdYY HGGiE70hwrsnOFkDe+BfbogI3yRE3bsCoMA/2BCxNsAZZXc1bIioH178nf4EzgGoS8BxcUbcRhTA L0KAG0CRMP2QELl2rYGG/RASb/zwZY70hoiH3gK43Rr2t2/YcY6fcs6ptKyK9QC9oOwRaIpYAOzS MgRUw6cu9SbVxm1/0lhgwVB6y57hw5dXXBMYGwE8ekOF91wEs6Li/KnpIWERMyKi4xUj4udOj6gu czH31kbExE/xYuNSlsbjQu7DHj2lK+sbH42U8tGA6REhVGxIdFjEGEhe4MWW8iLGgrvLErPZw6Xh c8yHSlEkSKLiI4TTbQCSLV8dshgLgRFdWX6xs6PCwyUAfrFdWVT/6dKwaSOi5lUthlrLsV5sr1kR 0ZsTIjh24LGdLXAc+x6g+3Y2B+JjpdT0OK+4QdExCZr4OHCNGcWOiOvD5aeaDk6YETPaYZrDMd8Q c9SRPzBkliC2ti9/RBTbf7p0tlgR7R0rjaku4/O6al27uUBPnOmeP2KW2+TY6bfk/xSG9YSI2Ihw qIEM9MohXhojXD89YvJd/pbyJtVlI0VRMyLiSpzOlvPtW9c16ljr+Bq5A8ka7Q6ug4TCQUKbQcKg eh/hJx/hOx/hGx9h0Esf4WUf4REf4UbsSPIRxvsIJ/sIh2FHTx9hBx+hk4/QxEco+Qbu8HSj8OZG YdDhjcLVG4WzNgrDscN/o7DXRqHnRqHrRmF1841C641CDrTCUwQW1Uj/tSULKDbQ3xtkS+QCZM55 Qdnx3tZQiGrJG8AL4hlE4FZempJ3gfepHF3lfeK9r7KhcNPm4VZtTYE9boGNwYzCrZ5u9CYU7geO YAemyWDZlt8VdREQAhdkWwl8Nn+kTTMQwGghOLfl20XZmkptL76t4VaX9RcMblJo2hxGt4QWj4FV UwYh9g5CLt/arqlpsuCt4LM9/akRjoj+bYN63N3MgP2XnbAWd8Kv5QgsoTkFLaAljkaYD87vqxCw rKFTU2twag3dgDv9da3JC8qgZJd8o+hu93a4MxKcxW28Vx/89BUHhsJvfe9vw9O90Ap3QkFzNwCL PjglpWVmuH8LgEIwetDwEf5iSjwUhkWF4RYWJ50cL/QNmSMAX68xvV5Q7cwoJyxFaE9KynjWz6G3 aHH8YS0FSWAnw337fAv4ZCE1C28Bpr3hegvWdWAjni9vzhjeVJwEP//RrvG8U5t5h3iv6hG43QVo wWnORtCnI2jLilmEL+TCr9bXTW+zTWrZAHEP0LtqbSUCNlVxzRwiv1Xz8Y0daqmd4jO1Ra/JDsTb VlZCr6pe0K2RuvlMIdKWW5qdSqgXaqvoesWCo26+EPUoLRtZWhbk+L5qBc5wstlaOYdygnvAETqj 6i2lZaGlZe1w0Ug4T52RrrTMubRsYdM9EL5AiATaMmooFjQUBMPjF0HO2m9931dN444GsCotazEb FswHSa41wKDSsjbvqz7+oKACtZ8N9huEBLqARZ2vivOpvNRUlMHueBLeaoTHEE/Ex0Xm5sx/odwl RM1F/BJt2U3dSYif0gohV/gJR0rL+mCBOkGJReBRCd8CC8DzsyFe7Iy+SfjC2tKyAe+rGuP6M8Gs 92xc+M6oXZWcn2TT3Jl/Pd0XnvrK+SI+NHPm5xY4+kKCnB/nDP//3/9v/XSUQfr9q78/up9GWA9/ fbilazP+mvVm0PmXH4e9Mcb9G6w5lgRPME6fF0GrFqTh9sSB+B/9zbU/JnpEncA8cwomKzB8I4q7 CxyE/+/vPVvCb992/xFPfwfKgX/m+1fDnfT3ryz4x75//X/at66/9/uj+qPTWpSqqPghnsI/kInr qv2xp3QeMuCv64qOi64rugxHgiG/wWDIx3Qm7BwwpDMFfkvvP1JH/wjfcPXD9KC54RtIw/fJZzzu dKb9zXFiQhvRKeyqD0mn0JLVwFmx9iIzluFEAENd0R9RNpwI8PdONjF8bNlwPgD97DZsBygCRxSD HNFs5IAWIhu0GFmiJMTFJIfFKA0WoiSYjRZBDFqIwy6Ep7AI7uMhT41byx2QY+IiNVii+2CDnoID op9niLEhp3992sA/fmKUI36W4SwMR/TFiFUbMRZqwBospDsiRyMmMGK/GLFuRszLiA0yYqOM2CQj No3BGqM4BnPAJWXgbHB5GTg+WsSEM0cNJyrSJWjg6iCJ8a2CBuy9EdMYsXtG7KYRO2fE8ozYXiOW bcTWGLF045mOaUYuCRpSupg5BdKetch4RuRCo73mhcxJk/aYkxixQCM22Ij1NWIeRqyDERMaMTsj ZmnEdNCAfYMG7KMRe23EGmp/EW5zDalvOPd3qfHc3zTm3F87lr4tMqVxhwm32YjtNWK5RuycEbti xO4ZsWdG7L0R0xqxOiPGQQ0Y18hZooZU8dE9JpwDesJgDqghR3Qbb+gPDb+G/vDH55r8Uc/5e+eA rIZJ6KKeOmO+s9791z3zPxPPO5iEWwxNVpi30rv/r3gaJMU/Ew8LlkKoniZhfpLe/efEU4zjoOkM sPRU/CfFQ6BQPWHJpifiT6qfpSgQ0eSB3gFNS/+UeNai7zgITbsxv1vv/jPKLQl5wBs9WWHeSu/+ T+SnYdQ8dow+Rd0QjmscNSuw1JmE+3gk+hWk6DqWpQUwC53EdBzz+zG2A/ttxWG24LBbsHzbiiXb DngB++EZHMd0EvMFGLuO/X7VP+8vU02fUfqfT30nfertoBTP6iIQBdNQPcxEtZCAqnDKv+Lre+x+ jfFX2P8FDvcCSuAVaHA6n8N7nOqv+FqF3bUYr9c/5x9N9b9St5twO63V0yS0SU//d1v91+IZieOg qTOOg6aR/9E+8dfPYv3NHb+dKBmInGERJoP/P3OeWkN9G34Nz6fnHW3YHDz6N8f9whlf2+n5v83b H+WJ+0/nqeGO3/J0EQbDG0y/n6e/bi+/F9NvuXgNPlh6DcZXsZ7/b+YiFOJgFaZ/PxcrIRqPvXH4 OkfP/3dzoca5aJA0/14ubuJcqPH1gZ7/7+aiM1qF6T+Ri3YI60JoJbggmv9v5gL3C4T7xX8gF7gv 4FF8MJbbYkTz/81cBKLBaB36T+QiC/lguTsYZSExovn/bi4W4lws/I/kYg7OxUKcgyRE8//NXPTC umMvPEv/93PhgcLwkyZhDTRMz/83c6GDuZga5gz/Ti7YaA5+0kL4gSUtzf83cmGhzwUbj1MLkZue BvwHWlUX8MZPIlB3fKX5/0ZOGutzYg43sd5+HnGREvGRAjmilagZmo8pCvNjMTYYmfwHcuiPWMhX T1aI5v8bOWxoca2wFtwKuf4HctEeuaBWeF7VAl9p/o9ygf6JXLTUP9saRkE0GgNT0ASsmYdCGJqC r9OxOxrj0yEOu2dhfA72n0WfLY3o8H8bf0OO/p10ROO+GQNjIR6CYB6MhER8TcHuJRhPgTDsjsT4 FOwficOF6cP/Oek4g5+fh+M5guPLxfEewfHn4XScwVcVdl/C+BXsfwmHU+nD/znpcEQxYIPioRGa B1YoEV9TsHsJxlOgOXYLMO6M/QU4XHNEh/8z0nEdPLAe5gJ34Besk3XGc7Vf8MzNBYow/gp6YXc/ jBPYvx8O10sf/s9JRy90E48ad8AVPcB61TN8fYXdRRh/hWXYMywRH2At5Q6+3sRuOvyfkY4imIHn HVOwJI6Az7gdVuDrN+z+jvFvWP+ugFkYn4P9Z+Fwcfrwf0Y6SDQD+uPe6YsiYCgeSwPxdRR2j8H4 KBSH3bMwPgf7z8Lh4vTh/4x0TEJWEIxMIRzLq6k4ZAy+xmP3LIzHIxvsdsB4Y+zvgMPZ6MP/GelY hTIhA62AtSiNnt9DNr7uxO7dGN+J1mH3Joxvwf6bcLh1+vB/RjrSkClajkeaVUiH46rHcepgG3Zn Y3wbHoU24bFtLbLB/nwczgrR4f+MdOjoY1yQM+LgUcMCNcextUD22N0YtcPXztgtwjgeS/AVsFv3 O/OU/0Q6puJxazqOJwb9gmbheBbgayJ2J2E8EfXC7n4YJ7B/PxyuF6LD/znpmIKfH4bjCcbxTcLx BuP4w3A6puBrNHbPxHgc9p+Jw0UjOvwfpeMv3b8fa8MK0DNYgXsCTUmYT9K7G576Z+geTkDrHhZw Dbf0c7iFH8G9YAeOey1aBKmYZqHFeGxfChNQBpYQW5j7/x3d5DZaj3W57VCAFHr+98rsHysrFu6r JiyaMnE4mnYba+DPP0H8f3H+dwimnUxj/tvzv7tjl8vfvfuvf/T53w1xt4bfP/+7aMsIw/nfEeH/ jzj/m97D8J88/7sVvraFf/z83yj47fxv9FtH/Jd+/28///rP2v9CN7L/N+yf+F+c/z0NDPmmf/+J 87/b4Gt7+Mfb/3xLAF5LA/+/OP+brtf/5Pnf7fTXfzz/MzDNsTbwi3FZJFnSe4lx+8KUimkJpqWY 0jAtw7Tckm7nFFWDrysxrcIkx5SBKRPTakxrMWVhOo7pGKb1mDZg2ohpE6bNmLZg2oppGyYFpmxM 2zHlYNqBaSemXZh2Y9rDxLkPX/djOoDpIKZDmA5jUmLKxXQE01EmbB6+XsZ0BdNJTKcwncZ0BlM+ prOYzmE6j0n1/2HvTKCaSBb9XZ0FWcQEAiq4pAFRdNAA7oomBBRcg4h63SZhE6NIxwCijBhGXEZQ G1HUcQtGRxGXRhTckCC4oyYCihsGcF/GIKAsIv2qA46Mb+beOff55v7/55nDd7oqS1eKhOoKqd/X kDzIOUg+pKB1Hxfh9hLkCeQx5ArkKqQQcg1yHXIDooFoITchRZBiSAnkFuR2677uwO1dyD3IfcgD SBnkIUQHKYdUQCohj1of8xRun1FlSD3kBeQl5BXkNeRXyBuIHlIFeQuphtRAaiHvIO9b90XRAMuN kA+QJshHCAlhwtd/f/t/7n83/I20+t9rI1CkEL5pvVoHjm/+92/+92/+92/+92/+93/L/45QStoO ba9pdbCe/BcO1pOtDlZ6q4P1OeVg9UFaxqC6FgOr0yyczH/n1E0w5sF2xTSOJoFJSVhn5n2WsFYg bSSsY5e0ayNhbXyDfJKw1gV+krAWvUE+S1gXom0krLLwjm0krB7I7ySsJszfSVj7vEHaSFh7Ojq2 kbAuP2DbVsL6AXySsE7sw/4sYY2if5awqipAGwlrs6NFq4RVpwHJgDEGJNJiQ3+TsO7nfJawHgSf JazpZi6fJawvN7F/k7AeBJ8lrOlil88S1r33QRsJa20l+E3CaoO0lbD+ZObaVsLKeMP/nYTVz1fU RsK6W9tWwjo2ckIbCWuPRFFbCevC420krD1UU9pKWIsmA4OE1SmDkQGifF5UKykHa6p5YCkD7LYO VlEO1rI9lIN1L+VgLfuFcrDuoxysZfspB2sa5WAtO0A5WNMpB2vZQcrBeohysJYdphysRygHaxlB OViPUg7W2ZmUg/WYeWByvMubDgHbQJZ5oApk55oHpoN4cLpQkulfKLkaoCqUbCuUJBdKpiQUSpYX SmIKJXJYmVcoCSyUzCiU+MHK2EKJsFAyrFDiBit9CiX2hRLbQolloSTWtFDCgJ/z880lTKUHoHlI wkBdNSU33TsGTsFolNyUkcEQPPyBbiYQ9FxKQwTpdgwbRVS5wNFEEaX14M/iLYhe7LA4aq+Nza+0 N9nW5fzmw9+V85noy4XXnBoWUkJToLJ3k22lhKZDlzOVBn0pSTnZGfBDV5QOcWFUgvcgjONKTPlN XkrA+Xnzj3HIynjagJVxbeSlHkgbeWnRcuOljqsX7cOrGiPUa+MUtXic0U73DZvX9VGexCcq79A/ q0t3JSFNqg1UwIDKaU5LBHeyklKzkuYekNR1hfNwFyMwDNnt00UiRIYoxsbSZyoAKUiVjTAt3fMc 4UfH8nsmLUpapFKE2Vn8AvIUCbzHivcKStnjnFCS1N59xX0VM3UsPgsPx+NwdjJehcuVl1enFq+K zFzqCHycnJWz1J03907brKaC/eCaeoa6Sr1Vma7MUd7YUIGcDkfaP6r3GD3GXLK76pbymbJB2ceB kne1ezWpiRqV3Yng3oUXQCARSawithLpRA7hnLA+DzacUsTc/ZpoJthqezV7gDpZbaW5vHp38ap+ lfFqkKLerz6lpmvE+l6aeL2FPm+/frBmjGamZoHmyfsxXn0Szqk8AHNjPuNnTbFxk7vr98sMyqdN iMWiZYlVCUuXLWrWhNmtfAe66tKsS2rcdRN1Ep1c57S+s0+V+woRjanapzupu6pDH+je6Mbrb+gv r1YVr3pOA0sdd77PYW3Vd9y6s96UW6QHj/UC7g1WMLdWb0R2Jm9suDLvo//pOn41t8dAl/4TO9rD eYZ5zyAzo4/2sSlmLgjwBtLvyhtBwIBu7nAG4ybnG0Q65zzY/runtxP3vMIGm0bY9/ZPrV0G+rss sRvi5ImFk5Eh4ZERaEAEGSENDQ8JRgPJJahBEx9cFywP2YOGh6IBZFTkXEwujVwSjUqDd6LSOdI0 tEYaftheWIWOloaow4Kd0YBwLRoZ2yvVHguSBkSmofqIqMC+Zx2lIRGjeo+q2tNfMZOctvR8bGNf q8R3z2mKqIzRz1KtPqaOfuZrEEmV2jWoD0fYYXCOQ0qiTCWMx4E0BaAMd1FmKQM49LiqDznsjj3B jgFJA3TUaRksYi1MJX2SXOhbXI20rojSZYcLuD8AYXFY/Vmj2pm5+DH6C8uY3u5OdIG3exptg+Ch l8/A2w3065HhY+grvh992oVu6uoL+gvdPI2MdwvcPNMnIP2FWs8Mb3fPG7fH7gE7D1ctpWcjliuY m+jWKQxkJ4tgxXZHS6v7GE3nC7mTZyfq2RdTmPRo4DNcYs7n8l35nsPXjb927mbz/ClUQrwB0O3W 8CnDgZp/k/+I/44P2olsRN7MA75+jJuBQh+9n8mkd76VYaQHWyp6OWeFCKE3zUkVwpsitEHZQk+F 4LrHzcDwiInR94IiY/Y2ikB7cXexi1go9hfPES8WJ4iFO2b8ki7OEd8QKxo6wRkYKbbAVvIHYt7Y dGw+FosBHNuNHcN6jfGO82NgyUIvsGaV3+g1q4LHr4lbJPrJi9gENo/Hkss3hm/MFlYor3tgyez2 e15vWbzRMv2XrYp0RY4i7oaiXFGtYOAdcSd8x4x9wAefgYfhy9bqxUqcgxXg4Bb+DG/AzZTdlDwl pZMBo9o9SfVjmOcv2/pqvsMl+g+A2GyruLplUAy8qqB9QbYwTqG57mGen16QcKljQcbVfWAQ4UPM IMKIZUQSoSKOE/4XiR0z9j9NNZpQzawi0mknjRbWD7HN6riquj0pEGw1DDG613zBm0nOGfO7gpR3 seVFxRe19e9Ok7mlt2vYV249rim6Vd1QRZJlagdWeY36Ski81o+RUMnc77Y+wH7hIf52/eGn8xiM k4PtA1gRDDayegmDTgc9yy+uZX3QmOuWcUtYFvTl2pfMadXIzbLvSD8ucLYseriEXMvdxSXIEWQx CY5w87jwMwiX5BrzbHnOvFkjeb591z8aogG5oT39NczFveev7GGV0/6nQ7QUE2Eec7X9yaYnl8FE hch/FNoX9SdQMlgaECoPWIDyI+Zi0RHocPZhVC+NQMdsR+XhASQliAwIQyd/jHyMBsiD0WgpGRaG ygLkESHNh+0n+nqMQZ0i+XMDIlFpRKVDZg8SxeToxFH+qC4kPAgLTuslk+tC5oTI5Wl20vBnAfIl SZxTdtgclBwzWYQO6T9gCMnzCA7u59a7XwPalz2aLaMsmiSl0YyKCIloOmx/HQ0LjkDtPTTykAD0 IjvLzt5Zg9qP8WpkP7azn0yOGm9vauqPoWTIAtncgAhpTL3UIpq93FoaPgeTNywQWS5hU/GzCH2k PCqo1i4gKGgmJs+yjMRyujoftvdeGBVwFaW7Nln4Nlqc8Zost4ejOXAwzW2yGGMP+5uBht2PwIZa hg/nW4QsehUi/95+yXr7cCySREMWy8KkQVLvyLAlDyy2WN3s3C9OOyntKbFZZ5pTb5uVerXo4GP+ eC8G9u758Nw7tAm5JiwkSB2lbrF+grPqkfoKtUx/JeQuOsgLEUYzXSwshRv4wK00dTq4nOd5zmL0 Y1ejOS7NewS+rwMrtNxBgoWCI57eN7sNZkYKR2X+zFBvAv6jbmxVePAXIkKVJ/D0l8ftEe0/hwhv eB7xNvUsGZv2piTPBVl5+zy1WqhcU63pSEaSTrphpf2GHCUZAbrB6w7c473mNfO6HhN6AtcMagQ5 uur9/Rn8MP4yPkjiq/jH+Rf5lBZlXvJB33L5puJAtsheNED0alL9cv0/nE4lb4ybLeokjxTRgOOi JFH6pMt5xYFFQceFUQrB/nPFgakRcdEPgvbFHKgXAVNxV3E/caT4k47ZtORI+iFfRoZfwaRTk894 pBXMPoxYZDHKZ9Zqtdc1B9eEjqrzvYmsf8QCAoHkl8oZgmvxFVrTW/Hnam/HNd85vXJWfMHKuO8L rq0cH3RrZTK2FxO/jJNkY4rnsXHs8yuSmemF+pyyJy8e0eA0peaJL2jSU8f+N2TSx2urXinPkIBF FK/+jvhAmpvMJD4qFcTJF8o9xP0DiaBJCM7PE4K1QuA/1ngA4nlONRNpv3mrDM00cs5huaycMibz wm3kbsU+2iu6g2mc9uAhX3rGrA147NH9eAdegZWFIB8vwZ/izXfA3qzPw1KIMvZl59CMdY/D85kH U5T7laeUoFBZptQQFQSHKNVgxAcN2EhwdSeIDcQTTajupiZRJ3hFfCRY6pR30eht9NAhcY9csXZW 1x1ZPSNM+kYfLGE2IeGvOZhjcLxw7pPxYcDryvFK/2ejl6IaN42fpm5wZ5tyhhdazTz0CHuHtVti vXLrRfa9RdceK3I1YS/BBF0v/LBOrTtDXid1pDjx1IqX2u3TGODkbfQw21bvrNeKd53qOPuN6Z2P teBGRry+FzYUG4fNxjDsRwyU66v1DLJusDdgeGGWlZiPkDT64ddjlrOf/3rMtu8yRob1aAXtXMdA xWjkpAyzBOGc40ILXqEHZunu0LXXYg5N2OfwVcUDRRx5WdOe1Z2Fym+b6QgyCN8z5cgyPEbdpMIj H3k5ILqcbSRdIMgpefK+Hd2m8WJWjvqG+n3C1IH1DkA8kK6x1gziDtWM0+SH27i0vx2MCplHFJoN mj2aLA3YzqvgFeo+ataIpusOi2J14KZot+4H3RaRjTheNEJ8S1f7TNdwv5ebjwccX0gUjkXykIgI 0tRpUYBcGhBIhoWgYSHhoZHz5/Z2zh4wSO0mXzFg7JNj7cipzcKM2cd6x8RVELZ8Z/5IfuQj1YY4 Evv+upVAULadRX3GbFEMvTgKgkLqHcJCsvjUh5VX/I98l4hdPSWrN/WVMwlXkacITBGFipaIKOcl IdqsMBOD0wqe+KFisriveK+iJ56k0I7FV4t/Fjfc79b9tKkT6eo+YoyX+4ghChQLigyJjKgUG9eK jbDO8zNaXqDIR4pVVztM3nK/8zwMLMXWYxuHzkmhNC13sJdYXhPWQcFp7J208LyLipkBRip8FS16 rMV4Ap6jAD8TnfGzhDteQUjwYfh+QtBbvZGYoN6E78Mb7ncUprWbPGp8SdzD+Cd4HW6izO+y/agP awYrjLXMuMQGHhzHG/S1puFP87A3GZQbopj1hAXqWCbcLty+3GrlJG6QjWOexKF2QtEybhJXxY3Z NPdKXH7H+ReKbTZq6x3mX6ji0sGFUnO7CUVviscX29vrdUPt0AlFto8aS6cWoy+PUmYykMBLIJaq 83gDsmIus9R1PKHJiMyemiGasZpZVzpJNU0/aNZdbjGEIiaxFdSb4ZLmruaV5qMGsHR2uv66UOu6 crkVlzZLNz5cF6eLsQpL2nJ/07B6UGyblXJRtwh5oHtf4YRyaaA73d7+HGuoHZf2mn6tnROdVm2a 6aWfqp+rj9Hn6Xfp2Rn6fH2J3njksXq9KdmVnDrr8qaOw5vLJzRr12mAUhNPppD7yU9CLICwrMZc YTt4vbXvxxKw/FjtYjZZUzKN/gMotSt4fOetfXL/Koci2kb+C+StPTu3/67BjQ7nhx1rcWSB8dxk row7IKu7Uwp3P/fZr7uPX+U+4L7hgt6Ww5uf0yY03xGTC8kpvFDeEl4iD+zkEbxzvGKe3ZLtApfI Ar+tlFOxBz/GSirZ8sACjOMzg4P5RbeGTam8V+AXHATyJxfRQrAXSIFfUpAs9Npk2uZ5x5/zG/nt Rd1FwSKhCB2QVeVDvV+f/Zq1Q3RE1JQn8qsxnODGydp8eHPthObHrjxPXi8xGCoeJ54txsQ/ijeK fxH3OBC3QNZ/b8ryIvFj8fuZ6RHGwAzrFn57JaUTenwnZfmgjWBTfBFtsPIFkrI8cKNwy6542txt Waexa9hDrAobpLBSwLbzFw9VjFM8+zU7XBGnOJ6s8KvxHVn9lu/+sRH2/CVdbC1uUJjh3XAeDlpO UhGNe9zlp/qWhGam7cWz8fczJ42sbo5PE3TYoz3ifTN+/9GStCxjJUI7ld1DOXJ3Tmpo5pxjRbQ4 E80LJDRzQIHVJdmxYVezwVrlLmWGMl9pTDxVbr6wKQ2YEd0I3sGW//1/9H1RzQG/uX+cugkeKLa3 /JvpRTXJBC3yH7LFg2IOSEqRQsl/PlrWVLVYUso6UeofwUD4qZ5FA15t3T/+VSjSvzP4c/dPsB5F dlB3+CP3zxomCcBey1b3Ty2BIn07t3H/PNahyEqD+yfWiwu84J729WL89v3xF/Yf/XEaAPoq8If2 nxORmPxV1XhpB7oX2ar6CSMDWlQ/kzUtqp+uJl4hdbLIuX0p1U/kCWl4qBN92lxb2nidNDzEH5uJ eIaRIQEtsp8aEN+XPtMg+ylzkRtPxIKDTcZjschkYJD9LAZLAGb2s0H2Y0vTeculwcHjAPD+KLel tch+iqUxC8BTs+l96R6LsJDwqJAqOhi4jr7LrNN0AAavo2Q/hnN+UbIfhSzKIPsR0mtCIt6ChQbZ zzVP62nWlOzHmu0T8DKQK+/NnjyFkv0ookUG2c+rqqz+qeyhqfDm9RwPNfXFCxrkCEIUlOUHJCGZ 1iRl+QkLmRP5DIAdFyjNj3SBWUjEqc45F9jPOZU2NzqRlObHitYfTGF2Q2tt0Cc26E0bdEquDXra Bs22QTNhJcMG3WmDrrRBw2FFYoP62aBDbVBHG7tGG5Rhg1aD/qAyXYpekKLZUnSbFF0GK4FS1FeK ukvRnrBiL0W7S9GuUtTcVooycNTxd46fToAk48xxu7/q+GGRlN+H0vuQlN8HwLe1mvL7AGZdFYdF nY3OzqrF7pPrgrBBB2DxqsqSBJTgBwV2Y+1aBT8Gv0/9J8FPd9DNv5QWyGFPZ9tNY5uzbF1b/T6f 9T4nv9T7UH9n6pa/szdvEZJS/FCGH3VLQ89qkYMGxU+L4Qf5Q8UPoxpFuNu7ADCSUvzoBwT8C8XP 2rfw/mSX/78VPyzS5/bQDwbFT0nVid5fKH7utFX8HF/61xU/a73aKn66xv5e8XNmgCyMCQDl+CGY nxw/a9N/ANF6ajTq8aw2tlHP6BUNSraiyFkNHM98KMEP0ybdIPhh3AfmPLY53L8bGA0YcehBxJbH LtRXXT0B2pMedsgTWwAONbcIfnJ+QNXIhi6GL0Upw88hOITexdjoWIPhpwFj0yy8ooG6K3wxTbrG cbrmngDjE0eD3ko2r/FVVZcT4LxqNPgHTflN7/N/8PIjZDkkHrSsL1oJWQVZDVr8NWsgCYD6lzQA ayHrIOshOGhZy7QBkgzZCNkESYFshmyBbIX8DNkG2Q7ZAdkJKHMZAEpIKmQ3RAVa1ivshdtfIPsg +yFp4PM6hoNtyhQErGdAjkIyIcfa3J79xX1Pw/qZ1uvOwm0uRA1a1qmda3Pf81887jKgJhIAXIUU Qq61uV3zxX2LYb0EcgtyG1IKWrxGdyH3IPchDyBlkIcQHaQcUgGphDyCUN8QPoE8hcBDKHgOeQF5 CagvaQF4DfkV8gaih1RB3kKqITWQWsg7yHsInPWAekgDpBHyAdIE+QhpBtQgBQyLwD6tA6P8OWnt 2/pz/H1O2FK3mwBAH2dErVBr+b6SWqHW1p9DR3Jof7ZC+Y/Wv/6xP+fTalhbMAHIaRTdYLmbof7H /puWNpmG66h9fWqT3rqa98/zQX9lVS7VboyBz8/j92t8v047VBv3DHQztBXzv9TOvTa/V6qte1+5 nd/vi/bFIz6nw7Yh3SAOv7Xx6fKpjU9rsv+uZzMB4v0faXsQfCUG0Rz+Q21PgHzdfn9ez14GEmgU sbAca6j//vn893a+zAJ8jT4Gwslqd8if9bFt/Y9HqJbLp/1/WvnPhXNFW8NEuL2h/GXf/jfyDZ/6 lAzbvf2nfWL+rv5HLX3uxS1Yugf3dAv2gCr/nb1YjljAY+DX6IUOPnuqFzp4je5vfi0yYS/CaV+j Fwto7eG4bAG3HQ3lv7MXc2jTYS+mf5Ve+MNeTIfb7w3lv7MXQtjusK/Si+Hw2Q+CexoOe0CV/85e GMF23b5KL1zhs6d64Qp74Po3vxaVyHSwC/kavVAi38Oj83S49TeU/85e2MN2N3+VXqTAZ0/1IgX2 gCr/nb3IBtPhMfBr9IILvodHvelw628o/1kvvpwx/LNefJ5rI4icRvECll8Y6l/u/9MzbvlvLQN8 uvxP/bPUZyrqc+a/65/d1Hr9v+OfpYE/88+2eGapkjH47JmlPo8zWx//tXyy/4n83x5IZOsv4sv8 3xBYGvpPH/37C5X/s4Nb6jHfgT/O/33K/UmmLvt/Iv93AHzd/B/loesL/nr+Jx18zv/9T33CyOeB 69+6fMsP/mfHr/9E/u8Q+Lr5P2e45YG//v7fbAbbdWgp/yfyf4fB183/URZN6njwV9tPg/2/3DoA /bP8l+F31Cb/ZW0Px4PW0fNb/utb/utb/utb/utb/uvr5r/u/4v81/2/nv+yEYzxPamg1qd1+Jb/ +j+V/9qUwThlyH+dpvJfZwz5rxzr4LOG/Fculf9SG/JfeVT+65wh/5VP5b8KDPmv81T+64Ih/3WR yn9dovJfTy6bB87r69IhQA6uvqHyX4VU/uvaGyr/dd08MBnckJsHbmsH76ACWvPA6HRw0zwwExTB 4mlQbB6YD0pg8Sq4ZR5YBG7D4j1Qah5YCe7A4ktw1zywGsRXgf3xoJEjs1z4kiOrTOfI7nFkRRzZ VY4sH1ZOc2SZHBksqCDbOLJkjiyBI1sOKzEcmZwjm8eRBcLKDI7MjyMby5EJYWUYR+bGkfXhyOxh xRbumSMz5cgYangYMkV8zCQI3d/IQ3IGbcmTjQF+WjMjKk+2N4Mh+IE+00RwL9JUYMeweRXVmd+z Qva8ppw/i3c3erFD+eOovTav6VudWoJkU3+85hTyY2uQbJesngqS/bKcecowqJ+IO8TPxi+vOoCW 05wur3pDq0yAP/TK1Tbsd4xuVkxHC2p2oGidHYRbTdbyI5CVfnTXzc1as2YbNq0liEauAIuRlcAX KV0NqESamct65GwYx7U1kZbr6UKjEmnrkpCiDRtpG5JaE2kMKpJmSKSZGRJpdsjD5KWONYsylVVz 4gt3gNcKQFge9tnN4x1XjiVmEffuIWafEmnV6anIkd0tibRoNpJIlyWC1HOpZXMPSFoTacXDkAok HHF5VD8+hFwUEoa6oZOjyMBgbEGANNz0g6lp9R5XVB4iIwOkclQWEDl3MpDCKS5y51mtxR0GSQWn hq5/NMR7/aPLBJJieY+DrFtxi9bNir5uBcPRimn3vF9HG8uenHYDs5tdOlo9q3XLcLky+cIItej4 PU7VLHW42p79czacHADr0LcZjEpQuEZSn6FZqH3yfi2jg+Zxan/n/Bo14+m+p/uQlZNtLr6hTbgK rOf1ZLPas+2cz/M5Tpbap/sGWa66ZGNtCHX1grOE4S7hSFffHWmZ6eNcftqfb2EuOe0BaL575BHI IcVtJu3SYufiZcIV9PcCx3dbXkUxV1WxcLbd+u63huHZHQVT8bl4DC5Zi+9acScvbYWuiHm655af 0joN2zgpk5a7e6JSkkLrKk2SbaQD2yXKROVOpfEHZSxRvPW0bnNq5a9KUgksCAeiL5qvX05sIur1 q/RoV3IvkU1cJu61xP9KHmqyY+mXFg8ojkqVqal0TiW/W0mjqcBRq2/OQ9qN1ZXVzbmLNEbcOy84 1vm8gDpcZenWX9KBZvu9qKoqHT3jVglM08BRwDyzs/wYYnoWMH8B9AO00/Cqq+DyCaOroAA5Y6WX pLCQfvINNNBz+NOTo/TT9LTvnPIwYvUbKXJvwxnao2T2GdpSR8AyMdJy2iVObdRbzeDOp9HEHehj Pyw/d7znzOaOV+1okuuo0QQSzPPh9Z3hRHQOI5e9fcit6lJf2oPJ6+RMrSNpPxxJ0qQxgKpsX0SV qcMgj1t5OXvILPISebeJpqt5ricTuByWYweXgSNZcdRZdQ0n1e3wEq3U5rTPoNW5MXNyaHThRdpb N5QmKEY+DrEUFCA5L1lNLNCBi3LduF7cqdy5nejCaEtAF/7IpU7ZfoJ7hXuf+ysXkNz9PAfeXZE3 bzpvPo8nTsV5k8XHeBd4pc7CW3ln0Ve8jzwWP6G4e3F9P76AD/z4fnexkMX8BP4O/hF+Hj+piL/D 1E1SqT2bQePLmcjZHNo4+UXaUPlYWTEyajFjhqwAOdtykt25n06yO7fTOHm05Tj5FdF9EfhVRIos xA7igWJvsV48XwzscFy8W3xMHI2XirfjH8RW5lips+etvNz+2ChsGmbMujtI2724WoHZ4nuwmbcZ 67WuxtXXMR32FqMrrBWXeylikiq1uRm01SpmLsihbVRdpP2oSk4tRtalqVJpBUhujGKtYpciQ5Gv KFGAp4q5nTaqoi03qixwB3wgDrzx6fh8PBbH8cHKY7hUDUrxF/gHXK3mKh+pPZVTlKalzl638tQ/ KNcplcqEYqPqIivLXKVWWams/Zm8AIwJW8KZGEn4EoGEc0x+nlulVp1B0xQx1Tm0+0Vxu1RXiu5p i5Fbd15qCxA1yCdKiKdEPWGq7qrup57bCdwvira8XzRdPV8dq6ZmbKBlyqbQfFAf1XM1rpo4T007 MlTzHUmd/bnUeRQtOimvQHNL80zTcG0xtkcPnHUjdXlYoC5St0q3VZeuu+wcYwrcZXnaok6WzDzw oMjBcpfKwtKeXXOzW2c3No1ZkWeq76pvOSl0sB4s0md4O1huqXSw3K0/pr+gB6X6F/oPenOSC9+U nmQDF4SSS8hEUsQjyAheMfmENCWujY5OOmfG6sbisRqu2HWayJKw5KwVrE5bWAdYcWdY11k61lvW dz/4ubjLzrXXFomFzHMPiuYLd6mmC9F5gpqbIT4xAmbFOT9uMBcs4v7E3cY9xM3l1kfPF26pBPOF L7gfuOY8Lo9acD6FB0LhezKR5yFuWfC+RZxaxzsj7sLvyyeueUcn5aOtZ312B6q0s0m7+eAY/wK/ 1L08hJqIWIp6iJIGiWRHtkmuafO1Rfvhuzb/QdEx+S7VbnmmrObm4cWMfBmzIn+b6JAoV6QVVYpA rchILDhxTL6l8pjcVewpBlPEoeIl4kTxTjEhnoYVi8EavE5sgnXBdDgfoyuDMKsojLjmo84r2I4d xtQYo0EzXVuv5C/HzRSjdL33gkEKH8UMRZhimeLkw8qkvTKbAm2RXsUseFD0QfW0SPBC1Zhac/Nd mmkGs6KgUgFqFUZ4Z7wP7o5PxH969kEFtlR+UC3BE/GdOIGfw4txQIU0lMouyptqvnKSMkgp6KVZ rRynOag8q6xrGlOWFHD+kfKdsh2xZsgmzkMMDCHgAe9ImNZJQY20+wiUOlc5w7aPdq/sfJVqcCWd eb5J5VnZz9K1Ulg+3MJ4xHO/cvrR833U7uqJaokayNUr1JvV2k6elTpLz8pzalCsfqKuU5toumj6 avjwvQiCNDbkas3PmoMajNRoNpJONRqmju/uV5Z04TvdCB1bpFvT32mf055GHmFJbtcZ33JZdCDy l8ZYolT3QvdBl2Su5+rlYK/sQpVKYclELjSpEi0XCZdYJrDjPVZ2Zmxj049eaDl7eZr+tB5c0z/U d56WaHkiM9HShOxCgr4kn5xEBpFR5GqSxzpIggCehqwga8gTvE6s+7zhLP8JrNVhvmVJFyMALZr1 ck0H2nbj85qQVNkIgjqsZDNrwhwf17IHWwwoYQ+hEibEB7sG9ew9dqNc/3ty2MvLmx5ncaIItY7o bzTOax7fKy481SLRzlTCF1jTR3sYKTyQiYJxggQv9DvuCO5s7paIOXG00y57ZaZz4uiVQub7Ef1S 6wbV9d/9ejXaRV43UEbQus6grzCfGuVCP+XaSVYprPA0Mvb1rfCcPhupFComi6e98py4csZFsPM8 +zYnu6yjySa1td4KqeM29DlvYctDTxX5dzQW/cSjLUi0cdk8sBv9JtsHXDrDv87X8aceML5ZRZ/y PMzxKXsicpvNn7V3uGiCSCxaKIoXgRTRftEpUaGoTPgPyROvOHnS21GHJbvmOO15vyO044yngGTs CunA2RPlMV0j850UJwdvIxQRIX7ViqWw0i3+YzRjTYRDwqUD4jPi62Kd+K0YpWMHwgznk15wmcoL 18ZiuLSp/TQBIJWin6/tuMseMzr5St5cMvklfVLMlid8UIw9weowE0UXheEk0wo0SFHq8z4uPrK7 inmi3bb/Yu9M4Jo49gc+GxLkEBNuUSABRAGVRESLPm0iAQQ8QuJ9YAKKAlaCHCoWSxA5KtooHsUz KqAIPhKp0rRSgqj/UkoNIJcKBgQVFYkCCiolbzbAYt//+fTfp7X9P/Gzn9nfd8eZgZ2Z3Q18d6IR VR4hwapDa6jhjzHMNHND4J3B4lieEKZZpAVwdomj2RTLExfSDp0ak3Yxqxid0kHfnH78K48jqLTn ue7iT6jVNFI0/nBNeBddxQiMmGuaO13RSfJs+kZeGHhSub95SJZWqzNrq2iv6KRIKgIlojpRmwiI I6L2SuIi8ou0xmf+UjrzZCdbjCNHilsvAhYnv2j8tQuXAjiOimh2fhFpybUpNVcucW/8dEfcJdaW CUbKxsuO72wq4MnCZJ7rSvrfACD8TDoUnSTK+QCd35nyBfI18ig5Or0D/SynhriIpe3CTb+Ung6V EsC5GJyidrOmiQ97afvPHUs6QACnVBUNg66Omq6VHb++QEriFPsUpxTfKX5WoOtlayFKQ+Ws4J/R JdIXKZ9MU/UpPDiG1qHmQ7yucQ3WrFBRgbJMCW4r+/x/B9U0VURUGeDFRXQbPJk7Zb+hiSbDhIuz W9jjxI0gjbJlcboNgmxAl2EAJ5gaze422GcTOQaxwR1y+NkKleKJi4hBxM+JJCvzw8Qcoue60nJi E/EpsZe9R/0CAyNTNmPvqtOhBhOfkOY2upDBMPlycghZQEY/AcsjF5OP3SBHRIXQ4iL2uxKyPmED 14zsycOWZ0+aM1Hi7mVT7gXcl+93HTJvHzOAo8WNZu93JU2cZ7hIxJyytFRGRRdRFzylDqGb0WXT ptJn0z3X/ULj02Ppe+gZLnuNCt3TV+NtyZ+QtQ81ttJ76ajnCpxZHqzFrGBWNGtT5FD4bc92Dstw 22viE+i10sBnDSjx8g71Ez90Wx6qiNH1q/EBzmETw804J2NobOew8vCzG/HTw2s2/zKoQFG+5Y6l 3+Q+4vpNvarHJ/MzJ/AzpvhuaOs5X5jUJgHVdG9yKj+Ln8+/ym/gt/MBPsYkxuB0lsAqvSIlw913 A9L6rbtvqPeZe/EboxCfFk+wOzIuqyKFmVa+x4zjJqaxKRUp/DTWqZt7IrOuvozREwKycIKQKVwg fLljgzBJuO2HGfJs4Q9CubBxx9mOp11CoO7por5LQ6QoUQQOiNBLw3eFnhLZ5dCixlR8y5XOI88I YlHXmLJRYkkXwLMhvsS/ZMa5LafBfZLetUc/Rl0yvCE/IM4W/yAWoDprh5ggM5XZy/ymlpV5yZbJ 1skyXCpf7v8VjqeOJX5uY2vrOpNaJjWVSqSHnsVWDNENVxbJKmV3Zd0yHTkwlzvKGXKOfO7zu2W+ ncPa/ZkR81/u3/yY3GHIMDaKBWNtyU+PqB66TX68yB6AVTbD2mM69DrMOAIVjT2snZTdkdxl2nH2 RdknCi/FMoVgnSJGsbt+Uluu4rKiUK9cck/xXKGrtGiZb+zSmWkMLIybjxZUSqQindVKsEm5XXlY maMsVFYom5XPlKDdcBt4aXTGIMOdxSvRdN+ALyGUeBvVupUQ4qMiw5eNAi/08ewzBhY22YZmHEsq PANnDLxs7MecN2Q5lFep7qnAcxV6+7NbUTUUvUlfMd2qIp6I3v1YtJxj8Q5fUTFGP0esmEXdj6e1 rJ+4ePUtmvmt2aeHPNd9wFOSyNZkZ7IHGSwmB5OjyV+R7aKsaQfcvF2NmJG+Gx4siKicFSpxD9yM M8x+sC0qjPGUqfDAs71dwQWmF5Nqnc+iweAe88eZ+HnMR94V4dR46tfU09QLVMov49d/2kYF9B7f azb0SXTOzGmtI++Ed+g43GmXnEdw5YTg1UNXR/PT6Xn0Yjq4QR8YEc6sTP1Cn7pPIlr8CbTP7xls o38DdKffLWEjoJSHk/nrgl6B8fYI/W34wPAOBL8mcDN35YKn7WBbBDVywullodIZLf5bwu+tBFTr L2KaYXA6/MuNT1aKN9df0/exRuIN52sA5IYFl8qdwU3kBnCP1BgHJu3gHuUe3Fl5kXuNO3NaC2VY fImGxuoQmkNcrSSvnKBXLDn/mP5saFFRVbxfMI7nr/lMMyD2YiL7+c3CTH4hag8Wf50gqNq7M4VQ ucIEtlQBmiOLRzZT0JsnhYal0DcFWfm1f6xJZeLBA/rHn29hzBd27uOQ0u5rnLoN3DxPdJrmnHt8 wDOtWSPrVn3s8UeZpmL7TEFa/d+y9KUnGj1Z4iep0rRyjSxp2sVEcaV9pjTtrMapsq1cHuXOgqm5 d+wz7RKTwWdKJBk4L5H0gORscNlPssNPMr+mWksG0hFPUJUo0KiEN21facxyGfd0aQshPanYIa7N LuBU9S27AMmxLuHEfQWSb+Q6+9oMDxaCWSJf0aqto1PXi/Bd0RL9Ts24IkJV9xqjxKGbjpBE2wuI EeqPRyxouIU1oQpQFz6iacPikc2ALfgu5UrKJZGh8Eex1/eZpJDPJQSgM7NMA3GrAEHx5XnDFXan 7RJLZKsV7aJj007vV4xSfK8gXdf1ooX9HZlZBnpJDYhRI5Jz7mIyIC2R1PpJjm32kwRGaqLv4RHM eMGZQDye5BrGXxsQHxILqvseVLoWBxoTCwvuVhRUN8ueFaQ14HXk5lfu2soHXmpDy9T3axAbBbYT qvfKT8qBVF4ir5O3yYFihaJBMfkmUu1ebY8Lis+7+6sqR5FUC/JaZhFbFC8UsUQiMYOoo2xRP6Tc 1zueNDsoxHjtioaaRAF+9e2jsXwlOBl/bPfONu7kPcym0eWyJpnWjQfcSTu9mk3lw1QUlZOK56Za qHIjzXGbZU2oiVKBZNURlVh1UYU+vjCJV4i4yTdr3KuHOs1TeBOXE79UAClxOr2O6EdXUuPprcRe YieJPL3V6HiSj19YhCoIfV8GxQncD1pC2t3o/MVYQBrDRX+Psd6Tkb+FwYmZMWSmxxarvaIU+xUN F2vdyYvIQeRdE582PabjvrRoOWh5M+Ecmbk+272CjGs2bnlEVpH14XP4JGqz3/AQxsNVkRxC7XJq CFVAFaRQ06l51GLqaHomffLNWuBePdk/KP6Shw5/A93H5ZInWMyX0IvoX/HN+bn8CnozXesZXYs1 Ys6EsazpLBbLz7v8eqIwlpW9w+js95naf2fcbbLD34nXvRPfbT034OWFmQ2sZmPdcgPzBUi3wmC0 qCY8IO5W5GiuC7dhMTd4cWropvmirYTrNMtnt6VH6WDkpNQFyhlTJQm9/7MAB7TKF5ZGMvJEnVwO v5I/e9oPq7t/5DOu8zVOPdq0ix8o2iyq2ynab5+ZndW0uyJE4C/Da7qX9fT/mc8/u7RmDJ8Yad9H 9v+5S2uub4XEWIDXu7SlMEMLmuG1Lu1j036XNj2bgkRZDLq0onHFFKTcFOgCgLq0qFnb/tGl/S90 aWkWf36X9ub/cmnhOJP1jbPf69L2wLFDvkfpd2lj56x/g0u73ADmn2XV59I6v71L2/vnMWlvqerr j/SZtA/CXjLflUmLn/vOTFptlmW/ScsmkzgpiP23yE2whEzSe/hY1W/SIlWryf0m7bTTMVbIBHgK z8DD/SYtUlXPJaEi7UbQM2yNFWJbBLgkwLzXed+9CKhF2jMkq4fIghgj82+Bc7JHNogsAuPVGu0Z 6gkPcKII/KU02r/6++sHUtRf7DZ81V8M/PSgLXoc9Rc7tdGWOapzoi181V/8DFn+DvzFgZWMRwB/ 4IrzB7NwPDAPtwwsxs0DS3HecBsB9/Uh04bH8DAPDubFqS0YbfgPD/f6CLq26zxIlkHCU5f3e/3H V+M3OVseyFIcuiXA/QR1/Nu/wB6oD3ntz6ivNNvXlPZ+fb+B1W7GgavwTBQDJ3AZuIAi8ClMXWHs BrkrqIRxLeQ34PFamK9Snf+33+e7aoc14gjMEScwHHEBJsinMHWFsRvkrsAOxuMgd4THx8F8dgia /320IwGWmwTr3QHrT4HtSIXpYRgfhfwwrDcV1p8C27EDpkkwTnhP7cgDvUAKukE+6IRnpR2ekU5Q CuOrkJcCPFIMtJAioIPkw1QKYzT/+2jHSaQXZCLd4AzSCXKRdiCFab56RcZemOIRKaKF5CI6yBmY ZsIYzf9+2mENyzeH9QyH9ZnAeocj+TAugDwfsYPxOMgd4fFxMJ8dguZ/H+2wxFkjFJw5Mgo3HHHA mSA0mDrDeDLkzjg7GI+D3BEeHwfz2SFo/vfTjnRAwR0Fo3AHgQMuFdBg6gzjyZA747JgnAO5BB7P gfmy1Pnfz3m5AftHJewfZbB/XIX9owz2i0rYP27AtAHGzZDfhcebYb4Gdf730Y4SJB2UwlFahhwE 1XCU1sG0Aca3IW9AsmCcA7kEHs+B+bLU+d9HOxLgCE2Co3UHnEdT4MhNhelhGB+F/DCcP1PhPJqi Xt2rFuarVOd/l+34bVm4f/ofg54TOqej82zf8T/WpUbn9MF584+tG53H8+G8+WHqvgrn83bwYX7m V1/pa39s3eh9hQu8K/sQdaNzIDpPf4i60bm/APkw/Ry9RqLX5Q9Td7t6zv8QdUvhNagMzu8fom70 WjN4nf1j6y5A0HsSyWvrfjV+u5re1FpEXYYRrhde09E9Q7h3AhlgIowdxdghjH2Nsb0Y24OxXRjb gbEvMZaEsXiMxWLsC4xtwdhmjG3AWDjGwjDGx9hajAVibA3GVmGMhzFfjC3H2BKMLcAYB2NsjM3F mDfGZmLMA2NMjNExNg1jf8OYC8acMTYBYzSMjceYPcZGY8wWY9YYs8TYSIyNwJgpxgwxRsIYEWND MaaFMQLG8BhDMPYr1tdegAH2HGPPMNaOMSXG2jD2EGP3MNaMsSaMNWCsDmPXMVaLsSqMlf+hY94A oGN+CHwKTYD96QxMS2HaClNDhINMQTwQj9fO+2+eBwbff9QN+w+6tcL9VnX82xa9TSmLYQkH1Vsr 3G9Vx//3Ui4jzvBJCt3skMsIujn/y6eqf1/Kp/B7SVBv6OcJ6DZYysB5Gvh9zLs4T6g1aquBVz8H pAAn+PzhpH42ed25+T19ZfDzqGBkKQ7dODAfugW/9rnz/a+R+//560P4/zngdf7/JLg/BZb59l/D Yf8aqHsi+Nf+/4D3L+iK/1P4/+fg9i79fyeYTgJv7/+eB4P+/1/9/RUf31/wn81/H8L//xYMnpN3 4f87w/QT8Pb9P08XAM9+3fxD+P9S8G79/8kAqOfMt63/O4D10X/r/6t/Rv3+f91OCqJpBoBr/wTw 0f//6P9/9P8/+v8f/f936/+3vcH/b3sL/99HaqmKf8geyvByLo0JUKU6gY/+/3+V/198r7NO7f/X o/7/LbX/rzBe1aD2/xtR//+22v9vQv3/ZrX/fxf1/x+g5n/9Q1T9b0XN//o7qPp/D135dUsLuvRr HNiczMva7heczPNP5i1N5nGyknneyTzXZN7UZJ4TDBySedbJvBHJPAMY6CTz8Ga0rXq8OtwMgJ/B 84Q3CKhof9OfU6GNR0V7Gira42TlKjrDxNhsfUcBw7aHzjiZMXZ94wiGbatdZDl9OVVv4yab9OGR 6WY9e0Y5RKJrt8bRCdvXl9od6Fu7teGEdQUPVe6vhxHqaKrP1YLNNvohVKYv7nPp259u6FWv6iqY zVCpV3XVQuK/t+Ed0nWyRFCJvgZb1xUs8gO9cwQIOw7HFhx8ZV1XhDJo0SNHt0bbksaEfiYUERKE BL/4MZsKhYKKnVq7/RMfC78QGomSzAZXdg3ehfSEYCu71iSD2thdx2J3BQLFdtAv0tdMRYJ+ne+M Xg1VwClMvZao10Ux0giGfLdfP3bvc//79gvZ63DmTd1e81gqiosTzUWt2ocERGzkh6110OPVzwCa Nf6Eev41raeaLwOdh0SilpPyabc2w3RLFZ2R5jje77jvsZaOKysyrlCYMeso7hm8mEzjqj2jeBmU 7TGHY3JiCmNGk6zTKVrHSrIo9beBzjCJqYRQb+cFzM7aSAi6Eg1iLkVCMZXQJBZ5NIn92XoD4aj4 C0TEKRYHRk9JkALUvxlrHZZBE1XslB8/GCuwyk3bapUbbet7kn8s6EyVY9QpyvcXTC8qu4TlX22X p+Ou5Gh4HrLXPze6d/yAKz5LlCYFgafmOxoXB4uid7vJF/5cM6pnrXxLqdoVR6bvEqbiwQn1mwe2 DG3qZjpuBkGKvVqooFYiso/lhUj4YNjKsgdPduCPKfChEwsqOmT3aeerK7X3Pfeng7XzUcXfSNGT 9NxfW4/XeEtbPFI8Xuxgcyx0ukqnpqmJzij5CcxpPJ/gK+aLVzow72yymX0H9Dv44lZxb45mQxbF 7JZJrmE74ZZ1Lrl9XC5Dr93y8ZSzZt2Oj+3P3vKRAX9ZhCxBlirLkuX/g707j2ri7PcA/kwWQAQT EFBEOwFEwIoDKK7oJLghKmEpLn3VJAgFLDoQcMNrBwGxFiGsaq06CFjXGnHBJbRB3KsyoqVSi2dY iqggw+qCSm4mCfTtvX17+0fv7dtbcziQhxNOEmZ7MvP5/n7qirNwByhMgjua1K/UA8kRJEKKSBBM hpPm1DbyC/IrUk1WkmXzeN0kxrOl3qem1fiMhdaLKRkVR22hdlL7YBXFv01RVDvFrqX0xxubaS3l ZfPs64PpcHodDba1+jkV0Kfpq3Q1/ZTuPR7GEdTEUDYnLTy5lMNJMMJzdMdAz+Huk4uHTBrj7loM Uf4aqUauSdHs0BzSXNCAirMjPAuTRng2al5oBvDseMCNh/ICeSt4A+GtvM95R3ngax7Jmyvu5K0S D4Fd4anvQRsWwBI4Fk6G8+A9kvNwwE34IUzD7Nrae1LW/dBDvbGWyIUtrNeRbcYJFnltNutPB4a+ LNkaEPa4t8BX367sVbe6Mtj+vshMusZUowuTAuM1NBMm3R7GTrTIzitgL9xhHGiUE7Y1LBFjGtGO EJlKt0qt2Rkyo2syaIc0R3o3LPFrhERohFzHktbEj5ZzR7gLZYHn9nXELNzRu/YMmLK2d3pEDLYq VuOGTo9ofYrHPrAVbnEQoOG5DdFr8h3TN7A3rTUOsGdDsnsBo+WucUZlMa5xSTc2QaPldBy5blxc d0ItCvYCF2jLN4mRHiO/a8Mm5J7fsnk8tA1dsk94DM2r18wOwIaJ16anHRVOyc5jr3D3BXVszBr7 0Dn68tSnhS1+rbcWR7KWB5cWiO98kIzlYQex8xi4iT3EaAzCB+NO8luJbvHDurK5aQ2OT/weox9p 17jUeO6BXPrgpt2PymK7ssMLQWdOlfwjZYt2kFUYe/BtjnznkTrbREEyC5S4KsBUxQJFjiJWkbzZ bt8uxREFqzS9/raCUrQr2Hv8xtgTYBwxi1hERBH62H4xAS4RVUTT7pUn3OKzy9mH/EYB9KNdTi7K vLGHN+4aVRabXQ7Y97IuVck5VIt2gNzj3ed8ccnrQb1KeVtJKduVbLXAWu2snqyep1Z/1sCk9U8r 1JMj22dJgwLFde0mgU6V5zK+O3ZX/ZP6udqEBMPIMeR0MoAMJePJx5+b1M7Mu+zewZ0e4f8IDa38 oBb4N6bi1WX+jQ3XF7cdd9zwHJTFunfs70Q6q+QFmhbtff7tzq9eTO6819OwhPqY2kQlKqj91Cnq dul31COqNP2nEwNoO9qNRlseVD+DukAIHUFvoNPovbSSvkjfo0Ej/YJmktHOMV+CvMsVlgB92WIU /LyFG6apLmvhbtZAbBvnstgKS9Tx9uAquRARtmgHHzvOc74/OHb0Ty80gNk0+raMNbytPAf1Z40H eed5ztG+E1c+t/Xpdfbe41lZYs7fM+6Y8RxQGcxx3t5l7XbzzJzBe7zS4ZkEPHG/0bHZxfDWyw43 +bkz3fPKGm+UmfoJg4XcwEaoNkQkEXLnCNnzfIRLtb+LFi6ZHS0MFzUun/oJItSXgjH37KqJRYTg qkUqGAUtSgE8+5RJ+0edg3LBvYAzDhcd1IhR5nGvGsTc5yJUZPcdf4a7RPh+ABvKX+bj7PX5BHOb oxNKz0wUDCxVRQTSb/0FHpaSmAAnFuTPLhoiGM9pHBViMYBr417EN7Kd1CI2gpdKzkJg4I0yOfR+ APDqtZJCQ2UQyJEcWPqyZaRKcnupbr/cCWVWgm+2MHvmrb7g0Sx0ERqFsnP04v6xkVA40Ma6UtaZ hRaiZ9Ax+eBa+MTCO+G1aAfKETPToutT/D+T5pU9CvLZKec+Ast9CuWRPlnygpg1or3rT8awwkWP mMoZhg9SYvBSbCoZvqRQ7hZUKJ8omSsB/5CskuCSLEmh5IxkGfaDBDRL3kp4mD3WoJiFGRNRGGtj dFMathdTYhu9/el6DHRhZWicZjTujfvjUlyOX5/udyczr6wpyOdhAbdJ+xKeFET63C94nL9G1HDo Zb72JTTdxfv7qivAdEWAYviSJwVuQU8KmGQ1YMLGVxT6ahmFBEwAD4IplxFBuJJpxAJSSZRvjH5c STQQN3kXI68bg4rVN6p7kaHwaNgb9oelsFQOp8BZykPwBZjNsrkTNq5rej33KubfcMikIgKwRvJx h3WyRjfH99Z620+vB8qGaQ2BDifoSO3gxwZVE2dOQ93Tx3nIQeQ8chNJU+fTSERNj9oBHT/t6ZA7 RkF2d7n2lN05I7R66Y+meVAHkPa01zbyd5y6okCFY93MoQFgx6kzLFPuGZHymtfztuWFPd3Rh6Er Y0aacd9SPPqY0omeOTPsdJu/8GmQz0UW9+lyH3CbFemjYt0Ca0TXTGpAuEjz1F0/BWOnoKKXgsqR p65aIA8cL0hSgCe0ZVaJn1gNZGqvN+9x52vMSIfg2yy3oPzbrJ3dA4zsgLXZlaZzF0CnmksO0R4U p5INpIS8Ams/dD0Zmk+eJEch35N+SA95NzE8Kigf7PcW2AG+2lkXO3NxL82MrbUefFQQmG/sPGGE Re5YER8CHgH57Fl3CcEgRxsRWDmwHdrvaMPht6xFMwa7j9vFnD9oUUzYXg3yFnhq5wanv24D+63e swOfLvAcUF7c1qyrQqNpfvOgGjiLXrSxedY8Z95ks1GzAniJhkI0vMRPat1Ftc1m5axnPtzmCtYr n+PyJh/BS2Ej1OlrElAFNb/hDYJBfyEaOAHeDkvTwCufYstXPir4NkzB7TAbAdaIMzIZqUOWIRiy GclBwAFkAXYDicWeIRrEAnVETbzQOegSb58oNAVNRwnUpBi9hFZNaqlDO1GueEE1ZBLyBBGLxMFi 39TNdKI4MVtcJC4RXxc/8DNLFNW2aF+ibTa3pYLllN1VMDhbMDKzEYJ3jc+sglpcJFMkYL5kuSRG kiTJlXwpOSf5UgWcsostnbKbJK8kzIkKBAMiLBgLx8zxbZi+rAeoxDYou7G9Slv8fXwaLsZNZHgc vsR7Rh5+Aj+P38TBQ5zGqyboTxz2B94CNLr8jZlwPH5L/xn1dwbeupnAmzEY+CuBN7MiARRjBf51 4O3yOQH0A/OA/xZ4ExoCb3WDDIG3aO2Ef6XVPzWPLNougMr7m0eeVgighneBt79h4G3xJ9pF/28e eHv2c+Dt5+2M0m1nzzq066Qh7waovrwbqPo57/brcbfTAgiuHgKANxN3Oz/U4n+Iu3VptzR4ytC/ duvIS5qnET1xdUzgLXzv++L/Eng794vA27rfCLy5/zLw9qZEYAi8fT3sIJSpy7vN13D0ebeWh8f7 8m7cRf15t40g5Oe8G81567wOpKQLoB6rCEPezcc6k73J9SzwVgsgP4T/1tzQOvLEIgG0qK91pGT+ MwHkkNqfd1uq3cdVVaQCfd5tvhIXQFbaRSZobjswo6lrPK7vHGmm1C77mbjV8Dn868q02SAM5yPN bXbfzOEfK5gNcnB+HLAH725/zdv/Vv165mj/V8gP/t37h/wZ/qcU/Gv/w3wf95t//csb0/9D+9Z0 zmMq+HX/0+d+hNsO/lv4n3Lwx/qfKdqf08Dvv/5/Cfzsf975m793/5A/w/9cAX+s/2FmpCj4/ev/ 9YHa9d4AcP4M/3MV/LH+ZzrQH3d+7/Pf177/T23193/L/+j+Rwb/M+YLATTSTvs8//f+53C//zn8 zv+88z/v/M87//P/1/8YQb/tf4yg39X/gyrvPjRYmMB24f/I2B8D/dHZn376s2gQYPXRn7s6+2Og P2rAMtLTn52hAPTRnwzG/vTRn2TG/vTTn4GM/emnP346+9NHfwL09qeP/njo7E8f/bHQ2Z9++lOj sz96+rMO4lga6M8Rnf0x0J/BjP3ppz/djP3R0x8NdBbo6E8rY3/09GcqY38M9GcZY38M9CeEsT99 9CeEsT999EeifTcG+hPC2J8++uPE2J9++nOAsT999IdE32gM9Eeotz/99Gekzv70059Mvf3poz+m OvvTT39CGPvTR38cdPann/5s09mfPvrjyNiffvqTpbM/BvrDP36C0wp8n3TQ5qGmKtBmHsoB7dZh Ha2M/elk6E9XK2N/uhn687yVsT8vGPrzspXp/fGKAUA9rQwAes0AoDdjGQD01jx0paNgkGynHGjM QxOEYJAs6SaA9oZ+1qa9mw02sfeG7gbJ4IhKerhAJb0gy1ZJP1NJk7TjBJVUrpKuVElDtYMPVdIg ldRPJfXRDqaopJ4q6WiV1EE7GKaSWqqkpiopZ/RG95Pm0lYDFxLovZCj3MCF3g49wREGMCc0scA3 qDCFbS6c5GZeG/PJHXQpErJuvaN0TU0qUmJdizJKCBVx78becqmLNTTmcB8Wwygh+yRuK2OBYN3V VJ/Ygw5o0hQni9R50hSmsYaZxwsTyNBXo8dAgmSg129TIrQ5mbU5USeCBhtIkF4EpehIUEXSfzj5 uhSlt4H6ONX2SLxNwdo7KSs7fRQReVrhR1SzDX01boLe3ZnQPp0HWpbGlqaB6uLM/OLMf2qr8Wsa 6IZeAz3ZocwEufUiuevCwLlxDS/9w+M1DAASmM5arYyPit9gLqVFwCgIlnOd8HsmRjPWbxfjrC0s 4wh8A56G78U3FpXg4Dr+AG/Be3F+xvj8kSlTT67j0p7N2bHH0Plq4fIS/8110PKSVtb6C9ovV/b6 s7Z8faMSv/Q3noqZySlACqWCdQHQVkkKB6yNUgg2KtIVzYpVxKVPaTJ1aTl4qKAVEDGYWEakk5uJ YlKIklVkFlFInCGu7eHHcew5FGFo+OF4OiRppS2f7Xha1/FjrM2nTMePl7s84ziN2QtPlYL2HTVV Qy30ZfxL79YC4V0qkeLQNnTJw5bvPU9wBd60Py2lmTrovbn83XTtMZop5VxPdzXmghwllAuQFW03 ufkRy7kFXPACGnRgVMNLzYz5/sGmApe5mmAxMnfWDIGHxt1r0mRBgGyF5GNZRLjrNilnFau9iGkk ckE7q3YfN6i6QzvVIJ9/Z7Ql+MrzgFbWqx5gvSiR6SRS3ZXMtBKpfT7B0tPY1jrPXyTX9REJ2z+8 ovQDm4557p+K5BYe+W12OH+OEsU/PrYorlc4NltZpAQlym+5d5T1yi6lkXqomp8xNAWMTEmz5Lbd Us9ULFQIIxUm5DByPdlDlm9rI1PBJIePyU2kgtxPNpNRCI8C6YgdUozAlAc1g7pG/LDvcQ3V1chR uvy4a37UasuidtNsTVGnr6OUuU755ggv+mh+DNMyBGrRF6Q+e7zLi7kumai/MMnPOO6eYXXGhwu1 74GPw2WwdtYHP4c/QDjfI2Nc28nU0CB9mwywCbmG5EiakbOSWZIfJa+RRHMURj3QH4hm4i3BK7Ls xSJFYStlK8JXb1nhvr9DiV5E76Gjg4VoXYLV8TkPrw/qmcAym11jI9Yug3BL2H+W7wywVLxanCjO FvMzyqUZVjfkbG7HVXG1+Kn4jXiQRCAx+UQCsDGuHWTq2qTYkJ4JwE9xS/Ll4iHrdymMsKFYhQIs VXQoXLAp2HxsORaDJWFduVjYfrvkXTPD4+I1UatlupKl6uANcfHhqzzyO2svYVVYEzY9+XrBoQFC YIwz1zBdfYcfCMBD8Xg8MRXfhR/BSxOozAyrRwVcqNOw1SgcFOMV2QqOFTHGtXPZ1ZyTWxQ7FYcV QKXgEpfVrsRj9Vq1GTmZEDDVa7FcRJSQZasmKrNRkTxcBqIKwz4hTDKJAuKIR1ct0UFwlP849R4r pi7hAwtHpZdyjhK4zJ1YtUqJK7OUhcozymtK99KEnrIMK6ie29VfRB1VB6qVag9yjGsXmDzqeH2B +rT6qrpa7UBSNJhNsjVZtLNmIRlJJpAYcYfpjnGAKAwbpnq5MEotj18jixaURHW7vybNKZiyOTxI 2DlNTAEZtVi5GHiLd1PHtFOcO5S0nipNsAEZViMsud2WNBhJT6B96Q/paPpber5mjCvUPXnUt5Zf 0yRdR3fS0zTgNSzTwMhX8AwkVpOsydPUHtSc19zUPNTQGhAUjstWRMpCo8MHAEmYPDwuTi19PgQc YNmxWPY8j6Es1ER4ocErsMWj8jUaVuhy1Og/2bsbuKbq/Q/gvzM2REA2fCDBZEOFFL0yULSI3ERE 5ZpDFDQrN1HRTEUBQZEYIYLiwxCJwv4ymUaIxfAh9E/okJmplVPwoaycT5FaDgMERWX3nI19WL3S uvfyf3n7X3m9jpzzRs7viNvOOez7+37EaQNa7vuz5f4/su77N2VyfcUx/jtslvuHTujWorFni09y L3EbuGz+7dJgP+GX8S8EcZqFK91H1tD3WV3TvAJ9J/a83LXEYyhfzA/v4UalBxSR1a/2ZJMhc/mJ fN5a/o/8N3ymTW+eHekUvjSCZI64IhnuUzQ983mh1NR2NlraJMmSZvuofPb5HPWgH58tw0RMWYtL 8cBXSKi49u5sDkvuPze6YTansGG7KOqDcNmab+7utmeRzJojnAOyn0QPRVyJh0Qb15snCwx+JpbT EiphHuOEeZC3vy8vKZZGb6BaEjN+jv2m1+LoKvlyqdNAMne+k2KP9Ig0WFEjn684I11TJ70rtZ99 1zmmf4z/wiNT/84R1z5I8LeX+5/ymta6I73Ka1oY8hk22Xi8umSZ0bE9oMHIag9oCFmea5OaUXuE M4XnYpAly3PjclOZmroJb++yl8Vl2yRtst27iSJp2fLsQ7nHY76NuR/Tct6QmhsY7KLieG91GHXW N69rdrTwXdbgd6pecPhq+OSdNumji7Zm29x6e/YSF1Wv7bZ26dt6bd/wMeWi2rt984f87Sf/t+Qu 2eqYOtOZRTzLMxNyu6zOj6cK5XvlVW9v/IDVEB2oDFGMOLiOLAs76GXzCm88uVev4DGnDk9lvsxG 7h9v61pOxrwnU8Yq05V5ymJlhfJLZe+LyttKltqGtb4sMHhfdahnKWdkKTVBXT2SE61mLS+i0rbv q/as3avNV3npxWWF+6on1/qeP6idduHe92pSr6Y0PTSempGa7yunaxZo0pIPtm7QKDW7NdpKh9pm stDppuaBxkkn0PnpgnWROsI8hdbrCnSuzt6XAoPDGwZ4FjvUti7+YVFdQ3/BTR37zWaO3uatZo+a 8AZt4+RGkq86YiwrDG+ob9S1vNp4p5VqXanfoFfqd+u1+rP6H/V2TFN2ecV98z3DuDcGpAiX/EzY mZPYt3Our3qT7Kq3PKE4xmeMg4zkRePwoGMkMPh291ltCZdeXti1ebXx3ZbmXXPy3vjkjkhA0gvp r/Sv75GvivIpo9d5G/oveu5ej83e9125g7kvcVMl3FncOK7rs7ncIm7ywQeC49xvube442KWbGtK /GGM0jZCeU80hh/Bn8dfwV/HJ1v5av5hfi3fcXm00C1+YxDFmbgoUdbDJzsm/87B20E+ZOrgjUHG MRvG5KuItKxwYxBv8BSHae+O8Z3xYL/PcZ9vfVLN9SoTNEy5irzi4fx5ohWidYG333/RTnz6IMV2 d98z4nn+dVGryFHiLiFCSZBkqiRaslwy6Re2zHWHYUgsR+j8UuwmETm1d5rTrAH9AxPajmnEPUWm 7ATn8fMG+LBaj9qwzyQuW7Zz+5L0wiGx5LO4wXH5qqPyMnrjl7jTifH+cS1JDyPCBlKrp03tYkMu zpLGSVdLv5DulArkXV6Zf0p6RZp8sI0T80yM3aCYWVcTk1kvKj8TnRdlxpD8GObuWhdzOaYxhiN/ Rk5u8U6muu5oznlR/rJcGpeYTFHL5JnLdq24/xn/VJH8wErSnKPYfmfzyJpstWFpc86n2+3e/9C4 +XBJWx/F3xQixWSF+F3FMsVBab5il8LVYNQp7C4rGhVbX7DvrhygHKEcryQzlAuVKUrmrEDf2Sq/ VpKQe++VRTRVVXPUz6ilcWcryahtZyszEs5+Mkt9deyg2v3JpKr6lVqNtlA1Q29YWlW9utZu7vnj 2nUXjOakjT5MmRVzkpitWabZ76TZ9r4m9WONRtPHuXhiWPSb86+fuUYWxqTEDNCN0I3XzdAt1KXo SLZOpbvmqjvd1COrQae7rEuRxpmvF9YSQWj03JQ18do778pZ3t708FkN/W3WNhaqBnANS7MaJDa9 fbpsboywJ1SZvlp/Rp9apx9Sb19fZg5VukWR2fXL6jPr+w/TPmgvB2VSB+yMbsYhxlHGMGOUkcQb M34ZwtvQNLVfvnGX8SD9wN+ubaszzindP2h/8tR+t/qTKf0LVQYfw9Kp/VyH3Xvu9f4sfgBlrrxQ 0xcztVxZn/oWblf+ZMMUwVS2b3e7YOcAfqU/O6J35pL8G28m1LwSfTe312aX67m9ykRVZ37Okr8Y oh8zduxXrlUiux4+nj7po23P1I308Vg+RVC5oelhEIclXDlalb6miBcz5LKYNWDpWDfPqamf0zcO 7qOrfL2mZZAW+rySIV5N9GToRF/61DJlxPSv9u3kief5xfktFa0SvRNwREh5P3egwNdvSYaYQ+zP htmQAcIzYd/4/z2kSFrjWykNlpAmqe2iGt9V/GLpqJiwmIbJixz4p2Kps2GkrUB2j1LNyi00zR2Y Rt8sfCLb9ols/pQ6JdOI/g3+qWO7h7cJXyU8UxGc51KDrHKwrO/pLreifSaPze0bNKjvqVNhx8s8 xvU2Bs+NfmPx3DkC+kpIMIG57jUyF77CkcOGiaWXXhfcEzlI+kpO7+/W9SzP/Hzkn+/mfSFbopLw 9knMF2Ks1wUbmsan2XBsmAsyP2mwNFI6XypIkjLBBQtjql+3qY3sm0MuSxulzBNrVswk5eqYWCUh 9Gu3uejZXPPcRMl7xPca13vi3IS5RiY2ULJ44QpLc9GOruhypna0uIf4XkPLQJ74RgNTIGbsYq6k IUamQowpENMzFWKmAjE9U45h6oj+0NQS/TcFYgO2Cqh3XAihJj2iQGwH24NqdfmdArEDB0OIqUDM 1rm9QCydvv1TuDywI+b6MPbWaQLqqqk+LJhP5q7vT9jexBvvNT6tD/tvqQ8jXG5HQ/TW28SPG8yN 5M7nJnHXcwu4Zdwj1dyfblvqw4ixvT6MGNvrw4jeUh9GuljVhwkpvaU+jMjb68M8eJ5W9WFB/GTU h51nlVjVh3Xp/dv6MA7V0RC94yl2fyDP8AvFNEM3mqrD6EE+NVeHMcVhbo+pDntWLaD4d10JCWDe i7v6XsIfVIedoZ9m/Oluf+3qsO+N1wtEvreY6rCrk3jzHlcdFr/yMdVhqYJfVYcd8bS0Qz/r9iH5 biVhqsPYRnN1WFOvOx71zabiMEIizMVhE0290CNQHPZcIpGe2SKg+mSQcRp2zc1fojII0wqdnOGe 96AWZBBTbZiEKQ57QDLIF/W3H57YT/Yt96CCXFtMzdCZ2jBpPP36ZjD1Qn8oSiQflQooP7dppuKw MT82hct5rabisCM2HlRUq7k4bF0ISbtpLg4bx3uvMsSB7Jbz/lLd0P/7Pv4/9X8/0Nu6//sRYa+B zNe70gcz1ZE5MvP7LcwRWvd/T6e+pn6vw/qjO1iZe2VZdzxPIqPIBdPiRK87mbYt3235sHz3H3du p/6lI8igR2eWSHo90rRtGa8z9l5H75lZyun1ctN2Z+49hLpgWlyoJNPy2+7z/87eWfSxRpqWcnq9 3LTdeXu3p+rITNNSTq+Xm7Y7b+8J9N5OmJZyer3ctN15e2c6620xLS70ny5Wnfb+nb2b+wk2kKj2 foINJBq2ALYYFgtLgCXBUmBpsAxYFmwjLAeWB9sCK4CpYEWwElgpbA+sHFYBOwSrhh2FnYCdhNXA zsEuwC7CrsDqYDdhP7ev3W5f68n6GXYddg12CfYd7GvYGdgp2JewY7AjsCpYJewAbB+sDPYRrBi2 A7YN9j+w92C5sGzYetgaWDosFZYMWw6Lhy2BLYTNh82ByWCvwabDpsLCYBNh42HBMDEsEPY8bDhM CBsCGwgbABPAnoX1hvWE8WCOMDsYG8ayWrvZ/lVW+yORsSuwi7ALsHOwGthJ2AnYUVg17BCsAlYO 2wMrhZXAimAqWAFsCywPlgPbCMuCZcDSYCmwJFgCLBa2GLYAFg2LajdbvE7aw5xg3WEuMDeYO6wf zAvmDRsK84ONgAXARsGCYCGwUNgkWDgsEjYDNhMWBYuGLYAthsXCEmBJsBRYGiwDlgXbCMuB5cG2 wApgKlgRrARWCtsDK4dVwA7BqmFHYSdgJ2E1sHOwC7CLsCuwOthNmAHGnHU76ww+k2pr3+tMikVZ zJaymD3MCdYd5gJzg7nD+sG8YN6woTA/2AhYAGwULAgWAguFTYKFwyJhM2AzYVGwaNgC2GJYLCwB lgRLgaXBMmBZsI2wHFgebAusAKaCFcFKYKWwPbByWAXsEKwadhR2AnYSVgM7124z2tfoVwBYOGwS LBQWAguCjYIFwEbA/GBDYd4wL1g/mDvMDeYC6w5zgtnDbGEsWBuxWCuxWDOsAWaA3YTVwa7ALsIu wM7BamAnYSdgR2HVsEOwClg5bA+sFFYCK4KpYAWwLbA8WA5sIywLlgHLIDWwk7ATsKOwatghWAWs HLYHVgorgRXBVLAC2BZYHiwHthGWBcuApcFSYEmwBFgsbDFsASwaFgWbCZsBi4SFwybBQmEhsCDY KFgAbATMDzYU5g3zgvWDucPcYC6w7jAnmD3MFsaCWc4pWe1rzGPIYjmwPNgWWAFMBSuClcBKYXtg 5bAK2CFYNewo7ATsJKwGdg52AXYRdgVWB7sJM8AaYM2wVlgbjEVZzBbnZHuYE6w7zAXmBnOH9YN5 wbxhQ2F+sBGwANgoWBAsBBYKmwQLh0XCZlCPSlij/vBKhWXah7mD/O+lMlp60pPffO640rHkjZSQ UfQS2SlH8s+PTb+G0Xc4T2bsOnpxeeRvff5vx26jXxs753//nx17AX19+mfGtvz6tnP/3QX0uajg iYy9hSp/YmMH0GMHPKGx/eifOfNzfzJjl5vGf9TYTza/4knM//6cPHr+9zD6T9/HfvevP6zzH8aQ R+Q/eKvN8777HP+PmP/9Fb105vzvIPrzWPLn53+eJB3zv//q/QvmmDefzl//F+evP4n536dI587/ Dibm93//7PjXHei//wTnf58mnTv/m3mRY56vf3b8GnopdrRs/Wf2L2Ce23+1+oOvHazrD14KGd+N +TpTf3CVwxzh79cfvE2KOyF/3pKc1YW8SKQsZulDr/cxbT8uP/5x8//HWc3/b4oTUDZ9CAlu383T +f9P5/8/nf//dP7/0/n/nTv//8Af5H8c+BP5Hx/G9jWKe05+VjxBsEHOTm5ccEdEv8h9XLXOtj3+ g1piFf+xoounVfyHgXpoif+IWmmJ/zBQNzriPwTPW8V/LHY5YBX/QW37VfwHh/2r+A8D1csq/sPT s4dV/MdOt8PW8R/kLUv8hzfvw474D5uAjviPy2SyVfyHp7OxPf5DV2+J/5h3CPEfPWo74j9IREf8 h4MwoiP+I5d3B/EfJKIj/kMqjOiI//iWhFvFf1whrYj/oByt4z8cfIOt4z8MItav4j/CJDut4j9O hVnHf8S/7GkV/7FOkmMd/7Hveav4D1VEd+v4jynkxlymB8CzZewyMr7iRoOSif/Y1i2K/RMp7DVH xbQA2G5gegDsYFoAfGBgegAUMS0Aig1MD4CdTAuAEgPTA2AX0wLgIwPTA+BjpgVAqYEJAVEzGSC7 6dUksqdbVBrZG9stKmuVkOkB8Em3qMQtpLxblIqsel8WsWq2bNXhqC1aWY5WFpGllaVpZUlaWSy9 sUAri9LKZmhl4fRGqFYWpJUFaGV+9Ia3VtZPK3PTyrrTG/ZaGVsurOgmU46mr3tGyxaSlgamFcAE csrhOIvpBcAuY3uw7cVGcdxA10lrvqtrE3u6isX3h6/LP/+a+5diz67JyypF217zmZW4vP/CZTtc XW+xbALeSjA1BuBcXPrlQLtblsYAXqa+AHV/S+Mo20NC5GJTSIieEn7PvkKaiakfwE+ICJk1mLQt S6VWrGKtSA31ebkjIuSrwbztgh7miJCjacmeK5fY5SqUnFIFZ+3qlcuvK1o3iIWbsjJ7K4sUgUxE yBXyqjkiJCebytvUZokIWbeLfL0ze9vObKYlwH1zT4AAanx2H1kQNUQ+6i0bidzT85qz6M23RIKU 5EvuH+TJFz5HXbvPOiDfOOic/Lq8Ve6oELqvP5YtTNepONuYPuXiKEW8IkNxTRGtrMzc9nkGmb+H 6VcgUIZpHPP6FmdpyAJlsLJKM0mTpFyvLFCWKa9Xb2IiNhyv3h0dMiGom6zwuPJb5S2l96BWR7Wd u1qoDlK3RqjnqVeo16mrtqrVav66tCph+toaTiG5pG5QszUumoGaDI2drjKTKvw8o9+VRM1azfua jzUtGjKl/qomsZ5T76obrHtJJ9F9NEv3Q/OE4JTDqtGEk5ZZzd6gq7UL9C3V3WhwNorFqz5zbPzi /IPYBPnt1L4DD6+4+84XYk8q586njbpFXs68vfFpd3a4Hmu02dwcoJ+or5qpX6L3Sg+8LUwfw+Ko iGU28xW9uL66nj4a1ecZ3/2DvTMBa+Ja+/gZkgBCIGERBIEEkE0rYRVc6CSIiLgkCiKuYXVFooBL KxLEXVBUsNaFIlCsVTQCCohLQLAUXILbxaUaVkWtBjdwQea+k2Dt9eq99vv47O3z3Xme33NmMsl5 zztnzsycyfmfVy3eRty2n7FGQf0ObXnRxfhJseeeI+sEYwKrUeH3TKFOnNg+903goQ78DmtxP3cn Vy0reNTAbPPa1UPg4nhcb5u2E8aHB/85rHoU6mY+jCAVWORcDXZmVeXuzCvjNQJsTzKTUbqzlcMV AXTozvkkBwh0QnLsxHxidHxl19RldC63dia1PyFdcQ/nMsfm8W0Sc/YPuVvfb+eQu4TgtxAZWbGW 0DOmhyySK/W83k6LdDxCFmmbuVESm59bqD82MkXWbsZupJb3oN5CPa0QYyeKhbO62iRnzNbJ2inM 7TmhwbBj1A7W2Mr2pZa60C7YDa7OdB5wM+h+w5mr7Nk4tc4+J6/VnUn1s6RXP7vibnH9tSulZRDP yZKyxdIHlbocc1W35x5zTXIei5W6TBruMbLCdbp/TiHKyGpbQCnCltLSqeZ2yWrYFkYOY6HF2ScW 6n71nEGsG2OTm5il2yjzULnf0JB0zl5OCadmgNV+Re66wRTtPQu0ThLFO/i5ODdvuPTSxekxasMS Arepr5n4ZCjVvUOPiVvhAy+hdRN5eAAeiS/B1+O7cPaGNieBLzU4rNrzQvnd0o4TwU03PRdtDQ9a W3Sw+SF+7nFMpDafglbOtPOG74RPCvfyrhEF8tjBYc/Dr84KDX899/sV/DQ+Iq+21fybY8VBM8Tq wj7C0/0Dcp2Fw4UThcFfGXPF3NK9KQZ1R2+z0fqEzZM6OXnCU0IXvFH4TIjIqQb6i4aJBmtcWOBL bU/qrHbXS9RJ9W8ICOm8MUgvceapCyOmaK++lzzPuPoZc5vFdY80CrL8xs67PWlW2vOVXt6zM6E8 7UlpabHbiZU7duayxM5iNFw8Ufx2ig6J2HoKb69M3CB+KqalxMwMsdiEjue4p/4onJw6L5UMNJCV ilSBBkbPjdrjS00voH0rXnbd4SF+qNH4W57lksD+mefbDh0dmUmRFiE7b9hfkVbo5a0uC+SlFzCd K/SqMgo9avaezJRlNmQmPs2kSW6OPX7IU+IvYU/f16qceSDvRdZ+bitOcNfOdQi7gB6uMU7nPmu1 T6+IF3im9EJzG+5LOiW6UrbUReojDZKWzZZ+LRVEatX6Ul0aaU46esMbt+DZbX42t5k+6OeafO87 vRvUt9daG3Lb1cfdQmXj6lLmLK2veSq4qtVyrKy5gLL/rj3PpfFyE3Ju8vK+ogiEDaJJfndoUynt 1b6pZU7Y6umVFAq6M0v2lSxZdlEmkd3lMSff/pusVcae/qO23FzOkR+a+WKPJnfZwwchtxB288q+ jlcb5Lvlh+Rl8kty1Cxvl2sqTBVHXH9pO+lG1ffkKcjQOYhLY+teZaNNCj/9XMXB+VX3qfq5BhQD 5OW9lxXIo+pfNMg31jGoM8V+dCCGEmMJIZFLrCRcbQTOmmTgHPb0/bfaqA1PBM8e33/qw3v2hrpt HzUrl1BO2uKM4AZV8D0zb2LHr5k413NT0xv2YzZPuvyRV9XBqtc2bQNxmlsxPo6WOIlSU4Ae2NQV PrNpKXxjczFA3b2CQb3KqMtXZw+6y3ipeYg9NeLOURfa/vbXO5zgFlUMt6i6NjkKqWinIbqNIOt7 8zaW1QArB47mUM7Y/vFs7IZGkGWnnRkfrbLz5HdypvGjx26w1B+Zwq93hO6IKXRHxjkko04J3HIq BwpSBgoCvzvfrg79tZp8OmbZ1fFiYmxkBDvsK4IdFbk4MortQrBjRIviIudE/zALzaHU0rFhz18h uVJ5+sBq4QnBtvrLLoLQmsMam4K6NjF7p1+1ctaoPSDhlHMuczrb/b5D3MlO3n1GYlpBtW84DNwS fxlUV0iJRP74NDwaT8S34i2bTgperlKvDKMd+Am/ht/HO3FdPkJCfaEPf6B4D3+8uJK/SIxaoTM1 VHxSbAdNxEzoKLTnCicII8Y7zxG6xQs3TTbMFjZPcNCozSNnndiSt94sKzcrRxebnRCJbazV9GEE Ue+U1Jc1p9nunLNnAiLWjo5aLFon2ic64FGZuP2I79mttDxDli3L02T1o5k0prbtud4cQ7Hxzhxx MIdLSe2dSnY1Nkg2D1g1LNHxVRUVlWjUHiQbYyfGyPvRiMs9PENTo5oexMy0ylR2JhkoiUEq70sY qilwkF7Zkz3uzaanDVgPMz1YCNF6DzplPKj4m3shZfFpnkfVVpsYbzVM+ylbz/T08QqTClSsf0J2 ATbuVlRVWVc8rMEOvmbpcAZILMTFkmoJLtEcL0nmnO06dEpIitozmrro4a9w7uGQVU4amwxvaInM RI6infVYC9pYqd08WTRP1CBNFWWJnur2qazVMDzbSDtEToPyUoS0xb7yFLllaoDYjZCIg6FDIo4n OsQXxd5EJeFItBKtA1K9UvnJdjolvJhIIpTNiyDn8SBitewXh8bMCe0Ii4oMFUTPipvt4LAiNW1d zAOr8tw1B2hJRcmSM/I6+T05nWLY6IlQiJbCTOGo6O+h23uCIkKBFivWKXYq8hSn7l9EJW7X9Ck0 yS+KRwpE6BP9CCMGsmdMIXicIiKSc4NYz+ki0DWCz7nIGcp5ziEFlvzkN+Y6JaN8tOydhxFeo3yG eXmyRazwuMi42I2MTEY+43RR8uFLjGZGO0PTpA+0ybEx9ZdNq35hWrCcWN6sQKM+y9JNR8xnITFr CyuHdZRVGH3FqSripjeFdvgeizzYLI4zxxpH7vgsjo+wgjNbeJeTItTGUQtngvCK8EvhCyGOj8f5 yeZGOiUBI8aInda7bsY1s/EjeFFy/lMJTWosNZtNcOER1dHTpWjAGOrIojK/U4enSKOkKEG6Wfp2 9pYMfqc0UXqvNuRC+osYB9lQ2VgZskEGCYkGSxNqTJalGy1Cu34WJCYMX7impPxFzI6VHbHo/Omd qc2wcWZl7lps5dkNWL6e3FruLncX2onmye22MW2Wlgqz5UduFVwUNYmei+o1vootMxLbi4cshmcM Bjxk9HLMV0XAQavE34j3iUvF58S3xfpnsjeHmFfWZGukmqQOSEWJLXDqliRUMw/PS808v3FDTfa8 QlSdc/50lLS5vCZ7e+GS4ss5ahmlBarJn2wy52WOymROzZyfKc4svF2onP0ps6vrWG8u19jMZOoy W7XVtcHTXvYbV/7iVXFFxeprAr/y0EOMay483FzCkfAkARIUKVkiWS/ZJTkoqfWLK7vQvGD3peuS B5I3EoQMlk6kmkqnpBiE+kRcHS1NTtl9CXk17bq8vOBLRXr+7ktzmkbdpeZeFt0vLJdelrbAU6eX zLuvrOu0jCubINuacWSRLHitbIestjWR0Xz71xffITaXLmmTqckN5bZyT7m/HE2TR8sT5ReMfdtu GkarHZD3OymXwZ2kreUWvbnOsRS1PDVQVFDuvkxbFa3GMJhPQcsLmKz0/Gi1oQZ9jZdQeKbYkTRF rqJYUa1gEA8VGb2Zu16QZ/TWjKMjicnEPKJ/tolG8+1nL75r9hT7i9EloploJzQZpowvGF8yBAwk G9WHfduH67KckcrIYoQ5oSLGz4wktwbGUwatD9elwRXhrssLGvH0fK6LzvCHHqNc1Qz8j5LT26xn 7WI1sKQstmjEfHtyDqetGUUmnAGcei9O7BelsnOyJNtO32Matq1sKZHDOcqp4lznoAcc1YX5wdf3 ua/j9MM8+XgoHosj9CTR5tEO5gt5UFghbtlStjSJ86t+GCoM1wtfXnBElJ6vHyYPl86i9g1vmVvk wR/Fn8qfzy/koy18QnGUX8W/Pkb13vg3Zf8PRIy58h0FW7xR9YriE8O/3FKq+5Xi/vfDv6RL2ZiI FO9/NPxLJRu79iF1/5XDbFX4l3pmt7r/hISNzTH6ffiX3Wys/LfwL2YZbKzxv+Ff/h/K+5l9Uy3/ 08O//PAu/Ms/t7MHbYRS44/MkdgCdQeAmaTS+Csl/pQPa/yfQeNh1ZkghJMa/20PV/4bjX/gGfj+ sG6Nv9una/y7PknhH2eO7j8m9f2kvF+jW9+vkvczVPp+lby/WKXvJ+X9TaS+n42xMV90uKpb38/+ uLxfi2iM2KqS95/Z1yB6T95/7R+Cv8R/urzfx+6tvH+56Q/IbLky+gsxhqrS99d1mr3V9//L4C9j 4Gr00siuO/gLjxzJTEZ/oS5gY6PWoN+ivxycxMaClBL/mmJERFlbYpZQgW+6Jf4nlsHu80qJP74E Ec0VbMwI6mubSuI/SBn+5dQSFAgV7ys2NDs1krk52RfNFDMHvlJK/Lk5vihNTcxcYIn+u/xFF4wc wAJQyP+aMfL/eIJQh1QD0AR6AVrdn9Mh1QF0AQbABPS69xlACjc+1BswAowBsh2bdO/v253+d/nP WlTjqYgPzELwcaXYh0YlfGgcwiwl78YhvB150JN2SBtVSvoqbc36P7JT9btxFaStqh628495qb33 i3ejSUdjfQHrj84u8XZc6ucqzVDA/U+xbQ01Ya1m+SfZ/hLw/Le231ZQT9peAV0ibeBjtn+//eGR Q6rlbf7kQLB+8IxPh+dUDciXrux7Gb5XDspHfaL9YZ/e/uKdT6/A7kjsYz7R/oVP73vhi2nBGcmA 1FC5/jm9WAZ2+T3ihQBKT3ohAA/I9c/pxVNMF7HUdHvACwu1XtBKdCE1UK5/Ti8C1PzRVOB/78UU tRFw1feHlK9c/5xecMCuXY94YQ+lt4ac7MEDcv1zekGOimP1iBcWUHrSCwvwwOIz14UMvEjGesKL FIyP1kJOKdgI5frn9IIBdlf2iBdJUHrSiyTwgFz/nF7kIH+4B/aEF3TEh7ueP6QjlOvve6F6wzfj 7UPEPy1/9fiRf4b+h4a90/84o0DIN+x/rMHRBftkVmQ9fap9ZziAQ/arCtAT4+/J4zgafbp9bTB9 pNv/Hjj+f1h/oQ+2z3Xb/6vrb/6ofmAVRmpWVPu/RSp7e5CqnEeQylYZUvlJ6lTIY/MLUrXPVqQ6 Hp1I9YRP786LfM9Bvnx1g1QbUm739YX8z4Nso8GYqi1HYKq2HIWpfCfbAOlnPPbOb4vuvIeLouMi o+NiEWK/a7fw2dv6Cp8TGy5CcbG/7YPt99fJsowTxcwPjXKMEMW9q2vVbx0jyO03cM6oQWEpAJWc JRFQBzQATaAXoAVoA3RAB9AFGAAT0AP0AQPAEOgNGAHGQB/ABDAF+gJmgDlgAbAANmAJWAHWQD/A BrAF7AB7wAHoT1e9O/oC0oGAI8ABnIBhgAvgCrgB7sAgwAPwBAYDQ4ChwADAC/gSwAEuwAO8geGA DzAC8AVGAn7AKMAfGA2MAcYC4wA+IADGAxOAAICcZXIiEARMAoKBycAUYCowDZgOzACEQAgQCoQB 4UAEEAnMBGYBs4E5wFxgHhAFzAeiARGwAFgIxACxQBydHLSO0GJgCbAU+Ar4GlgGxAPLATFdVe+J dNS9QJ+lzRvSAqpWG3mGKwXhcEoHIO028iyh8sjzCsfI82cFpgdVL8Xoqrf5yhbBbOtuo4kuSKOt Az6lUP3s6cfuPHO9JLWzOxAvEp0j0GVMdX6qu5FfLUchln3bzsIH73/T93eSJC5kz4XGWFZNR/us NNEOMoOupTe2BeT7U3jMjIxbS6tNwmrZ+l9s0uyfZNXu7WY05dvTPsyoFKbAaf3mkGsXbnuPzte6 ofky0TC/TeMJpWvFje/13JLuXng0w4mn3eEZfXuXx+vF3wxW10MJVYg6hnJw89fWfXx+/nZjn1en JDk2gyKPXTzluOGeYMiwQ9nXtzj7JfHD1g3o3Jdtm+VUdkDgHmSw+qH3Q3sOPxlZBIxqzfpxT+6q wz+fu91rt7ED7yLVd8Q46hQR92zeoCxD35tGHmELMotKjh6zW7W5IWldiUnVAp1fF1a4OzXVnoxv fLl94fFsbd7zytiCuODBK76eoqdw7vg15sHBhIMz9i462z7Nb2PFhmWW7eY1z74vj41nLlnzZODM trX0+x2eDdsT3rAf0VumnquflbzCbkvbfrc3SxNqGfnez9Nwx94HZhQFdyzun+ttkqBY+0BULK87 GdzXcsRPr9Lz+1qdiH6Mbb8ROlxX3kTEX3wV8+C4g9ER/t9eVR52SAirT+MunVS6uPHv7P15IFbf /j/8r2twXWaVMaJBaaJCZG4QGkiSOXOm0ERE0SANpkYyJGWIzMpQhpRIRUmGRNFIyVAqinA/L3qf 0znv3n3u3/d3399/7m/nPC77vYe19157vfZea4+b1MMdTTwilJRE1d8pOx69fC69MWjWisxY6a97 1vccV30RPcqgFngvS8f+ZSUOCmcpOeTfVb/xQ8oZ5iraO/yP/A//WIWRdYnpvwujJgqjCPmrMP5V DFm70r8Vw4N2KIZTsCwMxsXADT8W8YaLztS8EncuOdF9lHxjG1+i04qsUW8hniQ+fkS/v415bP06 HR5OUdaunWf1qpUbMNlZdOdQWKsgN8+O9Rwf3Wm5Ho5ROUfDI79cwn8z1utuZB3HEF5JT+Oeo4tj +yoz7MYXeEEyZQ/HkB/2sttWr1y+cfe57qfqma8VJ5AXtXK7dXMWLbSJfLI70NbyfZKH7UrdPIfM 8gpXD/Z2hm4yORg5+dSpVcNR5jOXcaZ9zMz7YSxwb/KIyLN2B9thO7EBSudZnyj8fzTp5MOoBEad jfcj9uSkukrdAIfO/hO26ygfR068bNUNny8rfMwhuibH5piPDY19oPL1fttL/R5hajaH/Nk7PKt2 XT/5iHPk8tRwmSWm38rzrt9MeGZ6qUZ3MqXAztAlszVq0GaNgFim/nanzhK5Fe4xdxK138m/0Gy9 xVnissh0o13ijQDbTm5vF37J9wnxYQm3PqzYz3NJMX/FZ8HM24/Ohxw9XEHEqhfui1ojv4v61LJD W/u2053FcyJfTety2NrpXGyUcNmzm4dmu86jbuXrDAkeww0e02Zxx4kJ8/hv/KIuyvv4xsVbHbZr 31yKDjnsKzf7msY652UFTULXbRfQF44cc28KOzyYJPn6CzPyOsfqg4YJOf6Lez/eCrhY2n5YR3LF aFg7ze1tSoaq7+aLl7kXi4+GZQVp2m4tVGpOeXz6ovDx59sPVhVe9jNcHHDLNuElzWDPHcelGTF3 +Do97AQUhQ8/nNz7UUYzbinfYYaoqLa40dz8recClJxfdYhpBN+w2bwt8v5X+c+CKwYqb+VvKaxO t/S47X83t+Xw17TDWVEvn+pFHjt7ZwG3dlFQVPy+LbubCmxyW6Z3NqTKcgVIJkvWlUsb2xxmvzSz nUtQRCh0tN1m8lI7l92LX+2fWPutXCd0+0381oaLtIXN19Z+nRA+oqxwkeqLHLvj7nidQ0/iymdD /s76w1LJEnPlvoTc+hJ4xy4n4ojtRscUv8Al0YPvjl2c7vhj5QHbWXv74sTmXbdt2lxvN8Ut8n5e X+StG7PrjpywLC9LfT+gp9jK0Jzq7le+3nm2tnD0BAWmXpHTt8IdTD3xFd0nTmo6bxMr2jI447PD Ilkd95i9Cz5JvVmS51R4nYOSyhd1Qq06/3KElOeJ54oTVrxKrj90p1VeY5PWlh9coTnZdmUqK1PL v5181C2ql+S5pYnfcGiDnp3oVK/nXufaPxTY/JB+1hvpFiuiu9Yyd6txY3bAxVvtD7ZkctIOeF9+ n+JWeorfbNM1hw8fbPbG+lpnqFlfXbSk/cM3kZYg47acKMPT6cOq7W6KZyOdnSXWdJzacfzlbesO D6EGd4fzYgNyMxKj3LaWx1jm2dmlfmQrirpoMd/j4yKX78KuZx3dM+P6Qx9c21atdzrqx6SL3k53 7uQFm7Uxj1hwSWqO+FxpWxcalVGxJoS3bVBSWy90o5tN/mE/u2bT2e9P5fXJ1x1SOeapd8PhcFpQ jmC/e2DHtrLE0Q2OfR+Wyl/TLmPcGrZPWsNtuM2/LWV70fuB2Fnar1treA/3RlVuzlZyXLrJeFDz ZO0hAw3LiHW01xqRvLM1sj1C6Sp7nyrmBgW72+zw9k2OWfLsolV+6MWihIvp376L8cbwu98uCNkq 5VFZcMvv9CveuFPnpkovuG9c95TxcNKI2pvo84bVWfNkTdcz6jRuRkxOX8+v611p0iI/bEO/a3VC NlSvxruf26Rs576wmY4dq75rGd7cbZWkpfR6w7P2DqOWS3Jy55LmtgatoOXXLt6vdHQkIrJk4MBQ 24jbR/rZwvkKee6USkr+9ewhx66p1VNNVKaq346N2XD7a2i1YNf27B+exRR5aqbu84Ea27nyBXU+ C0dGhS/9mD/LceLSy7eCJh/QfuNUyyWZ/I1ybXlVqd+Sgh/Veya22AW5iyaVbtDYzf2gf/GR9bej Br11gk3Do982SPnkcibzXjrgR3PpqXg78crSSmvHNbrDGQ84I0RGDTmOVxWtoLVOGbJkbBb2p6nY /di5Ld38pZpJ0Y4hI7c7hkWSUkVW7Q4jfp/fOvhX/6DNWMvtcyuwZQ1rj79aa93KzBU2B6/Rx49V 4//+swkhNHM1x/9zx6rxitM/VJlusqpMc+isKtOHIX/Td2pFeuZWr2roazPfjxI6ffxYtVSdNep4 lekHluq/x9wk9O9louFYtgYTbT9ghnq8MLnPWouR3ecaTNyP6hqI+D9Ulnf0MnZzk9Z6eqJcauDI pHi9i3q5gWV8eZKKbdIurqeznD/naERPTRT/HqQ3//sc64tuhil6Mhvq288e6k8O//TMu0fdq5I3 RvyqY2fs5xs16gPFvZ9v9KoPSARSb54RPPh61bXSaUnrh5qXlSyLmtbxYr7sge/ztfaPnhbcXL+m alPS6XszV9Tf2BGfdjsmedHR16b85XNW5miXX+w5Gluo6eOa3PNo1XduzvbMt0OL5fxffpkRFjto uTO7Wrlz4XoVp6pmow9da0aKZ3yiPROctObD4/uxFgVaT+w1t1gtaz9iFOS9cijHWbs3zCF1ZaZA 0/ye5p5o+4Oin+efPRFauuHSXrY9d018D5+Xk7wdPp93l47b0tnP5Sd0GQe6LXKu4Qww1x5dObYc 8xk8qQu5C3Uu1/WsZ/eY4rRJ7fAxFUe/aQ8q91vv7s+QVHnKkzkzZXb5Qy2NDmP/8hiNXSu3fTZ7 KLHQad3VqJLWwZ4LvWH+feIdpyeaDFeoaq/+cTqs+5FB9eJMpXrxHI882iE9xf5spYTROa/We5c/ FAywMLPNnjOhYu7EI4WSXpki6bxv7J7sfiCuNPluT93nqyOx6SXzOTo5MGWH4sDlkZIHVhyqheVf alrrVrTJDL/ZoxoX0G3WE936OcxArve6ZXfbgFPoVsfRog06Jeu6vswZKV95b7Ci+Kr2jatHNrQk +3UdrRCV9rpvZyLtdduuQLr/kV2GhFf4yUvZUvrzG51kvKrtmNL5bXa7dr+33eWc06Qe/DynSSG4 QkboatPq4AaL9MbbXi1Tur7m2vk12TlJe92zO3vZIdW+s/yT8uSI4uQ4XZXChpe9XiHTZmz3Dpmg 6B7auNH9XIi9Usrtg2zZtvZGX6jfvSxHB/waPHpFmh6VzJ8uZnbsi+fKGx9NUj9FJmnb54oe6BUJ K1Bb21opsthuUr+Niv4ewcm+Gm/edmrKPbbPfNTU0Nv2dl7Mj9uNFic/Tp32wyRtrmn6JbvD0Yc5 tiiW1st/4nm97+3rXgN9s7Tqr4P7Xk+V+iS8aKB7jlFGZIrEoyFB3ZcDu6KaNffwfwr3MRMbNfOo Wf15fXCF0kFBpeAtm5K/sh/5OGVHcZlesf1w8+ewtlUvTeZ0XNQ2Cq5Lpcyu95myseD73lnrM6zs 5n4wz9T4eEM//WVH8WtT6Sm31biMXqgn6S1cucKkTz1/yhMfjS2PY3ac3Ja497XgRKvD1ncF1Xoz OiyKNHqVuCfyTj9/ct6ixdmc7o5cdo7CEVG+IYsq3yae3Hbux4Dhs1zbIz4HAtsn34mpXNUp9saj J65PdlIdn0nb/ZkGYv+833orbSD4v7Lfov5tv8VK95/3W5Sf+61boqz9lpPm2WWZH5U5u0pSytvO OtuMkljR8f3WwHLW3Mb3W+Ho999jPv5rNfBPDfX1fsz23aZt5MSLxcSe9UYA7LfqY7h265kIVQ7s i/WY8fXd0ZUKc2ckSvjtDrlx6fGcIN+VKlbiKhuM1rAnJUo1XJ6Qm2QuI7hx1dx4LWcO0dTLibkH I3wFJ3/NnLBiYrzch9ar/edddIZ2XYra2/ZgIKM3fchiqOvqVNeMkoEH19cvmetQMWLwKU9VYFRZ WnCVq+D7SVrfdkzeFa4WFz5v7lyDvPAHzc83tXrMOlEgfdd+fmWzws6quXOZX7mtb2dIpZb6cVU0 C/Hk1Ngm+k143bVJN++J7cUSgSiveV5NdTuaz3Mv7XCo9zo14X2Ilv6NO5875j7cLO11SbJqdcVW p7nrVD6sf/OmrF/16Br/jgnvnAyMSi3mPMqiGPUFT2tZGB10rtXz8eQ1RbG1Z97qzrgRd0nJY26r 2TL12AqB98X6ed87K+P0WzyOxelH9c80dz5+6XL/elGngUsnvRYXLDnY8ny/Wrf3nnfi0nWacibe 6WcGOr/X2TvcM72larzck+vJ21rq5Uk82Zb9NAaX6pHp8bF31uf0lLUFut82tY2KlJKm9bJbHHpb 1m6bl73ZTVgxtrKp4ZLtcVPr28q2/AYz3dRSlRaIHWmZcja0oqTsTl/1D7m1ZdaHZn3qem9+ftKH +SJv3yXP4tjDf1X8eerAoQe3VGwvq3UU6jy1swzbJv78s2aZ4suD2ZtQL2kJmm+nfnCn/4IqHbal Z592yfgKHTzUIJ9+oFbUYL9py6nSbOf+bGtHv/dMl1vL5p0QCokfLtO+qlNoPsNPsvFerlWTgPks N6Ek9rUXCwIfJAsHytgsbWxmz1kgpf4q+H1NWWvyEI/rHLeJbBwWqwQPJT32+RRwfQpPpuKRdcd0 dJOzAku0rNljlk3lFFs7lV1sXV0gz1uRnXm3FmulqzvnZj/8cjDbMbGkZG4FB5fsp5fHBMSNBvV1 wodP63qui+96Il/XmGER7hAvdycmqsc4oXuCqP1QXVW/g27OccmK1tCkfsfNT6OmzJ6/3ib5VlvU EZWHU/o/C3x58YF9RO3p6ttUJza5WF03D0XJmqehezuUFqicNej6Vnd8Hbugqnet1uxTfbHO9z3s nGPkI+Vi6eYvQhLuPdx8vuhy/e3V7W6LAzo/NsQtFW467XJcPexKF918C98lAdXDlYuiW4TvdRcH q3UPDzz7nHVjtH+KgF37jP2THJ4Ff7ySXaWtemS13bCQfGB3+8SdedsWmaQ//baqibFX2m1W7pP0 E3v57+YU1bxJXWHLtd3IdF6u00Mtnk/VAs58605Kv66VUIyKT77+2sW2d7nOvRUh/PncKtHGH89d dxP3rHeIetan0K9SeNYnvvvW0nJfUbayBatucMRzqlUu4Ip3LRN9bGQ7YHAye45K9zvdkwvNTVSm N47kVtV+utJt0jTHXLJrlvmCLqPo6V0KVi839QuFCiga9dE6THyN0+/V65nK7RJQDBhxNqXZ1r3j uyS0L+F7VPou7SxxT13H7YvdBRWDdh7iueh5misiSGiti1331p3aufcEltjxPdptG+qSPtzWQUqm Rr0NHeSdtyxJcv0sSdNZ8WGi+++kypunsnuafF20ks1uRlvkJc76s/P0Yw1ajCZcaYq+eP7WpK9S rYZxNmH3K6UFdeU3WkTsjk5qr5uSF9tqWJG78vlWh5Q589fyFOSnbZ6vn5HDWS+x9mWx4NE+L/VD zROd3by1E9WJe/fKlU/vHc2v+z6ovO+hvf/JbsE59bwJff1+nq2dy/aki5jbq6+9ZzyDp8AqeY6r 4vOtMvF25stbXGSy+MTmnFfsSz2jeUv6e9OqOBtaVo7r+8npF9i391S6qSRYJS80mpF02cklPuji 9FTaLpMBg7WC2qE+fKY6lm923Hv96fuU8zsGrb1V3u8tCCufV2Z1W6bszktj2x3s/Ir7O8oaBl95 5XitMLR1/zTbVq/Wqun5bl3TXWoy6aIMzs+VzrZCUuxFKY5c8zf2cqhekgv0S1bkbEno52q5HMY+ tEGQqyVR+ppbQCrv2QyTl2Vy9ZplxqmNZRGXRWzXNgXP5LoycI/9skngA8PPgUmps8o27JaaOXC5 u8zxcm/gAzv9+mafnIdvxIurHFNSZ8pmik7u328bG/hgo/6JTGWrJtXOWY9lIqe7hfmaNBXNM2xS C9cr1PEpe1zPYbv2e+LLK55vt113C+fkj7iV82pLmhEtxz/enHNoY55wf2CnpLQJj0D+2lDBfH09 Aa+VD/i9VpQs7Dp4f5JxoiKXx4nZ6WphHFy3jGwv7t98Xor9VLXH0hWHdt2M9V1426DzCmXK1QVi QUJlVlqqttviE7L5lB46LA7J35A7rfWl96IPbqq2Tkk3lhU6n98xme9Y3iSFK18565eZ+hUamWqm zuiynXfyRt6lGe+3LVGZlz5bPPdL4dXVTdOap7nNTDJTyUrmjFmWxb4nfJJMSQ/3hH7Fr0KKR5o5 1ya1lwkZWNoGr6oZsUud2+i581DGBddXmmnvsr81bBk0NpXym+cmbnjW7/6Qw6cpVqWb8k9aTcg/ +SpUUTf96Zdr2VM6Z0of6ZHtWnebesjhdOnl66RQQzwgrlb2Xb7bxPwDGvz5YY8POfSdr3BI+179 9orRF2/bqvcutlXvOGxd6if51s/wbL3ArIheY6uisz47u2A1x55gdeu9p3hX88Ys2xMY+krJ4+kq c0m3CZUFVYMeW7eb8a2Z1BhuJdAYPcjluk6foyhGhSNN5zjn628TjY9FsxeFbE9St3AauZqSJL8o laMlLLXM+N6aSe8sLf3bzC7EmxWote0/ZBHc4LHJdUbvRGv7qIdFDdeLPTaVTywKGUib/527MMLR Xj0u8eo7ns2ffbz4Z73iWrNsAc9txaAKk3qmqs8NL8Mle9fW3k3wUlqRseOg+fQ4iTvKW8KCv0wI MjsjSFkasUb6gPR0adtGzZRtWvEnG6YMmPFJPt5yQNF47Uqz4xdiGkRL0vPfOakHKaWpT0oPi7TZ Vbbxg2x1nsprWtp8Y4vnn6K+Crvl+dplNXAdyZh9ctvXW3zGSzddtbNtCfAZkOUO7+4waJAItGn1 2VhQ+Xnr5hllXXNT7PV1rqmL7er2kQ42OO4982sXd8RX6afSFpG9N7v7NSJo0j6bRlQjEqQrv4/0 mvUZtCywUa7cZbVMpvVe/aurRil+bArdrim21h1O8wofSKU6nk0gRTOMsuefdv/M25yqvdT01plt gY+8jXc1P7hSkXrLJ4XhV37lxNKazVHlfZOqrkrLShtIPzAV3R5lYXbfTOH9jIZEe4E1RaY7TeVM H0eWaCq840ld9/q7wOKgrW8NXY1aoxiPSH+V/5Snfse++fIMv2dyv4j1lxa0m7bn7bSwr0oaNO5L hiIrZn+SFq9cFPa14x374TpvkeWjy9TEyz/nxjlM1X5s9SP06re2b+fOLFM1vWH39M6pqiuBDvIt Gh07n0rHfSqJ2yket93yg6lGu++T7cOTpeebaWw24z2+b6T1qrXKk1faj3aGnFLLn7JNTNFysYb8 sV0SQzeqHD3odx8uQ5BVvmVf+2b39jzhHLN0fQ/da+nHa8+/ENmR4X7hqq9rGL+JayB/fN7NgQ0L qDPnH5ztmGu8vDF41TuFmacSdHZOFA3KmyUh2M9eebJRgt9VtZzTtcbg7RbxRbrptZEzu2TD5DP0 +F1NpPkbxSeXnb9pUua7g16YvpAz8OvrVWfOoQoSWjl1c4b/+dcbjM3C1pkZKIdtUoyVrGpw3JF+ vTF8yskFVYuafWsPbr3bv7260C2ulldEpsb5SLV85vY3hV2ilVlplh1zvBS0GrQCnJdvDPzxIKxc KGOearprSei6uyIbO0SemJ8P0ea5L2Ss6TVVQsYwveG9pUelbsKDRY1nuYOXdHHcVhHr33/5+kmf rUa2Cpfjs6M9rdRkz+TOPty3eu3VmtVnLVYMti5OeDD7eZtJYOD2hzvybEQlG2Ncpr032rHfeeTc vk0Z55zPq19YYHIz6m7DOg+NnXmG58I3dc/skBrg1b+z46mJdotj7qYEd9lm4Xi2T51Lqt/QMnz6 7vRabNumOPlyvneJn6ZDWm+D1K5T+k9nb8xUedjR9brTNSJWusi0f1Fb5ZW4qilvrvh0nlFJ7Guw 3WUu/tbju9muA/qbte5PrUidl5mmMsdAzzT6quermpLtehUvU30nam2ZtCDN7FpKayVbnlCHkSLn d2mjlP6cKW9r2KS13CQ1phsnrt27Zd4GhcumDQlTvz+jP9NXnPF95dPoeRcljZY7aThprFNA2zCg tZ7oG9qr3XY6ZPpwRYBSXIWBQM2aJRFW0n7fPabUvGTPP/5q5+pN/jPaBqTa4qq/Vi8Xfni1trjG uWYoVFGtmc/j4bY7snunZmjZW/H3XOBh79gVL/X2gmiWOOXLrPt1xqbFqvPKF0wp9997QNM0MGFV xWrdFRqvdjD0X0kXXl2Zo1b2OCRpbpX4nGUiLQE7RClKgX17+V6KHH9jK3FZU22Sj1Ja/+vc5uDT W4TDLosrVUtGJO/MsXa/oxEe8Hwel2qD75tUvk/XzY/q+xySb9icbmCfvSb0pk7qUo2N6mbxpuYf O5g5GxS0GHtubTE6WxVol8F5pzKVs83kQIXj95P6ryuktaTP1qucf70rdX1Gx9PWmx7nKz73fopp K+L1r8lbVZ3NV9jM0b/SRPXhyLsI1dvn26+s6Fc5a/nWqzA90k//SkLqnKKeST1RVWs2Sto+MVK1 ffJUPq9xcuENJVuTjcXZazt5bIUbuG07fM5Zep33M3WNspN5Y/ZY5rlTrlqOlU1v49e5xz7Pnxfp uXTLqR6dSFPxH6udZvbvNZlf4//eXPORkSnPO/6NMl8EPgx3vfbVC5tVIlUZlHfknklJSKMOgln9 neopXZnXK7lexerwDesd8ulRC5N44ivZPzH6tNWsmGP5jEGxE26H3l+V+CLitiLbtJR6qPum4OR7 25Tvb8qPS1iXdXFPha+I2CHxii22s09SYy8nc6gGCB+KXV5ce3h5x1BloE+8iWtsyFeJ29Ersri8 g74KVF614rkv1i2VI/FGLdlin3FuiZJ77t5Pn6aEbT/rsONcUfPsb9rpLo9kr56QbGvYcLFUdU+g ZLODfbZ27sp3px32PaQtCH6Z/uKKzsrPXYO5jbr32QzcDdem1B5U9rgbvZdmbHejdqjWuUJ7vlzz rNqD/nf8XZLqnmqNru3sePpWu025LV0tLTaBN2WQ/YjOvJf7+1YNx/kVDGZ1bGx3lRWXufzO777A sH5Hs8z5YL95YVMvxHVGpHVZOoWbd7gLHd3ivVpEI77NRqFcpmP3h69HhkqH+1o3qIj5ZvK8LWqK CakwLEh+uOjIxg8Ldm3Xfh/t70L/4V/HXr69V/1x0J7ek5HWIpTSuJAPvb3Lj2/4cGvx1hKdSde+ SkQZa6vvLjnjO+EAbVXfGqEZxTsvhPhmi4kbiKq/K2v9HGbSmRBsYh6+mq9517Hymxs6l3MWtEra X/8qsXpugsTMsxv48qcJGN2VVMy/KXnRoT5gwl6Teer7w/d7WR2jFJ9ar60ucmCLscsXm6C8CXtK 5DgMi69kh8xQFuyNWMP3uFv+2pvw2FUD96PkogNO381Zm8C8119ypiN8wpr++yUbFT0eRQqFr+Er VJ216tN9A8+BNasnP7hlVK6cVBtQuM5CtCu8KCXTpDmidkpu4tDaJObcZ6/sra4Hbyje4KVu2j9V /ea+2oC4/FP+XswzS623FayalW2S13H+en9cb9raBJPR0X6n79uHvLc7Pli8Ley71dDCp+erPTlu NI94NBpYPQ8bdBuK+dgz54HKi6vdo9FeO4f8vH+0mA1fHz69N3/4VtdS17lVTi37mEn2M4ZOZOWX RtY4VUS2X+0eOBdxPNLwSm/ePq550zm++uUPT3w2wj5VYnR7/yj7Z/HAhfmlYgWlMXwF+yYVtHk/ yVqg0TYi9WxESqNlZOZDdcuPo8+X/tgTW5qRV1gpZM3Pzz+aUDm474F3rcb34ZW05vmlcSmzSkf7 ilfH54nmGqYv74s5vix1hYUW14VNORHJU2xHzsiYKzfPMV5/KXtS+ndB4xBPW5OclaYT2zmKQq6H bQvrn6Uxt1PD86S/5XLVuieKZZmvp9tecCz78V7CVjDlclTwnbJUA0lb23i2De4JgR7KbVNka57W d9/mkA4fyH04Xc90utAxLwpXxaBke4z3rTEtzUvbBI1rncMRwwb13oey22MkFSWi+m6YTmq8P2S3 8JWmLYfpAjelLzGfb2cva5qWyC521Kzs/K2YdvFbc+O/Vnyw6w7YUXa+TMS2RHZD02mR6V2ruQUa xYYD1QOt2lvPt4eWL41J3nVlrwej0z6xuGW98GBsVLTIjHQVBkcR26DeYOo7GembxZYTbVoz2ZeZ 5Bhr77ENr33o7F5hzjZYoG70SDd3mZrz+caVpgqLJ3UbL17cXbeNETjjmc6TK2HsZzVWXjz/ZX7z F5Xm4uOTZHpTdqefPJw3QSiQt0wlusBcQuHqY4a6n6en+eQsN/tiOVHNwF1Co8WyHw6MlI0E+T86 2calIvau7QD3m9gTVa8+RmbvM/ZozzEwMhApbfOTz13PqVCRsSNqDlVRMWdYc8et8KBQkQOcoots 1uqk39zoajYvM4An+OiK5mnH7trd5JmeckHzskxgvcrBky8OBs2ftlXrFdX4pG9rrAefw+OLXIb2 q7deGxiIUO7YMxDr3fZBfcCqJ27ruesHXCtEqi3WXtt3qXPutTNPF29eFBP2ZUFq/6QQ+6kR90qG 5Z5s+JpWpviC13F6p1mOmYL2orQ72zMbXkSM5qj0lJp2ngvWbzri8XH6nkhGzOkzh30dnV65OzqV PZylxvUhMjZUofph5TxH4Rc+jpPlrnbbqbVo7SqU8LrkoNh+S/t65SxHtqjnh5lRzxfk1Ubesqi0 V+mSb7izv+hae2ucV1jb8CRhibKNjscf+1saFu38UaYhvYw2pMAcinpQZuV43HbJVZ2Pc68yP1Gu Tm562EVxm2gsqeJu07/IykmovKpaojK4+vzNnY6fc3KrOl06LizYf7zjwkNta0eHd95URZrwlmPv qqnXjj5dmXldsozb0f56e/uVpuHDtx3VeG8Rx4DauKeCSsefLsvptUuUrbo5uXpweqCZ9UzvTmtx 1V7zrjfcEt49vTpqO1vD3BW5JvfK7WEqVHeur3CTb82eXG1amb6hlU3xftFNX7Wqrl3SjvnarWzG VWI3uebY509a7li1/n6Xsq5DvsjpKJmDD05ZkRjlYYE7sjHBBtWOkk9yBur1wkJ1lqjk61tK9i4O MN9s+bl5HWk6smKxi1jC6BsNi5ClkeGv9ud/eufkvqt59ue6gfs/vqg3a1983qw9PebypluTt10e nNxlky9g61g1y6JnVr3cHjYFuT1+kle/7g42E7SyNw7Ns/zS0yzjE2B9dLQtW+XyoMXeu12qe2+5 Lb3h2M/vxChUXt+f+uOgZjVv/Mmn27Z/mzfK4Hvi38G9YkDVgPPq7VUOjUevRg2zTb0qucrJiz65 euRWUnXYq52OeiLV6Ryah3iEvdKyc8r6DukJCNl4CdS9XeJ4t7dZ6SOfY7AfV9RwKOcn+7lXtdNt vETSosTLzCvnCdj1z1dUNr6n4sicc2fXg9Y84SSrltOXfN2Pcy0a4j4d6XeI6qjqEHtlwEHwarfI vS5LbgfjGutJz7mPpUW5V4RX59/MTDDkGsrYLr/gRPjhh/bGAfLF/d+3p3adnTk06/73sL6CKzJK M/JKv681j02P/8LLu4jLfurVgY8yV/l2P0/aWEKbOqpfem1W3k4tsWyTnheMnssSseX+s5xjVFss W549Nfwyq3rD17xTMSrnzTiz1BuPhPkFRTUGv/3QwXDsKb78cGPX5nae/r7WdO2oU1pfpes0rNrs 87XltPzdOm39Z6kkbG7ObS9tlrUuVIhp8Qno7HXfE5c98ub0MK3o+qzgTrNLfsVLZztZ69tb64fz z/kkrN8vLNAe/m2h4emS5zy9l2aYyV9f2bxt6Pr5i6kPz+imOkV7qbnryyn2r396gGpd/tAtvMel KHZ2UOKD0pyZK59724eLsx03ilON6ObvL8m2Dhyenr46st+0sc7erFfE23hFddGMi+IS2kP2oxFN VaphPZE75jVuq+y9LJDhsD6XOyhiea3cHHOGVtUF58kCMgHxrJ75y6vesYvxyXgrp21MdTKa7Ty5 ytxHlV/GO1U9zMHquMNc2a/O+mqFx+1OWmgb+J1xqfx8vseh533rPO81/jet5TJSdsdvM7W697zz PK/Whb29HpsvWzhu8Lvk4q1Nv3/vwd17Xy0tumos6perep8K3cphoL65OfZi59H4ubNGym7S217E 3/MJpBjpNfYvapnUsEvLkMrmU5EUt2tRY1sab5TcqU5JPdXzEjPF5u+57JbwJftV/Kn4T1qnOVsE e48/Nc98XLx1bpLvZZfKukbDkIzkyxdHLo+svqFrneht2h3XdeHBtpMlW81WfJ116bmPopPW0+LM AMXehNnBFmUb+WKQ0etkFQeOhVhy6h4XCi51c9yhc/5c4xHLh+vlt+6oXFh0TrdOo/XIuzmicZ/s vLbmb9nenPVdpIbk3fwQsTl1dkx+3hK51uHUuRUp2avfHA3x3rYjOu2x7BD/xpnRM9cvjX7BJ7Ap czB1ScsjD3Pz40oGDpPj1iWPyOsn7e5IMSy5Wm/WKtdwfIaPUHhaypv192YpHs5/vnroTd0Nb98O wyGXV1wue5S7TZYPmTza8dbzxwqVmjrPG9/bix9kvV0++OCd09Yv0ZOPGdQ88/GMuPt5F2+s/IaY pK4h17Vul65ctd+00M192jYZQ8nI8MublL1yLSuMTa8XHjMLvC+geDNzZVqXSl6mn8zSr/wtj9LC LA+Y9yVG702ZwTZ/9b0JTyVmOGgmbj+anjqzIm3V9y2F1Lwvo8ZbnkzMSu62bV6oO3Tk/bVF4tb6 HZcTPrsrdIQqNLvofTc3uGG+MXNSuIXddAONmfePrPy+xuDGBvR5+yEwUOt79pypQm8LjvblzV5/ Q2Fqi8aI2qU1U9+GLeU3KrQKW+7Lcdjg3pOq9fEm8bpZy6/z2gZmBn8ymdYi9upzu4R+6eMQ69Vb SloDuweZXU+OvFQyHzrX43vidHrl+qieL48E6U+UQ5vaf/yI+yYyvFj55HFFld5b5td8+N8XTtnz IuJd3qHXLq6fqx+ffdS0JWy3hdruWpebyw2fdU0vKL+vH1bAbHvdbSyf3vLq1qYSMVXdpyHXL5Wb d09vldgb4jD4zeni1obTR5/3bPFvOUdL3bekYHdKj2y36bBaX+PwwtgHYoO9nP98Qc1LolHkf+WC Gu1vF9RYSfzzBTXqzwtq1pysaW2ktPaM3JS9e3OiwIWS4nNvR4kq5/gFtVWWrLmNX1CTR7//HrN9 7r+XSRUJe2C2J0LXkuwodUJh3ck2svtciTnPesEnghodzyp764hgkM3Kg4fkRN+27ct9dXpyeGo4 PUEqdsLM+ylqVce17d0qN6ieVpKdLD+S9FpEIeN1SMVlFfGTnudW6c5+YZ0iZaftTptudElElpES 7l/U283wmSbQOOCY2XGu95zHgL9Tb8ke75Nz96/KOzTpzcbH/hrOXrK5yzekS7VM0Ox+lTCkqqIy 57DbozuL3m8w/WIq9KCD2X3j2qu74pWLeeWMtdbLqCZqTpmUIjdTN6lqe7iU7JYz5akTnROUtLU+ bRe8b3v/4YH7Z1XL7+S5vdZvOjv/6cNKpTNVykF8n+fkTtzwMOGNSPLqWclVs89NNx/NnLjoun/m xKNzLTcta+5ecm3OEuHG64fsQvLSXTQvDMfwpN8un1FxUzv4gEN00wr++XI5bZFNEvzzl+To63Wl HnvuYS9frn89m3vjw6SkBP8FMjxGnhXqMpLPI431zgq9a1yRFMrTJSrWZMY/dPVYyTa7GL30+nKh mCZpfjFXO4NrAQukzxwpUlAVk+R5M/X6672mzyJ5BpoeiT7f6773afm66Kbp/C1b7MT0pGvKhSKb dvMHy8sWHcu7esDSyX5jx7PIhY7nZAfXFAiV7dtRGXpziqdts7SnC/9z85RqxZy9/Bb2dr2RTRr8 Q4/KH0Y1leqmPy8vK7/56o3+HfZykbWixgfXxsyY/TRSOS5aPj8i9Pq2HyHXt+1xVm+7Y/7OPdzT 6tMd0X0rrF9rnLm7qy+zVWi5dWILX1bZ1Ex+7u9Tr7dOTLdOeixiUf0l/uCz8C8WDpsaBIXTexdo Twku35w1f8E9a63ATKWpJdb7vLotD/ieyUlVUI440nme1CV8zfj6/QxfHVX0gbKbqfzcGOHoRm7f jNPbhLo7hFW1jL2Dqi9GrGvUFZXieipiqW/0tVvTKMtDMHZShtay44+6e9I6hx6VdG4zonoybnx5 1pl0fdb3D84png7Th21sE9gza2MUB+c97zkW+OF8Wxd7fVZffs7Fog6GlveNLaOmgxsuPHwc5+hQ E3w+MiJ6b7hUVNOPGU7H5Guu96lGt9/58c7puk8VF+fnuZHJBtu+fvxgqN65nisj/CKvedqHixL+ m9msix5Knriy1npB9UKzD9LmnyRmF9aSnW+yHi7cFG1huqJSuWGl/Fquz2s4zwVWeB6YbVbuW1D/ 7sEBs6S85+pdExqze/aenZ0Ypm8247y3T+ju1rcFFZ8XeFsW+b3cE8tfP7fWPGqTU8asFJ3P4k3N Crs3qwQ3tgvJJPly9JmWDL+UtXi6OVfPNXh3/uPojLNDjmx8+6qrig/aVd/kL9Y2kx21Cz8d/UXo YtwahZaitAUn2+fXGC05ct7ofNqCOKE92T1Vz+XXvdI5LjFrqve5Uv/7x41uXxZ0ipyvpLo3VL5C XPnugMPClnov3vXbsi1LwvIZvpRs4ZdV2tVTyh1nVN7K6Hphce6YR92UG+VP9wrp3y7dQYl7qeCc pbmP1uT1rX9G+zQ7vqteJQ8VboTmqIUp29erpF3YruXpxXHecl2YgIfU24g3N85ZnCsNSBjKm1GY 5XLFqm574T3NRIPDd8U5Tg7JrXIznUpJFc9z05b5YFClUt8nX98n/bCwYe/pNIO4qyl1Tt8KeHel 6QxHT2+xbXkzia/MauIM89LW9Ng9bXPmbGq8uVwiT0z6fN6HmnnVBhzz7l/KU7lnYP7B3SS332yf RX5Kpj6lyFdnlx9nOeXq4W3hK5/mttNNMozUG5PPd2ReNVPcdfVDV/iD510qsw1iD6jJSzhKWcpF /pgeZ3zwc3rA+Y28BaUfYo62aXoNuNZ+lR+cmmjSon1yy6RE2s7MTO8MT/1zP0a3rRuRONf61vKL svnAuR9Tb12eH7y2WDD5iOUJpufzGOktKVGvrj+lCu3YdLzgpuNdRcuBBcE7w5bEqdPsd+znrzWc EmejN7CAK7n8qmG6zcmFx97NDXty7NIeb8szVR3OxunBfB83S1fy9x1yLlxidu7Uzqg0jJWkcdPw wqYr9Ry1nr1Xbj5MmREuKH1wI6/v/Q05a+pK7r2SKda8MUuRy9g76pymvlEu/wb0pCZrLX695+Ey U+7TXl822y9dpTfACF4WG1jmMW+DzOyM7qs27j8O8t7d2SyjdSK6h0fKQOX0rY0HPIamCy5Q3ai2 Tvf15qToBTWpZnJmD8JFFPicBqW/G8u9DUqsclld5v/xDFuI/ppDPwxmvL0QIqjXe79pFnOnVNf3 mU4V0v7LD75he2qzfJbVya/vLusKLdviqz9w48PcHwbSr77c0Hw3R+54XcGG5QVvJAdFh3RKNh0u ZgzNf8HzcZ9WfKbB/kLdACMetsvHp823mcrMfOvt7eRvo5RtWPShKmf9hnmXDSUGMpaGiKUEiV4+ Ff1O6XmS5Jf992VTJQWqK+eGzJ97Lm2aq80T6ih1ZP7RIeqnvLtptZ+nLrW/NDP1knGwyNkdku4v pOa9LcqNnnri9LCPAtNj7pFPDN4Oubsy2QWUNo7RBeXdK38ovnF/yRhe2/Xa6ZzutitGIeKPVxkm Hnv8ZsGse7Q1E/atO2Wz7vSi8zNedu2vPhjL88Pnm7Bkj0+5k+TCtaJfsrKPx+3gfDDRVaS0Zl1z ZdW7aaUrdXZzGH2cocJjxjM046P5t4V95k1iB7YdLOXeETOhdKKP69e92xatS9qg0vlJ+MKIbOu8 oW/eO0/sk9H5pnD5xdedoldE+7Ve5H20fiOePUDa+EYp5d06PyTedE+QaRMLqXMuMr19Tag3aF/H wsthC2uXfqcqfPIZ5O0rzQ7fu1pjA99TehHb7vk/3I+6au3l6ov+gnlJ6BSk3Jp0p/dAbe8tt7hN 8Zo7D4Td8xmc0Gff1HCzpsya587UtVwfjb+1THgS9E3ojcL77602ahIhfAODgtkLQ7JW0S3DJxRO P/Al9Ntj8S++Ux9fon4q55leFLR/5fF5Et9EvvFPWML49OlucO3nklu7qVqGp2eF1BlR9Q2X2h4J apdWCPHYSC+lX5/SP+/Fum8mlz9lJ1Nr9rcduMZdrq/VuruxDxPNSPr0w6p0b3/gjlNB4Zu/Juqu t+0zFJS+anRis+aCA7Fcanwjm75ydwm84H8Rd+gax1H95a3y8W+X+t9R8pgVFuG5VuTI3Q2TD8p3 rfdZF/+2Q25N++p5bwSa6g7U7N9XmH7IkvuH0bcnkj1G5cKS25Kcv1vZnstdES8d1eC93ao0uG5f zBnONOsgS+VZ3DuvzatQrWMcM3I4YWGzjXaDf+T50ZZj39zvtswwv2EiMrt0rriQ7NY7d8VuvWBE bmJLUFlUxHl4yc3ciSEx00uPDJNrG7wcDLmfSvGdGCgZm8/OLP7XD018v7TNf7hduiW88eA3bleZ /Kob8tmfeGorhZdznUua9Z0tsCreSfDGK2nz8LTh4ekqkgVKcfHfY6xGe0MEe4cq63U1LmzYLdY0 sibQ44DvQeE5+84n7vWZmWjJ076nz37kSMibz6eqk8ttbwknl6be23Sx/dPU+imNX3ray5a1DVg2 DE59rqiTuYXtn6u7lLmz+N7Rtv5vu++1eey+V7roo7t6NKX0UIn74TGfvkwcJfk/73tdwnre9Wd1 NxP9/nvMw5P+vUxXsF5iWJ1p+Q7E9OQsspc1I1R3K0xqtolpCfgPzc8RS+MoWLVd5Ny0KUdpgakr y7Rkd6Sac25NXHluQucd1TCT5q7o5zvEbgdaKE8y2v7SjmP6jvuUHTkC0xNXKWul/GBbdVSTb/0O xsbP7RlPdimuWxtdYemits3LsXXAb1v7gzDBVTTnqm8elIjlGowIDoUrcp2fO73vCJjvSyvdJb/4 lQdb2WyLL+51FOcPTXdft2x/JhBiOKDhY7BRoaiVk97GWDIleX+64Zqj2w9o31uyJctpedSl856l OoPrbIfjL94avD9vStnxQXpe3Ymi8uLUF3a8PbcLfA/tP/hi4bks7Y17/OslTq1hD2ru9jrWvVRp ffPE8wzhnPMN3Neo7pGKm+desLzgpSTJqamk2Wsr+mXdYNAintTRldVXs0XvvJ4erqM2443Sumu8 pZ6zj2Sd1Tg66PnhYv+ThN0Z3Kof56rN7bMfXZ5Q751yd8O0WD79BiXG6i1zziYeHjgzc/GqkVr/ kyqbhz6JvpgiSnYmXqRfd6gRfCZIkQ+42brzeoWihW69srxMVce3h8/tHA3r1duEZBwtlBoznypV e7mIMA7crrnP9abX6JqjR2W006VgWnnVm4a05ks3OZZ7yE/1ueKziOm9vdXHzltNw9ft8IoPX05d Khsyp1R91WCUL7qjv/LbqEPdnZ0DUTb7koSzN+3TbnKXvtcZdkXniKTDkxNaZ7kFnmrI7Ckz7PH3 Prj+VfKzAGZAiv5ZS/uPCxxu827c6paerdZyUy3HzaNqSYHZ+oGtTO59i/Z07Q+XHdr7RCC/I5rX QjhS6dK2nJb819mH3zPPnUq/Yix99VxKzMGnyyMtS75sPl8zb75YSJFRTefs3nS5Yx0X3rxYdrtD oWfoSo2XXqkgb7hLd4OpzzDDYu/nvleuWlXmu+23Hphusrnho/pLI/UjCjSJCQHR1R/22565di9o upfXeYeqJLe7s4Otm7omvVrAv5VLUe1Ogdgu+eylETNO+K586uV6vlQv2oA3zXfrtB+ORucnOuZ1 fl+5brfszs/lrxMuHWOeUFs6sz86cb15MmfpnOmCztOD1XJS9k8xeihXV0l7wKHGWTqUH7K0tMKv 72m81RP+kN7FU4q2cCXPChw4qDwhLHDhI48f5Y/thhR2tW9aHXs3XDLygHc2d014fU7/R4vV31aO yJ+ZrSJtuynzQtusSCnV85LJLmvizAwHD116Ej7523JlPcNB2ehX8/plO3hr626cmr3H9NLsgVDr AJMXT+xvnOoLFRP2s248n5tw6uhIuiJt6axJw3tEdk0e3pOi15zwTDPuYtBcSQ5B4VCXYtcHNrGz 93yTUGkTn6/54dyBW/Kf2W9slHo/7HGiyOHVEqe6l9UveyJSam5N3a4zeaXawoAdKzbsEJ56MHVg x0LBzIi1gWnBL60vLBthbjm+WdjrK2+m9eyTX1tuf/1g47esf473y4GUV67qHIJt75i7Z3falOj0 zzEqDrzmzW+QE9yVFGS5cVq3Qeo3yw83j5hPmrd1C3P3wt7xkfZe8Lpw6miQ0eaFRunxVJfjGypm r2Fuk1mdYnqQVpzsmd0qqZo5Y/PowqsrhZc7cPzzntZWknWnrv7/tjt1G9hZe9qy5u1miycJ50z2 TNYIWtlTOkpy2Mf3tBfdWXMb39NeRr//HvPFzH8vUyd9/E7dZWUmY3fqerNmx9rTNvPpGj0RZ378 rDrQtyzHqDzUS+jIPldLhZGn53JWMI6yO3A9ZrSE8+aw7dWS2Dd1R8aV1RaaZ5ouJWy+Gf946ZU8 zeaG0Ds2OTx2rp7yed31D69vdDJeI2oSc7hwa9eentf+bOaGGQv5qt8++6xc+vnh9+dDPUUdgxMU tOemecaviLpQrS+Sv6q7J7Qu7r2VmGznpGrbH7qGiv41gm/PmOfyz/e1sVkWaN/LRY/2UxCZ/dC1 JtuuwW7Xyu684ylPum93pvitH25ozXrYlJXi4ZWmsm2JrUXIcItNjnOwtu5MO/V39glZGVsNJQTT ZhgtHtGyq6Fx5C62LRXs5zTvT3g7zZxX9TWb48wAD77qVWnL1tmGRV0vVDZb50N5yb9+RCduylEv O5WovXbXl2wr2VD0zH7CUVX5Ra0u/htuqDyUCIl5UV3pp17r22y5NCuleqHxjWWbIuX9D9HDRk27 H5q9nhO98/yzN7khtsFRAZP3bDE9c/9u1n3rqQWLehaMNjPXBn0u1shbWTJd02mRgrTvoi3LN/n4 u5wvUMtcnLUz1tfMb4am0wuJYy+dnqjHLVHpqFuZ3/k5/6ndoxa3jGb1stvHv5xtU5dod7Dad0pR /YHV4n6p2kuP2msjHhk/vuLs6vLBRczFwpkn1zL3rPOQ8xGX3kcPazUuDR8Xmp75fGamXoJMokyC w6MrLmy5G5oXuli46OV2OO9xyaod0VVdPiTczR/dmBlal/l8RYyWhe7QRJnT/YbNmrlrmu1zu3PF c9seWyWVLN8T07/EfGq3fHTlTveDb82nuPO6z3VX7t7aXOOs0cwwl+me2yyf21an4qKeO+A8igOZ ZXxonmXM5iLFAMXjEcssVhcdyY8wXteyKi1B4ZFXnVW8+AXxS7HxsQmxU5+5TnkWkxh3Yfhge/Lb up6E56vXJspceL4m+OLzZUNZ17wMNqmuVV29J7hRyzVZXX9PdH5oP3tGSISOhd7apIq69seX6uwO d/ktahKVnO287bFVQvdFdZ20ZPckdd35SRkXHeqMH0XUbk3WS9BL1Ho0KPNEI3/TkGq3uPkS96nd bM0Lmk/nyuTOa/Y155UJjlhpsSJGL2ZF0UnHOo2GzK9bnqyrDavlfTSyskVviCcjzFhzfnJGwnPN IQ6ZA/1+zdzN3s72LkFeyzepLsws0VFd8SFx+EA/d/eTXHNzhQc6e054LZGJzT+jGCekM6T4QHNo xfXG5E1D+/sVu/Wa03LVkbe+yOMjLny1jY/kXOY7B7sU1G29qJd4fX5UDHOgeldP8wxzte7K3Ibc FeaT3eXdxTKi+tW6j+cuaLZ2nu0y9fGCx9LdzTybTlY83po0fCJilYVW0XHjlZ/rJJLVl7ccU/fO eDdyzbXi48Q0j5onmfNKtzSorI0ycj1z38B9Z6mvscT6BxsSRcuzOpNE3wrVf3jRUmuVrLK+96B3 Qglzx/OjvStKeWWHj2TtXFhTZem673NDcbfadF0e/vCjOcV7kz5UKem0ZV35QptnKXxZoNvkXuG/ E+FcP3Br/qMenU1sr/zemVzQG12/+dyhnIOnZXu4rg1e+SKw+snVmVo1ZzeXCDhM6rz8cXFu8hpK p8Zutubho2nLivmGOav9Zs2cPFvy9eRJISFTT84pWV22K5T7rvH1mV8fL1Rd36M9rLVbrNn6zD3f At0nqpvzM88q7w6KDP32/t0Ss5iRi3d3X49Odw04teOYYFJV+nZLB55VebtWb8nw9+F04O9UfSnj 3Oai16jX6Jle42Sfp6FjkpC+ooR76+CRGa8FNhff41x3RznSR0hulY7U3LtzJkclTbvtuTk6MMRj vdCFngCTC8+PX+MsH3qUtWxsVmytDQ3L7zW5drybobr2bPN734DYeNeuzWoZie9868VePnDelsv1 a3Yc0edXXTw5eYZ9qfi5kKtJdx/eXON33S2bP/FO2FmVM19TlpTF1LY6d8RbsS/U3sPxKmii9VH/ 63asZQvfErqRbdbrSWk699PXpfcMvFLZWrnr2eEP18SffLLaVBn7+GB/bKNsvf5N/YRh7lfrJEfo g+L8dUsFJidftu9zXt/aMJTu9j5X7s0u1+vFDrPu7phvtS7hx+zOko8auQPm11OEy4JrrQ5esysX jrfOjMSqKXF1fFu/Xi7spOJ1s/Phcx9LX02k1FC+7p7nfGJmveFLF2f9cN76ohfPnXuXb1ryquhR lqYua0MfU3hS/aFQlScuSaJWcyP9flSEsaORS6Ptgf4X6duzvNyuthYVl3F0Nzm+NQrOq3wX8vxw R5P/5Fj7VsU3llOacx7wh1mLGyTI5l9fGlXU7xzi3jMi0/iuuOZBc3W6ko5Tl3/HAmVR+6WhRQPT XbtTMDjm7JOlF8WLKu7XG+3Osnbpuvg1Tez9llLl4LJCjY/75hgUPtopczxibdHZ/CCv2TKhEbpF Af205hnNm5p1m71dcnJFmnc3i5gr6TnHuT5ZsOXJiN7QUa8Ir+h+jW7LZoPm6c3LzYUzAvrlMmL7 Vc25MqIaVw0Juot172hOyNVbvDTjkLHu/MS3j3uSMi5lxCfVnnI5lqvqHOzs4dKW8CCx4rGdc1t8 aHJg3SHFaZl+C9TO5h53nvr44ePW5JK1qutU16iu+hDfnbzrUbPm4NNFtd/d2E38O4YOrvj0QXh9 /8VNl/jeqTxPtcjave/bYA3XgMU3CY46hWY3P1OFGBm3cvnerxmhD05GibYbrH47S+u7RqjHki8N mVvDro145jvkayinPhB6pqyt5JFrdPiJSeLX5MFmp2uVqbVWLW5WJZVyFjxOIt9aQlsP5DxUfb12 32vZruJ9V7nVtpw7vTzxfvX8rC/Gvmv37uBq0Pa7X9ivq5gm2tFySeRT54P7bgqSYbuynQqJvHu7 a6HJKafycIEdD0w20J3kH14/5eZwXqyjSmXXMzmLH4KZ7ewOypKjUzu4vA+F/eExzvf89lzvaD7/ 267ejNBY0x7KZg+Pb5ZsXd5eLJCqOEdplDTTfr75wps1t/FK1mP0++8xX3H9e5nKkWg4Joq0lyUf NaaQCz8f46yIWOt8xkSgcnRAV3u2lIZzrfnFU+WcFafW80itmLCavlq4WSu/cNG0xXmiunXflh2d MS9gAWNmbSe3+YRbr+bzTKp9KrLiY8uccOMJKycmHj3YpMWV8epbzND3UCmpxjuL/bd3PPN4OKrW 63ouKKlp6o7lrmdGI1PL480u77pOoSXsO+Ejax0Y9C3Ds6/+nE/61U0Lku9Vn6dW13yldhT36ttP Tbv7vFHHy+JzV8S87sNbulI73Zat7aYmBPtMMptdyLso5ma+XV1qad7q4/UX2xouF63pDCsUEY7k m1YU1MOItGjdF3lgz0nXyANz06f3OHx/Fi9qd16DoUEbLO95u0ZdSlA5JWWbq9mQ+y3DQzEvX68y axNwMq7N/VrUv0ssV7Zc0GdvWaDfOTuDBdpL+nLvP+iPfnVQqs9SYnS9taKfUf7mWuG196NvbGu9 lunn4driG5tUeHfAef6kqbZa8Qopfa6LDGW8VrSZmmd4LRPPt47NN1ndkkF7xP1jx5vZtaP0nsSv N61X+k8ennZt/gtmTlHIsNaPL7v3GZw90r9YY3NcSN5sjrbTkREm7gnMbkUJddOMNRm1agquYeZf DjQv1msxSlV/JPBj+RuXL5O3uzSUPZHctrJ00rN5H+fnuJbfkFia19q28suFi1uChT64hurz3X8m +mDng3m7ZIKKFPe3hCdoX//XtDL7s7StOvqdJ1/z/ViVnXb7huhSrk2tbeVfbNI0PLIGbB7ve3fr kZp7ZODnnPZKXcqeGRca5xw+XBH5xTzJ3uxkwQOpUrGAsnUx75ocFsxJ/1h+h/fM2/yaG2cLaQ+H xe/sLg9rvfORa8dpBZPvn5WMgq/ppHXrNJgfLvh4VPTC/BdiJ7OyDT92nBi4sJTZc6ay9HtxRev6 fYHHVSz56rOOFCZWqmSVfrl6XjbomY9g0dp5O4YfkRHRvg/vsgKKGBofvQy+fNTae2L+p10OXBns 1g+tvW40n8yJHbnWa+nzbEcbY9DjaHJBhrxW6+q+Ni1x1RQn5q7u+Bszd126cOSF/N3jF5cyFtBG ThSIuRwvdhXnKZ5rf9leKE2jJayTf+jAvlXPB8/lnPDhuWLuqeDFuCHsM3VQY3vJi5rdRaMJYW9V Mvr2+Z3mTzDu3zk6uiZ5X53G83qrdc+2Pg9oPVKTddNv1+2p2v70YdvtzyWW9o3oF9tLmP0YmJh8 drd6efcs/6k+my8Ofwy4m3VhKv1J76fXZyudlxjGZ0vVPsg9I+j3vc3124Mz66t19vLOjbDVdWf+ 897okth1of+Va8n0v+2NWD3+eW9E+7k3es5g7Y3Kb36y3ep/qOvyG/NNQ0VO/aPkOmN8b3RmD2tu 43ujHPT77zHDJP69TE+Q6By4cHolOWqpRPaxXiTF2hs95Vt1xmnKzU8dPus+65oYb50no+J+stG8 UHSewgbpvjlrOuYkLLfyrbLwii68/Ex7TUCI9mSeDaJVzhcfT7s9zWK59u0Qu8mMuVyLG03dlzcy 0gSvD/j1tm4rfLzBVfzH7rih4n3nBwb27O3122s9lxqYLT154SEjXYHBSuvgaQ75B41y3wbNWuaq vnHD7qX+5tWNN5z3BO3LlQmvSdjrmpizsXnnufxzWz8JH18Z6Bzuq1vbbBjS2976aume+W2i+zSH BgdN7WUjSpp3aOa+pe0qWdjUdOm+Wk7KmxVnJfXPnInsePl8wUq6SJq+aMnqpHi5+0FBsWKBLUWx cTs2pX1xVDOOUp5nLdV7d7u93jTXL/bHGyJOjlDsrl+9NrN0e4DpDDuHC7b25XbeOWnXpE2kzwzv EUl1HNG/bBbpFu672KVb6nWR2cUDXz8K0z4Pl2zrMvwwY8vQgMLj4gztMP8ZDk/7QnhzlkVXci/a xBlzTUbq/pOQba9X5qrbV0wZeiVgsalrD8exAq1rXxofzHs85anYlA+xsvZvizsyH0cmb7xskXZC QuL7qne16qvC7xytdeqtSVnocf3rVWGFvuHlO9XnWe+b8SROO8o1dku4b2KKzorjKgqemTs3Sopv Pud3YdXD7+Unuz2dzh5buLF+zsM2fbEYKUm15hFfNdd0be+RW3e+M49pPYy3O9ti0HXfOzigj8fW KqnV+oCxskWIWnJUqoXX5Jcn5UN3CyrLrG83itr0zjP3/hSFvpCD0s/7mJJqcnePno056aOV4Sko tC91eI34mc8y+iNv8+7PqbrrkWq4a0uS1nGBjKTKUY+3e194bu5QaXyrXKG9a0NUlFTHGwGV4KBy 3l3+9NeJA0KpPfe4tF1PNRaGWFZk2hdkl2YfiYxbLGMaLRRUcqwksCT0wW0hm+Bsh6YjTTqmvBFH BO3j7K3trG2t7dts2mzb7HVyTjcdb2LrkvMSLAp73meWlSWYutVG3XR2Y1ierYypfOPRBvs8UwXj QCO7t6Zzjfe/tTMzlYo4nGS32pQqFKxlryg9hetWeuTNHo7O2SlTGwN22XWbijUeVLAPNVU3Djay NzKdZRwWbsdmuiAi0MHOxXRexKFZNjmmix1vl+VMqA76/tX1+ceMr/z/KzOs82X7ets3e126uPw+ /YwbximKcpcCMVw0uGJS9kxpwbW35XKkpYXn31yTszN9UlpZao55uoRreXSOUDqPa6VKjkQXozH4 +W36gGRaor+pkuPt+BxTacrasg05i6X5q8p25lDTBeZXzsuZly6aVtGZo50+2fVWc7ZXOv+HW1tt SoZ7nguXP/p8oiNuoudljvt76hcIXtQNLrfLVpKeuPZOl6lKvqiHzQI3fuPDRjYt2ZamPPlTXW+G 2VTm1DUpd01qDLS8vdXOO3soMjdSyPmivyld6FiFzQ7TGREhT3M83RTab25qkkrnTruZb1uULeq2 tHG/+K0w++Qcj6ZZ6befdH7MW5EXddnFKZvflN+LXXV/d4WXfUuOTCRzfpmizdMmUWmaRVCSzeec 603SbqKKk2MOsdkKdR1Y3K3v0jy1aWFTjSnTS0I1IPZmdLZmE8VtYb5YS5j7LTXTifmUqjuNNpOb NkizxRx/UOFoW5d9z9S0tFGrrXmRj5BqoPhtXvtdTRpufPn8LUHud9Zk73VTzxeyCMy4GWHDlbPb jVeRFhMUaPs6h6TrR/UXyHUr9os1hlreWmDnlGPYJNu1yPhI9+1+G9WcjCbHdHpVZaO9a45RE6cb R/6E4Mp2G/nsy6Yijq0ZM/ZmrBf8v50fXEWHn5f32AzI3otVXx+lSAm+OSNHRJp3bfkpWdWIsIw7 UyK5Wg6F2wo2KboJGwd0V4pmSzbt6FrsxVtUv81L3vaR05Ka6Plz7TNnho8Y3xpad3vo8K29O/lv pru+6Pu0ae2+h4rP48tVzC5q1V24WvDy3L2PQ7ynPyQ6PUreubCgd2tG7xlhOert3j0HC4cOau+7 5tfW0D65pq7gbdIb97PzZfqdwgaq3u1Jqvh8f7D14oPtXikmdd6Z2WtLerIubTtePzR1cOnt2pLK x21ftQePBGs9PG651Snswdt8df89gku9txb/2HXzk05L3ECJVrZp+4/qKKc9T/LLYk2EFpa+/V5Q EDZKfSkwI/cj7Z8Pto9nH2W+o+3///lgy/a3gy3rVZD/fLCl/zzY2oxV/RfnrvBatz8zdrpw1hFG 8mnTUaL2s+pPCWDNbfxguxj9/nvMS3z/XqajbOMvl7xbYUeWZUwi1H9V/WvWCtiKVJb2qsr3ZC5w YbO1FM1bFjAj4EKAhJD0IjV6c+sMY3HFHRa23pOKpXenRCxgk1CT8ZySpenZKfAqyfAb81DtXPag rXPdaoaqHxY+7En9EPbh5u3PxfK9xW0d8jVD9nS7/fnilMIdlE65u76JUyscNgmEagR5vT2+89ye Yv6PmbdWbp0efuvgo8s7Tvf4Dg9OeFkZt1tg+tsXX9a05p+X/PCVf73GPLXArT1JPXfvn7aIj4sr T9WvbzLoox0+/H7IsOnmnpIjLbLcx6PXeuQ7HH/BFVSYtWzjN53etUsb7itdiZ9ptvzuzuvVT3sM dASHfEUfniy9NPlaiEJX5/3HAsnXu0te7mP08pTEu3xUV4jIcske1YvO2Nww57h4/rDa3rcXwkyO bHvbevjrYKF5mu8V37tb1CfxSX0S9VDqrPIWDzD45M7u4NL+zOV+U+CiyVKzBW67T2QE3G+LWxik mcfntEyMe+iDnd3gRKtXmY28t2+pfb0pdjAv0/WUsVe0tEnDsmWSG3R8C5+mnyxR5u+mGl2/sDD2 ZL/K0xbJvDzDRzdmnhJZduWyl3vRp60fLEe+7bBSVzl8Ij5WZrV/0OsX913uCLhHzTWv9DSQ+rRc 0T5IokwgcftbgQd3Z34XqFzOuW3fiFmP4+EXI9wGMS/v9QfOiWunaS+V6Mjw8fCqqDatMr5TbN8e YdXUuEJxmB4Q7/WjrlYso7bIoGAJW5qI6/WgnMJ50eaTYvTwHxeDLDaqG1XIpF4IOq4qfPvCtfga m6h0P06LfauKyrm/J09ZohLcrB7watOQ0iTl+Q5S7R0exhq9dnwle0fVDp81XHzVSV7oQZBbs7/i QfcfKheatjImGp/yPFVk2pBamGD/+jS//euBYuvy4sclzSfNvll6fzybPjw4XLv2y8KXJ7yVe95I b5r93OTieoG5Q9TQjTOpgt6nXiW0PzLnDCi71CUYqEf3OuKas0ogRo47SOb94xvtJxbueLY6qKbs orwiN+fZKyYCCyamXDstoLr9Xe9s7qDp176UvsYoUxI/Xhnlq651ziP/59//0//WOVPIyE4K6dxN IXIBFFJ5mEKCQikkP4JCblykEJ4UCjmaQSEReRTyo4hCmLcpJO8RhbxuopA5rRTytp1CtvRgmm8U 4j9CIe9oVDKdk0rcJlCJrjCVvJlGJZ3SVPJKkUquraCSiWuopEaPSsLWUUn0eioR20gls42phHsz lVzZRiU5nlSyZj+VlB3DuKeo5MkZKuGJoRJHyIcd8VSilU4l9TlUsqoA3aVUsukWlUjdoZK1D6nE 9jHSrKcSvyYq0X9GJfavqWTjWyrJ6KGStE9Yrj4qofdTieEAlbTAsiEq+QwRP6jEapRKvNhoxJ6T RkS5aESRh0bO89PIfnEayZhLI75LaKREm0bu69PIlE00wraZRja5YpydNHLPl0a8AmgkM4RGtCNp pPUCjSxOoJHESzRSBC5pNPI2g0aUM2nkEDTDimwaWX+VRjgLaMTmOo14FNLIJZhbRCMcJfhvML5B I2Gw8haNOJXRyKIKTA81MOsOjbyspBGVKhrZ85BGHj+ikXe1NCL2mEYE6mmkCaoaaGR2I40cQQNu 3lOsxzMaWfMcywo/wLqNRra/ohG9dhrpgzsdNILjJnn1nkaed9JIQjeWG2b10MhReN+LfOmjEf0v yIN+Gkn5hmX8DkM0EgRnRjFPmIcDozYkAi8HuuEiXOGkEzs+Onk8iU5M+OkkApgCdGIuSCdbROhk hSid9InRSZUEnQRPpZOO6XQyZwad2EjRyes5dDJ3Lp1YQTwkz8P4cnRyFDrgkBLmp0onBep0oqRB Jz6wdCmdNK3AvLXoRFCHTpwhAfavppNja+hkgS6dbANxPQzTp5OrhnTCv5FOThjRyStwNKETA1M6 2W5OJ+VAt6ATv010EmJNJ/Ns6WSnHZ00wDR7zHsznRx3wPI40QmnM52sgXIXOpnoTifLt2K5ttEJ YzudrIWlO+kkDKS86eSzD9Z/P518OYI8OYNli0T3OTqJvoj1u0Qn7Nl00viITjLr6eTyEzqpbsay v6KTs+/o5E4vnaT3Ie1+TDdEJ6sJG1lMZyM/ONjIQV42UsvPRq6JsBEZCTYyWZKNrJmNYapshHsp G8lZyUYSV7GRmrVsxH0dG9m3kY1stGAjjTZshM2Rjci7YpztbITHi43Y7GEjvAfYiP9hNkILwfQn 2YhyOBtpiWYjEhfZyNJLbGRzKhvJyGQjorlspP4aG+EqZiO7b7KRibfZyKk7bKSqio18eMRGbjay kco2NmL9jo0k9LAR5y9shDrIRlRG2cgcOoP0MxnkIxeDcE1gkMf8DGIoyiDU2QxSvJBBZisxyC5N BtFYyyB3jBik2opBjtozSN8WjOfKIF5uDCK/lUFEtzFIETRtZ5BXOxhE2INBHsIrTwbh92KQRG8G EfdhkCW+DOK5h0Fi9jLIBz8GMfNnkPp9DCJ2gEFWHGRgn8ggI6AQyCALDmM5jjBIDQgcYxBKEIOo BDOIegiDFIQyyLkwBok6ziDZJxiEeYpBRE4zSPMFBglLZZCqQgaZV4l+9QzC9pRBfJ4jzbcMIv2e Qab0MIjyNwZR42CSGwJMsn0Kk6yYxSSpC5jETpZJpOWZxEmJSYSWYfhKJklexSR71zJJ/TomWWbA JGJGGN+YSQzMmETVgkk4rZgk3JZJcjYzSYczk8S5MInPVia5tY1JHD2ZxHA3k0zbwySm+5nk3EEm 6Q9kkolHmGRTMJPUhjLJkZNMMiWCSb5FMklbDJOYnGOSebFMMus8kzwHtgtMsh/4LzLJw3gmKUlm kgkpTGILF2DiZSYxhgfQn8okumlMkgE94JLOJEUgk8EkCzOZJBiqwTkL65fHJKXwAxbmY53hMtQC WwGTKIITJEIdDMDca1hvOAaZcAW8riMNWFzIJBshCK7AW+ApYpI1sB0uQjF8htnF6AcDcKmESZ7C hBtMsgF8IAOeA28ppof9EA8l8AkkbiIvYOMt5B/cAFKGdMECgqEYvoHKbawHXIA7wChnkizgrGCS tbAbsqABBO9g24IvXIDXMKESywDbIRnuwReIv8skc+5hfnAK6mEIFt5nEms4AdXAW4VyAp4QDc3A rGYSDdgMiVALHA8wLeyEOHgKoyD7EGUI9sGCGibJhQ6Y+ghlAI5BCfTA1FqUKzgNRfABuB4ziRpY QAjkwVvgqUN5BmeIglvwDabXozzBPsiHNhBoYBJ1OAjJ0Az0RiaRAzM4BlfgHdg9RVkEj2Ym6YV3 LSgbz5nEH67AdfgE30C+FdsHvMAPbsFd4G3DtgBt0IPDEAo1IPKCSdaBEeyHI1AMt4H5EtPCWtgA UXABaqEJJr7C9GAOsdAML2Hya8QoOII7ZEMBvIAOmPUG+wXYAjsgHa7CNxgFrbeIO/CHQLgBFcBs R37AjHfID0iHZ9AJHO9RBmAN7IXLUACNwN2JMgRRcA+eQD9If2ASJdgCkXAJKmAIvnUhBnqwrT5i vT4zietX5FM/5jGAMvwN+yhw/464HsK2+8EkS2ArZEMjcA4ziTJsgTSogmFYOIKyA6ehGD6D8Ci2 C/hBNjwDETTTtWAXRMBDYKewE3PYRmMnRXR2QmVjJ8qwDLzAD8rgHnAy2MlEUIZl4AeH4BbcBSqT nXCALhhCFFyAx/AUJrCzE2EwASsIhTNQBGUwCEoc7KSKk52s4GYnH3jYSScvO3nHx07OTmAn4hPZ SfckdpLHj34wXYCd2MNRKIZOEBNkJ7ZwFgrgMdCFsLwgIsJO4iazk3hRLJcYO9Gfwk7uQ4UEO3Gd ivFhEplDOAmFWBC+f51AWUTIsk+oCy8a+1bxun99fcSN/PXdDutVFLr7Kg66B3iCCqEso2CYCqbg IKuIA8beTFzIVuJEphFZwvr+BYXQZtIYMynLpIjtTBqTKLAf0FwzhaCWSB2bVvu308qNzY9KMCF/ 4kcikKhGlklRJo5PLUKc2Qlr/rvYCVlBaGPprPhtOvJj6dD+Mx0qDyudX9JYSehjaaz8bRqLx9aD jvWgjK0HzXbmb5dkGWEbS2XZb1NRGEuF7V+5QUdu/PdyLCOMP6SgOJYC41/LwYbl+PuaMP+wJkvG UmD+axkYWIbfrYkuYR9LRfe3qSghFdZnrcdTmXjoEXWZFNMGf/6d2sT/TI3jD6kpj6XG8a/UlOjL pNht8OcfUlMjy5f1jV7EX25MtxKpOSK9XSilnkht/dj3c2yRMut3O3FGP+2xb+d4/kf7V46M6FMo ffjLTbiIIVJxxxJN+9fSOWB61hdZ+AinFOHS/jnNItZ6UOQID6bRxfgeY/NcMTZ31peMPMemmTA+ DXU8plZgmkmURWPrvgJLspn4YJqNGHv32Pis72Nj3bG2aGGxH8B6rccUMyhqY0v29yn+io1JrKl4 UL2mvJhw05b1TSvNNZOwbcwQcXIUJUzN/bdvDE0jemO5wjqpyU9kVk7DHlF/DRsxAGnCP7aVpLF2 aA8QfaL5M4ZR6yX8ibuxv8DWUBwvLHJEYGxsuf8YW26sfAkSvkN3x6awwt+fES9EiBSGsKaR+o9p WBHKiS3Jd+gExQpY4wn9ZrzFY+MJYzxTqhWwxhP+zXgKY+OJYLxpNKtDrA99S+G//j6e4th4kzHe O4z3bmy8yb8Zb8nYeKIYL5tuBazxRH8zntLYeGIYbzebFbDGE/vNeMpj403BeMsYVsD6lpMB8vLx 2Db7/RZn5RGViCNvNdfw/xIMi8kIH4W8oiwmrK93rsP43n8rw1QigaGsbaa/hootTUWMaGJ+fZT1 6D/ht/NjfX1q888ywyprU1lljQ8RbjUe5azl+DUoN5INrNJA3YgUJ/2PKf5VgqeNp+qMze5M+W2q hqzY+b+d6vi+fvp4ql3YWF3036QqTaay4osqPXaU+8+84iEzCM8dHOERUtPHvu8lTaZhbLmfY7P2 JNswr7/GlvyvsaXI3GXxZDlVamxLrh/bDzlgydaNxaDdz+kIWUDEkeoG6gKMx/OvVLf+TPvXvQOV zCKsEiKFdG2pSmM58ffxN4ztBVmps/LCnrC+qUYjq+ZRMKcZY3G6gLC+ZaU5Fv3//poYJ5k9FqcC QGPFKanCptmC3Z1ZLCGPignpHSVkOweFNJylkPuKVNKSQCUmS2ikZR2N1HrQSJgnjayMYpBJaQxS eAVt6zIG2isM0nGPQZahrXl3L9ofaEsuQt3b8xnq7Fqoq2ijTnWNnfyv/mN9b6UEwrCvmIpsN0Ls LkRcnkPMoUlPUAUjVyGeg5AHsIiTkAKYyUVIHDchQTyEqPASMp+PkNegw/rm2URCimDSJEwDc/mx 7fnH58e6HYJ1qcgcdkMEGf9mGDtrHwSqYAYWYAnWYAt5MBHL5gylwMQy6gPrAaUEYOUB5V9rxfqK G/XnM1L/2Zf+276M3/Zl/21fjt/25fpt30m/7cv/275Cv+0r+Nu+wr/tK/LbvpN/21f0t33Fftt3 ym/7iv+277Tf9p3+274zf9t31m/7StH/3U1+++//rZJ16eec0ewhP5PD79g10fECwj72PT92xtgv c+x3LB7ZOcZ+Ocd+x25KZB/7WBg7z9gv79jv2BVL9rGP8rFPHPsdexqPfSxc2AXGfgXHfv+93ncX EtKHBkbdEgrxWUUlW/WoxOo6lXwpoZJT1VSS/4BKLj6nku2tVPLhA5UM9lCJzyfU/wep5A6dRnZy 0EjBORq5fp5GjhykE5VBNiK1nEF04ZwDgwyHopbygEGMQGcqkxyCEwvQ9vRBG3bj+P4Ga9vJWjrW 9mAQxV+67X/pPvNL961fujt/6Rb+8O/uZb90u//SHfFL9+1furt+6Z7c9e/uFb90b/ulO/KX7opf unt+6Rbr/nf3yl+6d/zSff6X7ppfun/80i3T8+9u41+6A37pTv+l++kv3Yzef3fL/9Jt80t36L+6 yf/wj3UJnnXkk//p5P/xf/x/3Blg3XeSiN0z6xuO87E7tsVueA92v5kIrPesNtZkHC3ECJkmTkg7 Di/20wnJkiRk4ypCfMxwlHEjZHY4Ifw5hKy6S4jkO0I+81DI9EUUcnY1hSyxpxDHYAqRTaSQrGwK +VhCIVrPKeTmJwqR50IbZDKV/MChaQ/qgtHrqCTImUr6D1OJSxKVrL5NJbJPsG/voJIq1rVWtGiZ OEydVaKR7hU00rmGRto30cjeLTRS7zO+L7+eRSMWN2hk4T0asWmikd63NPLlI40MjtLIZlQ6Lk+l k61ydHJXg06eraWT10Z0UmA3fm2t6QideJ9kIxf5GSRKg0FUXLFX98Ye8BCDmIQxyGLUSZUeMcj3 ZuylOxjk+VcGmfKD9XVAJhGYgGOEMJMUT2OSb7OYpGQhk+gr4e9aJnE5wSTD1zHOUxw/3jDJxG9M YiTKTj4qspMN+qizWbKTGWhQHN/BTmK92cl3P3bCcZidXDzOTl6Fs5N9ceyEmcxOFmZg3Fx2UlLJ Tl7fYyd21exkO7afJ+wCL9gNPuALe8AP/GE/4DBHAuAQhMJpiId0yIViuA33oRYaoAXe0scf1eyF z/AdRoGBgz4n8AAfCMNUmAVyoAaarI9IgQFYgD24gCu4ww7YBT5wAI7DeUiDQrgLjfAWvrAqGchu PhAFKZAHHLKJPlhBAlRDA7yAPmBDhUQAcAgnM2EOSIMsyMNiUARsLqIK6rAMNGE12MA5mIcqjQuc Y1VtULExgHygI37WwDowgI1gBpas92rBZnACV9gGO8CDczz2dDG9PypA1xFrLYixVsSWozRqY2j+ t2kg5nSw/AZYJ0PkgTH6WyP/bRC7doQctkdbYzMhKxwICXEk5JQTIdzbkC9eqNEdJuRJCNqvCHRX BPpbtL/sUgjRTkO+ZyFe8wg5VogYL0VZuENIzX2kUYe0m7H+bYTs+4j9wiDSolPIXn4K2SFBId+k KOSINIVwLqaQAmUK+aBPIVHm+GtDIZ1T2YnkNHbiAEFwA7pAfDo7sYUEeAjMGexkPrhCBDyATyAr yU42wRm4BkMgNZOd2MAhKIIW+AHdUuzk1ByYy05OYKMsnY9pIEeGnZgswLygEfgWshMD8IJUaAKO RexEH05CMXyFybLsxAwOQRG0wVQ5drIGDsIleA8C8uxkHeyERCgH6mJ20qmAmEQsJy9hJ0uU2cls FcQlSKqyk5XqGA4LNJAPEA3PgLYU44ITREIrCC5jJ2qwBySWs5P9kA31wLaCncwBM/CDDHgENE3k E5iAL+RAA3CuxDzBAY7BDXgFs9Fe1gFfSII6GIL5aEMbQRqcX4VlXs1O5NewE0dwhwRIhdfQCTPX YhpwB08ohFvQB99hkS7WD7zBHzIgF1rgFUzWQ35ABMTCPXgEtHVYdtAFQwiDcHgGr0EA+0sx/fH9 phlEQRzUQAMMA2098hH2QSHcggEYgRUG7GQ1BMFJuAalMATUDexEA7TAHwLhLtSAoCE7mQLrwAhC 4DTUQTNwoE0wAZaABnhBHsQaobzCLGOsD9iCP+RACXSDiAm2IWiCN9wDqinyEDTAAo5DDFTBALCZ 4ZgBxnASdm9ix7Fw/FiyCDTAHY7BWSiHLnCwQrmCLCiBLmC3ZidCoAmu0AxfYaYNO5EDW/CDYLgG L1n/bYtlBy87xA2kQht8AJo9O1GElXAMOuEbSGxGHoA1eEMqXANOB3ayFfZCPDyB1zAECxyxLeEk fAWaEzuZC1awBQ5CHtyGdtiHHfRGN2ybbZh+JzsR9UK52s1OduxBHvtj+H7EaQA74cHx9fFRlMlg dnIhjJ3cP4m8xLF2aiS2cwzi9Dw7qb6I+SRi+XDsbbqM8pXGTkIz2cmBbKzLVXYyD8fhHXcx76rx Y/EO7M89wJs+3nI+AIGAagU5CkEQAqwnDU/AKTgDERAJURADsXAeLtDHW9+J9PEWeApchjRgvcQm C3LgKuRBAVyHQiiBUrgFZVABd+AuVEE1PIRH8Bjq4Qk0AetlOs+hFV7AK3gN7dAB76ELuoF173If fIF++AaD8ANGgOCYTWUb/5gkGzCBA7iAFybAJOAHQRCCySAGU0ACpsMMmAmzYQ7MA2lYAAtBFhaD AiwBZVABdVgKrG9/r4CVoA2rYDXogh7ow3owhI1gDCZgCuZgCVZgA7awGRzACVgvQnKDbbATPMAL vMEX9oIf7IODEACBcJht/BbtYxAMIRAGJ+AUnIZwiICzEAXREAOxEAcXIR4SIAkuQQpchnTIgCzI Zht/sdFVyIV8KIBrUATFcANK4RaUQTncgUq4B1VQDQ+hBmrhMdRBAzyBp9AMz6AV2uAFvILX0A4d 8A464QN0Qw+wPp79CT7DVxgA1ke2B2EIfsAIjAKV9Uwaq27Hqn4zxk89cQAncAMPTICJgOo8EQBB EAYREAPWh70lYBpMhxkwE2bBHJgL80EaFsBCkAU5UABFWALKoMIY//CgOiwF1nUYTVgJ2qADq2AN rAU9WAcGsAE2ghEYgymYgQVsAmuwBTvYDI7gBC6wBdxgK2yDHbATPGEXoPlCdoMvY/xcth/sg/1w EAIgEA7DUTgGwRACaPKQE3ASTsMZiICzEAXRcA5iIQ4uQDwkwSVIgcuAZhNhfdA9E7KA9YzgFciF fCgA1rOEhVAMJVAKN6EMyqECKuEeVMEDqIFaeAz18ASaAM0z0gKs5xbb4CW8hjfQDmi6kffQCV3Q Db3wET7DF+iHAfgOQ8Bq5o3AKFDQFqACnTnW9Bs74ckBXMANvMAHE2ESCIIQiMBkEANxkIDpIAlo MpLZMBfmwwJAE5LIgQIsARVQAw1YDitgJWiBNujAKlgDaHYSXdCDdaAP68EANoAhbAQjMAYTMAUz MAcL2ASWYAXWYAt2sBkcwBGcwAW2gCu4AevZ1W2wHXbATvAAT9gF3rAbfMAX9sBe8Id9sB8OwEEI gEA4DEfgKByDIAiGEAiFMDgOJ+EUnIYzEA4RcBYiIQqiIRbOQxxcgIsQDwmQCElwCZLhMqRCGqRD BmRCFmRDDlyBXMiDfCiAa4BmPymEIiiGErgBN+HnrX3kNpRDBdyBSrgL96AKquEBPIQaeAS18Bjq oB4a4Ak0wVNohhZ4Bs+hFdrgBbyC1/AG3kI7dMA7eA+d8AF+3nZFeuEjfII++Axf4Cv0wwB8g0EY gh8wDCMwCqynnChAZb06CtiAwT5+XY11mYADOIELuIEHeIEPJsIk4AcBEAQhEAYRmAyiIAbiIAFo ihI0PQmamwRNS4KmJEGzkcwCNB3JbEDTkaDJSKQBzUaC5iJB85Cg6UfQ1CNo2hE07QiadgRNO4Km HVECNO8ImnYETTuiBmjKETTdCJpsBM00giYZQfOLoKlF0KwiaE4RHUCTiqBJRdB0Imj+EDR1CJoz BM0VgmYJQfODoJlB0JQgaDYQNBkImgYETQGC6j0xBwtAFZ+gGk9QbSeoohNUxQmq4QTVboIqNkF1 mqCaTFAVZl2jJlvAFVAlJu6wFVA1JtthB6CKTDyAdScMqspjr+BCdZn4gC+g2kz2gh/sA1SfyQE4 CKhGk0MQCKhOkyOAKjUJAlSrSQiEAqrX5DicAFSzySk4Dahukwg4C6h2kyhA1ZvEAqrfJA4uAKrh JB4SIAkuAarkJAVYrxhLBVTNSTpkAKroBFX0sVeSXWEfv3abC3mQDwXAulx8HQqhCErgBpTCTbgF ZXAbyqECUN0nqO6Te3AfUO0nqPaTB/AQauAR1MJjqAfW69Ia4Qk0wVNohhZ4Bs+hFdrgBbyC1/AG 3kI7dMA76IQP0AXd0AO9wHre8BN8hi/wFfphAL7BdxiEIfgBIzAKFA7EJNBY57CAAUyO8Yt2HMAJ XMANPMALfDARJgE/CIAgCIEwiMBkEAUxmAISMBWmwXSYAZIwE2aBFMyBuTAP5oM0yMBCWASyIAfy sBgUQBGWgBIogyqogTpowFJYBsthBWjCStAGHVgFq2ENrOUYPxenB+tgPWwAQ9gIRmAMpmAG5mAB m8ASrMAabMAW7GEzsF7d5whO4AwusAVcwQ3cYRsH654IxCPsBA/whF3gBd6wG3xgD+wFP/CHfbAf DsBBCIBDEAhH4CgcgyAIhhAIhTA4DifgFJyGMxAOEXAWIiEKoiEGzkEsxMEFuMgxfk9EAiRCElyC ZEiBy5AK6ZABmZAF2ZADV+Aq5EIeFMA1uA5FUAwlcANK4SbcgjK4DeVQAXfgLtyD+1AF1Rzj92o8 hBp4BLXwGOqgARrhCTTBU2iGFngGz6EV2uAFvITX8AbeQjt0wDt4D53wAbqgB3rhI3yCPvgMX+Ar 9MMAfIdBGIIfMAwjMAqsR4dZ31mgARswgMk5fimdAziBC7iBB/hgAkyEScAPAiAIQiAMIiAKYjAF xEECpsI0mA4zQBJmgRTMhjkwF+bBfJAGGVjAOX4vjCzIAes7EotBARRhCSiBMrC+O6EG6qABS2EZ LIcVoAkrQQt0YBWshrWgC3qgD+thAxiCERiDCZiCOVjAJrAC1jcwbMEO7MEBHMEZXGALuIE7bIXt sBM8OcfPzdPFxs/FJ6sgrnWwHQ2wXEbIWxtsDzuUbXuUhc2II0fs611wDPJGbAZjOU4jlmJRdlJQ XjKQj3lYvxKkcwfHv2ps36dYhi7ExSDijYtCsqbCPAq5pEAhifoUMnUTZex5Soo3hTw/SCGRQRRi GUkhKxMphJZNIbXXKSS7nEL0miik7uX4c5OLhynElo1KZglQyfdZVCKpRiUH11BJ+DoqSTKkkoFN VHLHnUrSd6HfESopPkUlqZFU4hBDJV7nx5+F5L1KJYxSjFM2/gzk0GMq+dBEJd9eUcmEd1TS/4lK ZgxQyaXvVFLyg0pms9HIZU4aqeSlkY3TaER5MY281qURC3Ma4XKhkQc7aWTWARrRCqORgvM0ci+B Rg6m0kh7Bo3kZ9JIWw6NLL1OI9cKaeRLCY3Qb9GIbAWNUO7QiNQ9Gsl5NP4M4od6eEIjmc9oJPY5 jTi/GH/O8HUHjcztHH+uMK2HRi720Yh4P40ofaeRHcO0sY3oRaFjn0onhnx0soGfTtgExp8PFJsy fi0wcSad8M2lkySwlaMTiSV00q5OJ4UadPJKc/xZP6VVdCKtSyfDoLyBTlyN6OSWMZ0cMqeTOxZ0 wm9LJ1V2dJKwmU7ynegk0JlOPrrTydA2OtHciXnuphNu1snAE+iOphPfi3RyOoVOdGvpROEJHetF J8866UTyC518/0Enj+lsxJKXjSwVYSMTZ7CRl3JsZM9SNtK2io2k67GRN2Zs5OBmNqK1lY2Y+rCR rAA2ohs2/hxd4QU2cimFjchns5HB6+i+yUbqK9hI6wM20tXKRrg+sJGnX9jIiWE2cpfOwLGIQdbw MkikAINISDLI7UUMwq/JIP26DOJkwyC9WzDcjUHYtjHI3e0Mcmkng6R4MsgNLwbx8WGQ83vQz2/8 WTf+gxg/gEEaAzHOEQY5cYxBcoMZhBrGIDePM4jUKQaxPscg+zPRDw38qw0McgGN9N53SOMrgzxF A5kNjd6paLAloIG2Cg0ys8vjz3mxnum6jUaVfuH481WapUwyCY0nNTSc2NBgqkBj6QersYRGUjsa SNfQOKpDw+hRI5MIPh9/7qYEjZ8QNH7moeFzBw2flWjsfEVjp69nvAFThYZLIRotfWiw3GAbfx7j BhoopWiI7EfjYwsaHfvRwNjEup6FRsVtNCQa0HhIXcROEtFoKEZDYa46O3mGBoHXivFrL7poALSj 0u+nO35dIxUVfidU9vlR0fdGRb8XlfxTpuykAxX7Q6jUz0aFPhGV+XWoyLc5oJ/T+LllFCOyDw7D MQiG43ASwuEsoGiRcxAHKGIkCZIhFTKAda/xFWC9FP0aFMENuAnlUAn34AHUQB00wlNAESVt8BLe wDv4AD3wCb7CAAzBMFDYEH1s4zeGccNEEAAUaSIK4jANJEEK5sJ8kIFFIA+KoASqoAGsN2hogQ6s hXWwAYwAIUE2gTXYgSM4A0KEbAdPYN1DvQf8YT8cgiMQBKFwEs5AJNv4vZ8IJZIIyZAKmZADeYDQ IiWA8CK3ASFG7gPCjDyCemiCFngOL+ENvIcu6IU+6IfvgHAkFAbyDJjABQhLMgmEYDKIw1RAmJLZ MA9kACFLFoMSqIIGrAAtWA0IZbIeDMEEzMESEN7EHhzAGVzBHRDmxAMQ4gQhTvaCPxyAQ4DQJkEQ CghrgrAm4RAJMXAeLkIiJEMqZEA2XIU8uAZFcANuwW24A3fhPjyER1AHjfAUnkErvIK3gN0G+QA9 8AmwCyHfYBCGgSCsacAETuCBCcAPwiAKU2AazAApmAcysAiUYSnYgzNsBS/wg0NwAmIgBa4Cdknk PmCXQ15CN3wHOtpaE2AKzAHsLgh2E2QtIPQJwpx4gj8cgzMQDYmQBcVwB+rgJbyHPhgGNtQVJ4A4 zIYFoAJaoA8mYAdbwRcOw0k4D2lQCJVQD6+gG74BFXUgXpgMM2EhqIA25/h1EVZ8seKKdc2Cdc9G 1M+4KPhZ/lllnHVOn3W+nnWvButcO6tcssoe65w26zwz6zwxq3w8/rkNWedfWedK/7ovg3U+0vNn nrPO57HOt7HOtbHOgX34mb+sc0yiP/OWdZ6GdQ6Fdf6EdR6Eda6CdZ6CdY6BdR6AdQ6A1S5ntZtZ bWZWm5bV5mS1N1ntRVabjtWeY7W/jv/MJ1b7htX+YLU9WG2Iv+r3rHo3q17MqhOz6qhOP+uUQXAJ UuADMLlQX4cFsAb0wBJ8YC+chiy4ApXwGtphFMS4UT8HbbADBzgKiZAMb1i30vKgjMNMWAaaYAW+ 4AdRkAfXoAUGYBCEeZHHoAg2sBf2wQUohlKogQ/QA/x8KAMgBybgAV5wHgqhBJqhH76D0ASMCwpg B/5wADLhPjyA7yA4EccEWAk2YA974CxEQwk8hWfwDQQmYdlhFWwGJ4iEXCiAh9AJ3fADRPiRj7AY 1oMheMEpCIc0qIQqeAbf4AfMF8BxBtYKjN8Ldx8eApcg4gzmgwIYgBE4wyE4CtlQDY+AIYR9C+s+ OlAFE7CAQLgISfAKRoAqjP0NWIA1uEAgHINkuA2VQBfBPgtmwgJYA+vACQLgCFyAYrgJ96EdOoE2 GccQkAQNMAcrcIZDcBSuQwM8hc/AJ4rtD+KgDOqgA/bgBL4QAdFQAS/hLWsctJ/swQl2QCichES4 CeXAOQV5A/NAH1xhG6TDXaiGRuiDfuAQR9sU5sIq2AzOcBzSIAuewGcYAHEJLDOogyMchMNwAtIh G25DG7wGlaloU4I5hMJlyIA8qIUGeAJbZjKJP+wH1r3g/DyLR/ln1Y+G3/w/v//n93//b3gIv8qZ 0fD9rPvcUTzJdDJ+v7s0LPx5ry//dIy5f/yXdesvQpsgBMeeGmE9lch6kpD19IgRmJDxp0g8YBcZ f5qEdc/waTL+VEkW5JDxR0Gmg+TPp0s2gjE4wz44AMVQBw0gwnq2CmRhGxyGo4AmP0HTnrQBL9oP rCdgZtPH73sZX7O//Yb87fev/txj6/nHXxyiPlaPPczCGHs9H+vaFOupFiky/tQNy2yII5SPIRTW s7rMjzMJ69V8H4b8Td+pFemZW72qoa/NfD869l5d1viFY08j/DruP3+Q6sbn/x73n9+v6/ntv8f9 5zeDy4z+97j//A1YJk3wv8Z10jy7LPOjMmdXSUp521lnm1ESKzo+7gqe/x73nz8B0zZ7fFzqz3H/ /u/vj2v8O91/fvXhiUXj6S4jEp9YTwuNP/UxSvbv308GWI9q8hHqR1bldwJhH3sHI6uAsx6a4iO0 j6yLL6x3NM4hrMQ4Pk742yKwFnj83Y2sk3+ot46Nv4n85zdzWCdZDQnXR1bQBI31Gf9GGReFle7S sd+/vdkR/yaOdbMedeInM1itlbEHrcj+/54H/W/zoI/Ng/FzHtTfzoPtl3kI/Y/zYPxtHgz6X2+o ZM2D9tt5sP8yjwn/4zzY/zYPdvpfXxlizYP+23lw/jKPKf/jPDj+Ng+OsXkwf86D7bfz4PplHvz/ 4zy4/jYPLvpfr85mzYPx23nw/DIPwd/Oww4dKyjj85jwc9XtMQ9WEKwc+wzevrF0Syms3K6ipMyl kAdj/UcpE8by/19fwPvXnOj/45wm/v8xJ8ovc2L8dk7r0RHPPT6nST/nxI85scbaT8ba4//+0MG/ 0mKOdfP8XBvmb9I1Jv/eHvw/t8d/flKBayz3f7clJvzXnP68tQX/trUFx7Y2x895cP52HhN/mcfv t/avOSP0m5zh+FdafL+kNZ4jf+UMx/+QrvBv0uUiv8sH9v9Il+t/SFfkN+lyk9+tO+M/0uX+H9Kd /Jt0ef6V7qRf0mX7j3R5/od0RX+TLu+/0uX/x3R5f5Puql/SFfuZriTS5f6ZLt/fX5n/r9Sp/5E6 39jRZN0v6U35mZ480pv0M70JP6PwP1Nl/JLqfy7zhL+lKv6bVCf+NlXmL6lS/iPViX9LddpvUp30 21Q5fkmV9h+pTvpbqtN/kyr/b1Pl/sdU+f+W6szfpCrw21R5f0n1P7eWwN9SnfWbVAV/m+qvEfyf +Sr4t1SlfpOq0G9T/TUe/jMHhMZSXTE2zi9fUeX9917srz07a+zxVOmsez7IUhplbAn/vawBZPyW 6Ba0IZJNCUmBQhxAukCoAPsYUKpDUwESZCkkEWwW0chMORoJOEgnh2DeZQbpS2UQhYNMMimASSqh K5BJrh0ebypPoI/fdrAX88qeNf7Xc3ztfg5hPYrOGsL6Oz6EdTTZPjo6GjqfkAvCWPdFfw1hReU0 yvhNBoqs1Lj/GvLXyw9SMVRoJiGfkc+Lx9aSVaPaPzQ6+gr/4TAHuS/815ApP4ewTvWwhpwX/is1 Vlyx9gaCqJbcQKa+lfhrCOPnkKW08SGsMcZTY0XNouHR0WAskyxaFhZ8f03DqgutHxkd3Y/RDNDO qOL9a5q/Xq1QTljfdiTk0aS/hrCi5QT+nsCu/BOG2PD/lRqrRrLp/ego60YILcyvnf+vaVix0IUh 3/EfDRjCurwzPg2rPLMucERiS2tPR4Ntxl9D+H8OYd2SxBrCGmPx2JC/XsTAejDvMZbal/uv+fz1 aoIdP4ewboUbT03o51JvgUVI7f6/tqnwzyGstG9OH78FfXzIXy9xuPFzSNC/lvqvFzmwmrXbJce3 1/iQv17mwDoSTEM5yP7XfEZHWa8m4SHWZOPY64sWo6ErRxaBMlFA5Mn9x7AlII//LcHQRfj9p2GK +PvPacr/IU2lP6S5+A9p/mmYwh+GKf5h2JI/DFP6wzDlfxy2GF3/PEz2D8Pk/jDsn/N68R/yZfEf 8mXxH/Jl8R/yZfEf8mXxH/JF4Q/5ovCHfFH4Q74o/CFfFP6QLwp/yBeFP+SLwh/yReEP+aLwh3xR /EO+KP4hXxT/kC9/is0/xZjiH/JF8Q/5oviHfFH8Q74o/iFflvwhX5b8IV+W/CFflvwhX5b8IV+W /CFflvwhX5b8IV+W/CFflvwhX5T+kC9Kf8gXpT/ki9If8kXpD/mi9Id8UfpDvij9IV+U/pAvSn/I F+U/5IvyH/JF+Q/5ovyHfFH+Q74o/yFflP+QL8p/yBflP+SL8j/mC2vv8k/5whr2T/miOPb3n4f9 U76whv1TvrCG/VO+sIb9U76whv1TvrCG/VO+sIb9c77I/iFfZP+QL7J/yBfZP+SL7B/yRfYP+SL7 h3yR/UO+yP4hX2T/kC9yf8gXuT/ki9wf8kXuD/ki94d8kftDvsj9IV/k/pAvcn/IF7k/5Iv8H/JF /g/58t/16/8c9s/58s/1XcU/1HcV/1DfVRyr77aiNfN50b+dUPy3AV1C2PTQpkQTfbU+WkJoTNwH PwN0byJkIbyECCtC0qwJ8bJHC9mBkNvQjwbOOQ+0ZvzQojtISGgYIZqJaKVlog1TihYiGnScX9EO 2kkhRSFUQs+ikvvQk0slxZVUkkGlEedVNGIfRSPN8C6GRo5dpJH2RBpxvUQjTSU0ktFAIxHtNDKM Bp+UEp2Ya9NJzkY6GbClkx9b6WTSNjqR96GTQRj2o5OgfXQSB6wXnJ2Hr6/Yxl50thoceRiEW5bx r5eeeWozyAUdBlF1ZJC7Lgwi788gAQEMcid0/GVoJgUMIvjzhWjnhJlkzc+Xot2QZpLTC5ikHr5v YxJNHyaR2MMkK8HnAJPUoPW/NYZJwiHnHJO8OY/uOCbhZb08HU62Msn7fiaJoLKTkxPZic80duKp xU7SwV+bnTjosBP6RnT/fMEjq7XJOlfDOgfCavKxzoexzo+xzmaxxmCd12BdRWCd+fx5f8zYeR7W WRnWOVDW+UrWuRTWeUDWpTLW+VrWFRM09MdeEsa6ZiRKxi+Msq5AiJPxC6Ssi6rTyPiFVTSVCRqf ZCYZv8jKumjIulg4B+bCPJhPxlupMoSMvSyTdREWxW3sBbis15WyXkLGavmyXi/LenUs6wIs65Wv rIuwKqBKxi/GqoMGLCWsC19oWRPWK6pZ579ZL2dGe5+wXn1NiA4ZPwuxGtbAWsJ6UTIhKM6EdcYJ xXmsbYyiTDYQ1rkhghgZv9jLOr/OuuBrCmZk/MKvBbDOjFsCijsiCmUZbIF1RQFFn2wGFH3iCE7g DC5kvK3vCqwXfbtDOzJvcNG/XVL8NzoWcCZoYSF3YCEVsJBdcBYLugALoA7fIAELUYyFOIkZl2Gm dcCJmaQi5pYj5twQc2mIOVvE3AXE3CvEnBFiTgIxtxcxV4uYm4t464Q5eVTSjJirQMwdQMwFIN6+ AN85GklGzH1GzIUi5gYRc48Rc9mIOWFuOlmPmDuEmGtGzE1jvTQK8SYHuoi3Ob50Mt8fcYZ4S4NY xNsNYH/NRlYh3nbBHcScNmJOBvG2CaIQc3WIOT3EXC9izh0xV4KYe4B4EwljkJOIuSmIN1e4gpgz QLxFQyNiLhrxRl3IJBO2IxYRc7MQbxvhImJuwSEm2YV4S4IviDkG4q0GBBFvKyEDMcczwCRFiLlc xFwcYm4P4q0Y6hFz4TrjLzT5K+auI+juQDO8hLfQBd0wBD+A9b5aKnACDwiBOMyEObAQFEAN1GEN rAcTYL182YE6ftPAdtgB/nAETsBJOAdpkAOlcJeV1jSUcUhCIGZCKdyHfgTeKBiirFmBNYLMDSIh DpgItgkgg6BSgg0IGAtgIBC4IBYuQiWC4j6oIzCWQwwK/gXYhYLvDxIog7PBHgHgDIchGHIgH3wR FPvgPCTARASHABgjMKygDsHRCu/gMwxuJWQENHcgnsEa7MDVi5CtcBvuwnwf7EugcQ8hb+CAP+YN JQcIuQX9Adgeh5B/cBq2HybEE7hCsW1AGhZAO3wB/ZPYF0AgBMG5M1hPEInBfhD64TsIn8P2BLM4 xDlwxmO/CnuSsZ5QBKXw8TIhX8E+DfsF8IdgOJ5OyBkoyMIxEWZfxbpAfy7KEbgVYFlh1TVsV1h3 HdsG1AuR/3ANioGrCPOF/cWEHIKSEqw3yNzA/hWK4SY0QytsxX5gJ4wAtQL7d5AAQzCBAiiD5Xew L4U1sA4K7xJyA97Ce7j4gJBEEK5B2YaYRyhPsLYe+1m4BnchsIGQY3CwEd0g0ozjBSyGpRDdijwG hxcoN3ADbkHnS8QU+L1GfkI7vAfHN8hvSIZUuA8P4OBbpA+RcA5KoQy+ww8oakfasPQdyhS0wWsw eI99I9AGEAsDrIdGKeQbuPNQyA4ogVvAnEAh3PAC3oDWJApZDdoCFLIGrktgXHgzlYJ9PIWETqOQ 41A/j0KegPIiTAM/5LCDkKcQkyUUYgXSShQiC44qFOIKOZAPd9Qo5B60wktQVqcQNXDQohAX8FhF Id5wZjWFRAKfLoVMhDI9CikHf30K2Q8D6ynkO6gYUog+VMIzUNyIfmAM9vDOiEK6gcuYQibAejCC 7bALjkAwLHekEE2Y7kQhM2El6MAZOAuPoQE6oRvMnSnEEvbBQQjdQiHhcBeqQMSVQsRgjTuF6EE0 xEI11MCTHRTSDJd2UUgq1METWO6F/ARP2A21ezBfGIAhVvdeCnkK2n5IG27uQ77A3kCsC1wPoZDb cOwshZyEddEUYgAd57HcEJBEIUGQn0IhFcB1mUImwdJUpAki+RQyFawLsO3g6Q1se1hyE3kCz8uw 3WB7OdYbCqEaqiowDMJxEDkLl6qwXvC8GuPDlIcUMg0UQQWcalAuoBoewaTHFCIEz56gLEI79IBV E9YNMiAP5rVQiBLsgRDgeIblhUTIgw3PKcQZEiAXNrdSiC9ovKAQXdDDwc0CWBeGBF5TyOI3WHfg 66AQUWj6iDiBHX0UcgrWj2AZYM4ohchAPTSOsl6SzvroCZVw4qA4FZbiwLgGBunox0Ylk2EmXOKg knyogMegOolKNKFOgEqegKgglUhACQ6mt4AuTCXssG0ylZyFFEiFtaJU4gHaYlSyEaZJIH1YO5VK 9OHMdCqJhBszqKQMJs+iEnHQlKISHVDAAVoZbOZSyWZonkcl32DufAyHeunxjy+my6DNAnXQB8YL qGQXUHFw5wTxRVQyC47DWVa3LJXIwFmIAkVUAFTASBHzAR84BCJLqGQKLFSiEg1YBx5QDY+hAd7A R2UqGQC6CuYHU1CRmAHyS7H8oAHL4ekKKnkHGprIE7gDDTBDC3U/iNOhkky4pY/1gdOoiJwFygYq YQMXcAcha2wDGLalEg47Kvm0mUoYqKg4wRY45EglRyAcIsHDiUr8gXsLlQhDqCvShe9uWGZ3KrGG LdC/FfPahjyAbXANlZ6b0AEf4BgqQKGguJNKtKDWA8sP0zyxXSFuF5UkQIs3lbSB124q2QfDqDTR 9lHJa+hj3X25H8sLM0EZzkAknIN4eAwv4cIBlEVohTew7CDKDQzCCMwIQL7BAQiESIgD+iGkD73w GawDqcQehmDyYUwPTFTiDsEpeAhdEHuUSorgwjEqSQSVIGwrMAQLcA1GvsBROA9sqLtzAF8olQiA JqyCQAiCLLgK9+AByIahTMOnUyjHQI3EcgA1CmlAH3wDgRgqmQ50VC454dFFlG2Yk0Ql0lB6iUpu QyN0gVoy8gZICqaBYLgEj6AeqJcxH9gJXrAuHWUJ/OEYiGRTiSTchVowQmXWEuIgAUyvUskm8ABv OJaLcgClcBsmoN3CD+thI+zMx3wgC3KhDCrhFfRCRiGV5EAFNMOnIuRlMZXogTGYghPUw3vgKaES MVgPGyEVMmHoxnil+wcwbyI2YCckQhaY30JZBp8yKgmAybeRryAFi8AFdsC0ciqZB7MrkL+gDBpg CbbgCtshEpX7c5ACacB5j0p44cF9lFdgr8a2A8YDDIP5oACrQR9cYRd4wUEQeIhtCs3QCg41WB5Y /Qjjw344A1+A1GJ5YRf0wCBI11HJEtgFPqzuepRBiIBouAnl0AWDsKkBcQ674TCINSGGQAmWgiFs Bo6nyHOQgFlQCrfhG4yCVTPiAHhbkAaUwSPY+gzxDhGQAS7PsQ7QDC+A2YZpYC4sgkA4BgtfUIk6 fAOelxgGOmAM7uD8iko84eAb7K9h51t0Q1gH8gdkO1GmoRs+w6YPVGIH+7sxHFx7sFxQD69BtBfb HCZ/xHEQouES3IMa0PlEJRtgxxcsI2z6iu0P7t+oZC+cgRSY8h3LCjMGsR3h8hCVXAHVH8hPuA91 UDmMv8AxQiWTwBv2gOEo0obLUALyhEbWwhE4DY3QAZ4UGtkPeXALjlFpJBayaOgHr5k00gtMdhoR g+OQAI84aKQeJLhoRApuc9NIJdTDU7DjpREnCIco+AEMPhpJgixwnUAj3lArTCOt8Ar6YESERjgm 08hGsIUHYjRSB83QDl5TaGQvpEA2BIljfeASXAFRCRqZAWqwGuZNpREFMAVLSJ9GIwXwFj5CPwyB oSTGgaZZNPIcbs+mkbuwZQ6NbIM2eAUf4TMozqURZVCHZXAAAoE5j0aE4aQ0jVyEuTKYPzAW0lBf wLJDEEgswnJCGdwFKVka0QA1eRpZAfawBfwgAA5DHBTADVi7mEb0YQtsBTlF5BlkQym0wnvohC7g XUIjk0FGiUYWwyrYwupWphEl8IdjEAHx8An4VWjEFwIhHrJgmSqN6MAaWA924AylcB8WqGH5Yb86 poE2DSwDSC+lkSVgCOawFTwhHPLhMTwHhWWYB5jAZmiF98C2nEa4YRpIwQqwh7NwHnauQF5BA7yA AaBrIg3whiMQBdfhJkxbiTyDDWAGpyAWrkEVjAJDC2UR+GA+6MFROA0jMFGbRozBEsR1aGQOcK3C toX5q2lkITDWYLvDQTgBamuxfpAAyUB0sZxwEA4DUw9pwBbwhjNwAR7BY/gB7OuwHUEW7sEjeAMf 4AcQfRoRgFlgDOawFfYBx3oa4QEJmAWlcBu+wShUGmA7QukG9IeNhpgeLkISTNxII4KwBPSg3ggx AwYmNGIEWqaIO+iFYcg1wzJCF9DMaWQSzAU1S5QhmGGFOILLkAGONtiWwGWL/AQDO6QLQptpZDbs Bl+4DHlQAPehBt4BxQnzgVWwEYzBBXaAHxyEaIhxGn9hx1x440oj092wr9mKcg8btqFcw16og1YQ 2479A2TuQPmB7Ttp5BBweNJQP8U6gBqsgUS4AvRdyCtYAbrg5o3lBk8fLAO47EWZgOR9NFIBGQdR 9oAzAMt/CNNA3FEakQ9CPIAFUEKxLOARhnWA1ScxT1gH4Wdo5CoMnMV+MJJGSmBf1Pi5XpVz2L+A J+yG1lga+QKG52nEBpzisE+G9ARsM3gIjcCdiLIE1CSUZbBmfZAdqMmISTgER6EDeuD7/8XeXYBV lbYLH79X7LW3gaNiBxZ2d2KLYxcoOOpYqBiYhGK3GCh2i4FioNiNihiIKIqCgYUi5oiKo6Dj9+fA XK9nvvf9zpvn/c51HK/fxWavtZ6817M24twPZBvXoCT6YCgCAykXfttZY6Du4np0Qi/MDGLNTNvY fT/9Rp2D9AvjMRu7EIzDhzU5hiNHmQccOc4ait4naBfcTrLmQA8hjrATh/D2FPGImNOa3EGrs9SD iDCeVzh0iecfTJGs32gFR4zDRMy4Sjsw65omCzAvmvFGzRuMK8w3WS/xGVoM6y1yoyzqYTHWITyW NQq7bzFXKHGX9QyTHrL+wi1eE3eMeUK8wiaBuEcYLsIqUZN8cHxGn1HvOfWj1Uv6g4VYjZ3vWFcR pusSjoGZdRmF24jHjCy6LECFrLpUwTwrXZYjOpsu97HjB53ntC6Fc+pSFGn7SWUqoMtwjMegcrqM Rs1KutTD3uo6zyZdFtfSZR1MtXWeOboE4RD61tFlGJbW1WUDxtXTZSLeNdDlA3wb67IStVvo0hgP 8AzL7HXxx8WWtA1BP1IXirTRpTiettclCQu7cD3qOujSFC/TfkeIZ466vMflrrpEoZEzx5G3hy7F ENlblxh49tFlMqr11cUOlfvRL+Tqr0s+FBugiy1KunIMscN0eYgpbrr4oO5wrsPKEbqshfVI6sCy UbqshzJal6zoClcMxmTMxWrsxnGcRBSu4w6eIhmmMbrkRB5UQFM4whkDEIdfkAIrd12yIx8KoSzK ww6N0A6d0AN94IqF2ICN2IGdOIpbeJmx04Y1cqEwiqAMaqMx+sINz/EZiqcuWbDDS5c9mD2OGJyk /8e/mJ4xNf33s/OxAH4IRzRu4hl2TqN+6NN1qQ9PjJjJteg0hzZjho8uK7ADx+C4gLjESgTgIu7A yleXAqiAVZd12YZo9I3UxR0rEYwXV3TRrjKmGIXLeI1MUYwlGqAj/HEY13EP6jXmBhVhBwcEaCax 0U1SDLVQFzsQihtIxGfoJs5BI6zCYdxDCvIaJimComiINmaTOGM4PBGFp1hqMckuhOAaEvAalkyU jcrwmm2SuViGXHNMUhqd0R/TsAwWH5NYww6NsQVHYDPXJKVQD54pJhmPGYhONUkcxnzhfbiIIYPx UjPkDYJMhkQis9mQtvkNPs8bMgyfChiSraAheVEQXhiPAGxHxUKG1EfHwoY44DES4WVjyFykQili iIoscLPlfeQqaUgezMRsWJU2JAdKoRxWlTVkHS6XMyQKyVhQyZBKlQ2phm7ogdmYj3BE4kgVQ86j XVVDuuITLNUMOYNLMNc2JCe21DFkP04gHN3rGdIXrhgJL0zGXCzGU7yBdwNDpqNcI/qOAByAVWND sjdO//cKPfEZ15obrI+MJ7wxCztxAPfxBHlbGlIEZ3EBl1um/861fCtDauJiW0Oi0audIQMxEmNx DMcR05n5cTTkijP1oU135gGTMBXdexryEwZiEJb2M2QtnuMtnvY35BfYuRjSAuvRYWD6v7FIy5L9 EAlosM2QJpgbaIgvjm835BTG72E8MHOvIYvweD9lotchQ8YcNsQfmxGBW+hyhHnDQJQ7SqyEG2K6 lL6ZXSgi4BFJHzELPliDGNhGGVIBddASrdEP7tdoAxZgGfYhArmiDcmHe3iIeCTiFZIx4gZ1wQ8r EILLuIJY5LhpSH6URA14YhJ+uEVbkO82c4caqI/u6ItTOIuLuIMddww5jI5xHEd/jEDRe8Qyitxn LJD4wJAXeIVkfILy0JA4PMDjR4wtnuEDLsbTT3yCz2tD9v5C/KP2G0PqoRGa4gzC0STJkFZ48pa6 cOudIXfxEI/xG5T3jCFWwj6Z89H4A6/hAlckIRm5U2k72sEJzhiMLV/oM17jPUJ/M+QcMn01JCuG YQRGwR1hiEImMYsV6qEhRsEDJxWzhCHWZJZH+AWfoBhmyYImaIYNZrNswg0L5yJvJrMUQCEUQWu0 gwO6oRf6YD4WwjqzWfIgHwqiEZrCHq3ggkGYB19kz2qW/LiOm7iNOFhbUQ48MQELspnFD1+g/MDX tOzr2c1iggWD4YbVWIdNCEAs7iAOD9IyQ+Uwi47ssEYBFIYtSqMzHBGMA0jES4zMaRZ3TMMsLMNK rMY6HMIJnMV5xCMBJmuzZEJP9EZfuGAVtuICrqFwLupHGI7nof581I9zCMcHfEJIfr7H9gJmCcIe hOIiIvAWKTAVNIsNKqIm2sERc7AI+3AM9QsxR+gIJwQiGAdwCuG4htt4DKvCZsmGvCiCDuiCPnBF NOJwDwl4jWR8hdmG65Eb+VEcJVAe1VEPzWCP1uiM7ugDV4zEWExD3SK0uxhjj00YU9wsXrArQbxB t2Xc0QIt0QptkJbUZQqmYQZmYhb8sArbcRjRuIlOJc3SFU/wHOPKmGUS5mERbuA2ipdl/mCPNpiO OTiME3Aqb5ZhWInN2I2zaFKRNuIpktGjslm84ViFewteWITNCMXJqmaJQQoyVWN+0Qz9MRo+WI4V CEI4bqXtMFCdMUdnjMR0LIIfguFdg9e4gviM3dKyI19ts1RCQ7TBThzBUUSiYz3ajKGYgQ3YhRX1 zbIDH6E1MEtRVIWrnVnGIw7P8QKfEduQ16jTiP7AEQOwqjHlIVsT1hMUQkX4NGP9wFFcxGMk4UML s6SijL1ZaqMlusMdU3H1R9YDfIDWithDQ/yMcfBHEHbjDCLwCFprYhWt0Q1OcIMXZmEbTuMa7uMB fsEnWNqYpSyapm0UCA94YiYWYk2b9E0EryMF5rZcg1ywQVV0xjAsgT824gBCEIFXMNoRh6iBuViB lQjASVxFEqzam6UBOiBTB8YVoYhA+470DSmdOK8zc4+W6Ad3ZOrCuoy8KIc1CESAA2sKLuEqkjJ2 niiNGqiJepiEBTiBUORyYh1BKzjAHT4IxkmEIBzReIVszpSJZnDEThzBUVxHHF7CqjtjgYZoi03Y g2CcwqqfmDOkQu/BmtSLZwCaoyOOIRw3kABLb9qK+uiIPhiOdQiE3pfnCaqjEbbjCM7iBl71IxZQ tD9jAXs4YDk2pHEh5nAFd1B5AG1HK3RH3CD6BbMr9WAovDETy3FgMPGHRHxBtiHcK2iJ3vCCH+KQ gENDGVsMGMY6hc3Yh/0IRThu4TaeIQVmN8YBxTAby7ECu5GAL8g5gnhCCVRALO4iBdpIYhm10B6d 0QXDMAqe8MViLEEgghCMi7iMSDxA2o4jOnIgNyqiKhqjGX7Cz3DDKPhgAXyxFhsRgJM4g0hE4Rle pZU3mvUD7eCEwfDAfKzEAVzARdzBIyTBPIY5RjU0QVN0Qle4YADcMRm+CMBxnEYkruAOHuAVXuML crsz7iiOqqiLjhiEYXDDDMzHekTjMfJ48NkCNWCHdnBAVwzEUIzFOMzBcVzDHTzDO3xFXk/mFYVQ BnOxHPfxHC/wBslQvZhrZIM1iqIYquBHOMAR/RGGq2nnj+X5hOKoAg9MwlKsxR08h9U47kPkQUHU RRMEYz8O4iTOIhxmb7P8gKDxHMOoiTx/8BWmSaz/U5hr+E9jPcCYeXw2wGrsxAukouNi4gDD4Yny S1gLMACe8Mce5FnKughHuGIpAuCzjPsPgQjGjuWsQ3iKLyixgnhDMn5D6ErWUjzCc5xaTbzh9hre w1eY1xL/6xk39N5oliEIxH7k2sS6isqoh2uIw2ukovlmYgCbsQ/lAlhvMBVLMnbFyYkGcIAL3LEe O/ACX5BtG/c5VmAbMm8nVtEZPXEc5xGDR/DawVhgNbYiER/QYiftweFd9B1pu+9kwWC4YwYWotRu 2g5HDMZSbMcxXEQqsu4hLoI5BwPgjQAcQThioe1lfFAFLTAS07EUm3AFr/AbrPexpsMBLhiN9QjG GUSi4H7GEPMOcF8gGvfR8CBrOJzRHynId4jPA2gIV0yEL9biAh4jGZkP86zAj3DGQPghCCGIRtru Q9awRTX0wnjMx0ZEIh7voR7leY76aAsn5DtO7KEPhiICMXiKt/A5wTMeQQjBM7xH3ZM8wzAHy7AV BxCP10jLlGuFBmiFnzAIy7ER+3Eab6Ccog8oho74GSMxCUEIQRTuI9tp1jNUhh0mYz5uIh7J0M/w HEZ9tIMzZsMPm7EXF85TJqZfIK6wDXvgcZH3sB6BuIsXKBjOuoeeGI0NOIhX0C9xj6E12qI7RmAi fDAX87EKexCGHBHEH+qhObwwC9txCAlIRdXLzD88sQBhuIEYPEEqMkVyzyEP8qEk6qMjViMAZxAF /QpjjWZwxnCMw0JswV08xTO8R9arjDcqoS46oS9GYyKWIBA38Qq2UdSNkZiC6fDDNhzEGYQiDNeQ iC+4f516sTia+wCtbrCGwAUjsBE7MOkmMYcuMcQ6jt0ixnEVt/DzHe4TdL9LOzEFc5CIFzgTxxqA xEd8j8zxPNPQDB0wAfOQ/bFZCsATUxGOexiUSN+xB8eQ/xl9Rg00wm08wQdoz4kJ9EAQTqDFC35+ wCXEofpL5h9hiMUzmF+x9r3hmYvKqI0vsCRxr6Ia+mEUNuAQLiMWL6G85TMWmqA5OsAFHpiNxQjE UUQgBi+gvGMtRzN4wRdhuIFYJOAzMr8n1pAX+VEK9dABd5P5uQdJSEHXX1mD0fsj84jmn1hHcS6F mEHuVH7GgS/8cQHR0D7z/MEybMBZRGPrb/QX+cUitugHN1zCTSQgCb6KRfyxFyfxBVlUixiaRfIi h26R4vgVFpNFJhgWWYDLuImWZos4YzLm4RjC0d5iESecxnVsy2yRIyiY1SKl4IIRuIxYJOIdfK0s sgsncR2fkSMbbUAVOMMdM7EaZxGDRHxAkR8sUh9t0QdzsQ67cQJPYcpukTwoD0cMhjfmYB/CcBOP 8DWHRbLlpO/WjAdeIhXDc1tkIk7gHGrnsUgrjMB47MBRNMxrkR8RjNNYlt8iW2AuaJGc6IQeOIKz iMZ9TChE/7ATp/EcX5G9sEVs0BL9MAZzsBdhuInHsLKxSFnUQweMxTysxQ7cwDvoRSySH83gBFd4 wh9BCMElPClukfcYZMtxHEQIqpS0SFO4wh2bsQ+1S1mkCVZjK0IRiff4DTalaR8qoQ78ytE23MVT 2JdnbNAHQ5G1AtegCpogqCJjBjVtc3N0RT+MwVTswEFcwA18RdbKlIHycERvjMIkBOIoInAbehWL WKMkqqMn3DAZC3AY53ELT9POq2qRavDANCzFZkTjLl4jBeWqWaQG7OGAejV5jV4YgAq1eA8O6IWF WI/LuA2r2hYpgfboj5XYgwR8wEcYdSxSCOVQC7VRF/bojuGwrWuRivgJrpiG+TiFK3iXsbtfRTSF B+bjKKJgqW+RfCiAMmiItnCCM37CIIzHIkxoYJHZ2IS9eIx3KGZH+9AOThiKKTiI0whFJB4jGUZD 1gOURh20ggMGYQK2IQTvkaURsYJOcEBfeGEm/LAYS7ERB3EJ3ZtwHqyacr/jJM4jFvGwbsbY4hne 4WBz2okFLbi3EYP72GrPmoNmP1qkDea0YR3CfcTjdVvmC4fa0d526RuiFEUfuGByB4ss6ZC+kfst DOrM2oJAbMcvXViTkc2BeYANysI1Y8P1SZiHRdiANo7EE/rBDauwDbtwGglIQZmuxApsunGfoArs sRoBiMI9xCMVFieL5MJAZ+rDUhzBZ+Tsztjh6HrGbAPz5W+RRsi50SK54byZ/sJuCzGGRQFcj9SM XQ07baPNcAkkLpCwwyJvcGgXZeI24lAqyCKV8Q5fMG83Y4dSe1hfEIhg9Au2yBC8wUeM2Ut8Qt3H +KMF7DM4wAm9MAhD4AGvDGOxByE4hUhcQwxi8R4fkHM/44Mq2ICtWHeAZwD24Qge4DMaHyT+sARB uI57eIPMh1jz0QfrcBgJGbs3eh9O//9T+YT23b/flKwiUzEN0zEDMzErY8+KOfBBWiq8eZiPBfDF QiyCHxZjCZZiGZZjBVZiFVZjDdZiHdZjA/yzpiVVFNmUNX1/jC0IQCC24bevX79u5+sO7MQuBGE3 9iAYe7EP+3EAB3EIh3EER3EMx3ECJxGCUziNMwjFWYThHM7jAi4iHJcQgcuIxBVcRRSu4TqicQM3 EYNY3MJt3MFdxOEe7uMBHuIR4rOm7wvyBAl4imf4Qv+f8/UFXuIVXuMXpGUzTcJbvMN7JOMDfsVH fEIKUvE5rTz8hq/4jxwLf4qFgn8hRv74/l867x9V8B+oq+Af/LXX/C3t+9/gbxm/P173r2jLP7vM 77777rvv/vtpf5D+/p9/N/3Inz/j2zO1/+uMP3737/Hvrv+7f56/HKG/v/fXlPD31Pq3XvP3lvP/ OuefGcX/ijvi773T/tpr/pry/3T823VJ+0/vpL/7t7byX+n7+vSP+/9xDP+ru9n6vzjnu+++++67 7373/e8E//t8/3vP7/4Rf2/8/E+7X/9VZad9Nv7nl2oWPcPvf/Q/UP/Td99e++1Vhb55/ac/af+l 7Yr2OI0q8hw3tPRtmUfpIr5wshXpDb2kSGYk4yv8SonsRmSF9OzLfWqI9MeTmiKJuFRf5Cr6NRAZ hEl2ItPRozHn4mgTkVPQOovkxBN8gHsXkZkY5yAyFSMdRSajSFeR4vDqJzIDDfuL2KO9i4gDvIdQ PioNFamJJKSihJtIBdzEQ+wcLrIXDUeItMKg0SIeqOYpss5L5ApuoYy3SF3o40UsWDdZZDvMM0Sy 4C3yzhS5O0ckATnmixSA/QKR1vBdKrIM9stFOmLsCvoD240iNeC/SSQC+haRbLALFmmCHvtEeuIc rqDMAZGqKHBQpBD8sBSZjohkxaITfI+jISInoFwU+QGLwkWWYM0lkUCkXKauSMYYnzAplvZg622O 41KcyGsEPqTceBGbp/Q/UaTsK5E9r0XKv2MckTdFpFsq443ZWPxZZBPKmRSpjMM4hTd4BwdDkW5o lU0R7x8Usc6jSH7Yoie6FuI4riAVZhtF8mBAEUVG4w7iML2oIjPRpZgijlBKKKKjJmpDseVanMMV qKUVsUIn/ATryooUQfcqivRAQFVFdmF0NUUO4kR12o1XNRVJgk1atuL6ijxBqwaKVG2mSHW8b6FI o5aKtG9H2ZAu1IOZzor44DpiMOQnRdzxoocirzG2lyLHf1bEtbcibrB3UeTIAEUWDVLED8muinxA pSH0Cc7DFemLVTiD0SMUGY/9uAvTaEU64DeMG8P5nowZYrzpw3jGbIIiD7FwsiKLcW6KIhdRc7Yi deCDvXMUybaQsYG+VJEReI6XaL9CESe0WKlIRzzapMhH5NvM/KHNFs5B3gBFCmHnbtqJe3iPc3uY O7jspe1I25ZSwyIswfFTilxAVKgiNcIUWYsd32QNrnxBkZUXFdmELVhxWZE1WBbFmKDWdUXqwzZa kTI4dJMycSqWupH9liK5YNxVxILnyBPHmKET+txTpB9Kx9M+FkB3HHhCOQhJ4Nok+vSW8XqnyJf3 inzFtA+KzPjMXGMQK+8QVFNUmaiqMhkhmiqncVFXxf8HVV5kVyUZn/BrDlUWWCOfKn7YV1CV2xhT SBVvJMHTRpXNRbmuGK8rqrIa2yupchjB1VQ5hk21VNmF07VVaVZXFef6qvTEiAaqjESKnSpNG6lS vJkqpdAdveGJCfBqQX14gudo/aMqHTAF03GvvSrxyNxRFSvMhh+MzqpkQU4HVQqimCPl4wIeYXMP VQKxD4fwpJcqzxA/UJWXuDBYlWj4DVNlCXK6qVIAy4ershJ5R6hSBBNHUicOjlblONw9VNnoSbsn 0G7MwgLoE1Uxw22KKh6YMZUxx/zptAMRM1S59U122tGzVVmM9T6q7McHWOaq4jJPlXHI5qvKD5iC aKiLOI4ey1X5GVPWqLIQBdfy/XpVXP2Zf9zepEocnuE1Km1hPAPo3zZVOqNJIPOEYjtVsf0mO6z9 QVXaZ2RxvYy1x1XZgqunVIn9M1lWZ4RyHSxRtAGVUQuto1Vph8U3iBc8jKUd8Lmnyga84cH+FkOS VBmFOViYloXzM+P4hWvgj6ivqsQgkk8yUZigajIDN3VN4rA6kyaRaJNFk3ZZ0rNbrkfB7Jr0zaHJ dGvOx/PcmhTNo0m5fJpYFdBkA/xRorBGfGsyoqgm3vAqrckkjC2jyXjsr6LJYbhW1WQwFlbnuurp 2RzTMjkOqKvJrPqaHGugySOY7DTJgXKoguiGnJumrSYP0LSDJi3wEK9RvJMmttiP/F00Oe2gSRim dtVkJpK6pWfv8+5N3zG4nyZu6NpfE2eYB2iSGWcHanIeIUM0OYOziMCPwzTpiPpumjTLyKTXFUGj NeJYkzHumnhA9dDEQJ8Z9BVhMzW5gHtzqW8+x3w1scZqbEDJhZpUR2/0xSbsQZNV9BGh62gDrq2n bH/mZrMmHXAVT9B8myYtUXOnJnbYs0uTo4jYr8llxCAW2gFNdLQ+xBzDEV3hg7nodViTn+GKwViH 9Ug4kr5b0ecT6VnnfOGHcaGMLT6c5cNkmCYv8QZNImg32qIdvDAWDpc1cULeK5rkQ3GUQDc4ofxV TSqgFmpjCIZi6TVNlmEjNiEO9zDiuiYjMRGTsAUByBGtSQEcuEn7Yqj3jiY9cPWuJrdheaRJJuRC bjRHC4yPJy4wBz44izB0e0z74IIBmIf5+AjlCe1K0GQntJeaxEN9pUlWtEXN15oEvtFkO87DJon+ YD3eQH9LbGIWVmE1ruAq4vEYE5LpI+bABwdxCJ6/Mq4o9FGTwiiDsqiJWujyibbjV3yEnsI9heqo gcmqLtPxAr9quui6LmsMXb4iNZMuPTPrMgAX8AqZsupijfY5dOmK8Jy6RCPEWpdQbM6jyzaE4Rzi 8Rhf07YMzqtLYdggGMeQNZ8uRbERm3AQh/ACL/E1bdvg/LqULqRLGVRHDfRGH9Qqqksd3MFdPEUi 3iMZmYvpkgV5kQ8VUBHzi+uyCKVLUC5qoCb6oT+K2epSGyloVUqX9RhSXpdVFXRZjQBsxTVch0cN XcZhT03GBM/xAr/iIwrXot+YAz8UbqBLSWyw02U7ujXRxQn90B8LsQhjmjIueIwczbiuOeWgHMqj IzrhOMKwsAXl2NOX1rosR0QbXW7iVFtdzmJ3B9qIoziGBDzFxY60E3addBkMj866eGIapiMQ25G7 C/XDwYl5wktnXT7gfg9dHuA5XsC2J/2DuRdzBG9sw/6fdTmA0ziDp0hEl9669ECJvhzHXRfmayAx hfN45arLa3zEJ9gOpnyYh1A+vLEN+4ZSB07hNJLwFj2HEccIHUlcIhs/+OZGGzigDwaOSs9muCEj m6FVRjbDwRlZDNd+k8XwCRL+TPbC37MW/p6t8F1GxsLfsxX+np3w22yEOzOyD6ZlHryL+wgYq8vs tF3epuiyYkp6VsGZGVkFV32T2c/uCrGD/TiPYleZe8xH4DeZ/YZgwjcZ/X7P5NclI5PfY7zARt0k WzIy+YXBxmSSIt9k8PPCPCiGSfSMzH2N0BL9sAabEIZzaGY2SQtzema/n7ASq7AGu5DZYpIsmA9f S3qmv90wZTKJkelPGf4q/CHDnz924yGSUWMObfgm498arMVVXM/I/JcbxVESNeeapBbqZGT8a5lq knh4fzGJD37P6DcPSzG8gCEemFDQkMmYi7OFDInEDSwpbIg/HIsaMhJSjK/oVIL3EGVrSHxJQ14h CYNLGTITA8vxOiNTn2tlQxLxFnbVDGkMj5qGtKhtyP9h707goq7zP45/QZgZSAHxAC9EBCxuBJFD BeUQVFTkMNQ0EUSUQxgu7zIr8Spts9zMytTIoyjtUitzNbfNSikrNbfUDtNaj/KM9P8aftCwMp99 VJu7///jLz6ezfD7zPf8/eY34z4evvelcJ3aij19dOoSXu/L+PDup1PDkYPn0DNap5LQvSFRL3+A TlXgRLyOvwfoVG0C80XGQJ3KRA4m4cIQ+kXCUOaMOjw4TKfGpOhUFgaN0Km0EebkvFIEZjCfTJ16 B3c1JOc5j9aptghACCYjHwdxGOdxGa3G6FRrdEV3+CEY6+9gHeg5lvboNk6nfJE3XqemID9bpx7I 0amlKMpl/IbEvWewBYXP6pQR69fr1GZcRB18N9Efnqlh72q0RL3ROPC6lqJXcF2CnvEDLTkvAKEW 0vMerdWpVXgKNU3S83p9qOPvqzpVhQV4FKs+NKfpNabouR7Qqc4HzGl6K7GqSZpep49Ze5MUvbtx PxZgBaw+0Sk90pGB57EFpZ/SHqdxCSmHdGpEk1S9dw+z/9j/GecSh/AtjEd0qgwzcQ+ewH7E/50a /D5nbeiHBHyBbl/o1GA8+YU5hc/zqE7diikox91Yhm9wAgOPsdZj5lS+K7A9rlNOaIuRyEIBZuND fNQkrS+8IaXv87O0x8pzOvU4vsS3ONSQzvdIQxrfwIY0vugLOhWHsIs6FYHAS1xv2Ida/OWKTu3G +IY0vnU/61Q1TuNsQxrfHhQ2pPDNw3w8jqdQrLTUvcaUvV4GvQozaKl6BxFtp1f97bTUvKU4he9h a69Xekyw15LyzrXUqx9aaml4LlAOemXdJAWvGzwdtfS7Iqx00tLvTCl3tq21NLuM1lqa3ct4B92c 9WokMp21NLv5OOqsJdataKNXa9qYU+iuoYUL4+MxPNKBMTC/o149iKVY3tGcRncQxzqaU+jcOzE/ C6lzh/EZAjvr+f6mpc9l4lGs7WxOoduJt/EdznbW0udaIwRhDalzkzEH87ARNdiGN/EB9nXRUulM iXRN0+dMyXPXp801psw9iKVYhpVYi3XYiJfxM/RdtRS6gWjnrle3YZ2Hlj63EomeepWFXE8tdW6u p5YidwYBPfSqNzb4slfI89OrQjyDjVgVqFdP4QS+g38Qa0YpKoLMaXDWwZxnVGNjsDkVzhltezZP hzOlwj2PnXinpzkVbgDiQ7Q0uBdhG0pb5OKhUHMqnEcvvfKCEVV4Hi/gHC4hP4x1YCNqcBhHwszp cRWYjj9jZW8tRe4DuITznsAXOInbIvTKD1MxE2vwLI7hBLwj9erWSHPq3BI8iOfwGjpFse4oc+rc VBjxBvbjMn5CZF/OE6qxAe/ivb5aKt3PGN2P90g/cxrdWlTjB+hiOI8IwhRMw0F8hjpchSmtLgDF WIFbBuiVI4YiBQ/gYWzHW6iDdSxzRTmewPomKXe1+AjncBGRcVxj2IW/Qh+vV/ZIxFCUoxIvYDtu SdAr14Tm6XgTkIN7MN+UkodLuAa3gewDsvE01uFb/IhOiewxRuFOPIa1+BJfwyZJrxySzCl7plS9 vySZU/VMKXpFg8wpeqbUvDODzKl5ppS8+webU/JMqXjthphT8UwpeC8PMafgmdLunmmSdteYcleC 6diMl1CHFsP0KgmDsRxP4Ut8j+DhvN8wB3fjIxyGT4pehWMmZmMlVuEkvksxp+aZ0vF8EYporMfL eBN7UZrGmrEFO9PMqXmmlLwoZGJsujkl72ucwK0Z3DMxGUY8h834AVcQNpJ9RiXuwut4E9/hH4i4 nf5vN6ftmdL13r3dnK5nStH7KNOcomdKy3sLX+F7RI/mfokJyMWzeBFH8S08xnC9oxDFeAVbYXsH 1x4ykIU1qMEZXEToWM4VZmP+WC19711Yj6Md5uJ+nMF5TL2T9xvmYhH2oBb24/XKCSlIxcN4Cn/H F+iexXlBLvKztJS+rTiLKyiewLnBARxCejbXNWbhXryBXbDOYSwMRioW4KEm6X0uE7mv4k5k42ms x0VcQUwu5wD3YhH2oBYxk/gsQhUW4hGsQIc89hbjkY012ICgyVwzeByr0WUK98Yp5tS/GryE0ziP yny9mpFvTv+rg00B5xSDmqQANqb/mdL+PAq1lL8avI43YVVEDQlIwtOoxnF8j15Tuc5wO7IwG/Pw LF6Zak4FbEwDbEz/a0z7+wonis3pfo2pfo1pfo3pfY2pfTZGPveMWmpfhFFL7RtllFP7TGl9Pxi1 tD6PUnNaX2NKnymdb2mpls73RqmWynek1JzG15i+1zR17yn8DXvLtPS9r/ETdOXNU/hM6Xt55Vrq 3kJsxivl5rS9kAruM5iOORVa2t4KPIdteBsHKrTUvXMwpe05VZpT9vJhxD1YiLXYVKml7dXiCq6i YJqWsjcfC/AatsNmupayVz1dS9W7iJ+ROYv3PqbO5r2C2ZiDBViIFfizyb1c71iwkOsbzovpD3uX cM7gt5TPLsQgFkkYgpqHuZ9gL97HCZyEzXL2EX4IgOMKrg34IgCJGIxcTMapP3OuYHiM+wdikYBL aLmS36v5voP3d3LfReIuvv+hey3vH8QgFnfgTrh8ynsQIeiFw4e4HtD3K+6JyMRoeH2vVz2QidEo QwWW4iHsxh4cxXH8jGvo8A++K2AA4jEZBbgfC7AVr+MTHIL9aT5n8G0d92nofub6Rzdrg/JEP/TH aIxFJWbghMGgTkFnZ1B28EIYLjsZVB1cWhtUR/RCOFKRgWKU4mMXgzqIH3ERR7sa1Je4Bmt3g+oC d0ShHzIxBjE9DCoWYzEeJT0NqgzV2IC38Q6O42uoEINqgTBEIA0jUYIyPIBl2IjncQCf4iqsQg2q B3wQj0QEphlUb/RFHOKRjKFIxShkN0kZaUwXWYuN2I5deAf7cAyncBVW6QbVCm3QGd3ggwCEIDK9 eUrJDFRdl1JSB6sMg3JEGMLRDwMxGvkoxjxUYS3W4694D5/iCE5BjTQoB9yLKizGcmzAqxZSTrog GP0wAkXo9KSWblL8NOf3eeZew95t/mPSRKQkkWV4bIucHPLrE0M63nTTTTf9P9Did7b5Pe1+bd// TrvrH/8ILdQ/r/lGrf23zuNG9P1b29zI/v9oTc/fr53Ljdrr3/Laf/e6+6PW2uK65//u3vyaPv5T 77v/5LX5334f/CuW5vbfvu9ZYppLyHUsHbvpf6+m5/P3tPm1bkSfv2XON+mtlVKhyjjBjcc2SM6b UFJkLJpY6j6yqCTbPTwgSKkY078uGrvvRdND/fP238bYHn7Tqv65w9MPHGqzQ3seuar6PtcdVi14 agXTY360Vf3jq5319Y/X/1y9ppSNsm523HTE+sB7B1YGdHJ66BGD8vW7/Fwcx2yvOxbKQGc4booz NI05CY6YanotZkKHeWiNRXDBn3ALVsIJa5S2/o1ojy1Ki0fc3tD3/oY5fWmjlFvDc3dVWL8mP0dt rWtaaI+XthnqH4PbGerHUA1jWXp0c9LmbYfYosLSnMJSo2rppA1gGsg0+bS80vwc1bit6lGlftlL 94aDYUpr0q/hd9Nze4wbnhQ3bmB6Utwvs+/P41DMUBE8D+IiSFDBqif8VSzXQgJH/XmM508EzyKo hfI6f14RjwhaRKjeHOtVfzxIzVK//8eKK6AFE73Gj85Ouw52aKUEV9XseowrmlBWwB7Vry051XSM Q/Vn0PQ8oLEeEK5+jHixWBj05o/55798//nD/N7Pipv+7zJ9rzT/TURf/0Fiom9g04z539d2VP/8 72qb/7l2ra0yfYhMUHnKyH+LuOHFqUg1hv+OV6UYo4arEo5PUDm8wsjNOK7+tzJVwJFCXmPkNf35 vZQPpiJem6OyOZKkUtUwbqVB9BjOzbScW2wJAjgSwCuK6v8fMExjTmKUEo7k0Vsxt2Zt9OvHcOdV hbzKnX5zOFJa//rc+tGv7yWAm7xp/FhmME4lM7skPg5Ms5zKn3xeM6F+dXmMUli/osa1JtfXTOs1 YiJHx6iR9avK/mWVRWoEMzDtVTmPJWoaPRhpbfrNvb6V+79cffNVJ97QVcfVn7kp9TOf+ivPTNMr wu+XK6K/SoPpihhBD7F8VKaq2fRk2pl0aokcHcHRuH85SrDFUULozzRKRf1aTPWK+lWm0V8yI/4x ux98Q1fW8z+yfyE3R/ndo4y3quJL2BttMz50Utcc//mPlUqedL+qjfDMvr5iqpVY1amtXZfXWKpF ZwVYSe0utD5u1XnqqpJrjtd/K7FSXWy8rFsrOxtL7dx1Xtbu+wr7WKpVZZe3WG29qMRS7YPJ82yk 8S6HbrOR5ukdtc3m5KhLuy21+zx2r400z5SJ+8XajJaf2tTs/eIflvqcUeRpu063JMhSu+1zetlK 87xU+pNO6nNJaqxeW0Pzdlt7J+mldhcjRupdhDWsz/pJL83ljZFxBqldmc8Hhpd3nfSyVGvj39lO OkfTjDn2MS72cy21W9q1wl5aQ/HoSnvpPFjN2XWLVBs0I6yVVKuLL20ljReSF+kg1bL7RztIe9a9 b4aDtGfjrfY5SPsy0PG0w65l95VaavfQNHdHqd0V4x6x5nWbjZO0hrQ2CWLtqMtZJ2l9VbNmtpbG u+jZw1mqTaoY7Cyd9/Bp1c7SOWrl1K3NjlfSbC3VLhX4tJHaHUmLayPNpXbM38Va8pikttK+uMYY xdok2zVt3y7Md7JUc8pS7aR5PtA5qp2012V2i9tJ85zn8JpY29XHr71U+zD97fbSXJKVvYs0l4uJ h1zE90qbiy7SeBOdvF2l2vq2t7nOrcuwbz6eUke8ers6nNg+x9Jc9nrc7irNJWvQA+J4n/sO6SCt fWZpdQepz7emXO2wpMWFOEvt1gbGdpQ+NzNcLnSU+hxWNL+TtNcnc2s6jT1vv9pS7TtddefZOfPy LdX6Go93ltZ+eshQt8onlkRbavfBoCw36b2ZFVPkJq0hM2ymmzRenxynrtL6amNWd5Xa1fRNddfm 0ry20ne2+/CtT6Za6nNT+x3u0jzbJXf2kMZbFRHiIbVL9BwktvurT4qH9Fl8zHWLx4v+k6ss1SbZ 6LtLnw8nS3Z3F++7nbp4SrWc0jixttN41FMaL1B5eknr+8p6gpfULrlsoVjr3eqCV+GCY+MtziXv sjhebdJPYu3FlDbe1Yddd1iqbQq5zVs6f1f75nlLfS7xu89buhccyFsotqscsVocb/ekGu/IymU+ lvp07v6N2O58/4IeUu1gZUkP6b35QuY9t0rtQv3uvTX7iSctzmXfLL2P1C7KprWPNN4QBw+fM+6j 4i3VQsK9faQ9y7Aqk8ebssxHu3ab1zwmP+kjnaP12U+LfVaUfSbW1rTz9pXeK0WGcb7SdV3azuh7 8vyqOyzVjJGzfaXxhsw56ytduyvdL4vjbaks95POg/sdHfylNXSY1NFfOg+tZ3Xzl/4OZFc8xn97 9taJzftUyivGMWDon+aGWRrvQqt7AqRz5Oa9OuDB/eWnLNWSE3sFSu22RGcHSuvb4J8bJK1veKpt sFTb5DQ8WOqzW1Gq2O6+sFnB0jw7dZkTrJ2/5u26JswLlq6J6uk1Yi00cGewdN432ozuKV0va20X 95TWcGLYFrHm43aopzSXxa2eDzk5a0t7S+PZ9TgdIrX70M03dMnWuP2WalfiR4dK5+HHyam9HIX1 XbRzDJPWkNBd11v83AxP6i3Nc1Te5nBpP9/MuRwu9WlwLYmQ5jKo43ti7a4payKla2lRuiFKquW3 f1KsLYrcFiWNt7jr+1HS+j6rXNdH2pcNRZv6eJQnLLfUriD4kz7i+cs7LPY5Nc6urzTP1fEjxNrm W5eKtQmtXu0r7cvBoW79pLn4T2oZLfU5w7k0WurT2mOO2C4k+71oaV/u86gV+5xSOCpG6tMlsU6s TS9M6y/1ucmQLtZ+CH+0v9Tn2gFuA6TaHOf3Bwzyj5lmqc93I44PEL8TJTnGiusrcY+V9mxx2TCx 3aJuaWI736KpseI12HJZrPSd/aOup+Kk8c4G6eKl2icVi+Nv7zF3maU+q/ThCVK7v0WtSbjzpWUh lmovxG4Q2yXrOw2U1tC74IeB0trD3M8lSn22GPVIUvg3y64271Mpfcq2JOn72Y7BLQdL11mPKZvE WorzN4Ol87c+yGeIdM8aFD5/iPTZuDtq0xBpvDtv2Zwsrf2tHjOHSrXj3svFWlXlgaHSXMpjnh0m rSEoLXe41O4W/8nDpfGOdCgYLu1Zq8zK4dJ4xwa+NVy6Jvb3/zhFGm9F1OIRUp8/ha4ZIbVLCtw5 QjoPs1P2iO16Fz+eKrXrH/iJWIvveD71R49z31uq7S6ITJP2bOKwqjRpLg63HRZr3+WWp4v3AsPD 6dI8H3e9kP7xeztqLdUO9HHMkPosDfTIkPo8py8U2+V6lYi1ZQPKM6R9KSxeJ46XkrlVbNd6kv1I 8bMxYNxI7X8ja14LGHpGbLf9f9q7FqioqzR+Z5gZBpGngg8UFBEFETVUQDQkEZVARDFUNB7yUoSR l4ACtie2NNdSW3tsHnNd7Hhw3Wz17PbQNtse1pYZ1ZaVW+rR2taTWopPYO83M8D3wVxmgIH/DHLP +TP8uHzffX333u9+//9/fl7HlojKW6q8tURUz01OtUsrg9S3DOXZpw5aJpKr03guE9Xlc03UMlFd nlJ/sEw0V9KKXJJEclsyQ5NE5fX3WpwkqmdD5Zqk6MAjuYby8hR2y0VyaRGnhXm1oReXpwy/+aGh vBi7/BWierov37JCeD4qfn6FqF+OLXp/hahfXl98+OGGXXUGYxejcoOSReXtsklOFq11f0tITRbt m185rksW1eWF+GvJorYrR09PEeUdiHxWmBc55qIwz8YnIVVUl7/EVKWK2n43/nGhXGMqSxPl/ff+ 79JEY5Sc9/LKx4b83uA9vm1eE9JFcoXTvk4XjUN83oV0UdtXVLCMqOu1OwzlLU3JzxDpvLiAZYp0 ytwfzBTG3dR2WSK5+oQ5WSJ72RGakyUahzPOHtlPPHjS01BeaUxjtkju7LCzqx7w+NxgfL5ycNxq UV32K+1yzk3bkWMo777gZTnCOFjUZzmitj/rV75GlLdEeX6NqA0HwlS5Ip/2qM+6XJENvlhQniuK kZ2bdCFXZGe38yPyTs1477IhuavDL+d9X7Cw2pDcbu9beSIfLDxiokbUZ/dFHdCI+uXH4ac1ovZt T5SvlWnb0FZu6AL/tSK5et9/rr142PG4obz4RId84fkvrlKY11B2NF9U3hfJAQXCOTYqvEAkNz85 Qyj3euCcQlGfuah3FYrGNilsUpFIzq/IrVh4PloaIMxbkfIHYd5Jv8R1wvv2K0tKhPHI+6+XCPtM 8XSpKO+K3ZlSUV1eSbpSKhq/k/2vCfN2Rt4qffiE6jVDeYuHuZeV12YbWJcYq4mPLfMvf6bYkNyQ mItleyYEBhjK+83SG2WiNuQURawX5X0QsGe9qK8nr/vzeg/BXBmz7th6UX/WqE4Ky0uf+70wb1Pw HWHeM4Ndy0Xr7sG8qHKRTbxWMq1CNEb9MucI8+qWPVohqssTPjsqROWF9D9RKfTryi5ViuT+mHRd mOfmar9R1PaSaf7CvPvt394oWuvgpYZBrf/Mk/1gxpyqsmUuVc81uL2nZLJsmephjlM4jovmax2/ NGO5+N+vgAqFVhFNNu2o4KLwUoIfk1ZY3HLGXPjVIsxYCr8MtJx1pXy5UPiSwqVqYr1W+JKCC19S pHCsFw5k7Zd8St5c8ik5Fz4l746Wd6nnxS2Hyutb3lx5k1tuQsldEjbDVBG3vJ633EbX8npoeT1v uQ1teTdZuxkqb8Kw3bvrjKx7uq1npqoZhk26CSv1bLdqm+/W7bFnNqluVWE1VmAZHdmlJnTTKmCC FXbTEtJnwtrUjgozDUEvmDlSn1Ok9h+k70K1VqBtL/TTqvCwcam6cFerwsOGq/CwSeF4ilo2K3qg TgP0oVZDm29rME0DiIE7KNdrUXZKi1KvJZDrUTZpsu2MJlukKZDXrrletnad0GbXSltgs8VpNTZ9 qwPSGMLPxyfuaDWGwPk4hJ+PT9xp0WhvQGMgbzPW6tBhrQ4CrYFMRTWjSItpmp3a0RzIe5tqd2ml fY/SpSrltlb7HiXXvkeZwnGLdhcj2gOZ2sg62yVvrSfnudQOf/tdKDzqWcY62+ny4etUDJVvRFjG xutLlHdU1IaNZWbcpDsZ2Og126OUThIo6g7f0GrWLMuoRRdDsl2awVYa17Pq0Ix0lRdbGjgyektr dmTMHw6VWsV4C5r1lhvdMKkX1J1SoeIqVDoVeRYeILEM988EJ0jK9utPnx0VlumFpDfj7nKBpPY/ e8b0uxhY7qazR8+s4uMl7j6pvZhOe63tR/R+5sKuOuGfQfhnLuxa3xJR0elQ6HQIYnrGdChYS1RG p8dwVM+YHhXD0Z3243rGdKlZ60hRc90MRvaM6evXRp+i+cTQ2dhef4M6la30djy65yjUq2qtu8Px Ped2ddu20d/RCJ+rUf3qljJY62TyedlK78Ld6zdPpT4ndN61ude9E0s/7ZrchZYdphvbqFWxjel7 YWyjOa1At3F2SrjXPAJ2r0+hbto5u1u4F1heJ+7IyfRCveDGTi+wfsvoSKueRpYb5bWCBdTS2281 9zmt+o6XGbqwm96e6AVWaGXbmdSvwXSxCaLQp64JWbwJz+uakAVNyOJNeL7JK1LoRNtEPI2IGnt8 0Yi4Kc8tGul/Ux9YNKKmI08q6lQZjgxqOv6IohF1nXk20YjKzj6UqFNrOGSpMe1pRBge894Qa3+K MT4/GDOfz2ClN2R6gZ8ktZ9g1YEOS6y81B6qqp1aTFUzcw+B1FNQmnNWFx8g7tUxdqmHrmc8+16w 9Ui39VrivtHVG3wW3u1woBBX3vABwsCTh1YdVjS7cHt77RQL2mvhZ8cHH5X/poR7bfsjB6dBvXDz adDCVntpbNZMjxobarl5XEyTHeUuha/6XC0zqbBSb0EaYdFuK+35wOQZZ6EuVk/W3zJq0UPfOyZz 4EXxy4ZfCn41NDY2wtWX7o3UoRV7Z4vx7ATj2Wnm5b5LNt9p4S5GdCx90bKauIZ0/loXX02RC4RN vQUkbyNopFizvZBsuQ5DTzbBEg9aVuBfS9nzvd54+06ZkKzGkC3DFqVbSNq/J9POC9ntv9x4nAuH 64SPg/BxLhyOXtrTDb1Wg+DVRmMaTPu6MmNaTP+6MsPd0dmvKzOmre/ryizj68o6GcQ2w3uQvWBt l8vbCutc65uy5heiboLwTRm8ENXSc73maCZ1PEm6CLBVH0qtNPYtTRjGDBM2jevY3NjYiMVbY+An xhh4uDH+KeuQB8bAcYbxkwGP+WIcn/mpAmPgPcMYeKIxBk4qjIE7CGPgt8EY+Dkxlm18h2zbl2Pm e2IMPN8YA9caxm8mRqoxBp49jIF/FGPgCMMY+NwxBh4mjIGXHmPg/sUYeMwwBv5DjIE7FOO3C8/6 YKxRJxP9wFONcfSGqdj/YKNmPOSIcWzxltEYA2clxsDBhnG2wnYUxsAxizFw0WMMHEQY3whNJI4g cLVh7Bv2BrGfC/KVpH4uFSPHY3xoxqIRGAN3LcbA8Ysx8BZjDJynGANnPMbZJQ+6Ynw8p2EIxsBT ijHwCmIM/EUYA580xmWFGf0wPl1aMAZj4FfDGHh7Mf4kOo3Y+5HSdQEYA/clxsCZizHwm2EMfHwY AzcvxsCZhfFwxWgSryv2/4TMpw0aH3KGCFO4+GMMHE4YA1cgxpMDfjsW4xP+8d4YA88hxsCxjDFw wWMcy/qRVRX4xDEesWIIsS/g0sU4xtGb1B+44zCuSbtD7Bu4OTGuc3iUrBfA7Ywx8GRhDFybGAOX FMbAaYtxtZsvWQ+Aow5j4D7GGPjYMAZeU4zPDrrqjDFwvmJ80HkBmS/AKYpxnGYT2T+AXwvj72Z9 ROY78LVhDLzDGANXGMa5k74k+xfwG2P85KJZZDyAJx3jnwreJesZ8HBjDDy9GK9x30PsCfgkMQbu UIyB4xHjDa5FxN68V+8h9gRcvBgDBzTGj+RUT8MY+FYxPhKeTtbf78bFkPUqKP1jUj7wv2P82NQK Mp7AT4bx7dlJkzEGTl6MM4oiyf4UlrODtC9bWT0Q45qBfoMxBv50jIFrD2O7/OVkfoanBRIHCzhf Mf5Hxi3ib3y2+D13jFc6vDoD46hRqmCMy4v20/5bNY3sn2kzNWT9/VfoebK/A5clxs5pzA1j4OfF +N3sQ8SfAt5KjI9unELWUwfnkQMwBs5ijM+MDib9CxyEGH9ZsnU2xsCtjfH0DGcvjGOzH8eQbfYY Tsb7qWFhpH3AaYxxSNl+sp96+u4l6yHwJ2J8SbV/GMY3c/1Je88NPkL2gyK3QrL+AXcpxsCdijFw hmJ8azL1P4AHEuOtDi8HYQxcghgDtyfG8a4/kPUEuK8xBv5wjHeNqxyBMXAOYrw+L4H4DzXpfyLz 61SFLcHAQ4rx6fme92PsOuoHYm8PDaobijFwBWO8of9XpH+2e5UQ/yU491fib+0ODSLj85CsmNQP eCgxBp5PjAfPLCTrxevB88h6fj0il/hLpQv3kvbELp9H5P09vybnAeA0xhh4fjE+GORH9H1b+hLZ b4DjFuNzc46T/RU4TTEG/miMb8z9mvgjwPeMMfBKYnxt1TekfOCLxfhm0R0VxoXTKsl8uDu7iJwH RvspyP5+0P2tERh7RVWR/QB4wTG2G3OZzIf96w+R/x+nWUv2l4QBUaS8kuJviT28svRR4u9tDplH 1uOPvJeQ9Qx4kjH+MKw6CuPPPMeR/aphxioynsAdizFwamMM/M0Yfxrx73iMv1i1heg77/sM8Zdn FJ4n69crsw6Q+v0Yd4TY44HxWRMxfneeE+m/rcVxBAO3L8a/2OaR9QQ4gzEGLnWMP1ldReYz8Klj /PaqW+T8FTTgBrHX3017g/hDe2cvJPvp5oryligyTy7Z/RIxrl3+H7Keu8UOI+tFZtxm4v997vW/ SIxHahYRe6udd4fU99eQ58h6eSYhkpQHvPMYA485xpttQ8h4RQ/9OBRj9eACgovttpL9D/iVMZ7A fEj99im3kvEfkj2U+DfAx47xncnVxB8cNPfuTIzrNJ5kfwFeYYyBSxhj4PPFGDifMQ4K8SXz8/DY 7WR8bxe+T9hpU2WniH90w2cM2e+njvhlLsbA04vxpax1xP9Ii36KzPfK+PdJ++f6RBN7eWd6APHv gGcc4wWLlMRegOsY4xT7w7EY187cS/wf4HrHOGt0AZlvVY6vkfHPdPYl9V8baUf6z378arJf3LBz moox8Gxj/HTZCNLfgfOvkPlU53Ke+MNy743E3z8+ppysT19MdyL1Bw5njJdOLSf+7fjs/kTf1Ykq 4j86+n1D5mtO3rKZGL8Qf43sH1syQ8n5Yd8DnsR/HjB+GLnTF2OXT/zJmI1Xyf62yal2KcYNlWuI /vSIcGKfR72OkfPWCBWNZ9zOjyD+Y1BgMunvv8YPIOt/behF4n/vmzCL+FMFsrsYss3p68it2mCH OrI+zHG6TOqbn1RK/K1rqxdNwfjFgnKyHwKHNMbbE+XE3zX2QGRf6kt9qS/1pe5OqW1vFPalvmRl qXGmvL/ekGtKZKymVMZ2X1Ox3df5VadiNfX8auBXI7+Uttz95peaX3b86sev/vxy4JcTv1z45cqv AbbMw41f7ras4lU1S+GnLjaTwWc5FMU/78p1+LZKj5s+HXR/V9nqsFr/OdBR93dnPfbR44F67K7/ nKj/+1A9DtFjTz32bpLXf8bo88fqcQJg+H2O+zYZPLqjslEqlHIbxePEyeRum/4zga1iuSyDFbIR bD7/LOGfC5mG/y2VgR86heuRM6VSJpfZquTNz9ThkMoj8GMRK+MyaVwSohdBvtrS7VUKOSRh6RGs gJefqpWZNQVK4jJ2Ohn9v7QpKZYV8/8v4nJQ3yJe3whe00IGd3WDJ22jwXlGU1PmLF7PYm3ZGQyi WVOa68u7S8HrS255cCPTfybwumbre4exMJW2b1ir1KbGibycPJbF0vWfEB/xZgo2yX7TYHblFO+b bG3FZqvnvXR5yrzM+OqoKIVW75pwGXt1GDwlV20DD5XYOAegw5hM256mNo20YVdIpKsvdSDtU71l e4Qd4QPmOhGGcAiDqBzcibn5Brm/bCTVV5Dolj7pzL+xsSkyodZaYB633gztz6aImZKt5DZSyH9q yO99qbcmmdYSctlaFsdXT3Jn16Tkym0LO3XGJfjmwpeMjpckTh0t39zJmsv/P1BLAQIyCxQAAAAI APCCNClFRUhlpwkAAAAwAAAMAAAAAAAAAAAAIAC2gQAAAAAwNm4xNzA0Yy5kb2NQSwECMgsUAAAA CADvvSYpimEgMX8dBgAADhoACwAAAAAAAAABACAAtoHRCQAAMDZuMTcwNC5kb2NQSwUGAAAAAAIA AgBzAAAAeScGAAAA --ELM971421569-26217-0_-- From azinin@cisco.com Fri, 13 Oct 2000 22:47:27 -0700 Date: Fri, 13 Oct 2000 22:47:27 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt Tony: I think I'll establish an alias for this discussion and will drop it to the lists. > so who's game & when ? Hawaii, next month ;) What about an informal BOF at the next IETF? BTW, I think we should welcome presentations from academia as well. Maybe with preliminary abstract review. Alex. From vijay@umbc.edu Sat, 14 Oct 2000 14:40:35 -0400 Date: Sat, 14 Oct 2000 14:40:35 -0400 From: Vijay Gill vijay@umbc.edu Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt On Fri, 13 Oct 2000, Alex Zinin wrote: > > Tony: > > I think I'll establish an alias for this discussion > and will drop it to the lists. > > > so who's game & when ? > > Hawaii, next month ;) > > What about an informal BOF at the next IETF? > > BTW, I think we should welcome presentations from > academia as well. Maybe with preliminary abstract > review. Folks, this might be of interest. http://www.nanog.org/mtg-0010/igp.html Abstract: Towards Millisecond IGP Convergence Cengiz Alaettinoglu, Van Jacobson, & Haobo Yu, Packet Design -------------------------------------------------------------------------------- On currently deployed IP networks, "convergence" times, or the ability to reroute, is often cited as one of the key issues in providing new services and larger scale. It is, however, possible for link-state routing protocols to converge in link propagation time scales, that is, in tens of milliseconds. Why then are deployments of IS-IS, a link-state routing protocol, not anywhere near this point? In this talk, we present some analyses of IS-IS convergence by showing its behavior upon link/router failures and repairs, and its scaling properties to large networks, both in terms of number of nodes and links. We then explore changes needed in the IS-IS specification and implementations to reach IGP convergence in milliseconds. Our results are based on experimentation done with IS-IS, but some of the findings may apply to OSPF as well. /vijay From mshand@cisco.com Mon, 16 Oct 2000 15:44:18 +0100 Date: Mon, 16 Oct 2000 15:44:18 +0100 From: Mike Shand mshand@cisco.com Subject: [Isis-wg] ISO ballot At 09:19 13/10/2000 +0200, Tony Przygienda wrote: >Following ballot from ISO for the working group. I honestly tried >to convert the enclosed word to PDF first but mickey-soft word >just died repeatedly on me so I just added the ZIP containing >version 2 of the spec and the attached ballot. I know it's >humongeous and some people downloading through slow phone >lines will hate me but I couldn't think of a better way to >get it out. > > >Looks like the ballot is open to the whole working group >so everybody goes ahead and posts input to the list and >Tony & me will summarize to ISO I guess ... Oh dear oh dear oh dear. Firstly, let me congratulate the new editor(s) on a good job of reconstructing the document and applying the edits. Unfortunately some of those edits as documented by the previous editor are ill conceived to say the least. The main problems focus around section 7.3.16. In particular SC6 N10323 DR 15, resulting in the new 7.3.16.4 is complete garbage. It results from a misunderstanding of the operation of the protocol, and requires some intuitive knowledge by the router as to whether an LSP is from an old instanciation. The bug it is trying to fix does not exist and the fix introduces a bug "it shall optionally perform". We should leave the original text. Similarly the infamous table 1 on that page is wrong. If X=Y and P>0 and the checksums don't match you treat the received LSP as OLDER. Hence you return your copy (presumably), but the neighboring router will do the same and treat YOUR copy of the LSP as older and send you its copy again etc.etc. etc. I think we should remove it and put back the original text. If we want to clarify that a bit, then so be it, but lets start from something which is correct. I think the problem arises because the author of the changes has mixed up the actions taken on any old LSP with those to be taken on your OWN LSP. I found the following other problems in a quick scan through the document. I don't guarantee I have found them all. 2 Normative references. These need updating. For example ISO 8348:???? now contains the text of add1 and add2. They are no longer addenda. most (all) the items referenced yet to be published have now been published (I would hope:-) There are multiple references to 8348 add 2 in the text which should now be just 8348 6.2 just above NOTE3 ex-changed shouldn't be hyphenated. 7.1.4 according to TC1 the first sentence should continue "and the rules stated above in 7.1.3.1" Figure 4 in the DSP box it's should be its 7.2.5 bullets (c) and (d) have gratuitous space between them 7.2.92 two (new) references to attachedFlag should be in a sans serif font (to comply with the typographical conventions described in clause 5 7.2.10.3 typo Interrmediate Systems reachable 7.2.12.3 bullet (b) "Otherwise, the level 2" (should be level 1) 7.3.4.6 Although this text is what the TC says, it is somewhat misleading, since it implies that it is reasonable to not re-issue the (now empty) LSP and just let it time out. This of course is quite un-reasonable, and the text shouldn't suggest that it is. 7.3.6 last bullet which reads "detection that other systems(s) hold a live LSSP which have been generated in a precious incarnation. This is not strictly something which causes the contents of the LSP to change. It is rather an action caused by the normal operation of the update process and causes the LSP to be re-issued with a higher sequence number. I think it is misleading to include in here. If we HAVE to say something then perhaps something like "receipt of a copy of this system's LSP with a higher sequence number than that currently used by this system" (could be made cleaner..) 7.3.7 "point-to-point" etc. This is all confused. The original DR10 was trying (I believe) to align the nomenclature here with that used in 11.3.1 for circuitType. I agree that point to point static in and static out are all dealt with the same, but the new text doesn't really work. Its needles on a pinhead stuff, but someone may care... 7.3.8 The new text introduced by DR 11 talking about adjacency usage level 1 and 2 seems odd. MY paradigm was that on a LAN circuit the L1 hellos said L1 and the L2 hellos said L2 (not L1 and L2). We form two separate adjacencies, one L1 and one L2. If the L2 contains L1&2 then following this we would end up reporting TWO L1 adjacencies in the LSP. Its all tied up with the coding in the packet formats, which also got changed I think. The point it, if anyone cares, it should all be made consistent. 7.3.9 first bullet partitionAreaAddress should be a sans font 7.3.12 last sentence should say "set the SRM flag for that LSP" rather than "transmit the LSP" (as it does for L1) 7.3.14.2 item (e) This is something which SHOULD have been fixed, but seems to have fallen through the cracks in terms of getting into an ISO TC. SC6 WG2 N523 correctly suggested that bullets 2 and 3 should be replaced simply by "discard the PDU". This fixes nasty purge storms which have occurred when flaky links perpetually deliver damaged LSPs. 7.3.15.1 a) 3) ...from the circuit of manualL2OnlyMode, would read better as ...from a circuit with.... 7.3.15.2 ditto 7.3.16 stuff I've already complained about. 7.4.3.3 3rd para typo in the original "and the NPDU originated from the a local transport..." delete "a" Also I think the last sentence is now redundant. We have no concept of the forward "procedure" return true or false (I think this is a hang over from my original DECnet spec!) 8.2.3 a) "cause ISO 9542 protocol machine" would be better "cause the ISO 9542..." But this raises the question as to whether we should be getting rid of the 9542 baggage of sending an ISH first. Most implementations don't (I think). They certainly don't wait for it. 8.2.4 iSISHelloTimer should be in sans font 8.4.2.5.1. f) see comments on level1&2 in LAN hellos 8.4.6 new section in bullet b is "outdented" 9.5 Intermediate System Neighbors neighborSystem type should be in sans font new variable length MAC address diagram should have a box around the top 9.6 NOTE 59 - weird or what? Having the manual area address in the L2 hello might just be useful for management reporting, but isn't used by the protocol. Not sure what the edit is trying to do. ditto, box around the variable length MAC option 11.2.1.1 resettingHoldingTimer-B is outdented 11.2.5.7 ISISlevel2Broadcast -P PAckage. The defect report has become garbled. What it was trying to do was change the "l" of level to be upper case. Hence it should read linkageISISLevel2Broadcast-P NOT ISISlevel2Broadcast-P. It also needs correcting at the bottom in the REGISTERED AS clasue. Trivial I know! Annex. As far as I know this is no longer required, since the changes DID get made in ISO 10165-5. Strictly someone should verify that, but I'm not sure there is anyone left alive who would know:-) That's all for now. Mike > thanks > > -- tony > >------------------------------------------- > >Telecommunications and Information >Exchange Between Systems > > >ISO/IEC JTC 1/SC06 N 11704 > >DATE: 2000-09-20 > >REPLACES > >DOC TYPE: >Text for CD ballot or comment > >TITLE: >ISO/IEC FCD 10589, Information technology ­ Telecommunications and >information exchange between systems ­ Intermediate system to >Intermediate system intra-domain routeing information exchange protocol >for use in conjunction with the protocol for providing the >connectionless-mode Network Service (ISO 8473) > > >SOURCE: >Project Editor (M. Bartell) > >PROJECT: > >STATUS: >Per SC 6 Prague Resolution 6.7.5, this text is circulated for FCD ballot >closing 2001-02-15 to allow IETF input to the process so that extensions >for IETF requirements can be included as ballot comments. > >ACTION ID: LB > >DUE DATE: 2001-02-15 > >DISTRIBUTION: P & L Members; SC Chair; WG Conveners and Secretaries > > >MEDIUM: > >DISKETTE NO.: > >NO. OF PAGES: 175 > > >ISO/IEC JTC 1/SC 6 Secretariat >ANSI, 11 W. 42nd Street, New York, NY 10036, USA >Tel: +1 212 642 4992; Fax: +1 212 840 2298; E-mail: >mdeane@ansi.org > > > >Content-Type: *unknown*/ >Content-Disposition: attachment; filename=06n1704.ZIP >Content-Description: 06n1704.ZIP From azinin@cisco.com Wed, 18 Oct 2000 09:13:19 -0700 Date: Wed, 18 Oct 2000 09:13:19 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] draft-ietf-zinin-flood-opt-01.txt as WG items John, Tony & Tony, Mike and myself would like to ask OSPF and ISIS WGs to accept draft-ietf-zinin-flood-opt-01.txt as WG items. Thanks, -- Alex Zinin From Radia.Perlman@East.Sun.COM Thu, 19 Oct 2000 19:36:17 -0400 (EDT) Date: Thu, 19 Oct 2000 19:36:17 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Radia.Perlman@East.Sun.COM Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt I've been travelling and fall behind on email when I do, and I'm just catching up. Of course, I'd like to join in on the discussion of optimized flooding. Radia From azinin@cisco.com Thu, 19 Oct 2000 16:46:16 -0700 Date: Thu, 19 Oct 2000 16:46:16 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] Re: draft-ietf-zinin-flood-opt-01.txt Radia: Sure, I'll send the info on the list to the WGs. -- Alex Zinin Thursday, October 19, 2000, 4:36 PM, Radia Perlman - Boston Center for Networking wrote: > I've been travelling and fall behind on email when I do, and I'm > just catching up. > Of course, I'd like to join in on the discussion of optimized flooding. > Radia From azinin@cisco.com Thu, 19 Oct 2000 16:50:53 -0700 Date: Thu, 19 Oct 2000 16:50:53 -0700 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] Mailing list for the flooding discussion Folks, Below is the info on the mailing list for the new flooding algo discussion: Messages : messages should be sent to flooding@external.cisco.com To subscribe: send a message with "subscribe flooding" in the message body to mailer@cisco.com Should be working by now :) -- Alex Zinin From jerome@zeroknowledge.com Thu, 19 Oct 2000 20:09:13 -0400 Date: Thu, 19 Oct 2000 20:09:13 -0400 From: Jerome Etienne jerome@zeroknowledge.com Subject: [Isis-wg] Mailing list for the flooding discussion On Thu, Oct 19, 2000 at 04:50:53PM -0700, Alex Zinin wrote: > Should be working by now :) it doesnt :) >>>> subscribe subscribe flooding **** subscribe: unknown list 'subscribe'. **** Help for mailer@cisco.com: From jerome@zeroknowledge.com Thu, 19 Oct 2000 20:32:12 -0400 Date: Thu, 19 Oct 2000 20:32:12 -0400 From: Jerome Etienne jerome@zeroknowledge.com Subject: [Isis-wg] Mailing list for the flooding discussion On Thu, Oct 19, 2000 at 05:26:05PM -0700, Neal Castagnoli wrote: > I'm not sure if your mail message is meant to be a joke or not, but > subscribe does work. You typed "subscribe subscribe flooding," instead of > "subscribe flooding." it turns out i made two mistakes (i) forwarding this message to the list and (ii) being unable to type. sorry about that. From prz@net4u.ch Thu, 26 Oct 2000 20:46:20 +0200 (MEST) Date: Thu, 26 Oct 2000 20:46:20 +0200 (MEST) From: Tony Przygienda prz@net4u.ch Subject: [Isis-wg] do we need a session this time ? It's that time of of the year again. Please mail tony or me with the requests for the agenda (only thing I have now is presentation of the liason). If enough interest, we should probably schedule a slot ... -- tony From m1lu@yahoo.com Sun, 29 Oct 2000 08:17:09 -0800 (PST) Date: Sun, 29 Oct 2000 08:17:09 -0800 (PST) From: newbie m1lu@yahoo.com Subject: [Isis-wg] questions on draft "IS-IS extensions for TE" Hi: In draft "IS-IS extensions for traffic engineeing": "It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 - 2^25)." What does it mean "a single link metric does not overflow the number of bits for internal metric calculation."? Also where does it come from "2^25" in the following statement? Thanks. _ming __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ From azinin@cisco.com Mon, 30 Oct 2000 18:22:54 -0800 Date: Mon, 30 Oct 2000 18:22:54 -0800 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] do we need a session this time ? Tony, We asked to accept the flooding optimization draft as the WG item. If the answer is positive and there's enough interest I could present it. -- Alex Zinin Thursday, October 26, 2000, 10:46 AM, Tony Przygienda wrote: > It's that time of of the year again. Please mail tony or me with the > requests for the agenda (only thing I have now is presentation of the > liason). If enough interest, we should probably schedule a slot ... > -- tony > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From curtis@workhorse.fictitious.org Tue, 31 Oct 2000 12:01:09 -0500 Date: Tue, 31 Oct 2000 12:01:09 -0500 From: Curtis Villamizar curtis@workhorse.fictitious.org Subject: [Isis-wg] draft-zinin-flood-opt-01.txt (was draft-ietf-zinin-flood-opt-01.txt) A while back Alex wrote: Folks, The new version of the flooding optimization draft has been submitted to the IETF directories today. So far, it is available at the following URL: http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-01.txt This was followed by some thoughtful discussion (as opposed to recent MPLS discusiions of VPN and Optical Bundling :( ). The draft ended up as draft-zinin-flood-opt-01.txt. Apparently the internet-drafts editor could not find the zinin WG so dropped ietf from the name. :) My comments relate to (half joking about this): We could discuss this, actually, with the first question being "do we really need this" ? ;) I don't want to give anyone the impression that I don't support this work. With the kompella-bundle style of link bundling in which the component links run individual IGP adjacencies this is needed. [I'll also point out that for the layer-2 style bundling that Avici (composite-link tm) and Pluris are doing, this is not needed since there is only one interface for the bundle and one ISIS adjacency but multiple instances of SONET and PPP which scales just fine. Interoperability is good so we'll allow bundles to be made both ways.] My question is if we do solve the bundle problem in a neater fashion, whether we need the zinin-flood-opt changes to accommodate full mesh, or if we can also solve that problem through some means that is neater than using ISIS mesh group. It doesn't seem like zinin-flood-opt addresses the mesh problem at all. In the mesh case there can be exactly one adjacency between any two routers and zinin-flood-opt doesn't address this. We need to look back at how we got into the full mesh problem in the first place and avoid repeating the mistake. We inherited this problem when a certain ISP decided to build a full mesh over ATM and we got mesh groups when it (as predicted) blew up in their face. We now have IGP adjacencies between adjacent routers, PXC, and other fancy equipment. We will soon have FA across the topology (ala draft-ietf-mpls-lsp-hierarchy-01.txt), either for TE scaling or to accommodate optical equipment that doesn't look at the payload. We want to avoid falling into the full mesh trap here. I'm quite sure the assumption that some have made is that we simply don't bring up IGP adjacencies over the FA. Others, particularly our friends in UUNET, have pointed out that if the underlying topology changes it is nice if the LSP reroutes and we see a constant IGP cost of EBGP destinations seen by edge routers that are not MPLS capable (or not MPLS enabled). This makes advertised MED constant and avoids route flap damping headaches (another defensive kludge, this one to isolate BGP brain damage elsewhere). What we need to accommodate the need for less dynamic IGP cost seen beyond the MPLS domain is an advertised IGP adjacency. We could even bring up an IGP adjacency just so we can use hellos (rather than the BT proposed OAM MPLS packets) but we don't want to flood over that adjacency. The IGP adjacency over an FA would have the following characteristics: 1. Participate in the hello protocol. (Better yet do LQM :) 2. No flooding by default. (Might be OK to override this if the flooding through the PXC or whatever is deemed to slow but proceed with extreme caution and this should be the rare exception). 3a. Advertise IGP adjacency (if hello is up) but no TE parameters if we want constant MED only but don't want hierarchical LSP. 3b. Advertise IGP adjacency and FA with TE parameters if we want both constant MED and hierarchical LSP. 3c. Advertise FA with TE parameters but no IGP adjacency if we want hierarchical LSP but don't care about constant MED. I think discussions so far are leaning toward 3c, but 3a and 3b seem to me to be more useful for ISPs. The above would be a good thing to have in a document somewhere maybe draft-ietf-mpls-lsp-hierarchy-01, maybe elsewhere. It would be nice to avoid the full mesh problem and fix the cause rather than refine the mesh group bandaid previously put over the problem. Documenting this clearly might deter network designers from falling into this trap (again). [Not that it did the first time.] It would also be nice to do bundles right rather than put the zinin bandaid over that problem, if we're not too wed to doing one IGP adjacency per component link for bundles. If we are wed to doing bundles "as is" in draft-ietf-mpls-lsp-hierarchy-01 then draft-zinin-flood-opt-01 reduces the inefficiency that we introduce by requiring one adjacency per component link. Curtis From azinin@cisco.com Tue, 31 Oct 2000 09:35:31 -0800 Date: Tue, 31 Oct 2000 09:35:31 -0800 From: Alex Zinin azinin@cisco.com Subject: [Isis-wg] Re: draft-zinin-flood-opt-01.txt (was draft-ietf-zinin-flood-opt-01.txt) Curtis: [That was a long one ;)] Yeah ;) "-ietf-zinin" was "-ietf-ospf" first, than I had to change it to an individual submission for some reasons, so I confess, I forgot to remove "-ietf"... So allow me not to comment each and every sentence in your message and address the main points you bring. 1. You support this work. Thanks. ;) 2. Full/dense-mesh vs parallel links in draft-zinin-flood. draft-zinin-flood does not address the mesh problem and does not claim to. I hope you understand that the two problems do not have to be solved with a single approach. The fact that the draft solves the second does not mean we're not working on the first. However, the second problem is screaming louder, so it makes sense to address it now. 3. Do we need it of we do bundling in a cooler way. First, let me emphasize that the approach in this draft is not specific to optical networks, so you may have parallel links btw normal routers and still not want to do any type of bundling (just because you don't like that "right" bundling approach, or whatever ;)). Second, even if bundling is used in optical networks, you may have a number of bundles, each assigned to its control channel, and there maybe more than one control channel btw boxes, so you hit the same problem. 4. FAs, etc. The concept of FAs includes the possibility for it to be announced as native IGP adjacency, and even without Hellos being exchanged. I actually do not think we need to exchange Hellos. Just recall how VLs work in OSPF. Alex. > > A while back Alex wrote: > > Folks, > > The new version of the flooding optimization draft > has been submitted to the IETF directories today. > > So far, it is available at the following URL: > http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-01.txt > This was followed by some thoughtful discussion (as opposed to recent > MPLS discusiions of VPN and Optical Bundling :( ). > The draft ended up as draft-zinin-flood-opt-01.txt. Apparently the > internet-drafts editor could not find the zinin WG so dropped ietf > from the name. :) > My comments relate to (half joking about this): > We could discuss this, actually, with the first question being "do > we really need this" ? ;) > I don't want to give anyone the impression that I don't support this > work. With the kompella-bundle style of link bundling in which the > component links run individual IGP adjacencies this is needed. > [I'll also point out that for the layer-2 style bundling that Avici > (composite-link tm) and Pluris are doing, this is not needed since > there is only one interface for the bundle and one ISIS adjacency but > multiple instances of SONET and PPP which scales just fine. > Interoperability is good so we'll allow bundles to be made both ways.] > My question is if we do solve the bundle problem in a neater fashion, > whether we need the zinin-flood-opt changes to accommodate full mesh, > or if we can also solve that problem through some means that is neater > than using ISIS mesh group. > It doesn't seem like zinin-flood-opt addresses the mesh problem at > all. In the mesh case there can be exactly one adjacency between any > two routers and zinin-flood-opt doesn't address this. > We need to look back at how we got into the full mesh problem in the > first place and avoid repeating the mistake. We inherited this > problem when a certain ISP decided to build a full mesh over ATM and > we got mesh groups when it (as predicted) blew up in their face. We > now have IGP adjacencies between adjacent routers, PXC, and other > fancy equipment. We will soon have FA across the topology (ala > draft-ietf-mpls-lsp-hierarchy-01.txt), either for TE scaling or to > accommodate optical equipment that doesn't look at the payload. We > want to avoid falling into the full mesh trap here. > I'm quite sure the assumption that some have made is that we simply > don't bring up IGP adjacencies over the FA. Others, particularly our > friends in UUNET, have pointed out that if the underlying topology > changes it is nice if the LSP reroutes and we see a constant IGP cost > of EBGP destinations seen by edge routers that are not MPLS capable > (or not MPLS enabled). This makes advertised MED constant and avoids > route flap damping headaches (another defensive kludge, this one to > isolate BGP brain damage elsewhere). > What we need to accommodate the need for less dynamic IGP cost seen > beyond the MPLS domain is an advertised IGP adjacency. We could even > bring up an IGP adjacency just so we can use hellos (rather than the > BT proposed OAM MPLS packets) but we don't want to flood over that > adjacency. The IGP adjacency over an FA would have the following > characteristics: > 1. Participate in the hello protocol. (Better yet do LQM :) > 2. No flooding by default. (Might be OK to override this if the > flooding through the PXC or whatever is deemed to slow but > proceed with extreme caution and this should be the rare > exception). > 3a. Advertise IGP adjacency (if hello is up) but no TE parameters if > we want constant MED only but don't want hierarchical LSP. > 3b. Advertise IGP adjacency and FA with TE parameters if we want > both constant MED and hierarchical LSP. > 3c. Advertise FA with TE parameters but no IGP adjacency if we want > hierarchical LSP but don't care about constant MED. > I think discussions so far are leaning toward 3c, but 3a and 3b seem > to me to be more useful for ISPs. > The above would be a good thing to have in a document somewhere > maybe draft-ietf-mpls-lsp-hierarchy-01, maybe elsewhere. > It would be nice to avoid the full mesh problem and fix the cause > rather than refine the mesh group bandaid previously put over the > problem. Documenting this clearly might deter network designers from > falling into this trap (again). [Not that it did the first time.] > It would also be nice to do bundles right rather than put the zinin > bandaid over that problem, if we're not too wed to doing one IGP > adjacency per component link for bundles. If we are wed to doing > bundles "as is" in draft-ietf-mpls-lsp-hierarchy-01 then > draft-zinin-flood-opt-01 reduces the inefficiency that we introduce by > requiring one adjacency per component link. > Curtis From Alex Zinin Tue Oct 31 19:16:07 2000 From: Alex Zinin (Alex Zinin) Date: Tue, 31 Oct 2000 11:16:07 -0800 Subject: [Isis-wg] Re: draft-zinin-flood-opt-01.txt (was draft-ietf-zinin-flood-opt-01.txt) In-Reply-To: <200010311849.NAA22759@workhorse.fictitious.org> References: <200010311849.NAA22759@workhorse.fictitious.org> Message-ID: <0469.001031@cisco.com> Curtis: >> 3. Do we need it of we do bundling in a cooler way. >> >> First, let me emphasize that the approach in this draft >> is not specific to optical networks, so you may have >> parallel links btw normal routers and still not want to >> do any type of bundling (just because you don't like that >> "right" bundling approach, or whatever ;)). >> >> Second, even if bundling is used in optical networks, >> you may have a number of bundles, each assigned to its >> control channel, and there maybe more than one control >> channel btw boxes, so you hit the same problem. > My understanding of LMP is that it is moving toward one control > channel for as many bundles as exist between a given router and PXC or > PXC to PXC (I should say network element to network element that > sounds so ITU/ISOish :). This would also mean one IGP adjacency with > the PXC for many bundles. Not exactly like this. We are removing the 1-to-1 correspondence between the bundle and the control channel, so it will be possible to have one CC for more than one bundle, but there will be no limitation on the number of control channels between two OXCs. > The point is that we could do a much better job of bundling and if we > did, the zinin-flood stuff would be a good optimization to have handy > but would not be needed as a result of a bad job designing bundling. As, I think, we both understand, one does not eliminate the other. >> 4. FAs, etc. >> >> The concept of FAs includes the possibility for it to >> be announced as native IGP adjacency, and even without >> Hellos being exchanged. I actually do not think we need >> to exchange Hellos. Just recall how VLs work in OSPF. > You are right that the hellos are not really needed. I did mention > that some people like the idea of some sort of continuity check over > the FA. A OSPF packet with TTL 1 or non-routeable ISIS PDU would tell > us that we really do have bits flowing and not just signaling. TTL 1 will not work in MPLS networks, since LSRs may decrement the TTL in shim header. In ISIS, an end-to-end IIH will require ISIS-in-IP encapsulation, since one cannot expect CLNS routing in an IP-ISIS domain. > For > this reason I think we should reccommend that it be possible to send > hellos. The alternative is to send no IGP signaling at all and just > advertise one end of the adjacency when the RESV arrives. I think this is the current understanding of the FA concept. > Hellos also > assume/assure that there is a one hop reverse path. > A possible problem with a unidirectional advertisement with no hello > is that if the other end goes down completely, it doesn't withdraw > unidirectional adjacencies going out from the down LSR (because it is > gone) and its FA neighbors don't withdraw FA adjacencies going into > the down LSR and we have apparent hops (in the IGP) both in and out. Before using an FA in your [C]SPF, you're supposed to check if the node is reachable via the control plane at all. > Other means exist to get rid of the advertisements such as SONET > and/or PPP detecting the error in an optical path, or SONET/PPP on the > physically adjacent link going down and PathError and/or avertised IGP > infeasibility of the path that the FA-LSP is taking. > The hellos avoid failing to detect a LSR along the path with a bad set > of label mappings. Some people are asking for this (having been > burned by this sort of problem with ATM switches). I see your point. Note, however, that we cannot always assume that we can send IP packets over an LSP, since it may have been established for X-o-MPLS... I would vote for making the LSP end-to-end testing independent of the routing protocol. > ps - currently my mail to the OSPF list is not going through. It is, actually. Regards, Alex. From cmj@3Com.com Wed Nov 1 01:50:35 2000 From: cmj@3Com.com (Cyndi Jung) Date: Tue, 31 Oct 2000 17:50:35 -0800 Subject: [Isis-wg] Choice of encapsulation on ATM Message-ID: <3.0.6.32.20001031175035.00942100@mailhost.ewd.3com.com> Hi, We've been brushing off 3Com's old IS-IS implementation, making it support IPv6, and have noticed that it was never (in our system) made to run over ATM, so we're doing that too. The problem is that in RFC1483 it describes two encapsulations for OSI packets over ATM - the LLC encapsulation FE-FE-03 and the NLPID encapsulation, which for IS-IS would simply be the IS-IS frame (NLPID is the first octet, er, byte). So, which of these encapsulations ever got used? I know that CLNP was quite dead by the time everybody was implementing ATM (the reason I don't already know the answer), but IS-IS was certainly used over ATM to support IPv4 routing ala RFC1195. Does anybody out there know? Do we need to do both? Is there any reason one might be preferred? Thanks, Cyndi From dkatz@juniper.net Wed Nov 1 06:06:18 2000 From: dkatz@juniper.net (Dave Katz) Date: Tue, 31 Oct 2000 22:06:18 -0800 (PST) Subject: [Isis-wg] Choice of encapsulation on ATM In-Reply-To: <3.0.6.32.20001031175035.00942100@mailhost.ewd.3com.com> (message from Cyndi Jung on Tue, 31 Oct 2000 17:50:35 -0800) Message-ID: <200011010606.WAA12129@cirrus.juniper.net> We support NLPID and SNAP by configuration. It's got to be the same as the IP encapsulation, of course. Henk's very fine NLPID hack (treating 0x40-0x4f as IP, and 0x83 as ISIS) means that VCMUX could be used as well (taking most of the wind out of the sails of ISIS-over-IP). I suspect that most folks use SNAP encaps as it is the default (and the cell tax has already been paid for the small packets in any case.) X-Sender: cmj@mailhost.ewd.3com.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) From: Cyndi Jung Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 31 Oct 2000 17:50:35 -0800 Hi, We've been brushing off 3Com's old IS-IS implementation, making it support IPv6, and have noticed that it was never (in our system) made to run over ATM, so we're doing that too. The problem is that in RFC1483 it describes two encapsulations for OSI packets over ATM - the LLC encapsulation FE-FE-03 and the NLPID encapsulation, which for IS-IS would simply be the IS-IS frame (NLPID is the first octet, er, byte). So, which of these encapsulations ever got used? I know that CLNP was quite dead by the time everybody was implementing ATM (the reason I don't already know the answer), but IS-IS was certainly used over ATM to support IPv4 routing ala RFC1195. Does anybody out there know? Do we need to do both? Is there any reason one might be preferred? Thanks, Cyndi _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From chopps@nexthop.com Thu Nov 2 17:02:14 2000 From: chopps@nexthop.com (Christian E. Hopps) Date: Thu, 2 Nov 2000 12:02:14 -0500 Subject: [Isis-wg] IPv6 question from last IETF Message-ID: <20001102120214.F7048@nexthop.com> Hi, At the previous IETF IS-IS WG meeting someone questioned whether the IPv6 draft was aligned with regard to metric size with the TE draft. I've double checked and it is aligned. The question was regarding wether TE draft specified 24 bit metrics whereas the IPv6 draft specified 32 bit metrics. The confusion arose becuase the TE draft specifies 24 bit metrics for _IS_ reachability (i.e., link advertisements). The IPv6 draft does not define any new TLVs for IS reachability. Both the TE draft and the IPv6 draft specify 32 bit metrics for IP reachability. Thanks, Chris. From rsaluja@nortelnetworks.com Thu Nov 2 19:41:46 2000 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Thu, 02 Nov 2000 14:41:46 -0500 Subject: [Isis-wg] IPv6 question from last IETF References: <20001102120214.F7048@nexthop.com> Message-ID: <3A01C379.4553C76B@nortelnetworks.com> Hi, I think that you are talking about my question in last IETF. My question was not about the metric size, it was about the type of metric. TE draft eliminates any distinction between internal and external metric type but IPv6 draft IP reachability TLV contains 1 bit to identify external metric type. This is the inconsistency I was pointing. Thanks, Rajesh "Christian E. Hopps" wrote: > Hi, > > At the previous IETF IS-IS WG meeting someone questioned whether > the IPv6 draft was aligned with regard to metric size with the > TE draft. I've double checked and it is aligned. > > The question was regarding wether TE draft specified 24 bit metrics > whereas the IPv6 draft specified 32 bit metrics. The confusion arose > becuase the TE draft specifies 24 bit metrics for _IS_ reachability > (i.e., link advertisements). The IPv6 draft does not define any new > TLVs for IS reachability. Both the TE draft and the IPv6 draft > specify 32 bit metrics for IP reachability. > > Thanks, > Chris. > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- From chopps@nexthop.com Fri Nov 3 15:59:20 2000 From: chopps@nexthop.com (Christian E. Hopps) Date: Fri, 3 Nov 2000 10:59:20 -0500 Subject: [Isis-wg] IPv6 question from last IETF In-Reply-To: <3A01C379.4553C76B@nortelnetworks.com>; from rsaluja@nortelnetworks.com on Thu, Nov 02, 2000 at 02:41:46PM -0500 References: <20001102120214.F7048@nexthop.com> <3A01C379.4553C76B@nortelnetworks.com> Message-ID: <20001103105920.J7048@nexthop.com> On Thu, Nov 02, 2000 at 02:41:46PM -0500, Rajesh Saluja wrote: > Hi, > I think that you are talking about my question in last IETF. My > question was not about the metric size, it was about the type of metric. > TE draft eliminates any distinction between internal and external metric > type but IPv6 draft IP reachability TLV contains 1 bit to identify > external metric type. This is the inconsistency I was pointing. There were a couple questions. I believe your question was "answered" in the meeting (at least I didn't keep it as an open item to look into). Perhaps you didn't feel the same way :) To avoid confusion I'd like to point out that the IPv6 draft like the TE draft has only one metric type (i.e., there is no external metric). What the IPv6 draft did keep from the original RFC was some indication that the reachability was from another routing protocol. The reachability type does not affect the SPF. Its main use is to avoid redistribution loops (e.g., bgp->isis->bgp). My personal opinion is that the TE draft should have some way of indicating the "externalness" of the reachability. I believe the answer to this opinion in the past was "use a sub-tlv" to color the reachbility. This is a fine solution but seems overly complex for most scenerios. I'm not sure why 2 TLV types weren't used to carry forward the old RFC semantics (I used a bit because I had one available which isn't the case with the TE TLVs). In any case because the IPv6 draft implements sub-tlvs the TE solution of using a color sub-tlv is available, if people decide this is the better route to take. Thanks, Chris. > "Christian E. Hopps" wrote: > > > Hi, > > > > At the previous IETF IS-IS WG meeting someone questioned whether > > the IPv6 draft was aligned with regard to metric size with the > > TE draft. I've double checked and it is aligned. > > > > The question was regarding wether TE draft specified 24 bit metrics > > whereas the IPv6 draft specified 32 bit metrics. The confusion arose > > becuase the TE draft specifies 24 bit metrics for _IS_ reachability > > (i.e., link advertisements). The IPv6 draft does not define any new > > TLVs for IS reachability. Both the TE draft and the IPv6 draft > > specify 32 bit metrics for IP reachability. > > > > Thanks, > > Chris. > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > -- > > ------------------------------------------------------------- > Rajesh Saluja > Nortel Networks Inc 600 Technology Park Billerica, MA 01821 > Ph: (978) 288-7791 Fax: (978) 670-8760 > -------------------------------------------------------------- > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From prz@net4u.ch Fri Nov 3 22:23:50 2000 From: prz@net4u.ch (Tony Przygienda) Date: Fri, 3 Nov 2000 23:23:50 +0100 (MET) Subject: [Isis-wg] do we need a session this time ? In-Reply-To: <14765.001030@cisco.com> from Alex Zinin at "Oct 30, 2000 6:22:54 pm" Message-ID: <200011032223.XAA19727@net4u.net4u.ch> > We asked to accept the flooding optimization draft > as the WG item. If the answer is positive and there's > enough interest I could present it. Now that you asked often enough, let's make it a work-group item ;-) I would expect the thing to hang in draft until 1) we got some implemenation experience 2) the flooding optimization discussion clicks into place since that can prove to be a subset, incompatible 3) competing proposals show up (if any) and are resolved BTW, requested a slot today & will start to compile agenda one of these days --- tony From henk@procket.com Sat Nov 4 16:54:31 2000 From: henk@procket.com (Henk Smit) Date: Sat, 4 Nov 2000 17:54:31 +0100 (MET) Subject: [Isis-wg] IPv6 question from last IETF In-Reply-To: <20001103105920.J7048@nexthop.com> from "Christian E. Hopps" at Nov 03, 2000 10:59:20 AM Message-ID: <200011041654.RAA26674@kraak.procket.com> > To avoid confusion I'd like to point out that the IPv6 draft like the > TE draft has only one metric type (i.e., there is no external metric). > What the IPv6 draft did keep from the original RFC was some indication > that the reachability was from another routing protocol. The reachability > type does not affect the SPF. Its main use is to avoid redistribution > loops (e.g., bgp->isis->bgp). And it does a bad job of that. When I used to work in support, I saw that most cases of redistribution were in a scenario where a network operator tried to redistribute multiple islands of routing protocol X into/from a central backbone running protocol Y. Example: an ISIS backbone with multiple RIP worlds around it. Note that there might be more than one redistributing router between the ISIS backbone and a specific RIP domain. In fact,common sense would encourage you to design a network with redundancy. ---rtr1--- central ---rtr3--- RIPv2 world A IS-IS RIPv2 world B ---rtr2--- backbone ---rtr4--- If you use only the route type to decide whether to redistribute or not, you will find out that routes from RIP world A will be marked as external in the IS-IS world, and thus these routes will not be redistributed into RIP world B. The IS-IS backbone needs a way to distinguish between routes originated in world A and in world B. Internal/external route-type is not enough. IMHO if you wanna build something new, better build it good. So lets forget about a half-baked solution like internal/external route-types, and fix this right. > My personal opinion is that the TE draft should have some way of > indicating the "externalness" of the reachability. I believe the > answer to this opinion in the past was "use a sub-tlv" to color > the reachbility. Yes, that is what we have suggested before. > This is a fine solution but seems overly complex > for most scenerios. That depends how more complex you think a bit is versus a byte. :-) All implementation have to deal with sub-TLVs anyway. Even if they don't support any sub-TLVs, they still have to be able to parse them, just so they can ignore them. Adding a sub-TLV should not be too much work. > I'm not sure why 2 TLV types weren't used > to carry forward the old RFC semantics Why waste another TLV for a solution that doesn't solve the problem ? We have only 255 TLVs to spare. > (I used a bit because I had one > available which isn't the case with the TE TLVs). > > In any case because the IPv6 draft implements sub-tlvs the TE solution > of using a color sub-tlv is available, if people decide this is > the better route to take. Using sub-TLVs would be compatible with the traffic-eng extensions draft. Using bits would be more like RFC1195. I would suggest using sub-TLVs, and reserving your bits for more useful use in the future. I am sure people will come up with suggestions later ... Hope this helps, Henk. > Thanks, > Chris. > > > "Christian E. Hopps" wrote: > > > > > Hi, > > > > > > At the previous IETF IS-IS WG meeting someone questioned whether > > > the IPv6 draft was aligned with regard to metric size with the > > > TE draft. I've double checked and it is aligned. > > > > > > The question was regarding wether TE draft specified 24 bit metrics > > > whereas the IPv6 draft specified 32 bit metrics. The confusion arose > > > becuase the TE draft specifies 24 bit metrics for _IS_ reachability > > > (i.e., link advertisements). The IPv6 draft does not define any new > > > TLVs for IS reachability. Both the TE draft and the IPv6 draft > > > specify 32 bit metrics for IP reachability. > > > > > > Thanks, > > > Chris. > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > -- > > > > ------------------------------------------------------------- > > Rajesh Saluja > > Nortel Networks Inc 600 Technology Park Billerica, MA 01821 > > Ph: (978) 288-7791 Fax: (978) 670-8760 > > -------------------------------------------------------------- > > > > > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From Alex Zinin Sat Nov 4 20:10:36 2000 From: Alex Zinin (Alex Zinin) Date: Sat, 4 Nov 2000 12:10:36 -0800 Subject: [Isis-wg] do we need a session this time ? In-Reply-To: <200011032223.XAA19727@net4u.net4u.ch> References: <200011032223.XAA19727@net4u.net4u.ch> Message-ID: <19507.001104@cisco.com> Tony, >> We asked to accept the flooding optimization draft >> as the WG item. If the answer is positive and there's >> enough interest I could present it. > Now that you asked often enough, let's make it a work-group > item ;-) ;) Great, I will resubmit the draft as such. > I would expect the thing to hang in draft until > 1) we got some implemenation experience Another approach would be to make it experimental to encourage ppl implement it. > 2) the flooding optimization discussion clicks into > place since that can prove to be a subset, incompatible > 3) competing proposals show up (if any) and are resolved Agree. I would suggest setting a deadline for the last 2 items. Alex. > BTW, requested a slot today & will start to compile agenda > one of these days > --- tony From prz@net4u.ch Sat Nov 4 21:40:22 2000 From: prz@net4u.ch (Tony Przygienda) Date: Sat, 4 Nov 2000 22:40:22 +0100 (MET) Subject: [Isis-wg] do we need a session this time ? In-Reply-To: <19507.001104@cisco.com> from Alex Zinin at "Nov 4, 2000 12:10:36 pm" Message-ID: <200011042140.WAA31784@net4u.net4u.ch> > > Tony, > > >> We asked to accept the flooding optimization draft > >> as the WG item. If the answer is positive and there's > >> enough interest I could present it. > > > Now that you asked often enough, let's make it a work-group > > item ;-) > > ;) > Great, I will resubmit the draft as such. > > > I would expect the thing to hang in draft until > > > 1) we got some implemenation experience > > Another approach would be to make it experimental to > encourage ppl implement it. nope, implementation experience first, this is too critical to put it into experimental if it's broken anywhere. You're toying with flooding here and flooding is bastardly hard to get right just "thinking through" stuff. Don't even try for the "it's optional" argument, even optional proposed broken extensions to flooding procedures can cause havoc easily since it just takes one young cookie to implement the stuff withouh questioning the quality of the RFC. > > 2) the flooding optimization discussion clicks into > > place since that can prove to be a subset, incompatible > > 3) competing proposals show up (if any) and are resolved > > Agree. I would suggest setting a deadline for the last 2 items. We're tuned into ongoing discussions on both of the items and Tony & me will decide when these things are in a reasonable shape or fizzled out. no dates ... -- tony From prz@net4u.ch Sat Nov 4 21:52:06 2000 From: prz@net4u.ch (Tony Przygienda) Date: Sat, 4 Nov 2000 22:52:06 +0100 (MET) Subject: [Isis-wg] IPv6 question from last IETF In-Reply-To: <200011041654.RAA26674@kraak.procket.com> from Henk Smit at "Nov 4, 2000 5:54:31 pm" Message-ID: <200011042152.WAA31925@net4u.net4u.ch> > > > To avoid confusion I'd like to point out that the IPv6 draft like the > > TE draft has only one metric type (i.e., there is no external metric). > > What the IPv6 draft did keep from the original RFC was some indication > > that the reachability was from another routing protocol. The reachability > > type does not affect the SPF. Its main use is to avoid redistribution > > loops (e.g., bgp->isis->bgp). > > And it does a bad job of that. > When I used to work in support, I saw that most cases of redistribution > were in a scenario where a network operator tried to redistribute > multiple islands of routing protocol X into/from a central backbone > running protocol Y. > > Example: an ISIS backbone with multiple RIP worlds around it. > Note that there might be more than one redistributing router between > the ISIS backbone and a specific RIP domain. In fact,common sense > would encourage you to design a network with redundancy. > > ---rtr1--- central ---rtr3--- > RIPv2 world A IS-IS RIPv2 world B > ---rtr2--- backbone ---rtr4--- > > If you use only the route type to decide whether to redistribute > or not, you will find out that routes from RIP world A will be > marked as external in the IS-IS world, and thus these routes > will not be redistributed into RIP world B. The IS-IS backbone > needs a way to distinguish between routes originated in world A > and in world B. Internal/external route-type is not enough. We could tackle that problem of course, but is anyone willing to put in the cycles ? As well, how realistic is the scenario for ISIS ? Customers I know didn't try to do that with ISIS (ISP comments welcome here of course). Complicated IGP mechanisms have been devised (OSPF tags) and ignored and there is a danger that same would happen here. On the other hand, one vendor has route coloring and I heard that people are playing with it ;-)) So what I'm trying to say here I guess is that it would make sense to come up with a proposal for a full solution (route tags, tag sets, colors, whatever else) and in absence of such having external tag on the route is well understood and solves some of the problem so it's better than nothing. -- tony From chopps@nexthop.com Sat Nov 4 17:28:45 2000 From: chopps@nexthop.com (Christian E. Hopps) Date: Sat, 4 Nov 2000 12:28:45 -0500 Subject: [Isis-wg] IPv6 question from last IETF In-Reply-To: <200011041654.RAA26674@kraak.procket.com>; from henk@procket.com on Sat, Nov 04, 2000 at 05:54:31PM +0100 References: <20001103105920.J7048@nexthop.com> <200011041654.RAA26674@kraak.procket.com> Message-ID: <20001104122845.A14473@nexthop.com> On Sat, Nov 04, 2000 at 05:54:31PM +0100, Henk Smit wrote: > > > To avoid confusion I'd like to point out that the IPv6 draft like the > > TE draft has only one metric type (i.e., there is no external metric). > > What the IPv6 draft did keep from the original RFC was some indication > > that the reachability was from another routing protocol. The reachability > > type does not affect the SPF. Its main use is to avoid redistribution > > loops (e.g., bgp->isis->bgp). > > And it does a bad job of that. [... example scenario when a single bit of information is not enough ...] Indeed coloring with a byte is more powerful than with a bit. I'm not sure thats a strong argument against supporting both methods though. The IPv6 draft, while supporting the TE sub-tlv and thus being compatible with that direction of extension of the protocol, is not a TE extension. When I designed it I wished to support the possiblity of a router vendor implementing IPv4 and IPv6 regardless of whether the TE extensions were also implemented. One way I achieved this was by not requiring the sub-tlv be understood (beyond parsing) for proper functioning. This also carries over to deployment, a user familiar with the standard behavoir may not yet be familiar with the proposed sub-tlv coloring scheme, and may have no need to learn it. Given this goal it seemed obvious to me that I should support the full set of features from RFC1195 that were in current use today (i.e., basically everything but external metrics because of "the bug" :), and that this should not require supporting or understanding the new TE extensions. I do think that the sub-tlv for coloring redistributed routes is a good idea, but I am not sure I like the idea of requiring it to support even the non-TE RFC1195 behavoir with IPv6. If indeed this goal is unimportant then we can remove the bit; however, I am not convinced I see the problem in supporting both the old and the new, as yet to be defined, methods. Chris. From henk@procket.com Sun Nov 5 17:29:17 2000 From: henk@procket.com (Henk Smit) Date: Sun, 5 Nov 2000 18:29:17 +0100 (MET) Subject: [Isis-wg] IPv6 question from last IETF In-Reply-To: <200011042152.WAA31925@net4u.net4u.ch> from "Tony Przygienda" at Nov 04, 2000 10:52:06 PM Message-ID: <200011051729.SAA32026@kraak.procket.com> > > > To avoid confusion I'd like to point out that the IPv6 draft like the > > > TE draft has only one metric type (i.e., there is no external metric). > > > What the IPv6 draft did keep from the original RFC was some indication > > > that the reachability was from another routing protocol. The reachability > > > type does not affect the SPF. Its main use is to avoid redistribution > > > loops (e.g., bgp->isis->bgp). > > > > And it does a bad job of that. > > When I used to work in support, I saw that most cases of redistribution > > were in a scenario where a network operator tried to redistribute > > multiple islands of routing protocol X into/from a central backbone > > running protocol Y. > > > > Example: an ISIS backbone with multiple RIP worlds around it. > > Note that there might be more than one redistributing router between > > the ISIS backbone and a specific RIP domain. In fact,common sense > > would encourage you to design a network with redundancy. > > > > ---rtr1--- central ---rtr3--- > > RIPv2 world A IS-IS RIPv2 world B > > ---rtr2--- backbone ---rtr4--- > > > > If you use only the route type to decide whether to redistribute > > or not, you will find out that routes from RIP world A will be > > marked as external in the IS-IS world, and thus these routes > > will not be redistributed into RIP world B. The IS-IS backbone > > needs a way to distinguish between routes originated in world A > > and in world B. Internal/external route-type is not enough. > > > We could tackle that problem of course, Either you solve the problem (using sub-TLVs to indicate the origine of a prefix) or you don't solve it. Using the binary mechanism from rfc1195 will not solve the problem. So I see no reason to copy that mechanism. > but is anyone willing to put in the cycles ? Route redistribution is not rocket science. Besides that, IMHO most RFC talk about routing inside one IGP domain. There are no standards on how to deal with redistributing between IGPs. And IMHO there is no need for that. Redistrubution is something that is done inside a router, and thus is vendor specific. There must be some regions where vendors can show that they can solve problems without just imlementing what is in the RFCs. :-) The IGP must give a means to carry a tag, that is all. How to deal with it is up to each router vendor. > As well, how realistic is the scenario for ISIS ? Customers I know > didn't try to do that with ISIS (ISP comments welcome here of course). I suspect that those customers you are talking about don't do any redistribution of other IGPs into IS-IS. :-) > So what I'm trying to say here I guess is that it would make sense > to come up with a proposal for a full solution (route tags, tag sets, > colors, whatever else) and in absence of such > having external tag on the route is well understood and solves some of > the problem so it's better than nothing. I disagree here. I rather see a bad solution not implemented at all, in the hope that a good solution will be implemented later. Henk. From cwk@verio.net Mon Nov 6 14:52:25 2000 From: cwk@verio.net (Carl W. Kalbfleisch) Date: Mon, 6 Nov 2000 08:52:25 -0600 Subject: [Isis-wg] do we need a session this time ? In-Reply-To: <19507.001104@cisco.com> Message-ID: Whatever happened to the ISIS MIB? Carl > -----Original Message----- > From: isis-wg-admin@external.juniper.net > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Alex Zinin > Sent: Saturday, November 04, 2000 2:11 PM > To: Tony Przygienda > Cc: isis-wg@juniper.net > Subject: Re: [Isis-wg] do we need a session this time ? > > > > Tony, > > >> We asked to accept the flooding optimization draft > >> as the WG item. If the answer is positive and there's > >> enough interest I could present it. > > > Now that you asked often enough, let's make it a work-group > > item ;-) > > ;) > Great, I will resubmit the draft as such. > > > I would expect the thing to hang in draft until > > > 1) we got some implemenation experience > > Another approach would be to make it experimental to > encourage ppl implement it. > > > 2) the flooding optimization discussion clicks into > > place since that can prove to be a subset, incompatible > > 3) competing proposals show up (if any) and are resolved > > Agree. I would suggest setting a deadline for the last 2 items. > > Alex. > > > BTW, requested a slot today & will start to compile agenda > > one of these days > > > --- tony > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From jparker@axiowave.com Mon Nov 6 15:32:24 2000 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 6 Nov 2000 10:32:24 -0500 Subject: [Isis-wg] do we need a session this time ? Message-ID: Carl - There was a revision before the last IETF, and I sent out a list of "todo" items. I have seen a couple of comments on it since then, but have not rev'd the doc. - jeff parker > -----Original Message----- > From: Carl W. Kalbfleisch [mailto:cwk@verio.net] > Sent: Monday, November 06, 2000 9:52 AM > To: Alex Zinin; Tony Przygienda > Cc: isis-wg@juniper.net > Subject: RE: [Isis-wg] do we need a session this time ? > > Whatever happened to the ISIS MIB? > > Carl From Alex Zinin Mon Nov 6 19:12:43 2000 From: Alex Zinin (Alex Zinin) Date: Mon, 6 Nov 2000 11:12:43 -0800 Subject: [Isis-wg] do we need a session this time ? In-Reply-To: <200011042140.WAA31784@net4u.net4u.ch> References: <200011042140.WAA31784@net4u.net4u.ch> Message-ID: <3467.001106@cisco.com> Tony, OK. Let's start from there. -- Alex Zinin Saturday, November 04, 2000, 1:40 PM, Tony Przygienda wrote: >> >> Tony, >> >> >> We asked to accept the flooding optimization draft >> >> as the WG item. If the answer is positive and there's >> >> enough interest I could present it. >> >> > Now that you asked often enough, let's make it a work-group >> > item ;-) >> >> ;) >> Great, I will resubmit the draft as such. >> >> > I would expect the thing to hang in draft until >> >> > 1) we got some implemenation experience >> >> Another approach would be to make it experimental to >> encourage ppl implement it. > nope, implementation experience first, this is too critical > to put it into experimental if it's broken anywhere. You're > toying with flooding here and flooding is bastardly hard to > get right just "thinking through" stuff. Don't even try for the > "it's optional" argument, even optional proposed broken extensions > to flooding procedures can cause havoc easily since it just takes > one young cookie to implement the stuff withouh questioning > the quality of the RFC. >> > 2) the flooding optimization discussion clicks into >> > place since that can prove to be a subset, incompatible >> > 3) competing proposals show up (if any) and are resolved >> >> Agree. I would suggest setting a deadline for the last 2 items. > We're tuned into ongoing discussions on both of the items and > Tony & me will decide when these things are in a reasonable > shape or fizzled out. no dates ... > -- tony > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From Internet-Drafts@ietf.org Wed Nov 8 10:59:27 2000 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Wed, 08 Nov 2000 05:59:27 -0500 Subject: [Isis-wg] I-D ACTION:draft-dharanikota-interarea-mpls-te-ext-01.txt Message-ID: <200011081059.FAA21195@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OSPF, IS-IS, RSVP, CR-LDP Extensions to Support inter-Area Traffic Engineering Using MPLS TE Author(s) : S. Dharanikota, S. Venkatachalam Filename : draft-dharanikota-interarea-mpls-te-ext-01.txt Pages : 20 Date : 07-Nov-00 In this draft, we propose the extensions required to the routing protocols, signaling protocols, and the MIB to support the idea of inter-area LSPs. A companion document [INTER_AREA_FWK] provides the architectural requirements for such a concept. This document also provides the signaling extensions to support the crankback as defined in the architecture document [INTER_AREA_FWK]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dharanikota-interarea-mpls-te-ext-01.txt 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-dharanikota-interarea-mpls-te-ext-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-dharanikota-interarea-mpls-te-ext-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. --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: <20001107081312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dharanikota-interarea-mpls-te-ext-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-dharanikota-interarea-mpls-te-ext-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001107081312.I-D@ietf.org> --OtherAccess-- --NextPart-- From Internet-Drafts@ietf.org Thu Nov 9 11:22:04 2000 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Thu, 09 Nov 2000 06:22:04 -0500 Subject: [Isis-wg] I-D ACTION:draft-kini-isis-lsp-restoration-00.txt Message-ID: <200011091122.GAA11620@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Intermediate System to Intermediate System (IS-IS) protocol extensions for Label Switched Path restoration Author(s) : S. Kini, M. Kodialam, T. Lakshman, C. Villamizar Filename : draft-kini-isis-lsp-restoration-00.txt Pages : 4 Date : 08-Nov-00 Traffic engineering using MPLS involves the setting up of label switched paths (LSP) possibly with explicit routing and with bandwidth guarantees (for label switched paths). The reliability of these LSPs can be increased by providing a backup LSP onto which traffic can be switched upon failure of an element in the path of the active LSP. Backup LSPs can be routed in a way that bandwidth can be shared between backup links of more than one active path while still guaranteeing recoverability for a set of failures. This sharing greatly increases the network efficiency thereby increasing the number of LSPs that can be carried while maintaining guarantees. Algorithms which can route such recoverable LSPs while using only aggregate network usage information are being developed. To route the active LSP and the (possibly shared) backup LSP, the topology information of the network is needed and this can be provided by a link state routing protocol like IS-IS. This document describes the encoding of the additional information within the link state protocol data unit (LSPdu) of IS-IS to enable routing of shared backup paths. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kini-isis-lsp-restoration-00.txt 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-kini-isis-lsp-restoration-00.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-kini-isis-lsp-restoration-00.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: <20001108150709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kini-isis-lsp-restoration-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kini-isis-lsp-restoration-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001108150709.I-D@ietf.org> --OtherAccess-- --NextPart-- From rhan@ibnets.com Fri Nov 10 15:34:58 2000 From: rhan@ibnets.com (Rick Han) Date: Fri, 10 Nov 2000 15:34:58 +0000 Subject: [Isis-wg] I/E bit in TLV-135 References: <200011010606.WAA12129@cirrus.juniper.net> Message-ID: <3A0C15A2.2EF31230@ibnets.com> Hi, I have a question about TLV-135 (described in draft-ietf-isis-traffic-02.txt). How does TLV-135 indicate the metric type (internal/external)? Is there a bit in the 4-byte metric field reserved for metric-type? Thanks Rick From sprevidi@cisco.com Fri Nov 10 15:50:05 2000 From: sprevidi@cisco.com (stefano previdi) Date: Fri, 10 Nov 2000 16:50:05 +0100 Subject: [Isis-wg] I/E bit in TLV-135 In-Reply-To: <3A0C15A2.2EF31230@ibnets.com> References: <200011010606.WAA12129@cirrus.juniper.net> Message-ID: <4.3.2.7.2.20001110163615.00bb7a80@brussels.cisco.com> At 16:34 10/11/2000, Rick Han wrote: >Hi, I have a question about TLV-135 (described in >draft-ietf-isis-traffic-02.txt). How does TLV-135 indicate the metric >type (internal/external)? it doesn't. If you refer to the use of I/E bit in draft-ietf-isis-domain-wide, keep in mind that we have the up/down bit for that. > Is there a bit in the 4-byte metric field >reserved for metric-type? no. Note that to my knowledge thare are no implementations that really use I/E bit in TLV-128/130. Therefore the interest of having similar bit in TLV-135 was quite limited.... s. From Internet-Drafts@ietf.org Wed Nov 15 11:42:14 2000 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Wed, 15 Nov 2000 06:42:14 -0500 Subject: [Isis-wg] I-D ACTION:draft-ietf-ospf-isis-flood-opt-00.txt Message-ID: <200011151142.GAA01901@ietf.org> --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 : Flooding optimizations in link-state routing protocols Author(s) : A. Zinin, M. Shand Filename : draft-ietf-ospf-isis-flood-opt-00.txt Pages : 12 Date : 06-Nov-00 The flooding algorithm is one of the most important parts of any link state routing protocol. It ensures that all routers within a link state domain converge on the same topological information within a finite period of time. To ensure reliability, typical implementations of the flooding algorithm send new information via all interfaces other than the one the new piece of information was received on. This redundancy is necessary to guarantee that flooding is performed reliably, but implies considerable overhead of utilized bandwidth and CPU time if neighboring routers are connected with more than one link. This document describes a method that reduces this overhead. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-isis-flood-opt-00.txt 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-isis-flood-opt-00.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-isis-flood-opt-00.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: <20001114065550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-isis-flood-opt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-isis-flood-opt-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001114065550.I-D@ietf.org> --OtherAccess-- --NextPart-- From sprevidi@cisco.com Wed Nov 15 20:53:33 2000 From: sprevidi@cisco.com (stefano previdi) Date: Wed, 15 Nov 2000 21:53:33 +0100 Subject: [Isis-wg] I/E bit in TLV-135 In-Reply-To: <5.0.0.25.0.20001113202455.00a1b810@mail.verizon.net> Message-ID: <4.3.2.7.2.20001115214435.00abe940@brussels.cisco.com> At 05:14 14/11/2000, vze252px@verizon.net wrote: >Still don't understand. By reading the draft, up/down bit indicates a route >has traversed from L2 to L1. more precisely it indicates that the prefix went from a upper level to a lower level. > But how a router distinguish internal/external >routes? it doesn't. TLV-135 doesn't have any I/E bit. >If a router leaned both internal and external routes to same >destination with same up/down bit, how does it select one? Just >based on metric? Again: TLV-135 doesn't make any difference between "internal" and "external". s. >Bob > >At 04:50 PM 11/10/2000 +0100, stefano previdi wrote: >At 16:34 10/11/2000, Rick Han wrote: >>Hi, I have a question about TLV-135 (described in >>draft-ietf-isis-traffic-02.txt). How does TLV-135 indicate the metric >>type (internal/external)? > >it doesn't. > >If you refer to the use of I/E bit in draft-ietf-isis-domain-wide, >keep in mind that we have the up/down bit for that. > >> Is there a bit in the 4-byte metric field >>reserved for metric-type? > >no. > >Note that to my knowledge thare are no implementations that really use >I/E bit in TLV-128/130. Therefore the interest of having similar bit >in TLV-135 was quite limited.... > >s. > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From Internet-Drafts@ietf.org Mon Nov 20 11:14:19 2000 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Mon, 20 Nov 2000 06:14:19 -0500 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-01.txt Message-ID: <200011201114.GAA04455@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Extensions in Support of Generalized MPLS Author(s) : K. Kompella, Y. Rekhter, A. Banerjee, J. Drake, G. Bernstein, D. Fedyk, E. Mannie, D. Saha, V. Sharma Filename : draft-ietf-isis-gmpls-extensions-01.txt Pages : 12 Date : 17-Nov-00 This document specifies extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (previously known as Multi-Protocol Lambda Switching). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-01.txt 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-isis-gmpls-extensions-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-ietf-isis-gmpls-extensions-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. --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: <20001117145203.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001117145203.I-D@ietf.org> --OtherAccess-- --NextPart-- From Internet-Drafts@ietf.org Wed Nov 22 11:11:22 2000 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Wed, 22 Nov 2000 06:11:22 -0500 Subject: [Isis-wg] I-D ACTION:draft-fedyk-isis-ospf-te-metrics-01.txt Message-ID: <200011221111.GAA20837@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multiple Metrics for Traffic Engineering with IS-IS and OSPF Author(s) : D. Fedyk, A. Ghanwani, R. Balay, J. Ash, A. Vedrenne Filename : draft-fedyk-isis-ospf-te-metrics-01.txt Pages : 8 Date : 21-Nov-00 This draft describes optional sub-TLVs that can be used to extend IGPs to support multiple metrics for use with traffic engineering. These optional extensions are an addendum to the existing work on traffic engineering extensions to OSPF and ISIS. While the current specifications allow advertising only one metric, the ability to advertise multiple metrics has proven to be very useful in similar systems. The encoding for the proposed optional sub-TLVs is also specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fedyk-isis-ospf-te-metrics-01.txt 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-fedyk-isis-ospf-te-metrics-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-fedyk-isis-ospf-te-metrics-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. --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: <20001121111107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-fedyk-isis-ospf-te-metrics-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-fedyk-isis-ospf-te-metrics-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001121111107.I-D@ietf.org> --OtherAccess-- --NextPart-- From prz@net4u.ch Mon Nov 27 08:03:37 2000 From: prz@net4u.ch (Tony Przygienda) Date: Mon, 27 Nov 2000 09:03:37 +0100 (MET) Subject: [Isis-wg] Compiling ISIS agenda ... Message-ID: <200011270803.JAA17769@net4u.net4u.ch> That's the things I have so far on the agenda. Anyone missing ? Topic Presenter --------------------------------------------------------- Administrativa Tony x Last Call for IPv6 Ballot Deane? Flooding Optimizations Alex Update on Diffserv-MPLS Francois Packet-Design presentation Cengiz I didn't see request for "draft-ietf-isis-gmpls-extensions" ? Anyone else missing ? -- tony From vze252px@verizon.net Tue Nov 14 04:14:46 2000 From: vze252px@verizon.net (vze252px@verizon.net) Date: Mon, 13 Nov 2000 23:14:46 -0500 Subject: [Isis-wg] I/E bit in TLV-135 Message-ID: <5.0.0.25.0.20001113202455.00a1b810@mail.verizon.net> Still don't understand. By reading the draft, up/down bit indicates a route has traversed from L2 to L1. But how a router distinguish internal/external routes? If a router leaned both internal and external routes to same destination with same up/down bit, how does it select one? Just based on metric? Bob At 04:50 PM 11/10/2000 +0100, stefano previdi wrote: At 16:34 10/11/2000, Rick Han wrote: >Hi, I have a question about TLV-135 (described in >draft-ietf-isis-traffic-02.txt). How does TLV-135 indicate the metric >type (internal/external)? it doesn't. If you refer to the use of I/E bit in draft-ietf-isis-domain-wide, keep in mind that we have the up/down bit for that. > Is there a bit in the 4-byte metric field >reserved for metric-type? no. Note that to my knowledge thare are no implementations that really use I/E bit in TLV-128/130. Therefore the interest of having similar bit in TLV-135 was quite limited.... s. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From cengiz@packetdesign.com Mon Nov 27 19:03:29 2000 From: cengiz@packetdesign.com (Cengiz Alaettinoglu) Date: Mon, 27 Nov 2000 11:03:29 -0800 (PST) Subject: [Isis-wg] Compiling ISIS agenda ... In-Reply-To: <200011270803.JAA17769@net4u.net4u.ch> References: <200011270803.JAA17769@net4u.net4u.ch> Message-ID: <14882.45057.96900.820250@localhost.localdomain> Tony Przygienda (prz@net4u.ch) on November 27: > That's the things I have so far on the agenda. Anyone > missing ? > > Topic Presenter > --------------------------------------------------------- > Administrativa Tony > x Last Call for IPv6 > Ballot Deane? > Flooding Optimizations Alex > Update on Diffserv-MPLS Francois > Packet-Design presentation Cengiz This is a presentation on ISIS convergence. Please see: draft-alaettinoglu-ISIS-convergence-00.ps We are soliciting feedback/comments on this document. see you in San Diego. > > I didn't see request for "draft-ietf-isis-gmpls-extensions" ? > Anyone else missing ? > > -- tony > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg Cengiz -- Cengiz Alaettinoglu Packet Design Inc. From dwfedyk@nortelnetworks.com Tue Nov 28 18:56:39 2000 From: dwfedyk@nortelnetworks.com (Don Fedyk) Date: Tue, 28 Nov 2000 13:56:39 -0500 Subject: [Isis-wg] (no subject) Message-ID: <3.0.1.32.20001128135639.00728c38@pobox.engeast.baynetworks.com> Tony We have updated and resubmitted: draft-fedyk-isis-ospf-te-metrics-01.txt 0000,0000,ffff The action items I had was to make sure customers supported this feature for it to become a WG document. I have discussed with a several customers and some are now co-authors. Other than splitting out OSPF I think the document is ready to be a WG document. Can you allocate an appropriate time slot to discuss? Thanks, Don >>>> That's the things I have so far on the agenda. Anyone missing ? Topic Presenter --------------------------------------------------------- Administrativa Tony x Last Call for IPv6 Ballot Deane? Flooding Optimizations Alex Update on Diffserv-MPLS Francois Packet-Design presentation Cengiz I didn't see request for "draft-ietf-isis-gmpls-extensions" ? Anyone else missing ? -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net 0000,0000,ffffhttp://external.juniper.net/mailman/listinfo/isis-wg 0000,0000,ffff<<<<<<<< From prz@net4u.ch Tue Nov 28 19:28:41 2000 From: prz@net4u.ch (Tony Przygienda) Date: Tue, 28 Nov 2000 20:28:41 +0100 (MET) Subject: [Isis-wg] Iteration 2, Agenda Message-ID: <200011281928.UAA24316@net4u.net4u.ch> Next iteration: Topic Presenter --------------------------------------------------------- Administrativa Either Tony x Last Call for IPv6 Ballot Deane? draft-dharanikota-interarea-mpls-te-ext-01.txt Sudheer draft-ietf-ospf-isis-flood-opt-00.txt Alex draft-fedyk-isis-ospf-te-metrics-01.txt Don draft-lefaucheur-diff-te-isis-00.txt Francois draft-alaettinoglu-ISIS-convergence-00.ps Cengiz We're getting a bit full so slots will be pretty short. Everybody reads the drafts pls so the amount and cluefullness of questions remains at the usual ISIS working group level ;-) TW, none of the numerous authors of draft-ietf-isis-gmpls-extensions-01.txt asked for a slot. -- tony From bneal@broadwing.com Wed Dec 13 20:56:45 2000 From: bneal@broadwing.com (bneal@broadwing.com) Date: Wed, 13 Dec 2000 14:56:45 -0600 Subject: [Isis-wg] Draft Submission Message-ID: <8E9322ACF085D311918E00805FE6CEE702E7B1F7@metexch3.ixc-comm.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C06547.33D00C90 Content-Type: text/plain; charset="iso-8859-1" Members and Chairpersons of the IS-IS for IP Internets Working Group, My name is Brad Neal, and I would like to submit this draft to the list for review. Please take a moment to examine it, and reply with you thoughts. Best regards, Brad Neal Broadwing Communications Abstract: This draft describes an extension to Integrated IS-IS, which can be used to pass additional information among routers within an IS-IS domain that can aid in policy administration. This extension is roughly similar in function to the BGP communities attribute; in that it provides a mechanism to associate a routed prefix with some administrative group, such that an administrator may define a routing policy for that group. ~~~~~~~~~~~~~~~~~ <> ------_=_NextPart_000_01C06547.33D00C90 Content-Type: text/plain; name="draft-neal-isis-policy-ext-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-neal-isis-policy-ext-00.txt" Internet Engineering Task Force Brad Neal Internet Draft (Broadwing Communications) Expiration Date: June 2001 November 2000 A Policy-Group Sub-TLV for IS-IS Extended IP Reachability=20 Information draft-neal-isis-policy-ext-00.txt 1. Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This draft describes an extension to Integrated IS-IS, which can be "draft-neal-isis-policy-ext-00.txt" 176 lines, 7340 characters written [bneal@kenny bneal]$ cat draft-neal-isis-policy-ext-00.txt Internet Engineering Task Force Brad Neal Internet Draft (Broadwing Communications) Expiration Date: June 2001 November 2000 An Policy-Group Sub-TLV for IS-IS Extended IP Reachability=20 Information draft-neal-isis-policy-ext-00.txt 1. Status of this Document This document is an Internet-Draft and is in full conformance with all=20 provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task=20 Force (IETF), its areas, and its working groups. Note that other groups = may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months=20 and may be updated, replaced, or obsolete by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference material=20 or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This draft describes an extension to Integrated IS-IS, which can be=20 used to pass additional information among routers within an IS-IS=20 domain that can aid in policy administration. This extension is=20 roughly similar in function to the BGP communities attribute; in that=20 it provides a mechanism to associate a routed prefix with some=20 administrative group, such that an administrator may define a routing=20 policy for that group. 3. Introduction It is sometimes necessary for a network administrator to control the=20 distribution of reachability information in a routing domain according=20 to some policy. In particular, an administrator may wish control which = active=20 routes are advertised to various neighbors, or which active routes are=20 redistributed into other protocols. There are several syntaxes for=20 routing-policy specification among vendors, but most consist of an=20 ordered list of 'match' conditions and 'set' actions that is applied to = a routing process. Most implementations allow a match condition to be a = simple list of statically defined prefixes, or some attribute=20 associated with a prefix in the context of the protocol through which=20 it was learned (e.g., "match all area A routes, and redistribute=20 into..."). In general, it is more preferable to match some transitive=20 attribute of a prefix, rather than define a static list as a match=20 condition. This is due to the administrative complexity of maintaining = said list at every node that must apply that policy. Sometimes an=20 administrator may wish to match a group of routes with some common=20 logical property. For interdomain routing with BGP, [COMM] defines a=20 protocol extension that is helpful in this regard; and has, in=20 practical implementation, come to be of significant utility. 4. Policy-Group Sub-TLV There does not currently exist a mechanism in the IS-IS protocol=20 specification [ISIS-IP], or in the proposed standard [ISIS-TE] that=20 allows an us to arbitrarily identify an IP prefix as a member of an=20 administratively defined group. In most current implementations; if an=20 administrator wishes to match routes with some common property, that=20 administrator must define a static list of routed prefixes as a match=20 condition. We suggest the definition of an "Policy-Group" extension to=20 the IS-IS Extended IP Reachability Information" TLV which will address=20 this. =20 An administrator may define an interesting property and associate it=20 with a policy-group. A policy-group identifier is, in turn, associated=20 with an IP prefix with that property and 'sticks' to the IP=20 reachability information for that prefix as it is flooded throughout=20 the routing domain.=20 A complient ISIS implementation... - MUST be able to assign a policy group to any IP prefix,=20 for which it generates an extended IP reachability information TLV, - MUST be able to assign more than one tag to a particular prefix, = and.. - SHOULD be able to rewrite or remove the policy-group of a=20 received prefix according to its own policy. =20 The policy-tag(s) is/are a sub-TLV carried within the Extended IP=20 reachability=20 TLV, whose TLV type is 135[ISIS-TE]. A tag is represented as a 16-bit=20 value, so the length portion of the sub-TLV will be 16 times the number = of tags asscociated with the ip prefix. 5. Operation Consider the network in figure 1. We wish to "leak" L1 prefixes [LEAK]=20 with some property, A, from L2 to the L1 router R1. Without=20 policy-groups, there is no way for R2 to know property A prefixes from=20 property B prefixes.=20 R2--------R3--------R4 =20 L2 / \ =20 - - - /- - - - - - - - - - - \- - -=20 L1 / \ =20 R1 R5----1.1.1.0/24 (A) | =20 | =20 1.1.2.0/24 (B) Figure 1 We associate policy-group 100 with property A, and have R5 attach that=20 value, in a sub-TLV, to the IP extended reachability information TLV=20 for prefix 1.1.1.0/24. R2 has a policy in place to "match prefixes with = policy-group 100, and leak to L1." The previous example is rather simplistic, and it seems that it would=20 be=20 just as easy for R2 simply to match the prefix 1.1.1.0/24. However if=20 there are a large number of routers that need to apply some policy=20 according to property A and large number of "A" prefixes, this=20 mechanism can be quite helpful. It is appropriate 6. Security Considerations This documents raises no new security issues for IS-IS. 7. References [COMM] R. Chandra, P Traina, "BGP Communities Attribute", RFC 1997,=20 August 1996 [ISIS-IP] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual=20 Environments" RFC 1195, December 1990 [ISIS-TE] Tony Li, Henk Smit, "IS-IS extensions for Traffic=20 Engineering", work in progress [LEAK] T. Li, T Przygienda, H. Smit, "Domain-wide Prefix Distribution=20 with Two-Level IS-IS", RFC 2966, October 2000 8. Author's Address Postal: Brad Neal Broadwing Communications 1835 Kramer Lane - Suite 100 Austin, Texas 78758 USA Email: bneal@broadwing.com Full Copyright Statement "Copyright (C) The Internet Society (March 2000). All Rights Reserved.=20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain it or = assist in its implementation may be prepared, copied, published and=20 distributed, in whole or in part, without restriction of any kind,=20 provided that the above copyright notice and this paragraph are=20 included on all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by removing the = copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of developing=20 Internet standards in which case the procedures for copyrights defined=20 in the Internet Standards process must be followed, or as required to=20 translate it into languages other than English. The limited permissions granted above are perpetual and will not be=20 revoked by the Internet Society or its successors or assigns. ------_=_NextPart_000_01C06547.33D00C90-- From prz@net4u.ch Thu Dec 14 20:40:13 2000 From: prz@net4u.ch (Tony Przygienda) Date: Thu, 14 Dec 2000 21:40:13 +0100 (MET) Subject: [Isis-wg] Draft Submission In-Reply-To: <8E9322ACF085D311918E00805FE6CEE702E7B1F7@metexch3.ixc-comm.com> from "bneal@broadwing.com" at "Dec 13, 2000 2:56:45 pm" Message-ID: <200012142040.VAA24542@net4u.net4u.ch> Brad, looks to me like the OSPF tag pretty much. OSPF tag was generally accepted as good idea in its time. In practical deployment it turned out to not have been really used for anything. That's just my experience, others may disagree here. For your specific problem, I fail somehow to see what significant difference it makes to write policies to tag the prefixes from writing the policies to filter prefixes unless you change IP addresses in your IGP cloud often which is unlikely in IP backbones in my experience. This is _very_ different from the way communities in BGP are often used, e.g. a certain peer is putting communities on all prefixes it learns. Those prefixes are not known a-priori. Given that applying policies per neighbor in IGP is a really bad idea IMHO, the problems solved are very different and I'm not convinced the problem you mention is very relevant in ISIS. -- tony From echang@pocketmail.com Fri Sep 22 01:17:35 2000 From: echang@pocketmail.com (Edward Chang) Date: Thu, 21 Sep 2000 17:17:35 -0700 (PDT) Subject: [Isis-wg] Question on DCC Architecture Message-ID: <200009220017.RAA40923@www-004.pocketmail.com> Hi, I am a developer of DCC for an NE. I have few questions regarding DCC architecture. In the system that I am developing, the network between GNE and EMS/OS is IP, it is naturally for me to consider TCP/IP on the top of DCC. This architecture makes the DCN including DCC consistent, and makes the DCC implementation easy. However, when I read the SIF document SIF-018-1998 and TELCO document GR-253-CORE, I found that the OSI on DCC is a standard and TCP/IP on DCC is not. Here comes my question: Is there any standard about TCP/IP on DCC that I don't know? If there is no such standard, is any one or company implementing such architecture of DCC? If there is no such standard, is any one or company writing such standard? I appreciate if you could give me some related information. Thank you in advance. Edward From tli@Procket.com Sat Dec 16 05:50:45 2000 From: tli@Procket.com (Tony Li) Date: Fri, 15 Dec 2000 21:50:45 -0800 (PST) Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: <200009220017.RAA40923@www-004.pocketmail.com> References: <200009220017.RAA40923@www-004.pocketmail.com> Message-ID: <14907.693.141245.416611@alpha-tony.procket.com> Ed, Welcome to the wonderful world of SONET. | I am a developer of DCC for an NE. I have few questions regarding DCC | architecture. | | In the system that I am developing, the network between GNE and EMS/OS | is IP, it is naturally for me to consider TCP/IP on the top of DCC. This | architecture makes the DCN including DCC consistent, and makes the DCC | implementation easy. However, when I read the SIF document SIF-018-1998 | and TELCO document GR-253-CORE, I found that the OSI on DCC is a | standard and TCP/IP on DCC is not. Here comes my question: | | Is there any standard about TCP/IP on DCC that I don't know? Nope. It would make sense, wouldn't it? | If there is no such standard, is any one or company implementing such | architecture of DCC? If there is no such standard, is any one or | company writing such standard? I'm unaware of anyone writing such a document nor is it particularly clear as to where this type of feature should be standardized. It would make some sense to do this in the IETF, but it's certainly not the only possible place. I do know that many folks have discussed doing this. Tony p.s. I've excluded MPLS, as I don't see the relevance... From Alex Zinin Sat Dec 16 20:26:23 2000 From: Alex Zinin (Alex Zinin) Date: Sat, 16 Dec 2000 12:26:23 -0800 Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: <14907.693.141245.416611@alpha-tony.procket.com> References: <14907.693.141245.416611@alpha-tony.procket.com> Message-ID: <2518.001216@cisco.com> Tony, Ed A number of companies working in the SONET area already use or are planning to use DCC for IP control plane [I put MPLS list back ;), since this question is related to GMPLS and OTN-related work]. There are two types of IP encapsulation on DCC that I know of: LAP-D and PPP/HDLC. We use the second one in our SONET products. I think writing up an IETF document describing this would make sense. -- Alex Zinin Friday, December 15, 2000, 9:50 PM, Tony Li wrote: > Ed, > Welcome to the wonderful world of SONET. > | I am a developer of DCC for an NE. I have few questions regarding DCC > | architecture. > | > | In the system that I am developing, the network between GNE and EMS/OS > | is IP, it is naturally for me to consider TCP/IP on the top of DCC. This > | architecture makes the DCN including DCC consistent, and makes the DCC > | implementation easy. However, when I read the SIF document SIF-018-1998 > | and TELCO document GR-253-CORE, I found that the OSI on DCC is a > | standard and TCP/IP on DCC is not. Here comes my question: > | > | Is there any standard about TCP/IP on DCC that I don't know? > Nope. It would make sense, wouldn't it? > | If there is no such standard, is any one or company implementing such > | architecture of DCC? If there is no such standard, is any one or > | company writing such standard? > I'm unaware of anyone writing such a document nor is it particularly clear > as to where this type of feature should be standardized. It would make > some sense to do this in the IETF, but it's certainly not the only possible > place. > I do know that many folks have discussed doing this. > Tony > p.s. I've excluded MPLS, as I don't see the relevance... > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From yzhou@mahinetworks.com Sat Dec 16 22:19:02 2000 From: yzhou@mahinetworks.com (Yuchen Zhou) Date: Sat, 16 Dec 2000 14:19:02 -0800 Subject: [Isis-wg] Question on DCC Architecture Message-ID: <9D6D37E97A57D411BB7C00508BAE29C90FD5D3@main.mahinetworks.com> On a related thread to Ed's question ... You can use mediation devices to network EMS/OS with GNE/NE (which run OSI over DCC) over DCN. On the other hand, there are also some proposals to tunnel IP through OSI networks. Regards. Yuchen -----Original Message----- From: Tony Li [mailto:tli@procket.com] Sent: Friday, December 15, 2000 9:51 PM To: Edward Chang Cc: isis-wg@spider.juniper.net Subject: [Isis-wg] Question on DCC Architecture Ed, Welcome to the wonderful world of SONET. | I am a developer of DCC for an NE. I have few questions regarding DCC | architecture. | | In the system that I am developing, the network between GNE and EMS/OS | is IP, it is naturally for me to consider TCP/IP on the top of DCC. This | architecture makes the DCN including DCC consistent, and makes the DCC | implementation easy. However, when I read the SIF document SIF-018-1998 | and TELCO document GR-253-CORE, I found that the OSI on DCC is a | standard and TCP/IP on DCC is not. Here comes my question: | | Is there any standard about TCP/IP on DCC that I don't know? Nope. It would make sense, wouldn't it? | If there is no such standard, is any one or company implementing such | architecture of DCC? If there is no such standard, is any one or | company writing such standard? I'm unaware of anyone writing such a document nor is it particularly clear as to where this type of feature should be standardized. It would make some sense to do this in the IETF, but it's certainly not the only possible place. I do know that many folks have discussed doing this. Tony p.s. I've excluded MPLS, as I don't see the relevance... _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From prz@net4u.ch Sun Dec 17 07:44:34 2000 From: prz@net4u.ch (Tony Przygienda) Date: Sun, 17 Dec 2000 08:44:34 +0100 (MET) Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: <2518.001216@cisco.com> from Alex Zinin at "Dec 16, 2000 12:26:23 pm" Message-ID: <200012170744.IAA02178@net4u.net4u.ch> > > Tony, Ed > > A number of companies working in the SONET area already use or are > planning to use DCC for IP control plane [I put MPLS list back ;), > since this question is related to GMPLS and OTN-related work]. > > There are two types of IP encapsulation on DCC that I know of: > LAP-D and PPP/HDLC. We use the second one in our SONET products. > > I think writing up an IETF document describing this would make sense. First, this smells much like ISO thing to do so we'd need an agreement/liason first from their side. That is obviously only worth pursuiting if we have authors commiting to provide the cycles first. Second, which workgroup ? One of the MPLS offsprings such as GSMP ;-) ? What about a new one, IPSO (IP over SOnet) ? I'm joking but wouldn't be surprised if the joke find takers ;-) ? thanks -- tony From jlearman@cisco.com Sun Dec 17 15:48:52 2000 From: jlearman@cisco.com (Jeff Learman) Date: Sun, 17 Dec 2000 10:48:52 -0500 Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: <200009220017.RAA40923@www-004.pocketmail.com> Message-ID: <4.1.20001217101926.00a47100@dingdong.cisco.com> Edward, This issue has been discussed at NSIF (Network and Services Integration Forum, "http://www.atis.org/atis/sif/sifhom.htm") and at T1M1 (see www.t1.org) meetings, under the discussion concerning an IP profile for TMN, which does not currently exist other than for RFC-1006). T1M1 is normally for technology-independent aspects of telecom management; the more limited subject of IP for SONET DCC would normally be handled by T1X1, which handles technology-dependent aspects. If you are marketing your equipment for an IP infrastructure, IP/PPP/HDLC is the best solution, in my opionion. If you are marketing your equipment in circuit-switched world and you need interoperability with existing Telcordia- and TMN-compliant SONET NEs in the same ring, then you will need to support OSI, at least at the network layer and below. For IP/PPP/HDLC, be sure to implement the draft RFC, Three-Way Handshake for IS-IS Point-to-Point Adjacencies, "http://www.ietf.org/internet-drafts/draft-ietf-isis-3way-03.txt". In the latter case (interoperability required), it is still possible for your NE to be IP-managed, using IP/CLNP encapsulation, but note that there are nontrivial routing issues. Best Regards, Jeff Note: Opinions expressed are my own and do not necessarily represent the opinions of my empoyer. At 05:17 PM 09/21/2000 -0700, Edward Chang wrote: >Hi, > >I am a developer of DCC for an NE. I have few questions regarding DCC >architecture. > >In the system that I am developing, the network between GNE and EMS/OS is IP, >it is naturally for me to consider TCP/IP on the top of DCC. This architecture >makes the DCN including DCC consistent, and makes the DCC implementation easy. >However, when I read the SIF document SIF-018-1998 and TELCO document >GR-253-CORE, I found that the OSI on DCC is a standard and TCP/IP on DCC is >not. Here comes my question: > >Is there any standard about TCP/IP on DCC that I don't know? >If there is no such standard, is any one or company implementing such >architecture of DCC? >If there is no such standard, is any one or company writing such standard? > >I appreciate if you could give me some related information. > >Thank you in advance. > >Edward > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From Alex Zinin Sun Dec 17 17:45:45 2000 From: Alex Zinin (Alex Zinin) Date: Sun, 17 Dec 2000 09:45:45 -0800 Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: <200012170744.IAA02178@net4u.net4u.ch> References: <200012170744.IAA02178@net4u.net4u.ch> Message-ID: <0406.001217@cisco.com> Tony, >> A number of companies working in the SONET area already use or are >> planning to use DCC for IP control plane [I put MPLS list back ;), >> since this question is related to GMPLS and OTN-related work]. >> >> There are two types of IP encapsulation on DCC that I know of: >> LAP-D and PPP/HDLC. We use the second one in our SONET products. >> >> I think writing up an IETF document describing this would make sense. > First, this smells much like ISO thing to do so we'd need an agreement/liason > first from their side. That is obviously only worth pursuiting if we have > authors commiting to provide the cycles first. Hmmm... why do you think specification of *IP* encapsulation over SONET DCC using "PPP over HDLC-like framing" is something ISO should do? > Second, which workgroup ? One of the MPLS offsprings such as GSMP ;-) ? What about > a new one, IPSO (IP over SOnet) ? I'm joking but wouldn't be surprised > if the joke find takers ;-) ? Definitely not me ;) I think some kind of individual submission should be ok. I guess the Internet Area is the one that logically hosts it. Thanks, Alex. From riad@caspiannetworks.com Mon Dec 18 02:22:51 2000 From: riad@caspiannetworks.com (Riad Hartani) Date: Sun, 17 Dec 2000 18:22:51 -0800 Subject: [Isis-wg] Question on DCC Architecture Message-ID: On this subject, the OIF UNI 1.0 specification (submitted for last call) describes, among other things, how to use SONET Line and/or Section DCC overhead bytes to transport various IP control plane messages (called IP Control Channel -IPCC-). For discovery of information required by the IP control plane, both DCC or J0 bytes may be used in the actual proposal. For the IP control plane, the proposal requires IP packets to be encapsulated in PPP over HDLC-like framing with bit stuffing format. The spec also describes various aspects related to the selection and maintenance of IPCC parameters, as well as other ways of carrying IP control information in Sonet/WDM environments. Hope this helps, Riad > -----Original Message----- > From: Alex Zinin [mailto:azinin@cisco.com] > Sent: Sunday, December 17, 2000 9:46 AM > To: Tony Przygienda > Cc: tli@procket.com; echang@pocketmail.com; > isis-wg@spider.juniper.net; > skatukam@cisco.com; mpls@UU.NET > Subject: Re: [Isis-wg] Question on DCC Architecture > > > > Tony, > > >> A number of companies working in the SONET area already use or are > >> planning to use DCC for IP control plane [I put MPLS list back ;), > >> since this question is related to GMPLS and OTN-related work]. > >> > >> There are two types of IP encapsulation on DCC that I know of: > >> LAP-D and PPP/HDLC. We use the second one in our SONET products. > >> > >> I think writing up an IETF document describing this would > make sense. > > > First, this smells much like ISO thing to do so we'd need > an agreement/liason > > first from their side. That is obviously only worth > pursuiting if we have > > authors commiting to provide the cycles first. > > Hmmm... why do you think specification of *IP* encapsulation > over SONET DCC > using "PPP over HDLC-like framing" is something ISO should do? > > > Second, which workgroup ? One of the MPLS offsprings such > as GSMP ;-) ? What about > > a new one, IPSO (IP over SOnet) ? I'm joking but wouldn't > be surprised > > if the joke find takers ;-) ? > > Definitely not me ;) > > I think some kind of individual submission should be ok. I guess > the Internet Area is the one that logically hosts it. > > Thanks, > > Alex. > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From Manohar Ellanti" Message-ID: <035001c06903$6c6bdb00$1cd01318@frmt1.sfba.home.com> I think there are two aspects to the IP over SONET DCC. One is UNI Signaling for the purpose of CPE-ONE Signaling and possibly NNI Signaling and the other is DCN (at least that is the term we used and I believe is borrowed from work done in Sonet Interoperability Forum) for EMS/NMS. The latter is something that is discussed quite a bit in SIF and may be in ANSI T1X1 as well. Incase it might help here are some references. 1. Brown, Mike, SIF-AR-9804-055, "Survey of Requirements for IP on the non-DCC DCN," April 15, 1998. 2. Hunt, Christopher J., SIF-AR-9804-058, "TCP/IP DCN Alternatives," April 14, 1998. 3. Jamal, Rashid, SIF-AR-9803-054, "IP On DCN - Sprint's Response," April 14, 1998. 4. Reference architecture proposed at May IP DCN conference call. I think, SIF primarily focused on use of DCC bytes (called as embedded operations channel) for SONET network management plane and not for control plane. IP over PPP over HDLC over DCC bytes as pure network transport mechanism need not be linked with control plane or management plane. I think UNI 1.0 does leave scope for UNI signaling messages to be transported using 1. DCC bytes 2. SPE 3. alternate transport such as UNI over internet reaching the ONE. 4. Ethernet if CPE is co-located with ONE such as in a POP A general informational document drawing inputs from SIF, UNI 1.0 and from other useful dicussions elsewhere might be helpful for IETF community while avoiding re-inventing some of the issues and operational problems expressed already and draws from good inputs in the past of lot of people. Manohar N Ellanti ----- Original Message ----- From: "Riad Hartani" To: "'Alex Zinin'" ; "Tony Przygienda" Cc: ; ; ; ; Sent: Sunday, December 17, 2000 6:22 PM Subject: RE: [Isis-wg] Question on DCC Architecture > On this subject, the OIF UNI 1.0 specification (submitted for last call) > describes, among other things, how to use SONET Line and/or Section DCC > overhead bytes to transport various IP control plane messages (called IP > Control Channel -IPCC-). For discovery of information required by the IP > control plane, both DCC or J0 bytes may be used in the actual proposal. > > For the IP control plane, the proposal requires IP packets to be > encapsulated in PPP over HDLC-like framing with bit stuffing format. The > spec also describes various aspects related to the selection and maintenance > of IPCC parameters, as well as other ways of carrying IP control information > in Sonet/WDM environments. > > Hope this helps, > > Riad > > > -----Original Message----- > > From: Alex Zinin [mailto:azinin@cisco.com] > > Sent: Sunday, December 17, 2000 9:46 AM > > To: Tony Przygienda > > Cc: tli@procket.com; echang@pocketmail.com; > > isis-wg@spider.juniper.net; > > skatukam@cisco.com; mpls@UU.NET > > Subject: Re: [Isis-wg] Question on DCC Architecture > > > > > > > > Tony, > > > > >> A number of companies working in the SONET area already use or are > > >> planning to use DCC for IP control plane [I put MPLS list back ;), > > >> since this question is related to GMPLS and OTN-related work]. > > >> > > >> There are two types of IP encapsulation on DCC that I know of: > > >> LAP-D and PPP/HDLC. We use the second one in our SONET products. > > >> > > >> I think writing up an IETF document describing this would > > make sense. > > > > > First, this smells much like ISO thing to do so we'd need > > an agreement/liason > > > first from their side. That is obviously only worth > > pursuiting if we have > > > authors commiting to provide the cycles first. > > > > Hmmm... why do you think specification of *IP* encapsulation > > over SONET DCC > > using "PPP over HDLC-like framing" is something ISO should do? > > > > > Second, which workgroup ? One of the MPLS offsprings such > > as GSMP ;-) ? What about > > > a new one, IPSO (IP over SOnet) ? I'm joking but wouldn't > > be surprised > > > if the joke find takers ;-) ? > > > > Definitely not me ;) > > > > I think some kind of individual submission should be ok. I guess > > the Internet Area is the one that logically hosts it. > > > > Thanks, > > > > Alex. > > > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > From jboyle@Level3.net Mon Dec 18 03:17:52 2000 From: jboyle@Level3.net (Jim Boyle) Date: Sun, 17 Dec 2000 20:17:52 -0700 (MST) Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: <200012170744.IAA02178@net4u.net4u.ch> Message-ID: Tony, since you threw the bait in the water... Apologies to the ISIS wg, as this clearly isn't their issue. I think this is an important issue, if interoperability between the transmission equipment utilizing the wonderful IP control plane are to actually interoperate (which is a novel concept in some circles). There is a relevant submission in the NSIF (NSIF-0009-038) which says "use PPP" and then hits on some of the TLI/TMN issues. I'd suggest directing any further discussion of this topic to IPO as it is within the current version of their charter. They might be just as happy making sure that the right progress is being made somewhere, in this case, NSIF. Jim (at least I help cut the line :) On Sun, 17 Dec 2000, Tony Przygienda wrote: > > > > Tony, Ed > > > > A number of companies working in the SONET area already use or are > > planning to use DCC for IP control plane [I put MPLS list back ;), > > since this question is related to GMPLS and OTN-related work]. > > > > There are two types of IP encapsulation on DCC that I know of: > > LAP-D and PPP/HDLC. We use the second one in our SONET products. > > > > I think writing up an IETF document describing this would make sense. > > First, this smells much like ISO thing to do so we'd need an agreement/liason > first from their side. That is obviously only worth pursuiting if we have > authors commiting to provide the cycles first. > > Second, which workgroup ? One of the MPLS offsprings such as GSMP ;-) ? What about > a new one, IPSO (IP over SOnet) ? I'm joking but wouldn't be surprised > if the joke find takers ;-) ? > > thanks > > -- tony > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From prz@net4u.ch Mon Dec 18 03:32:28 2000 From: prz@net4u.ch (Tony Przygienda) Date: Mon, 18 Dec 2000 04:32:28 +0100 (MET) Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: from Jim Boyle at "Dec 17, 2000 8:17:52 pm" Message-ID: <200012180332.EAA14186@net4u.net4u.ch> > > Tony, since you threw the bait in the water... > > Apologies to the ISIS wg, as this clearly isn't their issue. I think > this is an important issue, if interoperability between the > transmission equipment utilizing the wonderful IP control plane are to > actually interoperate (which is a novel concept in some circles). > > There is a relevant submission in the NSIF (NSIF-0009-038) which says > "use PPP" and then hits on some of the TLI/TMN issues. > > I'd suggest directing any further discussion of this topic to IPO > as it is within the current version of their charter. They might be just > as happy making sure that the right progress is being made somewhere, in > this case, NSIF. yepp, I think that was the intention of my e-mail. At least one reader got the meaning between the lines. We have charters to follow here ;-) On the other hand, ISIS-wg has not been unheard of taking outrageous issues that had to be either done very quickly, didn't fit into any other corner of the world or were in the danger of inertia induced death in other, slow moving forums ;-) This one seems to me not being either (maybe yet ;-) thanks -- tony From truskows@cisco.com Mon Dec 18 15:40:37 2000 From: truskows@cisco.com (Mike Truskowski) Date: Mon, 18 Dec 2000 7:40:37 PST Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: <035001c06903$6c6bdb00$1cd01318@frmt1.sfba.home.com>; from "Manohar Ellanti" at Dec 18, 100 7:01 am Message-ID: <200012181540.HAA17062@diablo.cisco.com> For what it is worth, there are NO formal agreements in the NSIF for IP on the DCC and to my knowledge no work in the ITU dealing with the DCC. Mike > > I think there are two aspects to the IP over SONET DCC. One is UNI > Signaling for the purpose of CPE-ONE Signaling and possibly NNI Signaling > and the other is DCN (at least that is the term we used and I believe is > borrowed from work done in Sonet Interoperability Forum) for EMS/NMS. The > latter is something that is discussed quite a bit in SIF and may be in ANSI > T1X1 as well. > > Incase it might help here are some references. > > 1. Brown, Mike, SIF-AR-9804-055, "Survey of Requirements for IP on the > non-DCC DCN," April 15, 1998. > 2. Hunt, Christopher J., SIF-AR-9804-058, "TCP/IP DCN Alternatives," April > 14, 1998. > 3. Jamal, Rashid, SIF-AR-9803-054, "IP On DCN - Sprint's Response," April > 14, 1998. > 4. Reference architecture proposed at May IP DCN conference call. > > I think, SIF primarily focused on use of DCC bytes (called as embedded > operations channel) for SONET network management plane and not for control > plane. IP over PPP over HDLC over DCC bytes as pure network transport > mechanism need not be linked with control plane or management plane. I think > UNI 1.0 does leave scope for UNI signaling messages to be transported using > 1. DCC bytes > 2. SPE > 3. alternate transport such as UNI over internet reaching the ONE. > 4. Ethernet if CPE is co-located with ONE such as in a POP > > A general informational document drawing inputs from SIF, UNI 1.0 and from > other useful dicussions elsewhere might be helpful for IETF community while > avoiding re-inventing some of the issues and operational problems expressed > already and draws from good inputs in the past of lot of people. > > Manohar N Ellanti > > > > ----- Original Message ----- > From: "Riad Hartani" > To: "'Alex Zinin'" ; "Tony Przygienda" > Cc: ; ; > ; ; > Sent: Sunday, December 17, 2000 6:22 PM > Subject: RE: [Isis-wg] Question on DCC Architecture > > > > On this subject, the OIF UNI 1.0 specification (submitted for last call) > > describes, among other things, how to use SONET Line and/or Section DCC > > overhead bytes to transport various IP control plane messages (called IP > > Control Channel -IPCC-). For discovery of information required by the IP > > control plane, both DCC or J0 bytes may be used in the actual proposal. > > > > For the IP control plane, the proposal requires IP packets to be > > encapsulated in PPP over HDLC-like framing with bit stuffing format. The > > spec also describes various aspects related to the selection and > maintenance > > of IPCC parameters, as well as other ways of carrying IP control > information > > in Sonet/WDM environments. > > > > Hope this helps, > > > > Riad > > > > > -----Original Message----- > > > From: Alex Zinin [mailto:azinin@cisco.com] > > > Sent: Sunday, December 17, 2000 9:46 AM > > > To: Tony Przygienda > > > Cc: tli@procket.com; echang@pocketmail.com; > > > isis-wg@spider.juniper.net; > > > skatukam@cisco.com; mpls@UU.NET > > > Subject: Re: [Isis-wg] Question on DCC Architecture > > > > > > > > > > > > Tony, > > > > > > >> A number of companies working in the SONET area already use or are > > > >> planning to use DCC for IP control plane [I put MPLS list back ;), > > > >> since this question is related to GMPLS and OTN-related work]. > > > >> > > > >> There are two types of IP encapsulation on DCC that I know of: > > > >> LAP-D and PPP/HDLC. We use the second one in our SONET products. > > > >> > > > >> I think writing up an IETF document describing this would > > > make sense. > > > > > > > First, this smells much like ISO thing to do so we'd need > > > an agreement/liason > > > > first from their side. That is obviously only worth > > > pursuiting if we have > > > > authors commiting to provide the cycles first. > > > > > > Hmmm... why do you think specification of *IP* encapsulation > > > over SONET DCC > > > using "PPP over HDLC-like framing" is something ISO should do? > > > > > > > Second, which workgroup ? One of the MPLS offsprings such > > > as GSMP ;-) ? What about > > > > a new one, IPSO (IP over SOnet) ? I'm joking but wouldn't > > > be surprised > > > > if the joke find takers ;-) ? > > > > > > Definitely not me ;) > > > > > > I think some kind of individual submission should be ok. I guess > > > the Internet Area is the one that logically hosts it. > > > > > > Thanks, > > > > > > Alex. > > > > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From james.d.carlson@east.sun.com Mon Dec 18 14:59:14 2000 From: james.d.carlson@east.sun.com (James Carlson) Date: Mon, 18 Dec 2000 09:59:14 -0500 (EST) Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: Alex Zinin's message of 16 December 2000 12:26:23 References: <14907.693.141245.416611@alpha-tony.procket.com> <2518.001216@cisco.com> Message-ID: <14910.9794.654736.588261@gargle.gargle.HOWL> Alex Zinin writes: > A number of companies working in the SONET area already use or are > planning to use DCC for IP control plane [I put MPLS list back ;), > since this question is related to GMPLS and OTN-related work]. > > There are two types of IP encapsulation on DCC that I know of: > LAP-D and PPP/HDLC. We use the second one in our SONET products. > > I think writing up an IETF document describing this would make sense. Describing which part? I think there are at least three separate issues here. One is the control plane issue (specifying the use of IP over DCC for carrying control messages), another is the encapsulation (for which RFCs 1332, 1661, and 1662 should do fine), and a third is having ITU-T specify that PPP is a "legal" option for DCC. For the first two issues, I think those are already handled. It's just that third one that might be an issue for some users, and I don't think that can be done within an IETF working group. If you're suggesting a BCP saying that IP/PPP/HDLC/DCC is a good thing, I suppose that's possible, but I don't see what it accomplishes. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From xuyg@lucent.com Mon Dec 18 14:29:11 2000 From: xuyg@lucent.com (Yangguang Xu) Date: Mon, 18 Dec 2000 09:29:11 -0500 Subject: [Isis-wg] Question on DCC Architecture References: Message-ID: <3A3E1F37.72C9E56A@lucent.com> Hello All, Traditionally, SONET/SDH run OSI stack over DCC, that's where the LAPD/DCC came from. For IP traffic, PPP/HDLC/DCC is commonly used. Below is the introduction of DCC from "ietf-koay-mpls-and-optical-00.txt". Details can be found at any ANSI, Bellcore, ITU ... SONET/SDH document. "3.1 Line DCC-MS Line DCC or Multiplex-section DCC are the D4-D12 bytes in the overhead of a SONET or SDH frame respectively. Being in the line or multiplex-section overhead, they are passed thru repeaters in the span. Hence, DCC-MS should be used for neighbor discovery when the link connection contains section terminating regenerators. SDH customers should already be familiar with enabling multiplex-section DCC for management traffic (ITU-T G.784 10/98). In this standard, Line DCC-MS is recommended for routing management traffic and for communication between two SONET/SDH line/MS terminating nodes when regenerators are in the span. 3.2 Section DCC-RS Section DCC or regenerator-section DCC are the D1-D3 bytes in the overhead of a SONET or SDH frame respectively. The section overhead bytes are terminated by regenerators. Since regenerators are not Network Control nodes, Section DCC-RS can be used only if there are no regenerators in the span." However, using in-band control channel always has bandwidth limitation. Remember, DCC are fixed bytes and is not only used by control traffic. The "control plane" (not the data plane) "network" (not only links) should start from understanding its network level requirements (performance, security, reliability and etc.) Which physical medium and its "default" layer 2 protocol should meet the network level requirement and come naturally and conveniently. Yangguang Riad Hartani wrote: > > On this subject, the OIF UNI 1.0 specification (submitted for last call) > describes, among other things, how to use SONET Line and/or Section DCC > overhead bytes to transport various IP control plane messages (called IP > Control Channel -IPCC-). For discovery of information required by the IP > control plane, both DCC or J0 bytes may be used in the actual proposal. > > For the IP control plane, the proposal requires IP packets to be > encapsulated in PPP over HDLC-like framing with bit stuffing format. The > spec also describes various aspects related to the selection and maintenance > of IPCC parameters, as well as other ways of carrying IP control information > in Sonet/WDM environments. > > Hope this helps, > > Riad > > > -----Original Message----- > > From: Alex Zinin [mailto:azinin@cisco.com] > > Sent: Sunday, December 17, 2000 9:46 AM > > To: Tony Przygienda > > Cc: tli@procket.com; echang@pocketmail.com; > > isis-wg@spider.juniper.net; > > skatukam@cisco.com; mpls@UU.NET > > Subject: Re: [Isis-wg] Question on DCC Architecture > > > > > > > > Tony, > > > > >> A number of companies working in the SONET area already use or are > > >> planning to use DCC for IP control plane [I put MPLS list back ;), > > >> since this question is related to GMPLS and OTN-related work]. > > >> > > >> There are two types of IP encapsulation on DCC that I know of: > > >> LAP-D and PPP/HDLC. We use the second one in our SONET products. > > >> > > >> I think writing up an IETF document describing this would > > make sense. > > > > > First, this smells much like ISO thing to do so we'd need > > an agreement/liason > > > first from their side. That is obviously only worth > > pursuiting if we have > > > authors commiting to provide the cycles first. > > > > Hmmm... why do you think specification of *IP* encapsulation > > over SONET DCC > > using "PPP over HDLC-like framing" is something ISO should do? > > > > > Second, which workgroup ? One of the MPLS offsprings such > > as GSMP ;-) ? What about > > > a new one, IPSO (IP over SOnet) ? I'm joking but wouldn't > > be surprised > > > if the joke find takers ;-) ? > > > > Definitely not me ;) > > > > I think some kind of individual submission should be ok. I guess > > the Internet Area is the one that logically hosts it. > > > > Thanks, > > > > Alex. > > > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > From ssnarayanan@lucent.com Mon Dec 18 16:56:35 2000 From: ssnarayanan@lucent.com (S.Sankaranarayanan) Date: Mon, 18 Dec 2000 11:56:35 -0500 Subject: [Isis-wg] Question on DCC Architecture References: <200012181540.HAA17062@diablo.cisco.com> Message-ID: <3A3E41C3.98EA0CBE@hotair.hobl.lucent.com> Just to clarify a point... The ITU-T SG15 Q14 has recently started work on a generic DCN architecture and there was agreement in the last experts meeting in Dec, 2000 that this DCN would be IP based and would address the issue of interworking between an OSI based DCN and IP based DCN. Regards, Shiva From truskows@cisco.com Mon Dec 18 16:08:14 2000 From: truskows@cisco.com (Mike Truskowski) Date: Mon, 18 Dec 2000 8:08:14 PST Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: <3A3E41C3.98EA0CBE@hotair.hobl.lucent.com>; from "S.Sankaranarayanan" at Dec 18, 100 11:56 am Message-ID: <200012181608.IAA09491@diablo.cisco.com> OK, but the DCN is not the DCC. The NSIF, formerly the SIF, worked on the mediation issues dealing with OSI and TCP/IP. The work was incomplete since it dealt with datagrams and not software download. Are you saying that the SG15 is working on mediation in the DCN to include software download? Mike > > Just to clarify a point... > > The ITU-T SG15 Q14 has recently started work on a generic DCN > architecture and there was agreement in the last experts meeting in Dec, > 2000 that this DCN would be IP based and would address the issue of > interworking between an OSI based DCN and IP based DCN. > > Regards, > Shiva > From ctklish@nortelnetworks.com Mon Dec 18 20:26:48 2000 From: ctklish@nortelnetworks.com (Cypryan Klish) Date: Mon, 18 Dec 2000 15:26:48 -0500 Subject: [Isis-wg] Question on DCC Architecture Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C06930.D9287D70 Content-Type: text/plain; charset="iso-8859-1" > OK, but the DCN is not the DCC. Wrong. This is a very common misunderstanding, however, the definitive ITU-T recommendation states otherwise. Specifically, ITU-T M.3010 (02/00) 11.2 states: "The DCN may consist of a number of individual subnetworks of different types, interconnected together. The DCN may be a local path, or a wide area connection among distributed functional blocks. The DCN is technology independent and may employ any single or combination of transmission technologies." Previous editions of M.3010 such as (05/96) contained a similar definition. In fact, section 4.1.4. of M.3010 (05/96) stated: "...The various types of subnetworks may include technology specific subnetwork(s) such as the SDH DCC." In other words the DCC is part of the DCN; the two are not separate. SIF's Architecture Work Group found a need to clarify this further by adapting the terms "access DCN" and "embedded DCN" per the proposal contained in SIF-AR-9808-120; this became common usage in the final year of that work group's activity (1999). As to the scope of the SIF work, it addressed only an IP-based "Access DCN" - the part of the DCN between an OSS and a GNE; see the approved document SIF-033-1999 "Requirements for the TCP/IP Protocol Suite on the SONET Access DCN." This approved document does contain requirements (sections 7.5) for FTP-based file transfers and for a FTP/FTAM translation device, so an infrastructure for software download was put in place, so I don't know what would be considered incomplete about software download support. In fact, Annex C of SIF-033-1999 contains SIF's addional TL1 messages specific to file transfer. However, I don't know if anyone ever implemented these. The SIF IP on the DCC activity was never completed, although some of the contributions identified earlier in this thread are informative as to the issues and discussions. However, note they are just contributions and not approved solutions. Kip Klish -----Original Message----- From: Mike Truskowski [mailto:truskows@cisco.com] Sent: Monday, December 18, 2000 11:08 AM To: ssnarayanan@lucent.com Cc: truskows@cisco.com; ellanti@home.com; riad@caspiannetworks.com; azinin@cisco.com; prz@net4u.ch; tli@procket.com; echang@pocketmail.com; isis-wg@spider.juniper.net; skatukam@cisco.com; mpls@UU.NET Subject: Re: [Isis-wg] Question on DCC Architecture OK, but the DCN is not the DCC. The NSIF, formerly the SIF, worked on the mediation issues dealing with OSI and TCP/IP. The work was incomplete since it dealt with datagrams and not software download. Are you saying that the SG15 is working on mediation in the DCN to include software download? Mike > > Just to clarify a point... > > The ITU-T SG15 Q14 has recently started work on a generic DCN > architecture and there was agreement in the last experts meeting in Dec, > 2000 that this DCN would be IP based and would address the issue of > interworking between an OSI based DCN and IP based DCN. > > Regards, > Shiva > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg ------_=_NextPart_001_01C06930.D9287D70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Question on DCC Architecture

> OK, but the DCN is not the DCC.

Wrong.  This is a very common misunderstanding, = however, the definitive ITU-T recommendation states otherwise.

Specifically, ITU-T M.3010 (02/00) 11.2 = states:

"The DCN may consist of a number of individual = subnetworks of different types, interconnected together.  The DCN = may be a local path, or a wide area connection among distributed = functional blocks.  The DCN is technology independent and may = employ any single or combination of transmission = technologies."

Previous editions of M.3010 such as (05/96) contained = a similar definition.  In fact, section 4.1.4. of M.3010 (05/96) = stated:

"...The various types of subnetworks may include = technology specific subnetwork(s) such as the SDH DCC."

In other words the DCC is part of the DCN; the two = are not separate.

SIF's Architecture Work Group found a need to clarify = this further by adapting the terms "access DCN" and = "embedded DCN" per the proposal contained in SIF-AR-9808-120; = this became common usage in the final year of that work group's = activity (1999).

As to the scope of the SIF work, it addressed only an = IP-based "Access DCN" - the part of the DCN between an OSS = and a GNE; see the approved document SIF-033-1999 "Requirements = for the TCP/IP Protocol Suite on the SONET Access DCN."  This = approved document does contain requirements (sections 7.5) for = FTP-based file transfers and for a FTP/FTAM translation device, so an = infrastructure for software download was put in place, so I don't know = what would be considered incomplete about software download support. In = fact, Annex C of SIF-033-1999 contains SIF's addional TL1 messages = specific to file transfer.  However, I don't know if anyone ever = implemented these.

The SIF IP on the DCC activity was never completed, = although some of the contributions identified earlier in this thread = are informative as to the issues and discussions. However, note they = are just contributions and not approved solutions.

Kip Klish


-----Original Message-----
From: Mike Truskowski [mailto:truskows@cisco.com]=
Sent: Monday, December 18, 2000 11:08 AM
To: ssnarayanan@lucent.com
Cc: truskows@cisco.com; ellanti@home.com; = riad@caspiannetworks.com;
azinin@cisco.com; prz@net4u.ch; tli@procket.com; = echang@pocketmail.com;
isis-wg@spider.juniper.net; skatukam@cisco.com; = mpls@UU.NET
Subject: Re: [Isis-wg] Question on DCC = Architecture


OK, but the DCN is not the DCC.

The NSIF, formerly the SIF, worked on the = mediation
issues dealing with OSI and TCP/IP.  The work = was
incomplete since it dealt with datagrams and = not
software download.  

Are you saying that the SG15 is working on = mediation
in the DCN to include software download?  =

Mike

>
> Just to clarify a point...
>
> The ITU-T SG15 Q14 has recently started work on = a generic DCN
> architecture and there was agreement in the = last experts meeting in Dec,
> 2000 that this DCN would be IP based and would = address the issue of
> interworking between an OSI based DCN and IP = based DCN.
>
> Regards,
> Shiva
>

_______________________________________________
Isis-wg mailing list  -  = Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg

------_=_NextPart_001_01C06930.D9287D70-- From Jonathan.Sadler@tellabs.com Mon Dec 18 22:01:14 2000 From: Jonathan.Sadler@tellabs.com (Jonathan Sadler) Date: Mon, 18 Dec 2000 16:01:14 -0600 Subject: [Isis-wg] Question on DCC Architecture References: Message-ID: <3A3E892A.BEB26662@tellabs.com> However, use of PPP on the Section DCC may cause an interoperability issue if you have a regenerator in line, and it only supports CLNP/LAPD. For that reason, GRE encapsulation (ala the Cisco 15303), or IP over LAPD (ala RFC 1663?) may be a better approach, until a standards body puts a stake in the sand. Another issue not covered is the operational use of IS-IS on this channel. As IS-IS is used by SONET terminal/regenerator gear, what is going to happen to all the CPU and memory constrained ADMs out there when they start receiving the LSPs with all of the TE and GMPLS TLVs? Many are limited to less than 50 nodes and less than 100 links in an Area -- and the Node/Link TLVs are certainly smaller than the TE/GMPLS TLVs. Jonathan Sadler james.d.carlson@east.sun.com wrote: > > Alex Zinin writes: > > A number of companies working in the SONET area already use or are > > planning to use DCC for IP control plane [I put MPLS list back ;), > > since this question is related to GMPLS and OTN-related work]. > > > > There are two types of IP encapsulation on DCC that I know of: > > LAP-D and PPP/HDLC. We use the second one in our SONET products. > > > > I think writing up an IETF document describing this would make sense. > > Describing which part? I think there are at least three separate > issues here. One is the control plane issue (specifying the use of IP > over DCC for carrying control messages), another is the encapsulation > (for which RFCs 1332, 1661, and 1662 should do fine), and a third is > having ITU-T specify that PPP is a "legal" option for DCC. > > For the first two issues, I think those are already handled. It's > just that third one that might be an issue for some users, and I don't > think that can be done within an IETF working group. > > If you're suggesting a BCP saying that IP/PPP/HDLC/DCC is a good > thing, I suppose that's possible, but I don't see what it > accomplishes. > > -- > James Carlson, Internet Engineering > SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From prz@net4u.ch Mon Dec 18 23:13:03 2000 From: prz@net4u.ch (Tony Przygienda) Date: Tue, 19 Dec 2000 00:13:03 +0100 (MET) Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: <3A3E892A.BEB26662@tellabs.com> from Jonathan Sadler at "Dec 18, 2000 4: 1:14 pm" Message-ID: <200012182313.AAA06690@net4u.net4u.ch> > Another issue not covered is the operational use of IS-IS on this > channel. As IS-IS is used by SONET terminal/regenerator gear, what is > going to happen to all the CPU and memory constrained ADMs out there > when they start receiving the LSPs with all of the TE and GMPLS TLVs? > Many are limited to less than 50 nodes and less than 100 links in an > Area -- and the Node/Link TLVs are certainly smaller than the TE/GMPLS > TLVs. This is something that a body equivalent to Nanog in SONET world should probably be concerned with. ISIS working group has as primary topic the standardization of bits on the wires between boxes to make sure that different vendors interoperate. Although things like application guidelines and protocol analysis is common, it would be vain trying to publish RFCs with implementation guidelines since technology is still galloping forward @ a speed that makes such publications often obsolete within months. As to deployment issues with older gear that you outline, IETF has been pretty much shaped by the Darvinian ISP approach "get them to upgrade your software, get them to upgrade your hardware, if they can't, throw the gear away and pick up a better vendor". As an alternate solution, you may just choose not to deploy all that optional new stuff .. --- tony From jlearman@cisco.com Tue Dec 19 00:25:25 2000 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 18 Dec 2000 19:25:25 -0500 Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: <3A3E892A.BEB26662@tellabs.com> References: Message-ID: <4.1.20001218191638.00a648f0@dingdong.cisco.com> At 04:01 PM 12/18/2000 -0600, you wrote: >However, use of PPP on the Section DCC may cause an interoperability >issue if you have a regenerator in line, and it only supports >CLNP/LAPD. For that reason, GRE encapsulation (ala the Cisco 15303), or >IP over LAPD (ala RFC 1663?) may be a better approach, until a standards >body puts a stake in the sand. How would any of these solve this problem? If the regenerator can't handle IP frames, it will drop them regardless of the encapsulation. And this is not just a problem for regenerators, it's an interop problem for any multi-vendor ring. >Another issue not covered is the operational use of IS-IS on this >channel. As IS-IS is used by SONET terminal/regenerator gear, what is >going to happen to all the CPU and memory constrained ADMs out there >when they start receiving the LSPs with all of the TE and GMPLS TLVs? >Many are limited to less than 50 nodes and less than 100 links in an >Area -- and the Node/Link TLVs are certainly smaller than the TE/GMPLS >TLVs. That's only the tip of the iceberg on this issue. According to RFC 1195 (Integrated IS-IS), you can't have any OSI-only routers in a dual-protocol area. If you do, you won't get any error messages -- you'll just get black holes. >Jonathan Sadler > >james.d.carlson@east.sun.com wrote: >> >> Alex Zinin writes: >> > A number of companies working in the SONET area already use or are >> > planning to use DCC for IP control plane [I put MPLS list back ;), >> > since this question is related to GMPLS and OTN-related work]. >> > >> > There are two types of IP encapsulation on DCC that I know of: >> > LAP-D and PPP/HDLC. We use the second one in our SONET products. >> > >> > I think writing up an IETF document describing this would make sense. >> >> Describing which part? I think there are at least three separate >> issues here. One is the control plane issue (specifying the use of IP >> over DCC for carrying control messages), another is the encapsulation >> (for which RFCs 1332, 1661, and 1662 should do fine), and a third is >> having ITU-T specify that PPP is a "legal" option for DCC. >> >> For the first two issues, I think those are already handled. It's >> just that third one that might be an issue for some users, and I don't >> think that can be done within an IETF working group. >> >> If you're suggesting a BCP saying that IP/PPP/HDLC/DCC is a good >> thing, I suppose that's possible, but I don't see what it >> accomplishes. >> >> -- >> James Carlson, Internet Engineering >> SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 >> MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 >> Second Edition now available - http://people.ne.mediaone.net/carlson/ppp >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From jparker@axiowave.com Tue Dec 19 01:38:17 2000 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 18 Dec 2000 20:38:17 -0500 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers Message-ID: The "Sub Second convergence" draft draft-alaettinoglu-ISIS-convergence-00.ps has a number of useful suggestions about implementation. While most of these ideas can be implemented today, the one change that would be needed to include all recommendations would be a new way to encode the hold timer in hello messages. Do the authors plan to put that forward in a later version of the document? - jeff parker From truskows@cisco.com Tue Dec 19 15:59:16 2000 From: truskows@cisco.com (Mike Truskowski) Date: Tue, 19 Dec 2000 7:59:16 PST Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: <200012182313.AAA06690@net4u.net4u.ch>; from "Tony Przygienda" at Dec 19, 100 12:13 (midnight) Message-ID: <200012191559.HAA01127@diablo.cisco.com> The issue is simply stated... while you look at ISIS to enhance it for "IP". Don't break it for "CLNS" because there are 10's of thousands of sonet/sdh NE's relying on ISIS today. Certainly, we in the NSIF can move forward creating an IP stack... but the rings which are already using clns on the DCC will be there for awhile longer. I would prefer running a native protocol end2end while others would rather see clns on the dcc and ip2clns mediation on the DCN. There are no simple answers here. Mike > > > Another issue not covered is the operational use of IS-IS on this > > channel. As IS-IS is used by SONET terminal/regenerator gear, what is > > going to happen to all the CPU and memory constrained ADMs out there > > when they start receiving the LSPs with all of the TE and GMPLS TLVs? > > Many are limited to less than 50 nodes and less than 100 links in an > > Area -- and the Node/Link TLVs are certainly smaller than the TE/GMPLS > > TLVs. > > This is something that a body equivalent to Nanog in SONET world should > probably be concerned with. ISIS working group has as primary topic the > standardization of bits on the wires between boxes to make sure that > different vendors interoperate. Although things like application > guidelines and protocol analysis is common, it would be vain trying to > publish RFCs with implementation guidelines since technology is still > galloping forward @ a speed that makes such publications often obsolete > within months. As to deployment issues with older gear that you outline, > IETF has been pretty much shaped by the Darvinian ISP approach "get them to > upgrade your software, get them to upgrade your hardware, if they can't, > throw the gear away and pick up a better vendor". As an alternate solution, > you may just choose not to deploy all that optional new stuff .. > > --- tony > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From Jonathan.Sadler@tellabs.com Tue Dec 19 16:14:12 2000 From: Jonathan.Sadler@tellabs.com (Jonathan Sadler) Date: Tue, 19 Dec 2000 10:14:12 -0600 Subject: [Isis-wg] Question on DCC Architecture References: Message-ID: <3A3F8954.5B177B07@tellabs.com> At 19:25:25 12/18/2000 -0500, jlearman@cisco.com wrote: > > At 04:01 PM 12/18/2000 -0600, you wrote: > >However, use of PPP on the Section DCC may cause an interoperability > >issue if you have a regenerator in line, and it only supports > >CLNP/LAPD. For that reason, GRE encapsulation (ala the Cisco 15303), or > >IP over LAPD (ala RFC 1663?) may be a better approach, until a standards > >body puts a stake in the sand. > > How would any of these solve this problem? If the regenerator can't > handle IP frames, it will drop them regardless of the encapsulation. > And this is not just a problem for regenerators, it's an interop > problem for any multi-vendor ring. Agreed. However, autoconfiguration of a link becomes harder if the link layer protocol is not consistant for Dual and OSI-only interfaces. Of course use of GRE is the band-aid of last resort to connect IP islands. > >Another issue not covered is the operational use of IS-IS on this > >channel. As IS-IS is used by SONET terminal/regenerator gear, what is > >going to happen to all the CPU and memory constrained ADMs out there > >when they start receiving the LSPs with all of the TE and GMPLS TLVs? > >Many are limited to less than 50 nodes and less than 100 links in an > >Area -- and the Node/Link TLVs are certainly smaller than the TE/GMPLS > >TLVs. > > That's only the tip of the iceberg on this issue. According to > RFC 1195 (Integrated IS-IS), you can't have any OSI-only routers in > a dual-protocol area. Again agreed. However, it is possible to have OSI only links on a dual router. Some vendors are utilizing this capability to add Integrated IS-IS support to their nodes in anticipation of IP over DCC being standardized. > If you do, you won't get any error messages -- > you'll just get black holes. Actually, 1195 does require generation of ICMP host unreachable and CLNP destination unreachable messages when a dual router identifies that the next hop is, respectively, IP or OSI incapable. > >Jonathan Sadler > > > >james.d.carlson@east.sun.com wrote: > >> > >> Alex Zinin writes: > >> > A number of companies working in the SONET area already use or are > >> > planning to use DCC for IP control plane [I put MPLS list back ;), > >> > since this question is related to GMPLS and OTN-related work]. > >> > > >> > There are two types of IP encapsulation on DCC that I know of: > >> > LAP-D and PPP/HDLC. We use the second one in our SONET products. > >> > > >> > I think writing up an IETF document describing this would make sense. > >> > >> Describing which part? I think there are at least three separate > >> issues here. One is the control plane issue (specifying the use of IP > >> over DCC for carrying control messages), another is the encapsulation > >> (for which RFCs 1332, 1661, and 1662 should do fine), and a third is > >> having ITU-T specify that PPP is a "legal" option for DCC. > >> > >> For the first two issues, I think those are already handled. It's > >> just that third one that might be an issue for some users, and I don't > >> think that can be done within an IETF working group. > >> > >> If you're suggesting a BCP saying that IP/PPP/HDLC/DCC is a good > >> thing, I suppose that's possible, but I don't see what it > >> accomplishes. > >> > >> -- > >> James Carlson, Internet Engineering > >> SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > >> MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > >> Second Edition now available - http://people.ne.mediaone.net/carlson/ppp > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg From yzhou@mahinetworks.com Tue Dec 19 17:21:38 2000 From: yzhou@mahinetworks.com (Yuchen Zhou) Date: Tue, 19 Dec 2000 09:21:38 -0800 Subject: [Isis-wg] ISIS compliance test Message-ID: <9D6D37E97A57D411BB7C00508BAE29C90FD5D9@main.mahinetworks.com> Hi, Does anyone know of any ISIS compliance /interoperability test suites / tools? UNH InterOp lab does not seem to have such a suite, while QA Robot does. Yuchen From Alex Zinin Tue Dec 19 18:34:35 2000 From: Alex Zinin (Alex Zinin) Date: Tue, 19 Dec 2000 10:34:35 -0800 Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: <14910.9794.654736.588261@gargle.gargle.HOWL> References: <14910.9794.654736.588261@gargle.gargle.HOWL> Message-ID: <16440.001219@cisco.com> James, I'm talking mostly about the second part. The question such a document (BCP or whatever status) could address is "how does one send IP over a SONET DCC channel?". The answer could be as simple as "by using RFC1662 encapsulation and treating D{1-3}/D{4-12} OH bytes as a synchronous stream of octets", i.e., not by using LAP-D, or LAP-B, or SLIP, and not trying to align HDLC frames within the sequence of SONET frames. -- Alex Zinin Monday, December 18, 2000, 6:59 AM, James Carlson wrote: > Alex Zinin writes: >> A number of companies working in the SONET area already use or are >> planning to use DCC for IP control plane [I put MPLS list back ;), >> since this question is related to GMPLS and OTN-related work]. >> >> There are two types of IP encapsulation on DCC that I know of: >> LAP-D and PPP/HDLC. We use the second one in our SONET products. >> >> I think writing up an IETF document describing this would make sense. > Describing which part? I think there are at least three separate > issues here. One is the control plane issue (specifying the use of IP > over DCC for carrying control messages), another is the encapsulation > (for which RFCs 1332, 1661, and 1662 should do fine), and a third is > having ITU-T specify that PPP is a "legal" option for DCC. > For the first two issues, I think those are already handled. It's > just that third one that might be an issue for some users, and I don't > think that can be done within an IETF working group. > If you're suggesting a BCP saying that IP/PPP/HDLC/DCC is a good > thing, I suppose that's possible, but I don't see what it > accomplishes. From hshah@tenornetworks.com Tue Dec 19 18:50:50 2000 From: hshah@tenornetworks.com (Shah, Himanshu) Date: Tue, 19 Dec 2000 13:50:50 -0500 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers Message-ID: <6B190B34070BD411ACA000B0D0214E563A8135@newman.tenornet.com> OSPF restart (which I guess can be extended for ISIS) and fast convergence seems to have conflicting goal (by way of affecting routerDeadInterval, one desiring longer other desiring shorter), don't you think? This needs to be tackled in one or the other RFC too. -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Monday, December 18, 2000 8:38 PM To: isis-wg@spider.juniper.net Subject: [Isis-wg] [IS-IS WG] Subsecond Timers The "Sub Second convergence" draft draft-alaettinoglu-ISIS-convergence-00.ps has a number of useful suggestions about implementation. While most of these ideas can be implemented today, the one change that would be needed to include all recommendations would be a new way to encode the hold timer in hello messages. Do the authors plan to put that forward in a later version of the document? - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From james.d.carlson@east.sun.com Tue Dec 19 19:02:32 2000 From: james.d.carlson@east.sun.com (James Carlson) Date: Tue, 19 Dec 2000 14:02:32 -0500 (EST) Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: Alex Zinin's message of 19 December 2000 10:34:35 References: <14910.9794.654736.588261@gargle.gargle.HOWL> <16440.001219@cisco.com> Message-ID: <14911.45256.826676.896877@gargle.gargle.HOWL> Alex Zinin writes: > I'm talking mostly about the second part. > > The question such a document (BCP or whatever status) could > address is "how does one send IP over a SONET DCC channel?". > The answer could be as simple as "by using RFC1662 encapsulation > and treating D{1-3}/D{4-12} OH bytes as a synchronous stream > of octets", i.e., not by using LAP-D, or LAP-B, or SLIP, and > not trying to align HDLC frames within the sequence of SONET > frames. Note that there are no IETF documents covering, for instance, how to carry PPP over T1 lines. I don't consider that to be a gap that necessarily needs to be filled. Similarly, I think the treatment of D1-D3 as one bit-oriented synchronous data stream (Section DCC) and D4-D12 as another (Line DCC) is a rather obvious usage of those SONET features that doesn't need a separate draft for interoperable use. I don't think SLIP is a serious suggestion (is it?), since it has no error control or protection against address misconfiguration. LAP-D/B/F variants are possible, but similarly somewhat outside the control of the IETF. That's why I suggested a BCP instead. I don't see it as a standards issue but rather a usage issue. (If some implementations concatenate D1-D12 together, then I suppose that could be a problem, and would need standards language, but, again, probably not from the IETF.) -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From jparker@axiowave.com Tue Dec 19 19:15:42 2000 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 19 Dec 2000 14:15:42 -0500 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers Message-ID: My understanding of the two proposals has them in strict opposition: the convergence draft tries to minimize the impact of a crash by reducing the time needed to route around any problem, and the Restart proposal tries to work fast enough to avoid getting caught. Of course there are other uses for this functionality, but if you know you want to bring one side down for an upgrade, you can simply configure the box to start sending hellos with a longer Holding Timer. In IS-IS each side gets to dictate their own criteria. I think that if you try this with OSPF, the other side will break the association. My point on the converge draft was simply this: there is only one aspect of the draft that describes on-the-wire behavior, and that would have to do with the meaning of the Holding Time. One side could send "1" if we trusted both sides to be able to respond to hellos in a timely fashion, but we cannot go below that with today's draft. If the authors think 1 second is fast enough, we could simply change the granularity of the resend in the MIB, and keep the protocol behavior unchanged. - jeff parker > OSPF restart (which I guess can be extended for ISIS) and > fast convergence seems to have conflicting goal (by way of > affecting routerDeadInterval, one desiring longer other > desiring shorter), don't you think? > > This needs to be tackled in one or the other RFC too. > > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Monday, December 18, 2000 8:38 PM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] [IS-IS WG] Subsecond Timers > > > The "Sub Second convergence" draft > > draft-alaettinoglu-ISIS-convergence-00.ps > > has a number of useful suggestions about > implementation. While most of these ideas > can be implemented today, the one change that > would be needed to include all recommendations > would be a new way to encode the hold timer in > hello messages. Do the authors plan to put that > forward in a later version of the document? > > - jeff parker > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From hshah@tenornetworks.com Tue Dec 19 19:51:08 2000 From: hshah@tenornetworks.com (Shah, Himanshu) Date: Tue, 19 Dec 2000 14:51:08 -0500 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers Message-ID: <6B190B34070BD411ACA000B0D0214E563A8138@newman.tenornet.com> I understand your point and am not contradicting that point. My point is that, If I understand correctly, router restart's proposed goal is to restart before neighbor declares him dead and proceed to clean up. If routerDeadInterval is in sub-seconds, restart may not complete. If this is a point to worry about then it should be addressed or mentioned. If not, no sweat.. If ISIS allows changing hold times on per packet basis then your described method would work for managed restarts for ISIS. However, if that hello packet got lost after changed configuration in congestion (which can happen in busy network :-) then you may have to hope for the best... -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Tuesday, December 19, 2000 2:16 PM To: 'Shah, Himanshu'; Jeff Parker; isis-wg@spider.juniper.net Subject: RE: [Isis-wg] [IS-IS WG] Subsecond Timers My understanding of the two proposals has them in strict opposition: the convergence draft tries to minimize the impact of a crash by reducing the time needed to route around any problem, and the Restart proposal tries to work fast enough to avoid getting caught. Of course there are other uses for this functionality, but if you know you want to bring one side down for an upgrade, you can simply configure the box to start sending hellos with a longer Holding Timer. In IS-IS each side gets to dictate their own criteria. I think that if you try this with OSPF, the other side will break the association. My point on the converge draft was simply this: there is only one aspect of the draft that describes on-the-wire behavior, and that would have to do with the meaning of the Holding Time. One side could send "1" if we trusted both sides to be able to respond to hellos in a timely fashion, but we cannot go below that with today's draft. If the authors think 1 second is fast enough, we could simply change the granularity of the resend in the MIB, and keep the protocol behavior unchanged. - jeff parker > OSPF restart (which I guess can be extended for ISIS) and > fast convergence seems to have conflicting goal (by way of > affecting routerDeadInterval, one desiring longer other > desiring shorter), don't you think? > > This needs to be tackled in one or the other RFC too. > > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Monday, December 18, 2000 8:38 PM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] [IS-IS WG] Subsecond Timers > > > The "Sub Second convergence" draft > > draft-alaettinoglu-ISIS-convergence-00.ps > > has a number of useful suggestions about > implementation. While most of these ideas > can be implemented today, the one change that > would be needed to include all recommendations > would be a new way to encode the hold timer in > hello messages. Do the authors plan to put that > forward in a later version of the document? > > - jeff parker > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From prz@net4u.ch Tue Dec 19 19:57:46 2000 From: prz@net4u.ch (Tony Przygienda) Date: Tue, 19 Dec 2000 20:57:46 +0100 (MET) Subject: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: from Jeff Parker at "Dec 19, 2000 2:15:42 pm" Message-ID: <200012191957.UAA30001@net4u.net4u.ch> > My understanding of the two proposals has them > in strict opposition: the convergence draft > tries to minimize the impact of a crash by > reducing the time needed to route around any > problem, and the Restart proposal tries to > work fast enough to avoid getting caught. > > Of course there are other uses for this > functionality, but if you know you want to > bring one side down for an upgrade, you can > simply configure the box to start sending > hellos with a longer Holding Timer. > In IS-IS each side gets to dictate their own > criteria. I think that if you try this with > OSPF, the other side will break the association. > > My point on the converge draft was simply this: > there is only one aspect of the draft that > describes on-the-wire behavior, and that would > have to do with the meaning of the Holding Time. > One side could send "1" if we trusted both sides to > be able to respond to hellos in a timely fashion, > but we cannot go below that with today's draft. > If the authors think 1 second is fast enough, we > could simply change the granularity of the resend > in the MIB, and keep the protocol behavior unchanged. > > - jeff parker ISIS restart draft doesn't even exist yet and the fast convergence draft is _not_ a workgroup item and had generated some contingency in terms of viability, therefore I would prefer not to see work going on based on extrapolation of things to come but rather have the group focused working on items within our scope. That does not mean thta I discourage the discussions happening, but I'd prefer not to see changes creeping into existing drafts before the facts. -- tony From rbush@bainbridge.verio.net Tue Dec 19 16:06:28 2000 From: rbush@bainbridge.verio.net (Randy Bush) Date: Tue, 19 Dec 2000 08:06:28 -0800 Subject: [Isis-wg] Question on DCC Architecture References: <200012182313.AAA06690@net4u.net4u.ch> <200012191559.HAA01127@diablo.cisco.com> Message-ID: there are small security advantages to NOT having is-is over ip randy From jharper@cisco.com Tue Dec 19 21:09:39 2000 From: jharper@cisco.com (John Harper) Date: Tue, 19 Dec 2000 21:09:39 +0000 Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: References: <200012182313.AAA06690@net4u.net4u.ch> <200012191559.HAA01127@diablo.cisco.com> Message-ID: <4.3.2.7.2.20001219210836.02a17038@jaws.cisco.com> Not true - there are BIG security advantages to not having is-is over ip. It rules out a huge class of spoofing attacks to which OSPF is vulnerable. Further, there are no evident advantages to having is-is over ip, at least not that I have ever heard of. John At 08:06 19/12/2000 -0800, Randy Bush wrote: >there are small security advantages to NOT having is-is over ip > >randy >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From prz@net4u.ch Tue Dec 19 21:20:22 2000 From: prz@net4u.ch (Tony Przygienda) Date: Tue, 19 Dec 2000 22:20:22 +0100 (MET) Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: <4.3.2.7.2.20001219210836.02a17038@jaws.cisco.com> from John Harper at "Dec 19, 2000 9: 9:39 pm" Message-ID: <200012192120.WAA31189@net4u.net4u.ch> > Not true - there are BIG security advantages to not having is-is over ip. > It rules > out a huge class of spoofing attacks to which OSPF is vulnerable. last I checked nobody saw them so the whole thing is more a mental construct than reality. And even if, running proper security in your routing protocol is a pretty good answer to that ... > Further, > there are no evident advantages to having is-is over ip, at least not that I > have ever heard of. there are some, they are just not that important at the moment and that's why the work is dormant. One day we may run out of patience defining IS-IS encaps for every new link-layer technology that comes our way or really want to solve the MTU problem or maybe simply run out of smallest MTU times 255 LSPs bytes space in the protocol and then it may become a very handy tool thanks -- tony From jlearman@cisco.com Tue Dec 19 21:41:12 2000 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 19 Dec 2000 16:41:12 -0500 Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: <14911.45256.826676.896877@gargle.gargle.HOWL> References: <14910.9794.654736.588261@gargle.gargle.HOWL> <16440.001219@cisco.com> Message-ID: <4.1.20001219163611.00a558d0@dingdong.cisco.com> >That's why I suggested a BCP instead. I don't see it as a standards >issue but rather a usage issue. This is not an IETF standards issue, it's a SONET NE standards issue. Vendors need to know what to implement to ensure the widest interoperability. This is not the forum to discuss them, although it was a reasonable one to ask the question in order to get the appropriate redirects (which were provided by several responses). Regards, Jeff From jlearman@cisco.com Tue Dec 19 22:22:26 2000 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 19 Dec 2000 17:22:26 -0500 Subject: [Isis-wg] Question on DCC Architecture Message-ID: <4.1.20001219172222.00a7e6f0@dingdong.cisco.com> Folks, I don't think this thread (IP on SONET DCC) has anything to do with IS-IS over IP. Please pick a new topic if you have something to say about that. Thanks, Jeff >there are small security advantages to NOT having is-is over ip > >randy >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From dkatz@juniper.net Tue Dec 19 21:54:44 2000 From: dkatz@juniper.net (Dave Katz) Date: Tue, 19 Dec 2000 13:54:44 -0800 (PST) Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: <4.3.2.7.2.20001219210836.02a17038@jaws.cisco.com> (message from John Harper on Tue, 19 Dec 2000 21:09:39 +0000) Message-ID: <200012192154.NAA29817@cirrus.juniper.net> There was the ATM-VCMUX-encaps-to-avoid-two-cell-TCP-ACKs argument, but Henk's NLPID scheme (a truly wonderful reverse-ISO hack) is a hell of a lot simpler. Not true - there are BIG security advantages to not having is-is over ip. It rules out a huge class of spoofing attacks to which OSPF is vulnerable. Further, there are no evident advantages to having is-is over ip, at least not that I have ever heard of. From jlearman@cisco.com Tue Dec 19 22:04:42 2000 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 19 Dec 2000 17:04:42 -0500 Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: <200012192120.WAA31189@net4u.net4u.ch> References: <4.3.2.7.2.20001219210836.02a17038@jaws.cisco.com> Message-ID: <4.1.20001219170224.00a75460@dingdong.cisco.com> I don't think this thread (IP on SONET DCC) has anything to do with IS-IS over IP. Please pick a new topic if you have something to say about that. Thanks, Jeff At 10:20 PM 12/19/2000 +0100, Tony Przygienda wrote: >> Not true - there are BIG security advantages to not having is-is over ip. >> It rules >> out a huge class of spoofing attacks to which OSPF is vulnerable. > >last I checked nobody saw them so the whole thing is more a mental >construct than reality. And even if, running proper security in your >routing protocol is a pretty good answer to that ... > >> Further, >> there are no evident advantages to having is-is over ip, at least not that I >> have ever heard of. > >there are some, they are just not that important at the moment and that's >why the work is dormant. One day we may run out of patience defining IS-IS >encaps for every new link-layer technology that comes our way or really >want to solve the MTU problem or maybe simply run out of smallest MTU times >255 LSPs bytes space in the protocol and then it may become a very handy tool > > thanks > > -- tony > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg From rja@inet.org Tue Dec 19 22:05:12 2000 From: rja@inet.org (RJ Atkinson) Date: Tue, 19 Dec 2000 17:05:12 -0500 Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: <4.3.2.7.2.20001219210836.02a17038@jaws.cisco.com> References: <200012182313.AAA06690@net4u.net4u.ch> <200012191559.HAA01127@diablo.cisco.com> Message-ID: <5.0.0.25.2.20001219170332.00a0e1b0@gnat.inet.org> At 16:09 19/12/00, John Harper wrote: >Not true - there are BIG security advantages >to not having is-is over ip. Randy was right, IMHO, the advantages are modest. >It rules out a huge class of spoofing attacks to which OSPF >is vulnerable. OSPF is not vulnerable at all to spoofing attacks if configured properly (e.g. MD5 enabled, reasonable keys chosen). >Further, >there are no evident advantages to having is-is over ip, Agree. Ran rja@inet.org From rbush@bainbridge.verio.net Wed Dec 20 01:28:09 2000 From: rbush@bainbridge.verio.net (Randy Bush) Date: Tue, 19 Dec 2000 17:28:09 -0800 Subject: [Isis-wg] Question on DCC Architecture References: <200012182313.AAA06690@net4u.net4u.ch> <200012191559.HAA01127@diablo.cisco.com> <4.3.2.7.2.20001219210836.02a17038@jaws.cisco.com> Message-ID: >> there are small security advantages to NOT having is-is over ip > Not true - there are BIG security advantages to not having is-is over ip. not being in sales or at a vendor, i am used to making more moderate claims :-) From rbush@bainbridge.verio.net Wed Dec 20 02:02:26 2000 From: rbush@bainbridge.verio.net (Randy Bush) Date: Tue, 19 Dec 2000 18:02:26 -0800 Subject: [Isis-wg] Question on DCC Architecture References: <4.3.2.7.2.20001219210836.02a17038@jaws.cisco.com> <200012192120.WAA31189@net4u.net4u.ch> Message-ID: >> Not true - there are BIG security advantages to not having is-is over ip. >> It rules out a huge class of spoofing attacks to which OSPF is >> vulnerable. > last I checked nobody saw them i assure you that the ops community, at least the wiser part of it, sees them. > And even if, running proper security in your routing protocol is a pretty > good answer to that ... except the beast does not exist. md5 sigs are not considered strong. randy From prz@net4u.ch Wed Dec 20 02:46:31 2000 From: prz@net4u.ch (Tony Przygienda) Date: Wed, 20 Dec 2000 03:46:31 +0100 (MET) Subject: [Isis-wg] Question on DCC Architecture In-Reply-To: from Randy Bush at "Dec 19, 2000 6: 2:26 pm" Message-ID: <200012200246.DAA02309@net4u.net4u.ch> > >> Not true - there are BIG security advantages to not having is-is over ip. > >> It rules out a huge class of spoofing attacks to which OSPF is > >> vulnerable. > > last I checked nobody saw them > > i assure you that the ops community, at least the wiser part of it, sees > them. I didn't argue that they don't _exist_, I argued that I didn't hear of many incidents where ISP OSPF backbones were target of such attacks (contrary to some fancy BGP TCP attacks ;-) And if such attacks are being performed and I'm unaware of those, doing things like dropping OSPF packets with TTL>1 (with necessary exceptions) is a fairly trivial fix on the fast-path for many vendors. > > And even if, running proper security in your routing protocol is a pretty > > good answer to that ... > > except the beast does not exist. md5 sigs are not considered strong. about 1 1/2 years ago there was some wind that some guy came close to crack MD5 with serious computing power but didn't happen as far I heard. I get the impression that we're arguing here for the sake of the argument now and not the technical content anymore, so that's my last e-mail on this thread. BTW, Randy and others, pls subscribe to isis-wg list if you keep posting to it, otherwise it's quite a pain to let e-mails of non-subscribers in since we're running it moderated (which is a very good solution, thanks to Juniper hosting it ;-) -- tony From cengiz@packetdesign.com Fri Dec 22 18:12:00 2000 From: cengiz@packetdesign.com (Cengiz Alaettinoglu) Date: Fri, 22 Dec 2000 10:12:00 -0800 (PST) Subject: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <200012191957.UAA30001@net4u.net4u.ch> References: <200012191957.UAA30001@net4u.net4u.ch> Message-ID: <14915.39280.503477.749864@localhost.localdomain> Tony Przygienda (prz@net4u.ch) on December 19: > ISIS restart draft doesn't even exist yet and the > fast convergence draft is _not_ a workgroup item > and had generated some contingency in terms of > viability, > therefore I would prefer not to see work going on based on > extrapolation of things to come but rather have the > group focused working on items within our scope. > That does not mean thta I discourage the discussions > happening, but I'd prefer not to see changes > creeping into existing drafts before the facts. Tony, A large group of people who spoke at the microphone expressed the need/interest for this. The topic is of increasing interest. It's difficult to get credible experience with the real effects of using sub-second timers if they can't be specified. It is all right for some vendors not to be able to implement this today because they lack the horsepower (which becomes more and more available everyday). But, some vendors who want to differentiate their products will want to implement this sooner. And everyone will get there eventually. It is better to have a standard way of specifying this. (We are not suggesting everyone to switch using subsecond timers immediately nor instead of a level-2 notification scheme. But the WG should not stop people from being able to do so). The subsecond convergence is covered by the WG charter. Hence, this work can be a WG item if the chairs/WG agree. I dont mind doing the work with other volunteers to write what needs to be added to the wire protocol into a short draft. Happy holidays, Cengiz -- Cengiz Alaettinoglu Packet Design Inc. From prz@net4u.ch Fri Dec 22 21:23:56 2000 From: prz@net4u.ch (Tony Przygienda) Date: Fri, 22 Dec 2000 22:23:56 +0100 (MET) Subject: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <14915.39280.503477.749864@localhost.localdomain> from Cengiz Alaettinoglu at "Dec 22, 2000 10:12: 0 am" Message-ID: <200012222123.WAA05244@net4u.net4u.ch> > > Tony Przygienda (prz@net4u.ch) on December 19: > > ISIS restart draft doesn't even exist yet and the > > fast convergence draft is _not_ a workgroup item > > and had generated some contingency in terms of > > viability, > > therefore I would prefer not to see work going on based on > > extrapolation of things to come but rather have the > > group focused working on items within our scope. > > That does not mean thta I discourage the discussions > > happening, but I'd prefer not to see changes > > creeping into existing drafts before the facts. > > Tony, > > A large group of people who spoke at the microphone expressed the > need/interest for this. The topic is of increasing interest. whether the discussion on the mike expressed need/interest or only mild interest/irritation (Vijay) is bound to interpretation by parties tinted by the agenda they pursuit so I don't buy this argument. There was no motion made and consensus built and implying any such thing on the list here should be done only carefully. > It's difficult to get credible experience with the real effects of > using sub-second timers if they can't be specified. It is all right > for some vendors not to be able to implement this today because they > lack the horsepower (which becomes more and more available > everyday). Lack of horsepower is not the problem with sub-second hellos in terms of _real_ implementation of such protocols, this is just something you extrapolated from your black-box observatioons. There were people (including me) doing that sub-second stuff on different IGPs in proprietary fashion around for quite a long time and the effects were to put it mildly "surprising". Otherwise, believe me, it would have been widely deployed already. > But, some vendors who want to differentiate their products > will want to implement this sooner. And everyone will get there > eventually. It is better to have a standard way of specifying > this. (We are not suggesting everyone to switch using subsecond timers > immediately nor instead of a level-2 notification scheme. But the WG > should not stop people from being able to do so). > The subsecond convergence is covered by the WG charter. There is a lot of things that can be interpreted as "being in the charter" but won't make sense. Are you making a formal motion here to make the "subsecond-timers" being a workgroup item ? And if so, it would help your cause immensly to have a couple of ISPs deploying the protocol today on a large scale saying "yes, go for it" on this list and moreover, clearly stating what is the problem this sub-second hellos they hope will solve for them ? And then, of course workgroup items need a draft so we know what we talk about in terms of bits & bytes first. > Hence, this > work can be a WG item if the chairs/WG agree. I dont mind doing the > work with other volunteers to write what needs to be added to the wire > protocol into a short draft. IMHO, that only makes sense if you remain completely backwards-compatible with the existing implementations. If you intend to change the hello interval fields or their semantics in the existing hello-packets than I would say, you rather sit on the sidelines until a new version of IS-IS happens that will not be compatible with the deployed one or convince some preople to do it under the wraps as proprietary thing or move the work into IRTF since I would be most reluctant to open the "new ISIS-version" can of worms right now. thta's all modulo other Tony's opinion of course since I didn't have any chance to syn up with him on that topic yet ... -- tony From vijay@umbc.edu Fri Dec 22 22:46:10 2000 From: vijay@umbc.edu (Vijay Gill) Date: Fri, 22 Dec 2000 17:46:10 -0500 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <14915.39280.503477.749864@localhost.localdomain> Message-ID: On Fri, 22 Dec 2000, Cengiz Alaettinoglu wrote: > A large group of people who spoke at the microphone expressed the > need/interest for this. The topic is of increasing interest. Having worked with very large scale networks, the trendline based on emprical experience, network meltdowns, and implementation failures has always been to turn up the timers such as hellos and the hello-mults. Emperical observations from working on ISP type networks indicate that setting the isis hello-multiplier to 12 or thereabouts seem to result in more stable networks. > It's difficult to get credible experience with the real effects of > using sub-second timers if they can't be specified. It is all right But first, instead of setting the multipliers and timers to milliseconds, getting the large isps to set them to 3 down from 12 might be a good interim step. Large networks prefer stability before speed of convergence in general, and a reduction in a factor of 4 should give us good feedback. > for some vendors not to be able to implement this today because they > lack the horsepower (which becomes more and more available everyday). > But, some vendors who want to differentiate their products will want > to implement this sooner. And everyone will get there eventually. It Considering that vendors can barely implement the spec as it stands. The number of people I'd trust to implement isis, (outside of Dr. Li, John Moy, Dr. Przygienda, henk, dkatz and bcole) I can count on one hand), I'll not be holding my breath anytime soon that these vendors will actually see use in operational networks of any size. /vijay From henk@procket.com Sat Dec 23 00:35:02 2000 From: henk@procket.com (Henk Smit) Date: Sat, 23 Dec 2000 01:35:02 +0100 (MET) Subject: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: from "Vijay Gill" at Dec 22, 2000 05:46:10 PM Message-ID: <200012230035.BAA01424@kraak.procket.com> Vijay wrote: > Having worked with very large scale networks, the trendline based on > emprical experience, network meltdowns, and implementation failures has > always been to turn up the timers such as hellos and the hello-mults. > > Emperical observations from working on ISP type networks indicate that > setting the isis hello-multiplier to 12 or thereabouts seem to result in > more stable networks. Most of this "empirical experience" is based on very old networks built out of routers with 20 MHz processors (cisco 7000s come to mind). And in those days the queuing strategies on linecards, and between linecards and control planes was all less elaborate. FYI, when I worked at cisco, I have worked with customers that used holdtimes of only several seconds, but those were not ISPs. > But first, instead of setting the multipliers and timers to milliseconds, > getting the large isps to set them to 3 down from 12 might be a good > interim step. Large networks prefer stability before speed of convergence > in general, and a reduction in a factor of 4 should give us good feedback. Note that the lowest possible value of the ISIS holdtimer is 1 second. With the current protocol one could let a router send, say, 5 hellos in 1 second. That would be a considerable improvement over today's networks. (For those that are interested, over a year ago I implemented a feature in cisco IOS that would allow you to configure a holdtime of just one second. This feature is available in 12.1 for sure. Ask you cisco support about the details. Maybe Stefano has ported it to 12.0S). I agree it would be very interesting if some networks (ISPs or other networks) would get more familiar with holdtimes of 1 second before we define a new TLV. On the other hand, issuing an experimental TLV would not hurt much. > Considering that vendors can barely implement the spec as it stands. The > number of people I'd trust to implement isis, (outside of Dr. Li, John > Moy, Dr. Przygienda, henk, dkatz and bcole) I can count on one hand), I'll > not be holding my breath anytime soon that these vendors will actually see > use in operational networks of any size. Thank you very much. But you are exaggerating. I don't think low holdtimers are the tricky thing to implement fast convergence. The tricky part is to react quickly to events in your network, without ever risking a meltdown. There is more to it than just faster hellos. Tony Prz wrote: > IMHO, that only makes sense if you remain completely > backwards-compatible with the existing implementations. If you intend > to change the hello interval fields or their semantics in the existing > hello-packets than I would say, you rather sit on the sidelines until > a new version of IS-IS happens that will not be compatible with the > deployed one or convince some preople to do it under the wraps as > proprietary thing or move the work into IRTF since I would be most > reluctant to open the "new ISIS-version" can of worms right now. Tony, maybe you should do a little technical thinking before we start the politics. ;-) Doing sub-second holdtimers in a backward compatible manner is *very* simple. All we need is a new TLV to be included in the IIHs. Don't forget this is not OSPF. You configure the holdtimer on the router that is sending the IIHs. Suppose you configure your router to send an IIH every 20 ms, and you want the holdtime to be 100 ms. So what your router must do is: 1) send hello every 20 ms 2) set the old-fashioned advertised holdtimer to 1 second 3) set the advertised holdtimer in the new TLV to 100 milliseconds. If the neighbor supports the new TLV, it will see both the 1 second old-fashioned holdtimer and the new-fashioned 100 millisecond holdtimer. Of course it will prefer the new holdtimer. So after the neighbor missed 5 hellos from your router, it will declare the adjacency down. Exactly what your wanted. If the neighbor does not support the new TLV, it will use a holdtime of 1 second. So only after it missed 50 hellos it will declare the adjecency down. Not very quick, but still it would detect the down event. And the simplicity is that there is no negotiation involved at all. You include the TLV or you don't. You understand it when you receive it, or you don't. The protocol does not break. Hope this helps, Henk. From prz@net4u.ch Sat Dec 23 00:28:34 2000 From: prz@net4u.ch (Tony Przygienda) Date: Sat, 23 Dec 2000 01:28:34 +0100 (MET) Subject: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <200012230035.BAA01424@kraak.procket.com> from Henk Smit at "Dec 23, 2000 1:35: 2 am" Message-ID: <200012230028.BAA07021@net4u.net4u.ch> > Tony Prz wrote: > > > IMHO, that only makes sense if you remain completely > > backwards-compatible with the existing implementations. If you intend > > to change the hello interval fields or their semantics in the existing > > hello-packets than I would say, you rather sit on the sidelines until > > a new version of IS-IS happens that will not be compatible with the > > deployed one or convince some preople to do it under the wraps as > > proprietary thing or move the work into IRTF since I would be most > > reluctant to open the "new ISIS-version" can of worms right now. > > Tony, maybe you should do a little technical thinking before we > start the politics. ;-) Doing sub-second holdtimers in a backward > compatible manner is *very* simple. All we need is a new TLV to be > included in the IIHs. Read once more through my mail: I did _not_ say that it could _not_ be done ;-) Thanks for your proposal, I assume you'll go ahead and help with the draft then ? -- tony From henk@procket.com Sat Dec 23 00:48:17 2000 From: henk@procket.com (Henk Smit) Date: Sat, 23 Dec 2000 01:48:17 +0100 (MET) Subject: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <200012230028.BAA07021@net4u.net4u.ch> from "Tony Przygienda" at Dec 23, 2000 01:28:34 AM Message-ID: <200012230048.BAA01482@kraak.procket.com> > Thanks for your proposal, I assume you'll go ahead and help with the draft > then ? I'd be happy to leave that for the people who are gonna implement this. At the moment I am spending my time doing other things than IS-IS. It is not gonna be more than 1 or 2 pages. And I think I have already seen people offering to write a draft. Henk. From danny@ambernetworks.com Sat Dec 23 01:31:16 2000 From: danny@ambernetworks.com (Danny McPherson) Date: Fri, 22 Dec 2000 18:31:16 -0700 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers Message-ID: <200012230131.SAA06831@tcb.net> > Most of this "empirical experience" is based on very old networks > built out of routers with 20 MHz processors (cisco 7000s come to mind). > And in those days the queuing strategies on linecards, and between > linecards and control planes was all less elaborate. > > FYI, when I worked at cisco, I have worked with customers that used > holdtimes of only several seconds, but those were not ISPs. Actually, at a previous job [] in a very large [but newer, not legacy] network I did a lot of fumbling with really low hello intervals (1s), and multipliers of 4 & 5s. The primary driver for this at the time was to provide a mechanism for detection of a "new neighbor" on a point-to-point links when using inter-router SONET APS schemes. The problem was that APS switches on the remote end occur without the local router knowing, and as such, the fastest detection mechanism to trigger an adjacency tear-down and re-initialization was reception of a Hello message from an "unknown neighbor" on a point-to-point network. Other 'hacks' were experimented with as well, though their impact on network stability was even more questionable (right Henk :-). So, obviously, increasing the frequency @ which Hellos are transmitted (by an order of magnitude) had a significant impact on convergence. This had an even further reaching impact when considering that many implementations throttle initial or SPF reruns and if I could get the new adjacency established and LSPs flooded before the first SPF was executed, then the network was a lot happier in the long run (as were attentive customers :-). Fortunately, we didn't have tons of pseudo-nodes or large NBMA clouds with lots of neighbors, the network was composed mostly of point-to-point POS connections. As well, removing Hello padding [after adjacency establishment] enabled us to not use quite as much bandwidth [though it's never been the size of the packets as much as the volume], and it wasn't really negligible anyways. Then again, I recall working on another very large, very complex network that was configured with things such as Hellos (and every LSP/SNP [re]transmit interval and SPF throttle know possible) WAY throttled, and 200+ neighbors on a single NBMA (w/point-to-point VCs) interface consumed a steady 1.5% of the usable bandwidth on the connection. Of course, this was the network that encouraged Dave to add all those IOS knobs in order to increase stability, not improve convergence times :-) I think the work has merit here, though I agree that manipulation of such parameters is extremely sensitive. Fortunately, as Henk allluded to, a significant portion of this work can remain spec-independent. That is, anything with a Hello Multiplier >= 1s is doable without changes to the protocol, it's just a matter of the implementation supporting it. As such, perhaps something informational along these lines, or at best, experimental, is in order? As Vijay suggest, more experience is probably in order before messing with the new TLVs and the like. -danny From prz@redback.com Fri Dec 22 22:32:55 2000 From: prz@redback.com (Tony Przygienda) Date: Fri, 22 Dec 2000 14:32:55 -0800 Subject: [Isis-wg] last call for IPv6 in ISIS .... Message-ID: <3A43D697.CD46A48C@redback.com> Draft draft-ietf-isis-ipv6-01 goes last call as agreed in the meeting. Last call will end in 2 weeks from now thanks -- tony From vijay@umbc.edu Sat Dec 23 06:26:46 2000 From: vijay@umbc.edu (Vijay Gill) Date: Sat, 23 Dec 2000 01:26:46 -0500 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <200012230035.BAA01424@kraak.procket.com> Message-ID: On Sat, 23 Dec 2000, Henk Smit wrote: > > Vijay wrote: > Most of this "empirical experience" is based on very old networks > built out of routers with 20 MHz processors (cisco 7000s come to mind). > And in those days the queuing strategies on linecards, and between > linecards and control planes was all less elaborate. I am not going to sit and explain to my management why we made the front page of the WSJ. If I do have to do it, I better have a very good story, and given our past experiences, I'm going to err on the side of caution, till at least someone else of large size has done this and I trust the people running that network. > Thank you very much. But you are exaggerating. I don't think low > holdtimers are the tricky thing to implement fast convergence. The > tricky part is to react quickly to events in your network, without > ever risking a meltdown. There is more to it than just faster hellos. Given the quality of implementations, I think we will just have to agree to disagree ;) (this isn't a slam on any implementation, it is just that operational experience has shown that there are some very subtle and strange interactions in large networks that can cause meltdowns due to combinations of bugs that individually are just annoying.) We are paranoid and crazy for good reason ;) /vijay From tli@Procket.com Sat Dec 23 06:31:55 2000 From: tli@Procket.com (Tony Li) Date: Fri, 22 Dec 2000 22:31:55 -0800 (PST) Subject: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <200012222123.WAA05244@net4u.net4u.ch> References: <14915.39280.503477.749864@localhost.localdomain> <200012222123.WAA05244@net4u.net4u.ch> Message-ID: <14916.18139.104873.14754@alpha-tony.procket.com> | thta's all modulo other Tony's opinion of course since I didn't have any | chance to syn up with him on that topic yet ... I'll take that as an invitation to opine: The proposal that has been put forth is a reasonable WG work item. There is clearly an audience and sufficient technical opinion. Therefore, it seems appropriate for the WG to entertain the work. However, I can't believe that this is the best way of solving this problem. The issue that I have with this approach is that it implies that the responsiveness of our systems is now going to drop to sub-second levels. While I can believe that there are real-time systems that can be built with the required responsiveness, not all of them were originally designed this way and the resulting modifications might be more than challenging. Comparatively, the protocol changes are trivial. Are there other things that we can do? Certainly. Make better use of SONET. Make more use of Ethernet link failures. Somehow, just making everything run faster seems like the brute force solution and puts stability at risk. Tony From truskows@cisco.com Sat Dec 23 16:06:00 2000 From: truskows@cisco.com (Mike Truskowski) Date: Sat, 23 Dec 2000 8:06:00 PST Subject: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <14916.18139.104873.14754@alpha-tony.procket.com>; from "Tony Li" at Dec 22, 100 10:31 pm Message-ID: <200012231606.IAA08794@diablo.cisco.com> I agree... while you can make the protocols run faster you put a burden on the cpu and bandwidth which generates and transport the intelligence... I do not understand the referal to better use of sonet and/or ethernet link information... I understand the local significance but not the remote side.... Maybe I took this wrong. Mike > > > | thta's all modulo other Tony's opinion of course since I didn't have any > | chance to syn up with him on that topic yet ... > > > I'll take that as an invitation to opine: > > > The proposal that has been put forth is a reasonable WG work item. There > is clearly an audience and sufficient technical opinion. Therefore, it > seems appropriate for the WG to entertain the work. > > > > However, I can't believe that this is the best way of solving this problem. > The issue that I have with this approach is that it implies that the > responsiveness of our systems is now going to drop to sub-second levels. > While I can believe that there are real-time systems that can be built with > the required responsiveness, not all of them were originally designed this > way and the resulting modifications might be more than challenging. > Comparatively, the protocol changes are trivial. > > Are there other things that we can do? Certainly. Make better use of > SONET. Make more use of Ethernet link failures. > > Somehow, just making everything run faster seems like the brute force > solution and puts stability at risk. > > > Tony > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From danny@ambernetworks.com Wed Dec 27 06:24:39 2000 From: danny@ambernetworks.com (Danny McPherson) Date: Tue, 26 Dec 2000 23:24:39 -0700 Subject: [Isis-wg] draft-mcpherson-isis-transient-00.txt Message-ID: <200012270624.XAA15582@tcb.net> FYI... It should show up on the IETF ftp server by Thursday. -danny ------------------------------------------------------------------------- Network Working Group Danny McPherson INTERNET DRAFT Amber Networks, Inc. December 2000 IS-IS Transient Blackhole Avoidance 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This document describes a simple, interoperable mechanism that can be employed in IS-IS networks in order to decrease data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. McPherson, D. [Page 1] INTERNET DRAFT December 2000 3. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 4. Introduction When an IS-IS router that was previously a transit router becomes unavailable as a result of some transient condition such as a reboot, other routers within the routing domain must select an alternative path to reach destinations which had previously transited the failed router. Presumably, the newly selected router(s) comprising the path have been available for some time and, as a result, have complete forwarding information bases (FIBs) which contain a full set of reachability information for both internal and external (e.g. BGP) destination networks. When the previously failed router becomes available again, in only a few seconds paths that had previously transited the router are again selected as the optimal path by the IGP. As a result, forwarding tables are updated and packets are once again forwarded along the path. Unfortunately, external destination reachability information (e.g. learned via BGP) is not yet available to the router, and as a result, packets bound for destinations not learned via the IGP are unnecessarily discarded. A mechanism to alleviate the offshoot associated with this deterministic behavior is discussed below. 5. Discussion This document describes a simple, interoperable mechanism that can be employed in IS-IS [1] and [2] networks in order to avoid transition to a newly available path until other associated routing protocols such as BGP have had sufficient time to converge. The benefits of such a mechanism can realized when considering the following scenario. McPherson, D. [Page 2] INTERNET DRAFT December 2000 D.1 | +-------+ | RtrD | +-------+ / \ / \ +-------+ +-------+ | RtrB | | RtrC | +-------+ +-------+ \ / \ / +-------+ | RtrA | +-------+ | S.1 Host S.1 is transmitting data to destination D.1 via a primary path of RtrA->RtrB->RtrD. Routers A, B and C learn of reachability to destination D.1 via BGP from RtrD. RtrA's primary path to D.1 is selected because when calculating the path to BGP NEXT_HOP of RtrD the sum of the IS-IS link metrics on the RtrA-RtrB-RtrD path is less than the sum of the metrics of the RtrA-RtrC-RtrD path. Assume RtrB becomes unavailable and as a result the RtrC path to RtrD is used. Once RtrA's FIB is updated and it begins forwarding packets to RtrC everything should behave properly as RtrC has existing forwarding information regarding destination D.1's availability via BGP NEXT_HOP RtrD. Assume now that RtrB comes back online. In only a few seconds IS-IS neighbor state has been established with RtrA and RtrD and database synchronization has occurred. RtrA now realizes that the best path to destination D.1 is via RtrB, and therefore updates it FIB appropriately. RtrA begins to forward packets destined to D.1 to RtrB. Though, because RtrB has yet to establish and synchronization it's BGP neighbor relationship and routing information with RtrD, RtrB has no knowledge regarding reachability of destination D.1, and therefore discards the packets received from RtrA destined to D.1. If RtrB were to temporarily set it's LSP Overload bit while synchronizing BGP tables with it's neighbors, RtrA would continue to use the working RtrA->RtrC->RtrD path, and the LSP should only be used to obtain reachability to locally connected networks (rather than for calculating transit paths through the router, as defined in [1]). McPherson, D. [Page 3] INTERNET DRAFT December 2000 After initial synchronization of BGP tables with neighboring routers, RtrB would generate a new LSP, clearing the Overload bit, and RtrA could again begin using the optimal path via RtrB. Typically, in service provider networks IBGP connections are done via peerings with 'loopback' addresses. As such, the newly available router must advertise it's own loopback, as well as associated adjacencies, in order to make the loopbacks accessible to other routers within the routing domain. It's because of this that simply flooding an empty LSP is not sufficient. 6. Deployment Considerations Such a mechanism increases overall network availability and allows network operators to alleviate the deterministic blackholing behavior introduced in this scenario. Similar mechanisms [3] have been defined for OSPF, though only after realizing similar usefulness obtained from that of the IS-IS Overload bit. This mechanism has been deployed in several large IS-IS networks for several of years. Triggers for setting the Overload bit as described are left to the implementor. Some potential triggers could perhaps include "N seconds after booting", or "N number of BGP prefixes in the BGP Loc- RIB". Unlike similar mechanisms employed in [3], if the Overload bit is set in a router's LSP, NO transit paths are calculated through the router. As such, if no alternative paths are available to the destination network, employing such a mechanism may actually have a negative impact on convergence. Finally, if all systems within an IS-IS routing domain haven't implemented the Overload bit correctly, forwarding loops may occur. McPherson, D. [Page 4] INTERNET DRAFT December 2000 7. Security Considerations The mechanisms specified in this memo introduces no new security issues to IS-IS. 8. Acknowledgements The author of this document makes no claim to the originality of the idea. Others To be supplied... 9. References [1] ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:1992. [2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, December 1990. [3] Retana et al., "OSPF Stub Router Advertisement", "Work in Progress", November 2000. 10. Authors' Address Danny McPherson Amber Networks, Inc. 48664 Milmont Drive Fremont, CA 94538 Phone: 510.687.5200 Email: danny@ambernetworks.com McPherson, D. [Page 5] From Chris Whyte" Message-ID: <039201c06f92$5cb136c0$eae5130a@cisco.com> > On Sat, 23 Dec 2000, Henk Smit wrote: > > > > > Vijay wrote: > > > Most of this "empirical experience" is based on very old networks > > built out of routers with 20 MHz processors (cisco 7000s come to mind). > > And in those days the queuing strategies on linecards, and between > > linecards and control planes was all less elaborate. > > I am not going to sit and explain to my management why we made the front > page of the WSJ. If I do have to do it, I better have a very good story, > and given our past experiences, I'm going to err on the side of caution, > till at least someone else of large size has done this and I trust the > people running that network. > And one could argue that some ISPs are making, or will make, the front page of the WSJ because of the additional complexity they're putting in their network just to get around the fact that we can't do sub-second, or just plain faster, igp restoration. My experience says there's a lot of interest in achieving this goal without adding another protocol, technology or whatever to the equation. I would really love to see the WG look long and hard at changing the protocol, if necessary, in order to achieve it. I guess I'm just not convinced that any one specific group has looked at the routing protocols as much as they've looked at other (newer) protocols or technologies which attempt to achieve this goal. I think it would be nice to be able to possibly optimize something that people already know, love and understand than to start somewhat fresh with a new approach that will just add more complexity since the routing protocol certainly isn't going away. > > Thank you very much. But you are exaggerating. I don't think low > > holdtimers are the tricky thing to implement fast convergence. The > > tricky part is to react quickly to events in your network, without > > ever risking a meltdown. There is more to it than just faster hellos. > > Given the quality of implementations, I think we will just have to agree > to disagree ;) (this isn't a slam on any implementation, it is just that > operational experience has shown that there are some very subtle and > strange interactions in large networks that can cause meltdowns due to > combinations of bugs that individually are just annoying.) We are paranoid > and crazy for good reason ;) But I'm really curious, how much experimentation has been done in this area in the last year or so? I really don't know but I suspect it's been minimal. I understand the paranoia but I also believe that some, or much, of this paranoia can be attributed to historical issues that don't necessarily apply to more recent router implementations. And I'd hate to see it continue to gate any possible progress in this area since we have much better separation between data and control planes, faster CPUs and, overall, a much better understanding of some of the fundamental implementation and network design issues that can be done in order to avoid meltdown these days. Thanks, Chris > > /vijay > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From rbush@bainbridge.verio.net Tue Dec 26 23:51:10 2000 From: rbush@bainbridge.verio.net (Randy Bush) Date: Tue, 26 Dec 2000 15:51:10 -0800 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers References: <039201c06f92$5cb136c0$eae5130a@cisco.com> Message-ID: >> I am not going to sit and explain to my management why we made the front >> page of the WSJ. If I do have to do it, I better have a very good story, >> and given our past experiences, I'm going to err on the side of caution, >> till at least someone else of large size has done this and I trust the >> people running that network. > > And one could argue that some ISPs are making, or will make, the front page > of the WSJ because of the additional complexity they're putting in their > network just to get around the fact that we can't do sub-second, or just > plain faster, igp restoration. yes, but it would be hard to support. e.g. there is a reason for danny's recent draft-mcpherson-isis-transient-00.txt. but we foolish operators do appreciate your concern for us. > My experience says there's a lot of interest in achieving this goal without > adding another protocol, technology or whatever to the equation. I would > really love to see the WG look long and hard at changing the protocol, if > necessary, in order to achieve it. once again, do you really think that this should be a high priority effort given the other problems we face? randy From danny@ambernetworks.com Wed Dec 27 07:09:17 2000 From: danny@ambernetworks.com (Danny McPherson) Date: Wed, 27 Dec 2000 00:09:17 -0700 Subject: [Isis-wg] draft-mcpherson-isis-transient-00.txt Message-ID: <200012270709.AAA15973@tcb.net> Folks, I also plan to detail an alternative solution here (much more similar to the OSPF Stub Router stuff), which employs really high link metrics during transient conditions in order to make transiting a router less desirable than 'normal' paths. I'll add this once I get a little more feedback on this version of the draft. -danny > > FYI... It should show up on the IETF ftp server by Thursday. > > -danny > > ------------------------------------------------------------------------- > Network Working Group Danny McPherson > INTERNET DRAFT Amber Networks, Inc. > December 2000 > > > > IS-IS Transient Blackhole Avoidance > > > > 1. Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC 2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet- Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > > 2. Abstract > > This document describes a simple, interoperable mechanism that can be > employed in IS-IS networks in order to decrease data loss associated > with deterministic blackholing of packets during transient network > conditions. The mechanism proposed here requires no IS-IS protocol > changes and is completely interoperable with the existing IS-IS > specification. > > > > > > > > > > > McPherson, D. [Page 1] > > > > > > INTERNET DRAFT December 2000 > > > 3. Specification of Requirements > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC 2119]. > > > 4. Introduction > > When an IS-IS router that was previously a transit router becomes > unavailable as a result of some transient condition such as a reboot, > other routers within the routing domain must select an alternative > path to reach destinations which had previously transited the failed > router. Presumably, the newly selected router(s) comprising the path > have been available for some time and, as a result, have complete > forwarding information bases (FIBs) which contain a full set of > reachability information for both internal and external (e.g. BGP) > destination networks. > > When the previously failed router becomes available again, in only a > few seconds paths that had previously transited the router are again > selected as the optimal path by the IGP. As a result, forwarding > tables are updated and packets are once again forwarded along the > path. Unfortunately, external destination reachability information > (e.g. learned via BGP) is not yet available to the router, and as a > result, packets bound for destinations not learned via the IGP are > unnecessarily discarded. > > A mechanism to alleviate the offshoot associated with this > deterministic behavior is discussed below. > > > 5. Discussion > > This document describes a simple, interoperable mechanism that can be > employed in IS-IS [1] and [2] networks in order to avoid transition > to a newly available path until other associated routing protocols > such as BGP have had sufficient time to converge. > > The benefits of such a mechanism can realized when considering the > following scenario. > > > > > > > > > > > McPherson, D. [Page 2] > > > > > > INTERNET DRAFT December 2000 > > > D.1 > | > +-------+ > | RtrD | > +-------+ > / \ > / \ > +-------+ +-------+ > | RtrB | | RtrC | > +-------+ +-------+ > \ / > \ / > +-------+ > | RtrA | > +-------+ > | > S.1 > > Host S.1 is transmitting data to destination D.1 via a primary path > of RtrA->RtrB->RtrD. Routers A, B and C learn of reachability to > destination D.1 via BGP from RtrD. RtrA's primary path to D.1 is > selected because when calculating the path to BGP NEXT_HOP of RtrD > the sum of the IS-IS link metrics on the RtrA-RtrB-RtrD path is less > than the sum of the metrics of the RtrA-RtrC-RtrD path. > > Assume RtrB becomes unavailable and as a result the RtrC path to RtrD > is used. Once RtrA's FIB is updated and it begins forwarding packets > to RtrC everything should behave properly as RtrC has existing > forwarding information regarding destination D.1's availability via > BGP NEXT_HOP RtrD. > > Assume now that RtrB comes back online. In only a few seconds IS-IS > neighbor state has been established with RtrA and RtrD and database > synchronization has occurred. RtrA now realizes that the best path > to destination D.1 is via RtrB, and therefore updates it FIB > appropriately. RtrA begins to forward packets destined to D.1 to > RtrB. Though, because RtrB has yet to establish and synchronization > it's BGP neighbor relationship and routing information with RtrD, > RtrB has no knowledge regarding reachability of destination D.1, and > therefore discards the packets received from RtrA destined to D.1. > > If RtrB were to temporarily set it's LSP Overload bit while > synchronizing BGP tables with it's neighbors, RtrA would continue to > use the working RtrA->RtrC->RtrD path, and the LSP should only be > used to obtain reachability to locally connected networks (rather > than for calculating transit paths through the router, as defined in > [1]). > > > > > McPherson, D. [Page 3] > > > > > > INTERNET DRAFT December 2000 > > > After initial synchronization of BGP tables with neighboring routers, > RtrB would generate a new LSP, clearing the Overload bit, and RtrA > could again begin using the optimal path via RtrB. > > Typically, in service provider networks IBGP connections are done via > peerings with 'loopback' addresses. As such, the newly available > router must advertise it's own loopback, as well as associated > adjacencies, in order to make the loopbacks accessible to other > routers within the routing domain. It's because of this that simply > flooding an empty LSP is not sufficient. > > > 6. Deployment Considerations > > Such a mechanism increases overall network availability and allows > network operators to alleviate the deterministic blackholing behavior > introduced in this scenario. Similar mechanisms [3] have been > defined for OSPF, though only after realizing similar usefulness > obtained from that of the IS-IS Overload bit. > > This mechanism has been deployed in several large IS-IS networks for > several of years. > > Triggers for setting the Overload bit as described are left to the > implementor. Some potential triggers could perhaps include "N > seconds after booting", or "N number of BGP prefixes in the BGP Loc- > RIB". > > Unlike similar mechanisms employed in [3], if the Overload bit is set > in a router's LSP, NO transit paths are calculated through the > router. As such, if no alternative paths are available to the > destination network, employing such a mechanism may actually have a > negative impact on convergence. > > Finally, if all systems within an IS-IS routing domain haven't > implemented the Overload bit correctly, forwarding loops may occur. > > > > > > > > > > > > > > > > McPherson, D. [Page 4] > > > > > > INTERNET DRAFT December 2000 > > > 7. Security Considerations > > The mechanisms specified in this memo introduces no new security > issues to IS-IS. > > > 8. Acknowledgements > > The author of this document makes no claim to the originality of the > idea. Others To be supplied... > > > 9. References > > [1] ISO, "Intermediate system to Intermediate system routeing > information exchange protocol for use in conjunction with the > Protocol for providing the Connectionless-mode Network Service > (ISO 8473)," ISO/IEC 10589:1992. > > [2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, > December 1990. > > [3] Retana et al., "OSPF Stub Router Advertisement", "Work in > Progress", November 2000. > > > > 10. Authors' Address > > Danny McPherson > Amber Networks, Inc. > 48664 Milmont Drive > Fremont, CA 94538 > Phone: 510.687.5200 > Email: danny@ambernetworks.com > > > > > > > > > > > > > > > > > McPherson, D. [Page 5] > > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg From danny@ambernetworks.com Wed Dec 27 07:29:59 2000 From: danny@ambernetworks.com (Danny McPherson) Date: Wed, 27 Dec 2000 00:29:59 -0700 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers Message-ID: <200012270729.AAA16210@tcb.net> > yes, but it would be hard to support. e.g. there is a reason for danny's > recent draft-mcpherson-isis-transient-00.txt. Perhaps we should refocus our efforts here, coupling them with IDR, and coming up with a mechanism to get sub-second BGP table synchronization :-) -danny From randy@psg.com Wed Dec 27 01:00:20 2000 From: randy@psg.com (Randy Bush) Date: Tue, 26 Dec 2000 17:00:20 -0800 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers References: <200012270729.AAA16210@tcb.net> Message-ID: > Perhaps we should refocus our efforts here, coupling them > with IDR, and coming up with a mechanism to get sub-second > BGP table synchronization :-) i'll settle for 30 second, see abha's, abhijit's, and craig's most excellent http://www.acm.org/sigcomm2000/conf/paper/sigcomm2000-5-2.ps.gz and http://www.nanog.org/mtg-0010/labovitz.html but more germane to is-is, cengiz's, haobo's, and van's http://www.nanog.org/mtg-0010/ppt/cengiz.pdf which does suggest finer timers, but only after more modern spf calculation. and it neglects to consider such silly operational concers as addressed by your draft. randy From danny@ambernetworks.com Wed Dec 27 08:11:59 2000 From: danny@ambernetworks.com (Danny McPherson) Date: Wed, 27 Dec 2000 01:11:59 -0700 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers Message-ID: <200012270811.BAA16580@tcb.net> > i'll settle for 30 second, see abha's, abhijit's, and craig's most excellent > > http://www.acm.org/sigcomm2000/conf/paper/sigcomm2000-5-2.ps.gz > and http://www.nanog.org/mtg-0010/labovitz.html > > but more germane to is-is, cengiz's, haobo's, and van's > > http://www.nanog.org/mtg-0010/ppt/cengiz.pdf > > which does suggest finer timers, but only after more modern spf calculation. Seen both the above documents (a few times), though the pointers should certainly be of benefit to others on the list. > and it neglects to consider such silly operational concers as addressed by > your draft. Hence the timing :-) -danny From dkatz@juniper.net Wed Dec 27 07:25:27 2000 From: dkatz@juniper.net (Dave Katz) Date: Tue, 26 Dec 2000 23:25:27 -0800 (PST) Subject: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <039201c06f92$5cb136c0$eae5130a@cisco.com> (cwhyte@cisco.com) Message-ID: <200012270725.XAA17692@cirrus.juniper.net> Simple issue. This is not really a protocol issue, but a fundamental implementation issue. At least at this time, the dominant implementations are done in run-to-completion schedulers, and as such are a train wreck in the making. The protocol can do one second hold times now, and a trivial extension could choose something even shorter, but until we all reimplement our routers with true real-time o/s's this will never work (for large values of "work," as in "you bet your business on it.") Then if some of us fix it, we will get interesting partial collapses instead (I've alread seen this multiple times involving another familiar link-state IGP.) My mantra for years has been, "the implementations have a long way to go before we hit the fundamental limitations of the protocols" and I still believe this to be true in multiple dimensions. Reply-To: "Chris Whyte" From: "Chris Whyte" Cc: "Cengiz Alaettinoglu" , "Tony Przygienda" , "Jeff Parker" , , References: Organization: cisco Systems, Inc. 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 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Dec 2000 15:19:55 -0800 > On Sat, 23 Dec 2000, Henk Smit wrote: > > > > > Vijay wrote: > > > Most of this "empirical experience" is based on very old networks > > built out of routers with 20 MHz processors (cisco 7000s come to mind). > > And in those days the queuing strategies on linecards, and between > > linecards and control planes was all less elaborate. > > I am not going to sit and explain to my management why we made the front > page of the WSJ. If I do have to do it, I better have a very good story, > and given our past experiences, I'm going to err on the side of caution, > till at least someone else of large size has done this and I trust the > people running that network. > And one could argue that some ISPs are making, or will make, the front page of the WSJ because of the additional complexity they're putting in their network just to get around the fact that we can't do sub-second, or just plain faster, igp restoration. My experience says there's a lot of interest in achieving this goal without adding another protocol, technology or whatever to the equation. I would really love to see the WG look long and hard at changing the protocol, if necessary, in order to achieve it. I guess I'm just not convinced that any one specific group has looked at the routing protocols as much as they've looked at other (newer) protocols or technologies which attempt to achieve this goal. I think it would be nice to be able to possibly optimize something that people already know, love and understand than to start somewhat fresh with a new approach that will just add more complexity since the routing protocol certainly isn't going away. > > Thank you very much. But you are exaggerating. I don't think low > > holdtimers are the tricky thing to implement fast convergence. The > > tricky part is to react quickly to events in your network, without > > ever risking a meltdown. There is more to it than just faster hellos. > > Given the quality of implementations, I think we will just have to agree > to disagree ;) (this isn't a slam on any implementation, it is just that > operational experience has shown that there are some very subtle and > strange interactions in large networks that can cause meltdowns due to > combinations of bugs that individually are just annoying.) We are paranoid > and crazy for good reason ;) But I'm really curious, how much experimentation has been done in this area in the last year or so? I really don't know but I suspect it's been minimal. I understand the paranoia but I also believe that some, or much, of this paranoia can be attributed to historical issues that don't necessarily apply to more recent router implementations. And I'd hate to see it continue to gate any possible progress in this area since we have much better separation between data and control planes, faster CPUs and, overall, a much better understanding of some of the fundamental implementation and network design issues that can be done in order to avoid meltdown these days. Thanks, Chris > > /vijay > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From james.d.carlson@east.sun.com Wed Dec 27 17:03:38 2000 From: james.d.carlson@east.sun.com (James Carlson) Date: Wed, 27 Dec 2000 12:03:38 -0500 (EST) Subject: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: Mike Truskowski's message of 23 December 2000 08:06:00 References: <14916.18139.104873.14754@alpha-tony.procket.com> <200012231606.IAA08794@diablo.cisco.com> Message-ID: <14922.8426.701703.522053@gargle.gargle.HOWL> Mike Truskowski writes: > I do not understand the referal to better use of sonet > and/or ethernet link information... I understand the > local significance but not the remote side.... Maybe > I took this wrong. For SONET, you could reasonably send RDI-P upstream if something untoward happens to your local routing process or your ability to forward received packets. On detecting a positive loss of service by reception of RDI-P at the other end, you could remove the link from your database and start negotiation over from scratch when the defect disappears. On point-to-point Ethernet, you could probably do something similar by taking the link out of sync intentionally for the duration of your local outage. Assuming the peer has been properly implemented to monitor link status, this should give rapid and accurate indication of remote failure. For multi-access Ethernet, there's obviously a problem. However, since there are few 10BASE5 systems left, the worst problem can be ignored. For the remainder, it'd be helpful to get the bridge ("switch") vendors to support notification of link loss in a manner that'd work well with routing protocol implementations. I can see how detecting failure at the routing protocol level might not be avoidable in some situations, but I think fast-hello is a band-aid at best, and a likely source of instability and scalability trouble. The detection and propagation of failure information isn't just a routing protocol issue; it's a system issue. I don't think that this should be carried to the other extreme either (lengthening the hello interval). The hello exchange provides a reliable upper bound on the delay of upper level failure detection in case the other failure notification mechanisms themselves fail. It's important, but it shouldn't be the only means of detecting problems. (For what it's worth, similar issues occur with many other protocols, such as RIP. Most of these protocols have a "goodbye" mechanism [such as sending out infinite hop count routes] that can be used to speed up failure detection.) -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From dkatz@juniper.net Wed Dec 27 18:47:00 2000 From: dkatz@juniper.net (Dave Katz) Date: Wed, 27 Dec 2000 10:47:00 -0800 (PST) Subject: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: (message from Randy Bush on Wed, 27 Dec 2000 06:59:12 -0800) Message-ID: <200012271847.KAA18750@cirrus.juniper.net> what do you think of van's point that waiting for three hello timeouts, as opposed to noticing the physical (or framing) link going down, may be contributing the largest part of convergence delay? and, if you believe it, how might making such a change affect stability? randy Well, if there is physical evidence that the link has gone down, every implementation that I know of will respond to it. The hello timeout is definitely the slowest part of the *IGP* convergence (assuming that there is no low-level signalling to glean), but in the kinds of networks I'm familiar with (big, expensive, and full of ~100K BGP routes) the problem is much broader. If you have to change the next hops on tens of thousands of routes, this can take a sizable chunk of time (no, I don't have any hard numbers). The IGP implementations that I'm familiar with (one of which I haven't seen the innards of in almost four years, so I can't vouch for its current state) are pretty heavily biased toward stability at the expense of convergence, due to "interesting" field experience. We haven't seen an IGP meltdown (well, at least an ISIS meltdown) in a major network in quite awhile, knock on wood. Given this, perhaps its not a bad time to open up the covers again and think about convergence improvements *very* carefully (I really don't want to see a New York Times article with the headline, "MegaNet down for 19 hours; programmer sought") but part of this careful analysis has to be looking at what the *real* issues are, and where the target-rich environments lie. For example, how often do links fail, in real life, in such a way that nobody tells the protocol and it has to time out? (And how many of those failures-to-communicate are due to bugs?) What are the factors that contribute to global convergence (as opposed to a localized picture of IGP convergence?) Like all cases of premature optimization, it's at best a waste of time (and at worst destabilizing) to start playing with things without really knowing what's going on. All of this can be done outside the protocol spec, which is why I don't feel that there's any real pressure in tinkering with the protocol at this time. If it turns out that the holdtime delay is truly important, and reducing it by an order of magnitude will truly reap more than negligible benefits (I'm skeptical) then we've got some interesting software architectural work ahead of us to pull this off in a way that won't endanger the stability of the infrastructure. It's a *lot* more work than just twisting timers. (For fun, go set the hello interval to 1 and the hold time to 3 and then take a major transient, say, in BGP, and then see how things hold up...) --Dave From Chris Whyte" Message-ID: <004b01c0703b$cdbc3960$eae5130a@cisco.com> Ok. I have two questions/comments then... 1. So are you saying that the suggestions made in draft-alaettinoglu-isis-convergence-00.txt, which do involve a change to is-is, aren't worth pursuing because of the reason(s) below? 2. Forgive my ignorance but it's not clear to me why we shouldn't continue to pursue changes to spec (eg shorter hold times), which ISPs appear to be interested in, given that there are at least some vendors working on true real-time o/s router implementations. Don't we always want to be in the situation where "the implementations have a long way to go before we hit the fundamental limitations of the protocols"? Thanks, Chris > Simple issue. This is not really a protocol issue, but a fundamental > implementation issue. At least at this time, the dominant > implementations are done in run-to-completion schedulers, and as such > are a train wreck in the making. > > The protocol can do one second hold times now, and a trivial extension > could choose something even shorter, but until we all reimplement our > routers with true real-time o/s's this will never work (for large > values of "work," as in "you bet your business on it.") > > Then if some of us fix it, we will get interesting partial collapses > instead (I've alread seen this multiple times involving another familiar > link-state IGP.) > > My mantra for years has been, "the implementations have a long way to go > before we hit the fundamental limitations of the protocols" and I still > believe this to be true in multiple dimensions. > > Reply-To: "Chris Whyte" > From: "Chris Whyte" > Cc: "Cengiz Alaettinoglu" , > "Tony Przygienda" , "Jeff Parker" , > , > References: > Organization: cisco Systems, Inc. > 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 5.00.2919.6600 > X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 > Sender: isis-wg-admin@spider.juniper.net > Errors-To: isis-wg-admin@spider.juniper.net > X-BeenThere: isis-wg@external.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: , > > List-Archive: > Date: Tue, 26 Dec 2000 15:19:55 -0800 > > > On Sat, 23 Dec 2000, Henk Smit wrote: > > > > > > > > Vijay wrote: > > > > > Most of this "empirical experience" is based on very old networks > > > built out of routers with 20 MHz processors (cisco 7000s come to mind). > > > And in those days the queuing strategies on linecards, and between > > > linecards and control planes was all less elaborate. > > > > I am not going to sit and explain to my management why we made the front > > page of the WSJ. If I do have to do it, I better have a very good story, > > and given our past experiences, I'm going to err on the side of caution, > > till at least someone else of large size has done this and I trust the > > people running that network. > > > > And one could argue that some ISPs are making, or will make, the front page > of the WSJ because of the additional complexity they're putting in their > network just to get around the fact that we can't do sub-second, or just > plain faster, igp restoration. > > My experience says there's a lot of interest in achieving this goal without > adding another protocol, technology or whatever to the equation. I would > really love to see the WG look long and hard at changing the protocol, if > necessary, in order to achieve it. > > I guess I'm just not convinced that any one specific group has looked at the > routing protocols as much as they've looked at other (newer) protocols or > technologies which attempt to achieve this goal. I think it would be nice to > be able to possibly optimize something that people already know, love and > understand than to start somewhat fresh with a new approach that will just > add more complexity since the routing protocol certainly isn't going away. > > > > Thank you very much. But you are exaggerating. I don't think low > > > holdtimers are the tricky thing to implement fast convergence. The > > > tricky part is to react quickly to events in your network, without > > > ever risking a meltdown. There is more to it than just faster hellos. > > > > Given the quality of implementations, I think we will just have to agree > > to disagree ;) (this isn't a slam on any implementation, it is just that > > operational experience has shown that there are some very subtle and > > strange interactions in large networks that can cause meltdowns due to > > combinations of bugs that individually are just annoying.) We are paranoid > > and crazy for good reason ;) > > But I'm really curious, how much experimentation has been done in this area > in the last year or so? I really don't know but I suspect it's been minimal. > I understand the paranoia but I also believe that some, or much, of this > paranoia can be attributed to historical issues that don't necessarily apply > to more recent router implementations. And I'd hate to see it continue to > gate any possible progress in this area since we have much better separation > between data and control planes, faster CPUs and, overall, a much better > understanding of some of the fundamental implementation and network design > issues that can be done in order to avoid meltdown these days. > > Thanks, > > Chris > > > > > /vijay > > > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > From prz@redback.com Wed Dec 27 19:57:50 2000 From: prz@redback.com (Tony Przygienda) Date: Wed, 27 Dec 2000 11:57:50 -0800 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers References: <200012270725.XAA17692@cirrus.juniper.net> Message-ID: <3A4A49BE.DC8E34A0@redback.com> Dave Katz wrote: > Simple issue. This is not really a protocol issue, but a fundamental > implementation issue. At least at this time, the dominant > implementations are done in run-to-completion schedulers, and as such > are a train wreck in the making. yes and no, if you go away from the run-to-completion scheduler and _even_ if you implement the whole thing on a real-time scheduler, let's say understanding priority and relative & absolute slip, you face another monster, namely locking of which a protocol like ISIS will have plenty, even in the hello processing/generation ;-) It is a perversity well-known in the database world (and IGPs are nothing else but distributed, loosely synchronized, real-time databases) that once you go into pre-emption, not your procedural/task design determines runtime behavior but primarily your locking disciplines/granularity/frequence/priority inheritance. Therefore you design high-performance databases these days starting from the locking disciplines & granularity and not from task/operating system side. At least last time I checked (and I admit it's a while) ;-) So, my strong feeling is that once you go into this realm you end up being very disappointed with what you can achieve by just adding preemptive, real-time tasks unless you start from designing your database specifically for the performance profile you want to achieve. Nobody tackled that one yet as far as I know in the IP world. Again, to prevent bashing, I'm _not_ saying it can_not_ be done, I'm just pointing out another piece of the dragon you get out the cave when you grab the beatiful end of the tail sticking out ;-) > The protocol can do one second hold times now, and a trivial extension > could choose something even shorter, but until we all reimplement our > routers with true real-time o/s's this will never work (for large > values of "work," as in "you bet your business on it.") > > Then if some of us fix it, we will get interesting partial collapses > instead (I've alread seen this multiple times involving another familiar > link-state IGP.) > > My mantra for years has been, "the implementations have a long way to go > before we hit the fundamental limitations of the protocols" and I still > believe this to be true in multiple dimensions. yes ;-) ... thanks --- tony From prz@redback.com Wed Dec 27 20:00:20 2000 From: prz@redback.com (Tony Przygienda) Date: Wed, 27 Dec 2000 12:00:20 -0800 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers References: <200012270725.XAA17692@cirrus.juniper.net> Message-ID: <3A4A4A54.8EDDFF83@redback.com> Dave Katz wrote: > Simple issue. This is not really a protocol issue, but a fundamental > implementation issue. At least at this time, the dominant > implementations are done in run-to-completion schedulers, and as such > are a train wreck in the making. yes and no, if you go away from the run-to-completion scheduler and _even_ if you implement the whole thing on a real-time scheduler, let's say understanding priority and relative & absolute slip, you face another monster, namely locking ;-) It is a perversity well-known in the database world (and IGPs are nothing else but distributed, loosely synchronized, real-time databases) that once you go into pre-emption, not your procedural/task design determines runtime behavior but primarily your locking disciplines/granularity/frequence/priority inheritance. Therefore you design high-performance databases these days starting from the locking disciplines & granularity and not from task/operating system side. At least last time I checked (and I admit it's a while) ;-) So, my strong feeling is that once you go into this realm you end up being very disappointed with what you can achieve unless you start to design your protocol starting from the locking behavior and as far I know nobody tried that in the IP world yet. > The protocol can do one second hold times now, and a trivial extension > could choose something even shorter, but until we all reimplement our > routers with true real-time o/s's this will never work (for large > values of "work," as in "you bet your business on it.") > > Then if some of us fix it, we will get interesting partial collapses > instead (I've alread seen this multiple times involving another familiar > link-state IGP.) > > My mantra for years has been, "the implementations have a long way to go > before we hit the fundamental limitations of the protocols" and I still > believe this to be true in multiple dimensions. yes ;-) ... --- tony From rbush@bainbridge.verio.net Wed Dec 27 14:59:12 2000 From: rbush@bainbridge.verio.net (Randy Bush) Date: Wed, 27 Dec 2000 06:59:12 -0800 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers References: <039201c06f92$5cb136c0$eae5130a@cisco.com> <200012270725.XAA17692@cirrus.juniper.net> Message-ID: dave, what do you think of van's point that waiting for three hello timeouts, as opposed to noticing the physical (or framing) link going down, may be contributing the largest part of convergence delay? and, if you believe it, how might making such a change affect stability? randy From rohit@xebeo.com Wed Dec 27 21:24:15 2000 From: rohit@xebeo.com (Rohit Dube) Date: Wed, 27 Dec 2000 16:24:15 -0500 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: Your message of "Wed, 27 Dec 2000 12:00:20 PST." <3A4A4A54.8EDDFF83@redback.com> Message-ID: <200012272124.QAA24794@bigbird.xebeo.com> On Wed, 27 Dec 2000 12:00:20 -0800 Tony Przygienda writes: => =>Dave Katz wrote: => =>> Simple issue. This is not really a protocol issue, but a fundamental =>> implementation issue. At least at this time, the dominant =>> implementations are done in run-to-completion schedulers, and as such =>> are a train wreck in the making. => =>yes and no, if you go away from the run-to-completion scheduler and _even_ =>if you implement the whole thing on a real-time scheduler, let's say understa >nding =>priority and relative & absolute slip, you face another monster, namely locki >ng ;-) => =>It is a perversity well-known in the database world (and IGPs are nothing els >e =>but distributed, loosely synchronized, real-time databases) that once you go >into =>pre-emption, not your procedural/task design determines runtime behavior =>but primarily your locking disciplines/granularity/frequence/priority inherit >ance. =>Therefore you design high-performance databases these days starting from =>the locking disciplines & granularity and not from task/operating system sid >e. At least =>last time I checked (and I admit it's a while) ;-) And don't forget you access methods - concurrent B+-tree access and the like. (And those who use lower fan-out balanced trees may want to check out some work by Sabine Hanke et al - http://www.imada.ou.dk/~kslarsen/RelBal/) >From my own experience doing similar work both with Databases and IGPs/Route-table managers, optimizing performance with locking can get fairly hairy and depends not just on granualrity and locking disciplines but also on workloads (number of readers, writers) and lock-timeout algorithms in addition to the points that you mention. FWIW, --rohit. From dkatz@juniper.net Wed Dec 27 23:29:49 2000 From: dkatz@juniper.net (Dave Katz) Date: Wed, 27 Dec 2000 15:29:49 -0800 (PST) Subject: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <004b01c0703b$cdbc3960$eae5130a@cisco.com> (cwhyte@cisco.com) Message-ID: <200012272329.PAA19459@cirrus.juniper.net> 1. So are you saying that the suggestions made in draft-alaettinoglu-isis-convergence-00.txt, which do involve a change to is-is, aren't worth pursuing because of the reason(s) below? I haven't had time to read this in detail, though I did have a private discussion with Van & Co. about the contents, and a brief reading seemed to line up with the discussion. There are certainly things in these implementations that could be done better, and some of them would be quite easy (though others may not be). The reservation I have with this work is that it does not characterize the potential gains in real world environments, and we should all be loathe to open the covers on our protocol implementations without understanding what the real gains will be. I just don't like making front page news, and as a matter of principle I don't like to do something this risky without a clear idea of why. The stakes are just too high. It's worth noting that, no matter how hard they hammered on the implementations, they couldn't make them fall over. There is a reason for this. I'm not opposed to the suggestions made, either in implementation issues or in protocol extensions. It's a very useful thing for someone to have taken a look at this stuff and to have made a reasoned and intelligent analysis. My only point is that, from a pragmatic standpoint with deployed products and operational networks, we have lots of room for improvement in other areas before doing invasive surgery on the IGPs. Convergence is a much broader issue, with many interesting (and unexpected) interactions, than simply finishing an SPF quickly. 2. Forgive my ignorance but it's not clear to me why we shouldn't continue to pursue changes to spec (eg shorter hold times), which ISPs appear to be interested in, given that there are at least some vendors working on true real-time o/s router implementations. I have no objection to pursuing protocol extensions, particularly backward compatible ones, if people want to do this. I don't think, however, that ISPs are interested in protocol changes; rather, they are interested in improving overall convergence times while maintaining the stability of their networks. Those that are convinced that speeding up hello times or SPF implementations will make their networks much better have been sold a bill of goods--it's just not that simple. A vendor that can field a very large network that will remain stable while maintaining one second hold times will have done very impressive work deserving of high profit margins, without having touched the protocol. It should be interesting to see. Having done that, said vendor should be well positioned to explore the subsecond realm. Don't we always want to be in the situation where "the implementations have a long way to go before we hit the fundamental limitations of the protocols"? Absolutely not. Where we want to be is in the position where the networks have a long way to go before they hit the fundamental limitations of the protocol implementations. Only then will the fundamental limitations of the protocol prove really interesting. From dkatz@juniper.net Wed Dec 27 23:37:17 2000 From: dkatz@juniper.net (Dave Katz) Date: Wed, 27 Dec 2000 15:37:17 -0800 (PST) Subject: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <3A4A49BE.DC8E34A0@redback.com> (message from Tony Przygienda on Wed, 27 Dec 2000 11:57:50 -0800) Message-ID: <200012272337.PAA19479@cirrus.juniper.net> X-JNPR-Received-From: outside yes and no, if you go away from the run-to-completion scheduler and _even_ if you implement the whole thing on a real-time scheduler, let's say understanding priority and relative & absolute slip, you face another monster, namely locking of which a protocol like ISIS will have plenty, even in the hello processing/generation ;-) No argument here. I would, in fact, like all of my competitors to port all of their code to a preemptive o/s immediately. ;-) I've had to talk people out of this idea many times over the years--you trade an obvious problem for a whole bunch of really subtle ones. Even naive protocol implementations are difficult. Scalable, stable ones are very difficult (look at how many are out there.) Scalable, stable, fast ones are even harder still. --Dave From randy@psg.com Wed Dec 27 23:54:14 2000 From: randy@psg.com (Randy Bush) Date: Wed, 27 Dec 2000 15:54:14 -0800 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers References: <200012271847.KAA18750@cirrus.juniper.net> Message-ID: > what do you think of van's point that waiting for three hello timeouts, > as opposed to noticing the physical (or framing) link going down, may > be contributing the largest part of convergence delay? and, if you > believe it, how might making such a change affect stability? > Well, if there is physical evidence that the link has gone down, every > implementation that I know of will respond to it. i would have thought so. but van seems to think otherwise, and claims measurement to boot. > The IGP implementations that I'm familiar with (one of which I haven't > seen the innards of in almost four years, so I can't vouch for its current > state) are pretty heavily biased toward stability at the expense of > convergence, due to "interesting" field experience. i assure you that some of us deeply appreciate this spoilsport approach, boring though others may think it. randy From randy@psg.com Thu Dec 28 00:24:26 2000 From: randy@psg.com (Randy Bush) Date: Wed, 27 Dec 2000 16:24:26 -0800 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers References: <004b01c0703b$cdbc3960$eae5130a@cisco.com> <200012272329.PAA19459@cirrus.juniper.net> Message-ID: > I have no objection to pursuing protocol extensions, particularly > backward compatible ones, if people want to do this. I don't think, > however, that ISPs are interested in protocol changes wrongo! to paraphrase mo, i want lots of them made available. so my competitors can try them. randy From prz@redback.com Wed Dec 27 23:36:35 2000 From: prz@redback.com (Tony Przygienda) Date: Wed, 27 Dec 2000 15:36:35 -0800 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers References: <004b01c0703b$cdbc3960$eae5130a@cisco.com> <200012272329.PAA19459@cirrus.juniper.net> Message-ID: <3A4A7D03.48E913F6@redback.com> Randy Bush wrote: > > I have no objection to pursuing protocol extensions, particularly > > backward compatible ones, if people want to do this. I don't think, > > however, that ISPs are interested in protocol changes > > wrongo! to paraphrase mo, i want lots of them made available. so my > competitors can try them. carefull Randy, some people on this list MAY take you literally ;-) -- tony From rbush@bainbridge.verio.net Thu Dec 28 01:51:46 2000 From: rbush@bainbridge.verio.net (Randy Bush) Date: Wed, 27 Dec 2000 17:51:46 -0800 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers References: <004b01c0703b$cdbc3960$eae5130a@cisco.com> <200012272329.PAA19459@cirrus.juniper.net> <3A4A7D03.48E913F6@redback.com> Message-ID: >>> I have no objection to pursuing protocol extensions, particularly >>> backward compatible ones, if people want to do this. I don't think, >>> however, that ISPs are interested in protocol changes >> wrongo! to paraphrase mo, i want lots of them made available. so my >> competitors can try them. > carefull Randy, some people on this list MAY take you literally ;-) but we just *love* to read about our competitors's meltdowns in the wsj. after all, what's the fun in running a boring network when you can look oh so modern and clever in front of your drinking friends at nanog? randy From Chris Whyte" <200012272329.PAA19459@cirrus.juniper.net><3A4A7D03.48E913F6@redback.com> Message-ID: <009c01c07090$551d50c0$eae5130a@cisco.com> > >>> I have no objection to pursuing protocol extensions, particularly > >>> backward compatible ones, if people want to do this. I don't think, > >>> however, that ISPs are interested in protocol changes > >> wrongo! to paraphrase mo, i want lots of them made available. so my > >> competitors can try them. > > carefull Randy, some people on this list MAY take you literally ;-) > > but we just *love* to read about our competitors's meltdowns in the wsj. > after all, what's the fun in running a boring network when you can look > oh so modern and clever in front of your drinking friends at nanog? > Well hell, I love boring and simplistic but maybe someone can explain why changes to the protocol to achieve something like faster restoration is more operationally complex than a large mesh of TE and bypass tunnels (ie FRR), which also requires changes to the protocol. And certainly running a network that uses the latter approach is no walk in the park. I realize I'm mixing a bit of operational complexity concern with protocol implementation issues but is it simply that the risk of meltdown is much greater? And if so, are there not things we can do like using an spf backoff algorithm in the face of instability to prevent meltdown (very similar to Henk's old work)? And if this is not interesting to others, or is beyond the scope of the mailing list, please respond to me offlist. I would be more than fascinated to hear people's opinions/answers. Thanks, Chris > randy > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > From tli@Procket.com Thu Dec 28 08:05:36 2000 From: tli@Procket.com (Tony Li) Date: Thu, 28 Dec 2000 00:05:36 -0800 (PST) Subject: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <009c01c07090$551d50c0$eae5130a@cisco.com> References: <004b01c0703b$cdbc3960$eae5130a@cisco.com> <200012272329.PAA19459@cirrus.juniper.net> <3A4A7D03.48E913F6@redback.com> <009c01c07090$551d50c0$eae5130a@cisco.com> Message-ID: <14922.62544.735986.360952@alpha-tony.procket.com> Chris, | Well hell, I love boring and simplistic but maybe someone can explain why | changes to the protocol to achieve something like faster restoration is more | operationally complex than a large mesh of TE and bypass tunnels (ie FRR), | which also requires changes to the protocol. And certainly running a network | that uses the latter approach is no walk in the park. One last time: it's not the changes to the protocol. It's the changes to the rest of the system. For the routing protocol to detect a loss of adjacency at the rates that are proposed, the routing protocol process must run at much higher rates to generate the hello packets, receive them, and time out failed adjacencies. Given the current run-to-completion operating system schedulers that we all seem to use, you basically have two choices: either try to run to completion with MUCH tighter timers throughout the ENTIRE operating system or convert to a pre-emptive scheduling mechanism. Both are fraught with risk. Whereas if you take a look at a TE approach, you find that the underlying protocol has NOT changed in any substantive way. It's being (ab)used as a mechanism for transporting unnatural information, but the dynamics of the protocol itself has not changed one whit. It's absolutely true that there's more complexity in the TE code. But when (not if) it breaks, all it does is to cause localized failures in the TE subsystem. Basic unicast routing should be very much unaffected. | I realize I'm mixing a bit of operational complexity concern with protocol | implementation issues but is it simply that the risk of meltdown is much | greater? And if so, are there not things we can do like using an spf backoff | algorithm in the face of instability to prevent meltdown (very similar to | Henk's old work)? Again, it's not the speed of SPFs that matter. It's that you now have to be able to respond to a timer expiration within 10ms or so. That's about three orders of magnitude faster than today. Tony From navaneeth@www.com Fri Dec 29 10:21:06 2000 From: navaneeth@www.com (navaneeth@www.com) Date: 29 Dec 2000 02:21:06 -0800 Subject: [Isis-wg] Clarification on isisCommands... Message-ID: <20001229102106.9091.cpmta@c000.zsm.cp.net> Hi, Can anybody clarify the use of the Cisco Commandline default-information originate (IS-IS): >From the Cli doc of cisco START :: To generate a default route into an IS-IS routing domain, use the default-information originate router configuration command. To disable this feature, use the no form of this command. default-information originate [route-map map-name] no default-information originate [route-map map-name] END:: What does this commsnd do? In the explanation it says, if the command is used without routemap option, the IS has to advertise the default route in its L2 Lsps. If the route map is specified, based on the route map, the default route must be conditinally advertised in the L1 LSPs. What is the use of this default route being advertised in the LSPs? How is the advertised default route processed? Thanx and Regards Navaneeth. ______________________________________________________ Listen to your favorite music while you work! - http://www.com/ ------- End of forwarded message ------- ______________________________________________________ Listen to your favorite music while you work! - http://www.com/ From E.T.Metz@kpn.com Fri Dec 29 14:25:36 2000 From: E.T.Metz@kpn.com (Metz, E.T.) Date: Fri, 29 Dec 2000 15:25:36 +0100 Subject: [Isis-wg] [IS-IS WG] Subsecond Timers Message-ID: <59063B5B4D98D311BC0D0001FA7E45220316A711@L04> > > Given the current run-to-completion operating system > schedulers that we all > seem to use, you basically have two choices: either try to run to > completion with MUCH tighter timers throughout the ENTIRE > operating system > or convert to a pre-emptive scheduling mechanism. Both are > fraught with > risk. > If implementation of "very tight timers" is a real big issue (and I'll gladly take your word for that), how does this relate to protocols like LMP? This relies on timers in the milli-second range, which is hard, if not impossible if I understand correctly. Would these protocols (FLIP is the other I believe) require a complete re-do of the router OS, or can they implemented in another way. cheers, Eduard ps could someone elaborate on the (possible) side-effects of subsecond timers in ISIS (or any IGP)? there were some hints to things go wrong, but without revealing what and why ... thanks. From prz@net4u.ch Fri Dec 29 19:57:22 2000 From: prz@net4u.ch (Tony Przygienda) Date: Fri, 29 Dec 2000 20:57:22 +0100 (MET) Subject: [Isis-wg] Clarification on isisCommands... In-Reply-To: <20001229102106.9091.cpmta@c000.zsm.cp.net> from "navaneeth@www.com" at "Dec 29, 2000 2:21: 6 am" Message-ID: <200012291957.UAA05885@net4u.net4u.ch> Questions about syntax/semantics of specific vendor implementaions should NOT be posted to this forum. This is rather a qeustion for a vendor support organization or maybe nanog. --- tony From prz@net4u.ch Fri Dec 29 20:03:17 2000 From: prz@net4u.ch (Tony Przygienda) Date: Fri, 29 Dec 2000 21:03:17 +0100 (MET) Subject: [Isis-wg] [IS-IS WG] Subsecond Timers In-Reply-To: <59063B5B4D98D311BC0D0001FA7E45220316A711@L04> from "Metz, E.T." at "Dec 29, 2000 3:25:36 pm" Message-ID: <200012292003.VAA05987@net4u.net4u.ch> > > > > > Given the current run-to-completion operating system > > schedulers that we all > > seem to use, you basically have two choices: either try to run to > > completion with MUCH tighter timers throughout the ENTIRE > > operating system > > or convert to a pre-emptive scheduling mechanism. Both are > > fraught with > > risk. > > > > If implementation of "very tight timers" is a real big issue (and I'll > gladly take your word for that), how does this relate to protocols like LMP? > This relies on timers in the milli-second range, which is hard, if not > impossible if I understand correctly. Would these protocols (FLIP is the > other I believe) require a complete re-do of the router OS, or can they > implemented in another way. this is a very deep question to which a simplistic answer is "depends on the layer". Analogy: it is hard to handle interrupts in unix user space, not so hard in well-written kernel drivers. Therefore certain protocols, especially those very close to hardware (e.g. BLSR ;-) can run in a very fine resolution. Traditionally, layer 3 protocols like ISIS are not that close to hardware in many respects and there having such fast answer times or what I use to call "small intertia" is hard ... Although there are people who tried OSPF in ASICs, at least the design ;-) > ps could someone elaborate on the (possible) side-effects of subsecond > timers in ISIS (or any IGP)? there were some hints to things go wrong, but > without revealing what and why ... thanks. I would encourage this discussion to happen rather on a protocol implementation related list, gated or zebra comes into my mind. This list & group is concerned with the specification, interoperability and deployment issues of the protocol and NOT implementation techniques. Otherwise all the ISPs will become bored and run away and will start to do geeks-cool-things instead of the right-for-customer-things. thanks -- tony From Chris Whyte" <200012272329.PAA19459@cirrus.juniper.net><3A4A7D03.48E913F6@redback.com><009c01c07090$551d50c0$eae5130a@cisco.com> <14922.62544.735986.360952@alpha-tony.procket.com> Message-ID: <022901c071ec$f50db270$eae5130a@cisco.com> > > Chris, > > | Well hell, I love boring and simplistic but maybe someone can explain why > | changes to the protocol to achieve something like faster restoration is more > | operationally complex than a large mesh of TE and bypass tunnels (ie FRR), > | which also requires changes to the protocol. And certainly running a network > | that uses the latter approach is no walk in the park. > > > One last time: it's not the changes to the protocol. It's the changes to > the rest of the system. For the routing protocol to detect a loss of > adjacency at the rates that are proposed, the routing protocol process must > run at much higher rates to generate the hello packets, receive them, and > time out failed adjacencies. Yes, I understood that. Sorry, I'm quite stubburn. I sometimes ask people to repeat things more than once. :-) > > Given the current run-to-completion operating system schedulers that we all > seem to use, you basically have two choices: either try to run to > completion with MUCH tighter timers throughout the ENTIRE operating system > or convert to a pre-emptive scheduling mechanism. Both are fraught with > risk. Ok. I think that one has sunk in. > > Whereas if you take a look at a TE approach, you find that the underlying > protocol has NOT changed in any substantive way. It's being (ab)used as a > mechanism for transporting unnatural information, but the dynamics of the > protocol itself has not changed one whit. It's absolutely true that > there's more complexity in the TE code. But when (not if) it breaks, all > it does is to cause localized failures in the TE subsystem. Basic unicast > routing should be very much unaffected. So everything above clearly helps me understand the protocol differences and how they impact the (rest of the) system but it what about the operational differences? My experience says there are also lots of big problems in networks due to operational complexity. And, as you admitted, since there's more complexity in the TE code then this clearly should increase operational challenges. Yes, I know... this is something that I'm sure you all would prefer to discuss somewhere else. My only goal (other than learning from this thread) is that I would like to see if there are any changes to the protocol that can be made in order to achieve convergence in the neighborhood of hundreds of milliseconds (I'm not necessarily stuck on some number like 50ms) yet not substantially increase operational complexity (or at least what I consider to be operational complexity :-)). And as someone else mentioned to me recently; convergence goals of milliseconds really requires better abstraction boundaries along with some richer metrics (eg 1-prop delay + 2-some link quality indicator to weight 1). I believe the former requires a slight fundamental change in how we design networks today (maybe not) and the latter has challenges in how we can make a multi-metric truly useful. Anyway, you get my point. > > > | I realize I'm mixing a bit of operational complexity concern with protocol > | implementation issues but is it simply that the risk of meltdown is much > | greater? And if so, are there not things we can do like using an spf backoff > | algorithm in the face of instability to prevent meltdown (very similar to > | Henk's old work)? > > > Again, it's not the speed of SPFs that matter. It's that you now have to > be able to respond to a timer expiration within 10ms or so. That's about > three orders of magnitude faster than today. I never said 10ms. I'd be very happy with 3 x 200ms (like I said above). :-) But hey, if you think I'm just wasting your time (and my time), I'll shut up. Thanks, Chris > > Tony > From navaneeth@www.com Sun Dec 31 06:53:47 2000 From: navaneeth@www.com (navaneeth@www.com) Date: 30 Dec 2000 22:53:47 -0800 Subject: [Isis-wg] Clarification Message-ID: <20001231065347.11600.cpmta@c000.zsm.cp.net> Hi All, Considering the functionality of a default route, do we at any time need to advertise the default route in the L1 / L2 LSPs. If so what are the conditions under which we advertise these and when we receive, how do we process the default route.( in case we already have a nearest L2 IS). Thanx and Regards Navaneeth. ______________________________________________________ Listen to your favorite music while you work! - http://www.com/ From amir@cwnt.com Sun Dec 31 11:45:59 2000 From: amir@cwnt.com (Amir H.) Date: Sun, 31 Dec 2000 11:45:59 -0000 Subject: [Isis-wg] Clarification References: <20001231065347.11600.cpmta@c000.zsm.cp.net> Message-ID: <012101c0731f$3e8aad30$2c00a8c0@amir> Navaneeth, There is a difference between a default route injected into the IS-IS domain, and the route to the nearest L2 IS. A router advertising a default route is attracting traffic which fits into that prefix (which actually is all traffic). So, if there is no more specific prefix for a given IP address, this route will be used. In this context, this is no different than any another route. So, you'd process it just like you'd process other IP External Reachability entries. This is relevant in both level-1 and level-2 routers. The nearest L2 IS is only relevant in level-1 (and level-2 un-attached routers), and is used when a destination is not within an area, according to RFC1195. However, RFC1195 does not allow external prefixes to be injected into a level-1 area, whereas the current practice and recent drafts do allow it. I'd say that this changes a bit the definition in the RFC1195, to destinations not _advertised_ within an area. So, if a router advertises a default route into the area, it should be used, just like other external prefixes not in the area, and not the nearest L2 IS (even if it's closer in metric). The same is for a level-2 unattached router. Note, however, that injection of default routes into the IS-IS domain should be done VERY carefully. Hope this helps, Amir. -- Amir Hermelin mailto:amir@cwnt.com ----- Original Message ----- From: To: Sent: Sunday, December 31, 2000 6:53 AM Subject: [Isis-wg] Clarification > Hi All, > > Considering the functionality of a default route, > do we at any time need to advertise the default route in the L1 / L2 LSPs. If so what are the conditions under which we advertise these and when we receive, how do we process the default route.( in case we already have a nearest L2 IS). > > Thanx and Regards > Navaneeth. > > > ______________________________________________________ > Listen to your favorite music while you work! > - http://www.com/ > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > From navaneeth@www.com Fri Dec 29 09:45:39 2000 From: navaneeth@www.com (navaneeth@www.com) Date: 29 Dec 2000 01:45:39 -0800 Subject: [Isis-wg] Clarification on isisCommands... Message-ID: <20001229094539.24005.cpmta@c000.zsm.cp.net> Hi, Can anybody clarify the use of the Cisco Commandline default-information originate (IS-IS): >From the Cli doc of cisco START :: To generate a default route into an IS-IS routing domain, use the default-information originate router configuration command. To disable this feature, use the no form of this command. default-information originate [route-map map-name] no default-information originate [route-map map-name] END:: What does this commsnd do? In the explanation it says, if the command is used without routemap option, the IS has to advertise the default route in its L2 Lsps. If the route map is specified, based on the route map, the default route must be conditinally advertised in the L1 LSPs. What is the use of this default route being advertised in the LSPs? How is the advertised default route processed? Thanx and Regards Navaneeth. ______________________________________________________ Listen to your favorite music while you work! - http://www.com/ From rja@inet.org Sun Dec 31 17:27:34 2000 From: rja@inet.org (RJ Atkinson) Date: Sun, 31 Dec 2000 12:27:34 -0500 Subject: [Isis-wg] Re: [IS-IS WG] Subsecond Timers In-Reply-To: <039201c06f92$5cb136c0$eae5130a@cisco.com> References: Message-ID: <5.0.0.25.2.20001231121912.00a01ca0@gnat.inet.org> At 18:19 26/12/00, Chris Whyte wrote: >And one could argue that some ISPs are making, or will make, >the front page of the WSJ because of the additional complexity >they're putting in their network just to get around the fact >that we can't do sub-second, or just plain faster, igp restoration. One could argue anything I suppose; the particular example above would be a false argument as it happens. >But I'm really curious, how much experimentation has been done >in this area in the last year or so? I really don't know >but I suspect it's been minimal. Hence the desire to do some *science* with some *controlled experiments* on any proposal in this area BEFORE the IETF *standardises* any changes to a protocol that works. On this list, so far, folks are NOT saying "never change the protocol". Folks ARE saying, please let the interested folks run some scientific private experiments, document the changes made, and their results, and let the proposal have some good peer review -- BEFORE we *standardise* a change to the protocol. None of these items require ANY IETF action be taken *yet*. Folks like Van have, for many years, done the science and run appropriate experiments *before* coming to an IETF WG to propose changes to standards. If folks have documented results from some small scale or large scale experiments, please post a pointer to the documentation on the change made, the experimental setup, and the results. If folks have small scale results that are positive and want to try a large scale experiment, one approach would be to describe the change and the experiment in an EXPERIMENTAL RFC. Then, AFTER there is a high level of confidence in the proposal, based on such experiments, one could move the potential spec change into a non-experimental RFC. Ran rja@inet.org From rja@inet.org Sun Dec 31 17:38:38 2000 From: rja@inet.org (RJ Atkinson) Date: Sun, 31 Dec 2000 12:38:38 -0500 Subject: [Isis-wg] Re: [IS-IS WG] Subsecond Timers In-Reply-To: <022901c071ec$f50db270$eae5130a@cisco.com> References: <004b01c0703b$cdbc3960$eae5130a@cisco.com> <200012272329.PAA19459@cirrus.juniper.net> <3A4A7D03.48E913F6@redback.com> <009c01c07090$551d50c0$eae5130a@cisco.com> <14922.62544.735986.360952@alpha-tony.procket.com> Message-ID: <5.0.0.25.2.20001231123511.00a01870@gnat.inet.org> At 18:13 29/12/00, someone wrote: >My only goal (other than learning from this thread) is that >I would like to see if there are any changes to the protocol >that can be made in order to achieve convergence in the >neighborhood of hundreds of milliseconds (I'm not necessarily >stuck on some number like 50ms) yet not substantially increase >operational complexity (or at least what I consider to be >operational complexity :-)). It is fascinating to me that there is still interest in "changes to the protocol" after several folks have suggested that convergence time improvements by tuning one's implementation (without a protocol change) are more likely to be a ripe opportunity. My guess would be that whoever had good/valid/stable ideas about tuning without a protocol change and made them work would sell a lot more product than one who wanted/needed to change the protocol. Ran