From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 1 05:59:24 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11975 for ; Tue, 1 Mar 2005 05:59:24 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00FB9773@cherry.ease.lsoft.com>; Tue, 1 Mar 2005 5:59:17 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59803442 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 1 Mar 2005 05:59:15 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 1 Mar 2005 05:59:15 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Questions about OSPF v3 security draft thread-index: AcUauTfThfjJMmqZQmOoBQu1s8WJNADk+DMw Message-ID: Date: Tue, 1 Mar 2005 02:59:15 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Questions about OSPF v3 security draft To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Mike, Sorry for the delay. I may be wrong as I have not implemented this = myself, however my views are as follows: - If you see the SPD entry the Remote IP Address can be=20 "- Remote IP Address(es) (IPv4 or IPv6): this is a list of ranges of IP addresses (unicast, anycast, broadcast (IPv4 only), or multicast group). " So for OSPF the Multicast as well as the unicast addresses will be used = to refer to an SA. Next Layer Protocol would say OSPF. That way we will have just one entry for all OSPF packets out of an = interface, just as we want it and a similar entry for inbound traffic. I = do not see a case of Full Mesh at all. I may be missing the point. Thanks, Vishwas ________________________________________ From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike = Fox Sent: Friday, February 25, 2005 2:58 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Questions about OSPF v3 security draft Vishwas,=20 I shared your response with our security expert and here is his = response:=20 What we need to know is whether the paragraph is referring to unicast. " = What it means is we will use the same crypto-algorithm and keys for all = traffic to a neighbor over an interface." If this comment is referring = to unicast, the point remains is that there will be multiple SAs. We = will not be able to adhere to the figure 3 requirements for unicast, and = there will be full meshing of SAs required between all communicating = OSPFs. Not so bad if using IKE. Really bad if using manual SAs. =A0=20 Here is the thread of notes being referred to (since it's been a couple = of weeks):=20 Vishwas Manral =20 Sent by: Mailing List =20 02/15/2005 12:01 AM=20 Please respond to Mailing List=20 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =A0OSPF@PEACH.EASE.LSOFT.COM=20 =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =A0Re: Questions about OSPF v3 = security draft Hi Mike,=20 =A0=20 I think both the authors are on leave, so they will probably reply = later.=20 =A0=20 However regarding the first point, I agree the wording should be = clearer. However what it means is we will use the same crypto-algorithm = and keys for all traffic to a neighbor over an interface.=20 =A0=20 Regarding the second point, I think I too have brought the issue on this = list and the reply I think was that the draft does not prohibit the use = of IKE for unicast flows.=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0=20 Thanks,=20 Vishwas=20 ________________________________________ From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike = Fox Sent: Friday, February 11, 2005 8:04 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Questions about OSPF v3 security draft=20 =A0=20 Regarding = http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-07.txt, = and the previous drafts, a couple of questions have come up in our shop. = 1) Section 7, 2nd paragraph says "the implementations MUST use manually = configured keys with same SA for inbound and outbound traffic (as shown = in figure 3). =A0I assume the "same SA" MUST rule applies to multicast = traffic only and not unicast traffic. This is because an SA is defined = as an SPI, security protocol (AH or ESP), and destination IP address. = For unicast addresses, by definition there will be as many SAs as there = are unicast destination addresses. Therefore, I don't think it is = possible to apply this MUST rule given the current IPSec definition (RFC = 2401 section 4.1) of an SA for unicast. Assuming the intention of the = draft was to apply only to multicast and given the number of potential = SAs carrying unicast traffic, it would seem that using IKE to setup the = SAs dynamically would be a reasonable alternative to manual keying. =A0 = =A0=20 =A0 2)Section 9, 2nd paragraph discusses setting up a "secure IPSec channel = dynamically once it acquires the required information". =A0Since this = traffic is unicast only, IKE could easily set up the required SAs = without knowing the specific IP addresses in advance. Creating SAs = dynamically do not fit easily within scope of manual SA functional = capabilities. Why not use IKE for this traffic? Is this an acceptable = option? =A0=20 Mike=20 From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 1 06:08:08 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12374 for ; Tue, 1 Mar 2005 06:08:06 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00FB97B1@cherry.ease.lsoft.com>; Tue, 1 Mar 2005 6:08:06 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 59809696 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 1 Mar 2005 06:08:04 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 1 Mar 2005 06:04:39 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51E4E.762411A3" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Questions about OSPF v3 security draft thread-index: AcUauTfThfjJMmqZQmOoBQu1s8WJNADlknoA Message-ID: Date: Tue, 1 Mar 2005 03:04:38 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Questions about OSPF v3 security draft To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C51E4E.762411A3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, =20 I forgot to mention, we do know a lot of issues with the security provided using the manual keying methods. We had a long discussion with the Security as well as Routing AD's and now in a stage of working to bring out a draft on the issues as a first step and the probably work on possible solutions. =20 Thanks, Vishwas ________________________________ From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike Fox Sent: Friday, February 25, 2005 2:58 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Questions about OSPF v3 security draft =20 Vishwas,=20 I shared your response with our security expert and here is his response:=20 What we need to know is whether the paragraph is referring to unicast. " What it means is we will use the same crypto-algorithm and keys for all traffic to a neighbor over an interface." If this comment is referring to unicast, the point remains is that there will be multiple SAs. We will not be able to adhere to the figure 3 requirements for unicast, and there will be full meshing of SAs required between all communicating OSPFs. Not so bad if using IKE. Really bad if using manual SAs. =20 Here is the thread of notes being referred to (since it's been a couple of weeks):=20 =20 Vishwas Manral =20 Sent by: Mailing List =20 02/15/2005 12:01 AM=20 Please respond to Mailing List=20 =20 To: OSPF@PEACH.EASE.LSOFT.COM=20 cc: =20 Subject: Re: Questions about OSPF v3 security draft Hi Mike,=20 =20 I think both the authors are on leave, so they will probably reply later.=20 =20 However regarding the first point, I agree the wording should be clearer. However what it means is we will use the same crypto-algorithm and keys for all traffic to a neighbor over an interface.=20 =20 Regarding the second point, I think I too have brought the issue on this list and the reply I think was that the draft does not prohibit the use of IKE for unicast flows.=20 =20 Thanks,=20 Vishwas=20 =20 ________________________________ From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike Fox Sent: Friday, February 11, 2005 8:04 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Questions about OSPF v3 security draft=20 =20 Regarding http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-07.txt, and the previous drafts, a couple of questions have come up in our shop. 1) Section 7, 2nd paragraph says "the implementations MUST use manually configured keys with same SA for inbound and outbound traffic (as shown in figure 3). I assume the "same SA" MUST rule applies to multicast traffic only and not unicast traffic. This is because an SA is defined as an SPI, security protocol (AH or ESP), and destination IP address. For unicast addresses, by definition there will be as many SAs as there are unicast destination addresses. Therefore, I don't think it is possible to apply this MUST rule given the current IPSec definition (RFC 2401 section 4.1) of an SA for unicast. Assuming the intention of the draft was to apply only to multicast and given the number of potential SAs carrying unicast traffic, it would seem that using IKE to setup the SAs dynamically would be a reasonable alternative to manual keying. =20 =20 2)Section 9, 2nd paragraph discusses setting up a "secure IPSec channel dynamically once it acquires the required information". Since this traffic is unicast only, IKE could easily set up the required SAs without knowing the specific IP addresses in advance. Creating SAs dynamically do not fit easily within scope of manual SA functional capabilities. Why not use IKE for this traffic? Is this an acceptable option? =20 Mike=20 ------_=_NextPart_001_01C51E4E.762411A3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Mike,

 

I forgot to mention, we do know a = lot of issues with the security provided using the manual keying methods. We = had a long discussion with the Security as well as Routing AD’s and now = in a stage of working to bring out a draft on the issues as a first step and = the probably work on possible solutions.

 

Thanks,

=

Vishwas

=

From: = Mailing List = [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike Fox
Sent: Friday, February = 25, 2005 2:58 AM
To: = OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: Questions = about OSPF v3 security draft

 


Vishwas,

I shared your response with our security expert and here is his = response:

What we need to know is whether the paragraph is referring to unicast. " = What it means is we will use the same crypto-algorithm and = keys for all traffic to a neighbor over an interface." If this = comment is referring to unicast, the point remains is that there will be multiple = SAs. We will not be able to adhere to the figure 3 requirements for unicast, and = there will be full meshing of SAs required between all communicating OSPFs. = Not so bad if using IKE. Really bad if using manual SAs.   =

Here is the thread of notes being referred to (since it's been a couple of = weeks):

 

Vishwas= Manral <Vishwas@SINETT.COM>
Sent by: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>

02/15/2005 12:01 AM
Please respond to Mailing = List

       
        To:       =  OSPF@PEACH.EASE.LSOFT.COM
        cc:         =
        Subject:        Re: Questions = about OSPF v3 security draft




Hi Mike,
 
I think both the authors are on leave, so they will = probably reply later.
 
However regarding the first point, I agree the wording = should be clearer. However what it means is we will use the same = crypto-algorithm and keys for all traffic to a neighbor over an interface.
 
Regarding the second point, I think I too have brought = the issue on this list and the reply I think was that the draft does not = prohibit the use of IKE for unicast flows.
              =                       =                       =                       =                       =                       =                       =        
Thanks,
Vishwas

 


From: = Mailing List = [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike Fox
Sent: Friday, February 11, 2005 8:04 PM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Questions about OSPF v3 security draft =
 

Regarding http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-07.= txt, and the previous drafts, a couple of questions have come up in our shop. =

1) Section 7, 2nd paragraph says "the implementations MUST use = manually configured keys with same SA for inbound and outbound traffic (as shown = in figure 3).  I assume the "same SA" MUST rule applies to multicast traffic only and not unicast traffic. This is because an SA is defined as an SPI, security protocol (AH or ESP), and destination IP = address. For unicast addresses, by definition there will be as many SAs as there = are unicast destination addresses. Therefore, I don't think it is possible = to apply this MUST rule given the current IPSec definition (RFC 2401 section 4.1) = of an SA for unicast. Assuming the intention of the draft was to apply only to multicast and given the number of potential SAs carrying unicast = traffic, it would seem that using IKE to setup the SAs dynamically would be a = reasonable alternative to manual keying.    
 
2)Section 9, 2nd paragraph discusses setting up a "secure IPSec = channel dynamically once it acquires the required information".  Since = this traffic is unicast only, IKE could easily set up the required SAs = without knowing the specific IP addresses in advance. Creating SAs dynamically = do not fit easily within scope of manual SA functional capabilities. Why not = use IKE for this traffic? Is this an acceptable option?   =

Mike

------_=_NextPart_001_01C51E4E.762411A3-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 3 10:25:22 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05434 for ; Thu, 3 Mar 2005 10:25:22 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00FBEEFB@cherry.ease.lsoft.com>; Thu, 3 Mar 2005 10:25:19 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 60123273 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 3 Mar 2005 10:25:18 -0500 Received: from 192.91.191.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 3 Mar 2005 10:25:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: Comments on draft-ietf-ospf-ospfv3-update-02 Thread-Index: AcUgBTN8L3ErLLAUTKqja/k/K5FoFw== Message-ID: <53F74F5A7B94D511841C00B0D0AB16F8057D8C35@baker.datcon.co.uk> Date: Thu, 3 Mar 2005 15:25:03 -0000 Reply-To: Mailing List Sender: Mailing List From: Alan Davey Subject: Comments on draft-ietf-ospf-ospfv3-update-02 Comments: To: acee@cisco.com To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Acee I have had a look at the draft-ietf-ospf-ospfv3-update-02 document. = Overall it looks good. However, I have a few doubts, which I have = listed below. I also noticed a number of minor editorial points with = the document. _Doubts_ - I have a doubt about the handling of multiple interfaces to a single = link. Consider the following case. o Neighbors A and B both have a single active interface to a single = broadcast link. =20 o An adjacency is formed between A and B. o A new interface to the same link is activated on A. o B receives a Hello from A sent through the new interface containing = no mention of B. o A also receives the Hello from A sent through the new interface and = decides that it should continue to use the original interface. o The new link goes into Standby state and takes no further part in the = OSPF protocol exchanges. o However, the neighbor state machine on B has moved to Init state as a = result of receiving the Hello from A containing no mention of B. Should the protocol attempt to handle B receiving the Hello from the = new interface on A without losing the adjacency between A and B? - Section 3.4.3, bullet 4. I have a doubt about the reorigination of = intra-area-prefix-LSA described in this bullet. o The first part of the bullet is discussing reorigination of = Router-LSAs. =20 o The reasons given for reoriginating the intra-area-prefix-LSA relate = to reorigination of Network-LSAs o Reorigination of Network-LSAs, and related reorigination of = intra-area-prefix-LSAs, is covered in other bullets. o Why is it necessary to discuss reorigination of = intra-area-prefix-LSAs in bullet 4? - Section 3.9, bullet 2. Suggest deleting the first sentence: "Each of = the multiple interfaces must be configured with the same interface ID." = This is not true and not, I suspect, what is meant. I think that the = bullet makes sense without this first sentence. _Minor Editorial Points_ - Section 2.1, paragraph 2. s/relaced/replaced/ - Section 2.7, bullet 4. s/Netowrk-LSA/Network-LSA/ - Section 3.2.2, second paragraph on page 19. s/Router ID appearing the = the/Router ID appearing in the/ - Section 3.2.2, third paragraph on page 19. s/identical to to = the/identical to the/ - Section 3.4.3, bullet 4. I have a doubt about the reorigination of = intra-area-prefix-LSA described in this bullet. o The first part of the bullet is discussing reorigination of = Router-LSAs. =20 o The reasons given for reoriginating the intra-area-prefix-LSA relate = to reorigination of Network-LSAs o reorigination of Network-LSAs, and related reorigination of = intra-area-prefix-LSAs, is covered in other bullets. o Why is it necessary to discuss reorigination of = intra-area-prefix-LSAs in bullet 4? - Section 3.4.3, bullet 4. If the last sentence is retained, there is a = typo: s/ot/to/ - Section 3.4.3.5, 1st paragraph of page 30. s/assume the the = IPv6/assume that the IPv6/ - Section 3.5.1, step (2). s/interface area has been been = configued/interface area has been configured/ - Section 3.9.1. s/Interface states machine addtions include/Interface = state machine additions include/ - Section 5, last bullet. s/suggested improvments/suggested = improvements/ - Section A.4.5, 1st paragraph. s/These LSAs are are the/These LSAs are = the/ Please let me know if you have any questions or comments on any of the = above. Regards Alan ------------------------------------ Alan Davey Data Connection Ltd Tel: +44 20 8366 1177 =20 Fax: +44 20 8363 1039 Email: Alan.Davey@dataconnection.com =20 Web: http://www.dataconnection.com=20 From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 4 14:14:37 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21926 for ; Fri, 4 Mar 2005 14:14:37 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00FC193C@cherry.ease.lsoft.com>; Fri, 4 Mar 2005 14:14:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 60289780 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 4 Mar 2005 14:14:31 -0500 Received: from 207.217.121.184 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 4 Mar 2005 14:14:31 -0500 Received: from dialup-4.243.137.24.dial1.sanfrancisco1.level3.net ([4.243.137.24] helo=earthlink.net) by pop-a065c10.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1D7IFq-0007CS-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 04 Mar 2005 11:14:30 -0800 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4228B362.7070705@earthlink.net> Date: Fri, 4 Mar 2005 11:13:38 -0800 Reply-To: Mailing List Sender: Mailing List From: Richard Ogier Subject: draft-ogier-manet-ospf-extension-03.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello, An update to my draft titled "MANET Extension of OSPF using CDS Flooding" is available at http://www.ietf.org/internet-drafts/draft-ogier-manet-ospf-extension-03.txt (The meeting agenda says version 02, but the draft was recently updated to version 03.) This draft will be presented by Tom Henderson at the OSPF session on Tuesday. (I am not able to attend the meeting.) A powerpoint presentation for this draft is available at http://home.earthlink.net/~ogier/cds_ospf3.ppt Here is a summary of the features: - A scalable CDS algorithm (and family of interoperable CDS algorithms) is proposed, which generalizes the OSPF concept of a DR and BDR in a natural way. - The set of DRs forms a CDS, and the set of DRs and BDRs forms a biconnected CDS for robustness. - The computed CDS provides source-independent flooding of LSAs (or other packets). The flooding procedure also allows source-dependent flooding as an option, if it is desired to flood packets along min-hop paths. - The CDS algorithm uses only 2-hop neighbor information from differential Hellos, allowing fast convergence following topology changes. - Only partial 2-hop neighbor information is required. Thus, a non-DR/BDR router never needs to include all of its neighbors in either a Hello or an LSA. - The choice of which neighbors to include in LSAs is flexible, allowing dissemination of partial or full topology information. - The number of DRs and BDRs, the number of adjacencies, and the rate at which new adjacencies are formed, are all found to be scalable in simulations. Regards, Richard From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 4 17:27:07 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11626 for ; Fri, 4 Mar 2005 17:27:07 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00FC1EF0@cherry.ease.lsoft.com>; Fri, 4 Mar 2005 17:27:08 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 60305900 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 4 Mar 2005 17:27:02 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 4 Mar 2005 17:27:02 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 04 Mar 2005 17:42:30 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,136,1107752400"; d="scan'208"; a="39335679:sNHT21277632" Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j24MR01j022571 for ; Fri, 4 Mar 2005 17:27:00 -0500 (EST) Received: from [10.82.226.24] (rtp-vpn1-536.cisco.com [10.82.226.24]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BFU78982; Fri, 4 Mar 2005 14:26:59 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <53F74F5A7B94D511841C00B0D0AB16F8057D8C35@baker.datcon.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4228E0B3.8080405@cisco.com> Date: Fri, 4 Mar 2005 17:26:59 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comments on draft-ietf-ospf-ospfv3-update-02 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F8057D8C35@baker.datcon.co.uk> Precedence: list Content-Transfer-Encoding: 7bit Hi Alan, Thanks much for reviewing and taking the time to compile the list of comments. See inline. Alan Davey wrote: >Hi Acee > >I have had a look at the draft-ietf-ospf-ospfv3-update-02 document. Overall it looks good. However, I have a few doubts, which I have listed below. I also noticed a number of minor editorial points with the document. > >_Doubts_ > >- I have a doubt about the handling of multiple interfaces to a single link. Consider the following case. > o Neighbors A and B both have a single active interface to a single broadcast link. > o An adjacency is formed between A and B. > o A new interface to the same link is activated on A. > o B receives a Hello from A sent through the new interface containing no mention of B. > o A also receives the Hello from A sent through the new interface and decides that it should continue to use the original interface. > o The new link goes into Standby state and takes no further part in the OSPF protocol exchanges. > o However, the neighbor state machine on B has moved to Init state as a result of receiving the Hello from A containing no mention of B. > > Should the protocol attempt to handle B receiving the Hello from the new interface on A without losing the adjacency between A and B? > > I'm going to defer this one to Michael. >- Section 3.4.3, bullet 4. I have a doubt about the reorigination of intra-area-prefix-LSA described in this bullet. > o The first part of the bullet is discussing reorigination of Router-LSAs. > o The reasons given for reoriginating the intra-area-prefix-LSA relate to reorigination of Network-LSAs > o Reorigination of Network-LSAs, and related reorigination of intra-area-prefix-LSAs, is covered in other bullets. > o Why is it necessary to discuss reorigination of intra-area-prefix-LSAs in bullet 4? > > Agreed. I don't think intra-area-prefix LSAs will change when a neighbor's interface ID changes. I will remove this and add interface ID changes to the first bullet. >- Section 3.9, bullet 2. Suggest deleting the first sentence: "Each of the multiple interfaces must be configured with the same interface ID." This is not true and not, I suspect, what is meant. I think that the bullet makes sense without this first sentence. > > This is the "Instance ID" as opposed to the "Interface ID". It allows one to use the same link in more than one OSPF instance or OSPF area (as described in section 2.4). >_Minor Editorial Points_ > >- Section 2.1, paragraph 2. s/relaced/replaced/ > > >- Section 2.7, bullet 4. s/Netowrk-LSA/Network-LSA/ > >- Section 3.2.2, second paragraph on page 19. s/Router ID appearing the the/Router ID appearing in the/ > >- Section 3.2.2, third paragraph on page 19. s/identical to to the/identical to the/ > >- Section 3.4.3, bullet 4. I have a doubt about the reorigination of intra-area-prefix-LSA described in this bullet. > o The first part of the bullet is discussing reorigination of Router-LSAs. > o The reasons given for reoriginating the intra-area-prefix-LSA relate to reorigination of Network-LSAs > o reorigination of Network-LSAs, and related reorigination of intra-area-prefix-LSAs, is covered in other bullets. > o Why is it necessary to discuss reorigination of intra-area-prefix-LSAs in bullet 4? > >- Section 3.4.3, bullet 4. If the last sentence is retained, there is a typo: s/ot/to/ > >- Section 3.4.3.5, 1st paragraph of page 30. s/assume the the IPv6/assume that the IPv6/ > >- Section 3.5.1, step (2). s/interface area has been been configued/interface area has been configured/ > >- Section 3.9.1. s/Interface states machine addtions include/Interface state machine additions include/ > >- Section 5, last bullet. s/suggested improvments/suggested improvements/ > >- Section A.4.5, 1st paragraph. s/These LSAs are are the/These LSAs are the/ > > Got all these. Thanks Again, Acee > >Please let me know if you have any questions or comments on any of the above. > >Regards > >Alan > >------------------------------------ >Alan Davey >Data Connection Ltd >Tel: +44 20 8366 1177 >Fax: +44 20 8363 1039 >Email: Alan.Davey@dataconnection.com >Web: http://www.dataconnection.com > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sun Mar 6 02:53:40 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16317 for ; Sun, 6 Mar 2005 02:53:40 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00FC4A19@cherry.ease.lsoft.com>; 6 Mar 2005 2:53:37 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 60441802 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 6 Mar 2005 02:53:36 -0500 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 6 Mar 2005 02:53:36 -0500 Received: from sjc-vpn1-794.cisco.com (HELO cisco.com) (10.21.99.26) by sj-iport-5.cisco.com with ESMTP; 05 Mar 2005 23:54:43 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,138,1107763200"; d="scan'208"; a="165453605:sNHT19417264" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <53F74F5A7B94D511841C00B0D0AB16F8057D8C35@baker.datcon.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <422AB6FD.5080800@cisco.com> Date: Sat, 5 Mar 2005 23:53:33 -0800 Reply-To: Mailing List Sender: Mailing List From: Michael J Barnes Subject: Re: Comments on draft-ietf-ospf-ospfv3-update-02 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F8057D8C35@baker.datcon.co.uk> Precedence: list Content-Transfer-Encoding: 7bit Hi Alan, Alan Davey wrote: > Hi Acee > > I have had a look at the draft-ietf-ospf-ospfv3-update-02 document. Overall it looks good. However, I have a few doubts, which I have listed below. I also noticed a number of minor editorial points with the document. > > _Doubts_ > > - I have a doubt about the handling of multiple interfaces to a single link. Consider the following case. > o Neighbors A and B both have a single active interface to a single broadcast link. > o An adjacency is formed between A and B. > o A new interface to the same link is activated on A. > o B receives a Hello from A sent through the new interface containing no mention of B. > o A also receives the Hello from A sent through the new interface and decides that it should continue to use the original interface. > o The new link goes into Standby state and takes no further part in the OSPF protocol exchanges. > o However, the neighbor state machine on B has moved to Init state as a result of receiving the Hello from A containing no mention of B. > > Should the protocol attempt to handle B receiving the Hello from the new interface on A without losing the adjacency between A and B? To my thinking, B should notice the different interface ID in the packet from the second interface on A, and keep state separately for the second interface, so the state between B and the first interface of A should not be affected. > - Section 3.9, bullet 2. Suggest deleting the first sentence: "Each of the multiple interfaces must be configured with the same interface ID." This is not true and not, I suspect, what is meant. I think that the bullet makes sense without this first sentence. I agree. Regards, Michael From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@PEACH.EASE.LSOFT.COM Tue Mar 8 04:27:21 2005 Received: from grape.ease.lsoft.com (grape.ease.lsoft.com [209.119.1.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02385 for ; Tue, 8 Mar 2005 04:27:21 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <9.00552429@grape.ease.lsoft.com>; Tue, 8 Mar 2005 4:27:23 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 60700636 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 8 Mar 2005 04:27:22 -0500 Received: from 192.91.191.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 8 Mar 2005 04:27:22 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: Comments on draft-ietf-ospf-ospfv3-update-02 Thread-Index: AcUhCU7lazk/SY4YQZa7sq8f2jfXuAB7AVNA Message-ID: <53F74F5A7B94D511841C00B0D0AB16F8057D8C46@baker.datcon.co.uk> Date: Tue, 8 Mar 2005 09:27:15 -0000 Reply-To: Mailing List Sender: Mailing List From: Alan Davey Subject: Re: Comments on draft-ietf-ospf-ospfv3-update-02 Comments: To: acee@cisco.com To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Acee Thanks for your response. One follow up point below. >- Section 3.9, bullet 2. Suggest deleting the first sentence: "Each of = the multiple interfaces must be configured with the same interface ID." = This is not true and not, I suspect, what is meant. I think that the = bullet makes sense without this first sentence. > =20 > This is the "Instance ID" as opposed to the "Interface ID". It allows=20 one to use the same link in more than one OSPF instance or OSPF area (as described in section 2.4). Sorry, I failed to copy the sentence correctly; as you point out, the = draft reads "Instance ID" and not "Interface ID". However, I think that = my point stands. For example, - the rest of the bullet discusses handling the case where multiple = interfaces to the same link may have multiple instance IDs. =20 - in the example given, interface A is configured with instance 1 and = interface B is not. =20 I think that removing the first sentence of the bullet makes the meaning = clearer: that OSPF protocol traffic is sent and received on a single = interface from a set of multiple interfaces to the same link using the = same instance ID. Thanks Alan ------------------------------------ Alan Davey Data Connection Ltd Tel: +44 20 8366 1177 =20 Fax: +44 20 8363 1039 Email: Alan.Davey@dataconnection.com =20 Web: http://www.dataconnection.com=20 From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 10 09:35:07 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19502 for ; Thu, 10 Mar 2005 09:35:06 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00FCDFE7@cherry.ease.lsoft.com>; Thu, 10 Mar 2005 9:35:05 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61032967 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 10 Mar 2005 09:35:02 -0500 Received: from 207.217.121.184 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 10 Mar 2005 09:35:02 -0500 Received: from dialup-4.243.128.110.dial1.sanfrancisco1.level3.net ([4.243.128.110] helo=earthlink.net) by pop-a065c10.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1D9Oke-0007cx-00 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 10 Mar 2005 06:35:01 -0800 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <42305B11.5020601@earthlink.net> Date: Thu, 10 Mar 2005 06:34:57 -0800 Reply-To: Mailing List Sender: Mailing List From: Richard Ogier Subject: Re: draft-ogier-manet-ospf-extension-03.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit All, Tom Henderson summarized some concerns about my draft that were voiced at the OSPF session on Tuesday, which I would like to respond to (since I was not at the meeting). The main concern seems to be that the solution may not be robust because there are not enough Backup DRs, or because each DR has too many Dependent Neighbors, or because it may take a long time for database exchange when a new DR is selected. I don't think these concerns are valid, but we will find out with simulations (and I agree with Joe Macker that simulations should include failure models in addition to mobility). For now, I will clarify some things that might alleviate any concerns about robustness. 1. There might be a misunderstanding that data packets can only be routed on adjacent (or fully adjacent) edges. This is not true in my draft, nor is it true in OSPF (in a broadcast network, a non-DR/BDR router can forward a data packet to a non-adjacent neighbor, as long as both routers are adjacent to the DR - note that the "synchronized neighbor" condition in my draft generalizes this condition). For example, in the full topology case, LSAs describe the full topology even though there are only about 2*n adjacencies. 2. A new DR does not have to complete database exchange with its (dependent) neighbors before it can flood LSAs. 3. If a DR fails, then a BDR will forward the LSA for it, so the main concern is what happens if a DR and a nearby DR/BDR fail at nearly the same time. The probability of this happening is fairly low, but it can happen, so let's see what happens. Note that it is possible to select more BDRs for more redundancy, or to allow *any* router act as a BDR, but I don't think this will be necessary, for the following reason. With differential Hellos being sent every 1 or 2 seconds (which is quite possible since they are small), if a DR fails, then a new DR will select itself within a few Hello intervals, e.g. between 3 and 6 seconds. Since RxmtInterval is typically 5 seconds, the new DR will probably select itself before the LSA would be retransmitted anyway! I would also like to answer a question regarding what happens if the 2-hop neighbor information is not consistent. This is a good question, and I will update my draft to clarify this. If node i has two neighbors j and k such that j indicates (in its Hellos) that k is a neighbor, but k indicates that j is NOT a neighbor, then node i must assume that j and k are NOT neighbors (i.e., both neighbors must agree that they are neighbors of each other). This provides faster recovery from a link failure, since one neighbor may detect the failure sooner than the other neighbor. (Also, note that the rule is different for partial 2-hop neighbor information, since the absence of a neighbor RID in a partial Hello does not indicate that the router is not a neighbor.) Regards, Richard From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 10 10:15:56 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23597 for ; Thu, 10 Mar 2005 10:15:55 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00FCE2CA@cherry.ease.lsoft.com>; Thu, 10 Mar 2005 10:15:56 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61035837 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 10 Mar 2005 10:15:53 -0500 Received: from 209.119.1.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 10 Mar 2005 10:15:53 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <6.005536BD@grape.ease.lsoft.com>; Thu, 10 Mar 2005 10:15:54 -0500 Message-ID: Date: Thu, 10 Mar 2005 10:15:53 -0500 Reply-To: Mailing List Sender: Mailing List From: SUBSCRIBE OSPF vishnuvardhan B Subject: Re: draft-ietf-ospf-multi-area-adj-03.txt Comments: To: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Ace, Thanks for the reply. I have some more scenarios: 1) I am trying to configure a secondary adjacency on a broadcast link. In this scenario should the secondary form full mesh(adjacency) with all the neighbors on the broadcast link? 2) One more question before configuring a secondary on a router the router should be an ABR or after configuring should it become ABR? Thanks&Regards, Vishnu From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 10 10:38:15 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26184 for ; Thu, 10 Mar 2005 10:38:15 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00FCE3F7@cherry.ease.lsoft.com>; Thu, 10 Mar 2005 10:38:16 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61039153 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 10 Mar 2005 10:38:15 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 10 Mar 2005 10:38:15 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 10 Mar 2005 10:54:44 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,153,1107752400"; d="scan'208"; a="39987589:sNHT20726168" Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2AFcCjI010479; Thu, 10 Mar 2005 10:38:13 -0500 (EST) Received: from [10.21.122.97] (sjc-vpn6-609.cisco.com [10.21.122.97]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BFY55212; Thu, 10 Mar 2005 07:38:10 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <423069E0.70808@cisco.com> Date: Thu, 10 Mar 2005 10:38:08 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-multi-area-adj-03.txt Comments: To: SUBSCRIBE OSPF vishnuvardhan B To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi Vishnu, SUBSCRIBE OSPF vishnuvardhan B wrote: >Hi Ace, >Thanks for the reply. I have some more scenarios: >1) I am trying to configure a secondary adjacency on a broadcast link. >In this scenario should the secondary form full mesh(adjacency) with all >the neighbors on the broadcast link? > > This solution requires the configuration of a secondary adjacency with each neighbor on the broadcast link .There are other possible solutions but this approach has made the trade-off in favor of simplicity. . >2) One more question before configuring a secondary on a router the router >should be an ABR or after configuring should it become ABR? > > It is assumed that the two routers are ABRs. However, the secondary adjacency is completely decoupled from the primary adjacency. Hence, there is nothing in the draft that precludes two non-ABRs from forming a secondary adjacency. Hope this helps, Acee >Thanks&Regards, >Vishnu > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 11 14:31:56 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00417 for ; Fri, 11 Mar 2005 14:31:56 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00FD17C5@cherry.ease.lsoft.com>; Fri, 11 Mar 2005 14:31:36 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61202150 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 11 Mar 2005 14:31:34 -0500 Received: from 47.129.242.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 11 Mar 2005 14:21:33 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j2BJLVe12969 for ; Fri, 11 Mar 2005 14:21:31 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Mar 2005 14:21:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5266F.83F1F199" Message-ID: Date: Fri, 11 Mar 2005 14:21:24 -0500 Reply-To: Mailing List Sender: Mailing List From: Andrew Smith Subject: Multiple ABR summarization To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5266F.83F1F199 Content-Type: text/plain Group, If two ABRs for a regular sub-tending area are summarizing the same intra-area routes into the backbone area, do both ABRs send the same LSA-3 advertisement or does one ABR defer the announcement to the other ABR? I believe for NSSA areas one of the ABRs will not send the LSA-3 summarization (might be only for external routes) into the backbone area. I was wondering if this behavior also occurred on regular areas. Regards, Andy Smith ------_=_NextPart_001_01C5266F.83F1F199 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Multiple ABR summarization

Group,
If two ABRs for a regular sub-tending = area are summarizing the same intra-area routes into the backbone area, = do both ABRs send the same LSA-3 advertisement or does one ABR defer = the announcement to the other ABR?

I believe for NSSA areas one of the = ABRs will not send the LSA-3 summarization (might be only for external = routes) into the backbone area. I was wondering if this behavior also = occurred on regular areas.

Regards,
Andy Smith

------_=_NextPart_001_01C5266F.83F1F199-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 11 14:43:55 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01185 for ; Fri, 11 Mar 2005 14:43:54 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00FD15A5@cherry.ease.lsoft.com>; Fri, 11 Mar 2005 14:43:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61203636 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 11 Mar 2005 14:43:29 -0500 Received: from 207.217.121.184 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 11 Mar 2005 14:43:29 -0500 Received: from h-68-164-90-248.snvacaid.dynamic.covad.net ([68.164.90.248] helo=earthlink.net) by pop-a065c10.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1D9q2j-0001dK-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 11 Mar 2005 11:43:29 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <4231F626.37471554@earthlink.net> Date: Fri, 11 Mar 2005 11:48:54 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Multiple ABR summarization To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, Don't both ABRs summarize? Why would they even want to defer? Mitchell Erblich -------------------- > Andrew Smith wrote: > > Group, > If two ABRs for a regular sub-tending area are summarizing the same > intra-area routes into the backbone area, do both ABRs send the same > LSA-3 advertisement or does one ABR defer the announcement to the > other ABR? > > I believe for NSSA areas one of the ABRs will not send the LSA-3 > summarization (might be only for external routes) into the backbone > area. I was wondering if this behavior also occurred on regular areas. > > Regards, > Andy Smith From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 11 14:50:46 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01606 for ; Fri, 11 Mar 2005 14:50:46 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00FD177C@cherry.ease.lsoft.com>; Fri, 11 Mar 2005 14:50:46 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61203940 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 11 Mar 2005 14:50:44 -0500 Received: from 158.130.12.194 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 11 Mar 2005 14:50:44 -0500 Received: from ee.upenn.edu (pcp02116477pcs.radnor01.pa.comcast.net [68.81.243.66]) (authenticated bits=0) by lion.seas.upenn.edu (8.12.10/8.12.10) with ESMTP id j2BJoXV6005390 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Mar 2005 14:50:34 -0500 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: multipart/alternative; boundary="------------070400020202010805000700" Message-ID: <4231F68E.4050203@ee.upenn.edu> Date: Fri, 11 Mar 2005 14:50:38 -0500 Reply-To: Mailing List Sender: Mailing List From: Roch Guerin Subject: Re: Multiple ABR summarization To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list This is a multi-part message in MIME format. --------------070400020202010805000700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andy, As far as I know, this rule only applies to external LSAs. See section 12.4.4.1 of RFC 2328, which states: The following rule is thereby established: if two routers, both reachable from one another, originate functionally equivalent AS-external-LSAs (i.e., same destination, cost and non-zero forwarding address), then the LSA originated by the router having the highest OSPF Router ID is used. The router having the lower OSPF Router ID can then flush its LSA. There is no similar definition for "functionally equivalent" summary LSAs, and even if the two ABRs advertised the same summary route with the same cost, this still represents different connectivity options, e.g., one may be much closer that the other for some routers in the area. This is unlike the example of section 12.4.4.1 where routing is unaffected whether one or two ASBRs advertise the (functionally equivalent) external LSA. Hope this helps. Roch > Group, > If two ABRs for a regular sub-tending area are summarizing the same > intra-area routes into the backbone area, do both ABRs send the same > LSA-3 advertisement or does one ABR defer the announcement to the > other ABR? > > I believe for NSSA areas one of the ABRs will not send the LSA-3 > summarization (might be only for external routes) into the backbone > area. I was wondering if this behavior also occurred on regular areas. > > Regards, > Andy Smith > --------------070400020202010805000700 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Andy,

As far as I know, this rule only applies to external LSAs. See section 12.4.4.1 of RFC 2328, which states:
                    The following rule is
                    thereby established: if two routers, both reachable
                    from one another, originate functionally equivalent
                    AS-external-LSAs (i.e., same destination, cost and
                    non-zero forwarding address), then the LSA
                    originated by the router having the highest OSPF
                    Router ID is used.  The router having the lower OSPF
                    Router ID can then flush its LSA.
There is no similar definition for "functionally equivalent" summary LSAs, and even if the two ABRs advertised the same summary route with the same cost, this still represents different connectivity options, e.g., one may be much closer that the other for some routers in the area.  This is unlike the example of section 12.4.4.1 where routing is unaffected whether one or two ASBRs advertise the (functionally equivalent) external LSA.

Hope this helps.

Roch
Multiple ABR summarization

Group,
If two ABRs for a regular sub-tending area are summarizing the same intra-area routes into the backbone area, do both ABRs send the same LSA-3 advertisement or does one ABR defer the announcement to the other ABR?

I believe for NSSA areas one of the ABRs will not send the LSA-3 summarization (might be only for external routes) into the backbone area. I was wondering if this behavior also occurred on regular areas.

Regards,
Andy Smith


--------------070400020202010805000700-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 11 15:48:34 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06295 for ; Fri, 11 Mar 2005 15:48:34 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00FD178E@cherry.ease.lsoft.com>; Fri, 11 Mar 2005 15:48:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61209280 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 11 Mar 2005 15:48:30 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 11 Mar 2005 15:48:30 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 11 Mar 2005 15:48:31 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2BKmS1j008615 for ; Fri, 11 Mar 2005 15:48:29 -0500 (EST) Received: from [10.82.241.140] (rtp-vpn2-396.cisco.com [10.82.241.140]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BFZ85897; Fri, 11 Mar 2005 12:48:27 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <4231F68E.4050203@ee.upenn.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4232041B.6040804@cisco.com> Date: Fri, 11 Mar 2005 15:48:27 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Multiple ABR summarization To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4231F68E.4050203@ee.upenn.edu> Precedence: list Content-Transfer-Encoding: 7bit Roch Guerin wrote: > Andy, > > As far as I know, this rule only applies to external LSAs. See section > 12.4.4.1 of RFC 2328, which states: > > The following rule is > thereby established: if two routers, both reachable > from one another, originate functionally equivalent > AS-external-LSAs (i.e., same destination, cost and > non-zero forwarding address), then the LSA > originated by the router having the highest OSPF > Router ID is used. The router having the lower OSPF > Router ID can then flush its LSA. > > There is no similar definition for "functionally equivalent" summary > LSAs, and even if the two ABRs advertised the same summary route with > the same cost, this still represents different connectivity options, > e.g., one may be much closer that the other for some routers in the > area. This is unlike the example of section 12.4.4.1 where routing is > unaffected whether one or two ASBRs advertise the (functionally > equivalent) external LSA. Roch is correct. AS external LSAs may include a forwarding addresses and the advertised route can be exactly the same with a non-zero forwarding address. Thanks, Acee > > Hope this helps. > > Roch > >> Group, >> If two ABRs for a regular sub-tending area are summarizing the same >> intra-area routes into the backbone area, do both ABRs send the same >> LSA-3 advertisement or does one ABR defer the announcement to the >> other ABR? >> >> I believe for NSSA areas one of the ABRs will not send the LSA-3 >> summarization (might be only for external routes) into the backbone >> area. I was wondering if this behavior also occurred on regular areas. >> >> Regards, >> Andy Smith >> > > From owner-ospf@PEACH.EASE.LSOFT.COM Sat Mar 12 17:08:26 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11620 for ; Sat, 12 Mar 2005 17:08:26 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00FD3938@cherry.ease.lsoft.com>; Sat, 12 Mar 2005 17:08:23 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61326186 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 12 Mar 2005 17:08:21 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 12 Mar 2005 17:08:21 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 12 Mar 2005 17:08:22 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2CM8J1j005166 for ; Sat, 12 Mar 2005 17:08:20 -0500 (EST) Received: from [10.82.241.140] (rtp-vpn2-396.cisco.com [10.82.241.140]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BGA30247; Sat, 12 Mar 2005 14:08:18 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <53F74F5A7B94D511841C00B0D0AB16F8057D8C13@baker.datcon.co.uk> <421CA02C.4080309@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <42336852.8000602@cisco.com> Date: Sat, 12 Mar 2005 17:08:18 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comments on draft-ietf-ospf-ospfv3-traffic-03 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <421CA02C.4080309@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Regarding the issue below, I'm inclined to agree with Alan and support a link state ID with an arbitrary value. My reasons: 1. This is consistent with OSPFv2 TE (RFC 3630). 2. If we define new TE top-level TLVs, we may have a link state ID space overlap when using interface ID for the Link State ID. 3. The Link State ID to Interface ID really doesn't buy that much since most implementations I've encountered maintain separate TE and Link State databases (so the network LSA<->TE LSA ease of reference isn't really a factor). Any other opinions? Acee > > >> Previously Noted Comments >> ------------------------- >> >> _Suggested Change to the Value Used as the Link State ID_ >> >> I do not think that the interface ID of the link is suitable for use >> as the Link State ID of the Intra-Area-TE-LSA. In particular, it is >> not suitable for the Link State ID of the single Intra-Area-TE-LSA >> containing the Router IPv6 Address TLV advertised by a router as this >> Link State ID must be different to all Link State IDs used for >> Intra-Area-TE-LSAs containing Link TLVs. >> >> I suggest using an arbitrary value with no topological significance >> as the Link State ID for Intra-Area-TE-LSAs, in a similar manner to >> LSA IDs in RFC3630 (Traffic Engineering (TE) Extensions to OSPF >> Version 2). >> >> > In practice, many implementations do use the IfIndex for the the 23 > bit OSPF opaque ID. > My previous implementation used the IfIndex for the LSA opaque type > for the link TLVs > and 0 for the LSA opaque type for the router address TLV. > Anyway, I can see arguments for going both ways. In the case of using > Interface ID and 0 (router IPv6 > address TLV), we simplify access and mapping between TE LSAs and > Network-LSAs. > In the case of the arbitrary IDs, we are not limiting ourselves to > specific ID when adding future > Intra-Area-TE-LSA TLVs. > > Any other opinions here? From owner-ospf@PEACH.EASE.LSOFT.COM Sun Mar 13 14:12:07 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03042 for ; Sun, 13 Mar 2005 14:12:07 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00FD5311@cherry.ease.lsoft.com>; 13 Mar 2005 14:12:06 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61430187 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 13 Mar 2005 14:12:03 -0500 Received: from 64.198.200.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 13 Mar 2005 14:02:02 -0500 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id j2DIxm7k008587 for ; Sun, 13 Mar 2005 13:59:48 -0500 Received: (from icanoop@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id j2DIxmQ8008584 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 13 Mar 2005 13:59:48 -0500 X-Authentication-Warning: localhost.localdomain: icanoop set sender to icanoop@bitwiser.org using -f Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Message-ID: <1110740388.8202.49.camel@localhost.localdomain> Date: Sun, 13 Mar 2005 13:59:47 -0500 Reply-To: Mailing List Sender: Mailing List From: Ryan Boder Organization: Bitwiser Labs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Back in 2002 there was a thread discussing why OSPF uses IP instead of UDP like RIP does. I can't find any convincing answer in this thread or anywhere else. Has anybody since answered this question? These best answer I see in the thread is that using IP is more efficient that UDP because of the UDP header. However they claim that it's 8 bytes more efficient which I think is wrong. The total length and checksum fields are useful to RIP and would be useful to OSPF, since OSPF includes similar fields in it's header. So only the 4 bytes for the source and destination port would be wasted if OSPF used UDP. I am only looking for an answer for academic reasons, I'm not claiming the OSPF should use UDP. But I would like to know why. Is it simply to save 4 bytes in the packet size? Or was the decision just arbitrary? -- Ryan Boder http://bitwiser.org From owner-ospf@PEACH.EASE.LSOFT.COM Sun Mar 13 14:15:18 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03380 for ; Sun, 13 Mar 2005 14:15:18 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00FD5340@cherry.ease.lsoft.com>; 13 Mar 2005 14:15:18 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61430274 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 13 Mar 2005 14:15:16 -0500 Received: from 64.198.200.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 13 Mar 2005 14:05:16 -0500 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id j2DJ31nu008653 for ; Sun, 13 Mar 2005 14:03:01 -0500 Received: (from icanoop@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id j2DJ31g3008650 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 13 Mar 2005 14:03:01 -0500 X-Authentication-Warning: localhost.localdomain: icanoop set sender to icanoop@bitwiser.org using -f Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Message-ID: <1110740581.8202.52.camel@localhost.localdomain> Date: Sun, 13 Mar 2005 14:03:01 -0500 Reply-To: Mailing List Sender: Mailing List From: Ryan Boder Organization: Bitwiser Labs Subject: Re: OSPF over UDP .. why NOT! To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit By the way that thread began here... http://archives.neohapsis.com/archives/microsoft/various/ospf/2002- q1/0194.html -- Ryan Boder http://bitwiser.org From owner-ospf@PEACH.EASE.LSOFT.COM Mon Mar 14 04:59:34 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06104 for ; Mon, 14 Mar 2005 04:59:34 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00FD6676@cherry.ease.lsoft.com>; Mon, 14 Mar 2005 4:59:34 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61476617 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 14 Mar 2005 04:59:32 -0500 Received: from 62.241.162.31 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 14 Mar 2005 04:59:32 -0500 Received: from pc6 (1Cust5.tnt4.lnd4.gbr.da.uu.net [62.188.133.5]) by galaxy.systems.pipex.net (Postfix) with SMTP id 46BC4E000206 for ; Mon, 14 Mar 2005 09:59:31 +0000 (GMT) References: <1110740388.8202.49.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <001d01c52873$c1373ce0$0601a8c0@pc6> Date: Mon, 14 Mar 2005 09:49:25 +0100 Reply-To: Mailing List Sender: Mailing List From: Tom Petch Subject: Re: Why IP To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I suggest you look at 'OSPF: Anatomy of an Internet Routing Protocol' by John T Moy, Addison-Wesley (1998) pp50-51 Tom Petch ----- Original Message ----- From: "Ryan Boder" To: Sent: Sunday, March 13, 2005 7:59 PM > Back in 2002 there was a thread discussing why OSPF uses IP instead of > UDP like RIP does. > > I can't find any convincing answer in this thread or anywhere else. Has > anybody since answered this question? > > These best answer I see in the thread is that using IP is more efficient > that UDP because of the UDP header. However they claim that it's 8 bytes > more efficient which I think is wrong. The total length and checksum > fields are useful to RIP and would be useful to OSPF, since OSPF > includes similar fields in it's header. So only the 4 bytes for the > source and destination port would be wasted if OSPF used UDP. > > I am only looking for an answer for academic reasons, I'm not claiming > the OSPF should use UDP. But I would like to know why. Is it simply to > save 4 bytes in the packet size? Or was the decision just arbitrary? > > -- > Ryan Boder > http://bitwiser.org From owner-ospf@PEACH.EASE.LSOFT.COM Mon Mar 14 05:50:52 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12957 for ; Mon, 14 Mar 2005 05:50:52 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00FD6745@cherry.ease.lsoft.com>; Mon, 14 Mar 2005 5:50:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61481422 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 14 Mar 2005 05:50:51 -0500 Received: from 207.217.121.249 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 14 Mar 2005 05:50:51 -0500 Received: from h-68-164-90-248.snvacaid.dynamic.covad.net ([68.164.90.248] helo=earthlink.net) by pop-a065d05.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1DAn9u-0003aU-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 14 Mar 2005 02:50:51 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <1110740388.8202.49.camel@localhost.localdomain> <001d01c52873$c1373ce0$0601a8c0@pc6> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <42356DD8.2A08863A@earthlink.net> Date: Mon, 14 Mar 2005 02:56:24 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Why IP To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Ryan, Let me try a acedemic answer., also read the Moy book. Are you asking why OSPF doesn't use UDP/IP vs just IP? Actually, the bigger question is why does OSPF have all the the retransmission stuff built into itelf vs using TCPs retransmission / flow mechanisms, like say BGP? I think the simple answer is that the UDP/TCP connection overhead was deemed unnecessary. This allows each packet to be IP routed independently vs possibly aggregating different OSPF packet types into one segment transmission. In theory with TCP we need to continually send segments to determine if our congestion has changed. With UDP it doesn't care, but still requires the connection to be established and maintained. With OSPF we just use the hello protocol to determine liveliness, and force the use of implicit or explicit acks to prevent resends. Thus, in theory if you infrequently send a few pkts to your constant neighbors straight IP should be lower overhead, IMO; in a less chaiotic environment. If you send bulk data transfers, then in theory the connection setup and possible teardowns in between could be amortized lower per segment/packet, and the packets could have somewhat of a guarantee of delivery. Now, I am wearing a wet suit so flames shouldn't bother me.. :-) Mitchell Erblich --------------------- Tom Petch wrote: > > I suggest you look at 'OSPF: Anatomy of an Internet Routing Protocol' by John T > Moy, Addison-Wesley (1998) pp50-51 > > Tom Petch > > ----- Original Message ----- > From: "Ryan Boder" > To: > Sent: Sunday, March 13, 2005 7:59 PM > > > Back in 2002 there was a thread discussing why OSPF uses IP instead of > > UDP like RIP does. > > > > I can't find any convincing answer in this thread or anywhere else. Has > > anybody since answered this question? > > > > These best answer I see in the thread is that using IP is more efficient > > that UDP because of the UDP header. However they claim that it's 8 bytes > > more efficient which I think is wrong. The total length and checksum > > fields are useful to RIP and would be useful to OSPF, since OSPF > > includes similar fields in it's header. So only the 4 bytes for the > > source and destination port would be wasted if OSPF used UDP. > > > > I am only looking for an answer for academic reasons, I'm not claiming > > the OSPF should use UDP. But I would like to know why. Is it simply to > > save 4 bytes in the packet size? Or was the decision just arbitrary? > > > > -- > > Ryan Boder > > http://bitwiser.org From owner-ospf@PEACH.EASE.LSOFT.COM Mon Mar 14 09:42:45 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07125 for ; Mon, 14 Mar 2005 09:42:43 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00FD6CFC@cherry.ease.lsoft.com>; Mon, 14 Mar 2005 9:42:39 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61531642 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 14 Mar 2005 09:42:36 -0500 Received: from 47.129.242.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 14 Mar 2005 09:42:35 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j2EEgYF07208 for ; Mon, 14 Mar 2005 09:42:34 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Mar 2005 09:42:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C528A4.0B62AC69" Message-ID: Date: Mon, 14 Mar 2005 09:42:30 -0500 Reply-To: Mailing List Sender: Mailing List From: Andrew Smith Subject: Re: Multiple ABR summarization To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C528A4.0B62AC69 Content-Type: text/plain Thanks very much for the clarification. I thought this was the case but it always helps to be sure. Regards, Andy Smith -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Roch Guerin Sent: Friday, March 11, 2005 2:51 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Multiple ABR summarization Andy, As far as I know, this rule only applies to external LSAs. See section 12.4.4.1 of RFC 2328, which states: The following rule is thereby established: if two routers, both reachable from one another, originate functionally equivalent AS-external-LSAs (i.e., same destination, cost and non-zero forwarding address), then the LSA originated by the router having the highest OSPF Router ID is used. The router having the lower OSPF Router ID can then flush its LSA. There is no similar definition for "functionally equivalent" summary LSAs, and even if the two ABRs advertised the same summary route with the same cost, this still represents different connectivity options, e.g., one may be much closer that the other for some routers in the area. This is unlike the example of section 12.4.4.1 where routing is unaffected whether one or two ASBRs advertise the (functionally equivalent) external LSA. Hope this helps. Roch Group, If two ABRs for a regular sub-tending area are summarizing the same intra-area routes into the backbone area, do both ABRs send the same LSA-3 advertisement or does one ABR defer the announcement to the other ABR? I believe for NSSA areas one of the ABRs will not send the LSA-3 summarization (might be only for external routes) into the backbone area. I was wondering if this behavior also occurred on regular areas. Regards, Andy Smith ------_=_NextPart_001_01C528A4.0B62AC69 Content-Type: text/html Message
Thanks very much for the clarification. I thought this was the case but it always helps to be sure.
 
Regards,
Andy Smith
-----Original Message-----
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Roch Guerin
Sent: Friday, March 11, 2005 2:51 PM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: Multiple ABR summarization

Andy,

As far as I know, this rule only applies to external LSAs. See section 12.4.4.1 of RFC 2328, which states:
                    The following rule is
                    thereby established: if two routers, both reachable
                    from one another, originate functionally equivalent
                    AS-external-LSAs (i.e., same destination, cost and
                    non-zero forwarding address), then the LSA
                    originated by the router having the highest OSPF
                    Router ID is used.  The router having the lower OSPF
                    Router ID can then flush its LSA.
There is no similar definition for "functionally equivalent" summary LSAs, and even if the two ABRs advertised the same summary route with the same cost, this still represents different connectivity options, e.g., one may be much closer that the other for some routers in the area.  This is unlike the example of section 12.4.4.1 where routing is unaffected whether one or two ASBRs advertise the (functionally equivalent) external LSA.

Hope this helps.

Roch

Group,
If two ABRs for a regular sub-tending area are summarizing the same intra-area routes into the backbone area, do both ABRs send the same LSA-3 advertisement or does one ABR defer the announcement to the other ABR?

I believe for NSSA areas one of the ABRs will not send the LSA-3 summarization (might be only for external routes) into the backbone area. I was wondering if this behavior also occurred on regular areas.

Regards,
Andy Smith


------_=_NextPart_001_01C528A4.0B62AC69-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 15 19:46:01 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09483 for ; Tue, 15 Mar 2005 19:46:01 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00FDA230@cherry.ease.lsoft.com>; Tue, 15 Mar 2005 19:45:59 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61735617 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 15 Mar 2005 19:45:57 -0500 Received: from 192.25.42.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Mar 2005 19:35:57 -0500 Received: from msgrel1.sgp.agilent.com (msgrel1.sgp.agilent.com [141.183.101.233]) by msgbas1x.net.asiapac.agilent.com (Postfix) with ESMTP id CC6A21A70 for ; Wed, 16 Mar 2005 08:35:54 +0800 (SGP) Received: from wsgpvs01.sgp.agilent.com (wsgpvs01.sgp.agilent.com [141.183.6.23]) by msgrel1.sgp.agilent.com (Postfix) with ESMTP id A286C33 for ; Wed, 16 Mar 2005 08:35:54 +0800 (SGP) Received: from wsgpbh22.sgp.agilent.com ([141.183.6.21]) by wsgpvs01.sgp.agilent.com with InterScan Messaging Security Suite; Wed, 16 Mar 2005 08:35:53 +0800 Received: from wausmb21.aus.agilent.com ([146.223.75.13]) by wsgpbh22.sgp.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Mar 2005 08:35:53 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Thread-Topic: Number of Routes and network stability Thread-Index: AcTY4n1/iuuQV4QxTu+o0bqvWumfGhQ2+obg X-OriginalArrivalTime: 16 Mar 2005 00:35:53.0445 (UTC) FILETIME=[1C41A150:01C529C0] Message-ID: <8C55AC6A1E6B594087667EC1F592C9FF738D69@wausmb21.aus.agilent.com> Date: Wed, 16 Mar 2005 11:35:51 +1100 Reply-To: Mailing List Sender: Mailing List From: Brett White Subject: Re: Number of Routes and network stability To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Mitchell, You say that a router shouldn't have an issue with 3000 links to other = routers in an area. What I am interested in is how you see the = breakdown of this figure on a per interface basis? Do you expect that = the device should be able to support these 3000 links on a single = interface or spread across say 128 ports? Regards, =20 Brett White -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of = Erblichs Sent: Friday, 3 December 2004 13:49 To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Number of Routes and network stability Andrew Smith, I don't think I agree with 90% of this. Available memory has to do with the max size of the LSDB, siumultaneous rexmit queues, etc, THAN the max number of routers supported in a area. Assuming that enough memory is available, link-stability and dead-router interval are more important than CPU capability wrt network stability. Next comes with the number & sizing of input queues, link-speed, and network topology. If the number of hellos and OSPF control pkts overload a CPU, then I hate to see the SPF timeframes, or what would happen if a large number of pkts are targeted to the router. If one says that they can't handle close to 3000 simultaneous links with other routers in a area, then IMO, they have a few issues with their code. I am NOT stating that 3000 simultaneous full adjs can be formed. But if you are dropping adjs because their are too many routers in the area and you thus are dropping (or delaing the processing of) hellos, then their is something wrong with the code or hardware. Support for a large number of routers within a area more has to do with IMO, the ability to decrease the hello interval and hello multiplier and still not drop adjs. Secondly, each router then COULD support fewer links and a failed router would have less of a topology effect. Mitchell Erblich ----------------- > Andrew Smith wrote: > > The recommendation for number of routers per area is usually derived=20 > by considering the amount of processor power and memory available to=20 > the routers in an area. Usually you consider the lowest common=20 > denominator. This means the smallest router (the router with the=20 > fewest resources) limits the size of the area. > > A good rule of thumb is no more than 100 routers per area. If you try=20 > to keep an initial design to 50-70 routers that usually allows room to = > grow and recover from a network crisis. > > The vendors that say they can do 3000 routers per area are giving a=20 > scalability number for that box. This particular router can achieve=20 > 3000 routers per area "under the proper circumstances". This is good=20 > to know for how much the box can take, not how high to scale your OSPF = > areas. > > Regards, > Andy Smith > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of=20 > Jing Shen > Sent: Thursday, December 02, 2004 4:46 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Number of Routes and network stability > > Hi, > > Some vendors recommended that number of routers within one OSPF area=20 > should not exceed 50, some others recommended number of routes within = > one area should not exceed 3000. > > To my understanding, OSPF stability is directly related to link=20 > stability, radius of an OSPF area and OSPF implementation( router=20 > hardware, methodology of link status processing). But, is there any=20 > research done on this topic? or how are those recommendation derived ? > > thanks > > Jing Shen > > _________________________________________________________ > Do You Yahoo!? > = =D7=A2=B2=E1=CA=C0=BD=E7=D2=BB=C1=F7=C6=B7=D6=CA=B5=C4=D1=C5=BB=A2=C3=E2=B7= =D1=B5=E7=D3=CA > http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/ From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 15 23:39:52 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27222 for ; Tue, 15 Mar 2005 23:39:52 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00FDAB2D@cherry.ease.lsoft.com>; Tue, 15 Mar 2005 23:39:53 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61753606 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 15 Mar 2005 23:39:51 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 15 Mar 2005 23:39:51 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBQJy-000NJ9-R1 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Mar 2005 04:39:50 +0000 X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <513898773.20050315203948@psg.com> Date: Tue, 15 Mar 2005 20:39:48 -0800 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Folks- Here's the write-up of the comment I brought at the meeting in Minneapolis. What the draft says is (briefly): a) ignore unknown link-types (Section 2) b) now that we ignore unknowns, introduction of new link types is possible (Section 4) c) when introducing new link types, make sure routing loops are not created (Section 4) Noting that processing of the 4 current link types is part of the protocol's core functionality, that every OSPF router must be able to perform, we have the following scenarios where SPF meets an unknown link type: 1) LSA creation malfunction at the originating router, before the LSA checksum is calculated. 2) Memory corruption at the calculating router before LSA's checksum is rechecked. 3) The originating router implements an extension of OSPF that introduces a new link-type that is not part of the basic OSPF functionality. In cases 1 and 2, silently ignoring the unknown link type is ill-advised, since it is extremely likely that routers will end up with inconsistent routing tables and loop traffic for a long time. At the very least, the router should "shout" very loudly. Whether the implementation should then (after shouting) ignore the unknown link and continue SPF calculation, stop the SPF calculation there, cancel SPF and retain old routes, or do anything else is not a clear choice and will depend on what the admin likes more--loops or blackholes. One could probably imagine different sorts of creative things (that I would personally not entertain) here. In case 3, something has obviously gone wrong. Changes affecting basic IP routing table calculation in OSPF were always introduced with a new Options bit. Introducing new link types that would affect routing table calculation without a new Option bit would be ill-advised again, since this would lead to long-term routing loops. Since such situation should not be legitimate, silently ignoring unknown link types here is also not a good idea. Given the above, I suggest that the related part of the spec is left intact and new link types are introduced with corresponding new Option bits. Comments are welcome. -- Alex http://www.psg.com/~zinin From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 16 00:11:53 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28994 for ; Wed, 16 Mar 2005 00:11:52 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00FDACC9@cherry.ease.lsoft.com>; Wed, 16 Mar 2005 0:11:54 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61756657 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Mar 2005 00:11:52 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Mar 2005 00:11:52 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Thread-Index: AcUp4jMmHYLkMVxlTLmshLwU3uic6QAA7kXA Message-ID: Date: Tue, 15 Mar 2005 21:11:52 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Alex, Thanks for the detailed mail. I have a few minor points: - > 1) LSA creation malfunction at the originating router, before=20 > the LSA checksum is calculated. If we ignore the Link in this case I am not sure how we can have inconsistent routing tables. > 2) Memory corruption at the calculating router before LSA's=20 > checksum is rechecked. I agree in this case there is no way and loops will occur till the checksum check interval. Action taken in this would be independent of protocol. > 3) The originating router implements an extension of OSPF that introduces > a new link-type that is not part of the basic OSPF functionality. In this case too as long as we are sure no routing loops are occurring it will not cause any problems. Adding a bit which allows SPF changes in certain cases can cause loops in case an old router does not understand them. Do let me know if I am missing the point? Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Alex Zinin Sent: Wednesday, March 16, 2005 10:10 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Folks- Here's the write-up of the comment I brought at the meeting in Minneapolis. What the draft says is (briefly): a) ignore unknown link-types (Section 2) b) now that we ignore unknowns, introduction of new link types is possible (Section 4) c) when introducing new link types, make sure routing loops are not created (Section 4) Noting that processing of the 4 current link types is part of the protocol's core functionality, that every OSPF router must be able to perform, we have the following scenarios where SPF meets an unknown link type: 1) LSA creation malfunction at the originating router, before the LSA checksum is calculated. 2) Memory corruption at the calculating router before LSA's checksum is rechecked. 3) The originating router implements an extension of OSPF that introduces a new link-type that is not part of the basic OSPF functionality. =20 In cases 1 and 2, silently ignoring the unknown link type is ill-advised, since it is extremely likely that routers will end up with inconsistent routing tables and loop traffic for a long time. At the very least, the router should "shout" very loudly. Whether the implementation should then (after shouting) ignore the unknown link and continue SPF calculation, stop the SPF calculation there, cancel SPF and retain old routes, or do anything else is not a clear choice and will depend on what the admin likes more--loops or blackholes. One could probably imagine different sorts of creative things (that I would personally not entertain) here. In case 3, something has obviously gone wrong. Changes affecting basic IP routing table calculation in OSPF were always introduced with a new Options bit. Introducing new link types that would affect routing table calculation without a new Option bit would be ill-advised again, since this would lead to long-term routing loops. Since such situation should not be legitimate, silently ignoring unknown link types here is also not a good idea. =20 Given the above, I suggest that the related part of the spec is left intact and new link types are introduced with corresponding new Option bits. Comments are welcome. =20 --=20 Alex http://www.psg.com/~zinin From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 16 01:36:31 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04050 for ; Wed, 16 Mar 2005 01:36:30 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00FDAECF@cherry.ease.lsoft.com>; Wed, 16 Mar 2005 1:36:29 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61761873 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Mar 2005 01:36:27 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Mar 2005 01:36:27 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBS8p-000DYg-7i; Wed, 16 Mar 2005 06:36:27 +0000 X-Priority: 3 (Normal) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <415115157.20050315223622@psg.com> Date: Tue, 15 Mar 2005 22:36:22 -0800 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Comments: To: Vishwas Manral To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Vishwas, > Thanks for the detailed mail. I have a few minor points: - >> 1) LSA creation malfunction at the originating router, before >> the LSA checksum is calculated. > If we ignore the Link in this case I am not sure how we can have > inconsistent routing tables. Good point. If everyone ignores consistently, including the misbehaving (originating) router, no loops will form in this case. >> 2) Memory corruption at the calculating router before LSA's >> checksum is rechecked. > I agree in this case there is no way and loops will occur till the > checksum check interval. Action taken in this would be independent of > protocol. I missed another case from the same category: x) Data corruption not caught by the checksum. (Not completely improbable given the properties of Fletcher.) >> 3) The originating router implements an extension of OSPF that introduces a >> new link-type that is not part of the basic OSPF functionality. > In this case too as long as we are sure no routing loops are occurring > it will not cause any problems. How would you propose we do that? > Adding a bit which allows SPF changes in > certain cases can cause loops in case an old router does not understand > them. The Options bits in OSPF Hellos and DDs will allow the routers implementing the new link types to reject adjacencies with routers that are incapable of processing them (and hence not setting the bit). Alex From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 16 01:46:15 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05652 for ; Wed, 16 Mar 2005 01:46:14 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00FDAFB9@cherry.ease.lsoft.com>; Wed, 16 Mar 2005 1:46:14 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61762155 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Mar 2005 01:46:12 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Mar 2005 01:46:11 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Thread-Index: AcUp8n3AoYGfvHp7RUmF1rkL5XVqVgAAZWyA Message-ID: Date: Tue, 15 Mar 2005 22:46:12 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Alex, >> In this case too as long as we are sure no routing loops are=20 >> occurring it will not cause any problems. > How would you propose we do that? The way to impose it is that we do not allow any standard link type extensions which can cause routing changes and hence loops. I think adding the option bit as you suggest will help for sure. However the point is do we want to extend OSPF that way (we already have opaque LSA's). If there is demand to add information which can cause routing changes, we could go in for the heavier extension as you suggest. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Alex Zinin Sent: Wednesday, March 16, 2005 12:06 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Vishwas, > Thanks for the detailed mail. I have a few minor points: - >> 1) LSA creation malfunction at the originating router, before=20 >> the LSA checksum is calculated. > If we ignore the Link in this case I am not sure how we can have > inconsistent routing tables. Good point. If everyone ignores consistently, including the misbehaving (originating) router, no loops will form in this case. >> 2) Memory corruption at the calculating router before LSA's=20 >> checksum is rechecked. > I agree in this case there is no way and loops will occur till the > checksum check interval. Action taken in this would be independent of > protocol. I missed another case from the same category: x) Data corruption not caught by the checksum. (Not completely improbable given the properties of Fletcher.) >> 3) The originating router implements an extension of OSPF that introduces a >> new link-type that is not part of the basic OSPF functionality. > In this case too as long as we are sure no routing loops are occurring > it will not cause any problems. How would you propose we do that? > Adding a bit which allows SPF changes in > certain cases can cause loops in case an old router does not understand > them. The Options bits in OSPF Hellos and DDs will allow the routers implementing the new link types to reject adjacencies with routers that are incapable of processing them (and hence not setting the bit). Alex From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 16 01:57:21 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06823 for ; Wed, 16 Mar 2005 01:57:21 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00FDAF6A@cherry.ease.lsoft.com>; Wed, 16 Mar 2005 1:57:21 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61762485 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Mar 2005 01:57:19 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Mar 2005 01:57:18 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBST1-000GM5-2P; Wed, 16 Mar 2005 06:57:19 +0000 X-Priority: 3 (Normal) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <528973954.20050315225714@psg.com> Date: Tue, 15 Mar 2005 22:57:14 -0800 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Comments: To: Vishwas Manral To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Vishwas, >>> In this case too as long as we are sure no routing loops are >>> occurring it will not cause any problems. >> How would you propose we do that? > The way to impose it is that we do not allow any standard link type > extensions which can cause routing changes and hence loops. Seems it's time to put the cards on the table :) What kind of information do you think we would put in link records? We need to keep in mind that we only have one router LSA per router and its size needs to be well-controlled. I personally would be reluctant to put there anything that isn't related to the basic topology abstraction. > I think adding the option bit as you suggest will help for sure. However > the point is do we want to extend OSPF that way (we already have opaque > LSA's). If there is demand to add information which can cause routing > changes, we could go in for the heavier extension as you suggest. This is what was done for stub and NSSA areas. I would use the same method for other extensions that affect route calculations. If they don't, then the question is whether this info belongs in the router-LSA at all. Alex From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 16 02:02:25 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09629 for ; Wed, 16 Mar 2005 02:02:25 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00FDB118@cherry.ease.lsoft.com>; Wed, 16 Mar 2005 2:02:24 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61763172 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Mar 2005 02:02:22 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Mar 2005 02:02:20 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Thread-Index: AcUp9Wdv5Gm3UNF3SG2cmVVgctrYMgAAZURw Message-ID: Date: Tue, 15 Mar 2005 23:02:20 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Alex, > Seems it's time to put the cards on the table :) What kind of=20 > information do you think we would put in link records? I think we can have something equivalent to what ISIS has (TLV for experimental use).=20 http://www.ietf.org/internet-drafts/draft-ietf-isis-experimental-tlv-04. txt . We could also use it for sending messages for informational purposes. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Alex Zinin Sent: Wednesday, March 16, 2005 12:27 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Vishwas, >>> In this case too as long as we are sure no routing loops are >>> occurring it will not cause any problems. >> How would you propose we do that? > The way to impose it is that we do not allow any standard link type > extensions which can cause routing changes and hence loops. Seems it's time to put the cards on the table :) What kind of information do you think we would put in link records? We need to keep in mind that we only have one router LSA per router and its size needs to be well-controlled. I personally would be reluctant to put there anything that isn't related to the basic topology abstraction. > I think adding the option bit as you suggest will help for sure. However > the point is do we want to extend OSPF that way (we already have opaque > LSA's). If there is demand to add information which can cause routing > changes, we could go in for the heavier extension as you suggest. This is what was done for stub and NSSA areas. I would use the same method for other extensions that affect route calculations. If they don't, then the question is whether this info belongs in the router-LSA at all. Alex From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 16 02:14:09 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21044 for ; Wed, 16 Mar 2005 02:14:09 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00FDAF8A@cherry.ease.lsoft.com>; Wed, 16 Mar 2005 2:14:09 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61763585 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Mar 2005 02:14:07 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Mar 2005 02:14:07 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBSjH-000Ikw-M0; Wed, 16 Mar 2005 07:14:07 +0000 X-Priority: 3 (Normal) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <1415170500.20050315231403@psg.com> Date: Tue, 15 Mar 2005 23:14:03 -0800 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Comments: To: Vishwas Manral To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Vishwas, Why are those "messages for informational purposes" better fit for router-LSAs than the TE attributes that we send in opaque-LSAs? -- Alex http://www.psg.com/~zinin Tuesday, March 15, 2005, 11:02:20 PM, Vishwas Manral wrote: > Hi Alex, >> Seems it's time to put the cards on the table :) What kind of >> information do you think we would put in link records? > I think we can have something equivalent to what ISIS has (TLV for > experimental use). > http://www.ietf.org/internet-drafts/draft-ietf-isis-experimental-tlv-04. > txt . We could also use it for sending messages for informational > purposes. > Thanks, > Vishwas From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 16 02:22:55 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02335 for ; Wed, 16 Mar 2005 02:22:55 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00FDAFAF@cherry.ease.lsoft.com>; Wed, 16 Mar 2005 2:22:55 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61763892 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Mar 2005 02:22:53 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Mar 2005 02:22:52 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Thread-Index: AcUp98Biiw9CnaZFSkKUVMRI15keGAAAjx7A Message-ID: Date: Tue, 15 Mar 2005 23:22:53 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Alex, Wouldn't something like http://www.ietf.org/internet-drafts/draft-ietf-isis-admin-tags-03.txt fit better in the Router-LSA? Besides let us not forget, leaving things as is can cause routing loops. So the main aim of the draft is to specify the behavior in case of unknown link. Extensions and further enhancements should be done taking care of the backward compatibility is all we are saying. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Alex Zinin Sent: Wednesday, March 16, 2005 12:44 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Vishwas, Why are those "messages for informational purposes" better fit for router-LSAs than the TE attributes that we send in opaque-LSAs? --=20 Alex http://www.psg.com/~zinin Tuesday, March 15, 2005, 11:02:20 PM, Vishwas Manral wrote: > Hi Alex, >> Seems it's time to put the cards on the table :) What kind of=20 >> information do you think we would put in link records? > I think we can have something equivalent to what ISIS has (TLV for > experimental use).=20 > http://www.ietf.org/internet-drafts/draft-ietf-isis-experimental-tlv-04. > txt . We could also use it for sending messages for informational > purposes. > Thanks, > Vishwas From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 16 04:23:54 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23329 for ; Wed, 16 Mar 2005 04:23:53 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00FDB201@cherry.ease.lsoft.com>; Wed, 16 Mar 2005 4:23:53 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61768772 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Mar 2005 04:23:51 -0500 Received: from 207.217.121.183 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Mar 2005 04:23:51 -0500 Received: from h-68-164-90-248.snvacaid.dynamic.covad.net ([68.164.90.248] helo=earthlink.net) by pop-a065c05.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1DBUko-0002qG-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Mar 2005 01:23:51 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <8C55AC6A1E6B594087667EC1F592C9FF738D69@wausmb21.aus.agilent.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <4237F8B3.B96F05E9@earthlink.net> Date: Wed, 16 Mar 2005 01:13:23 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Number of Routes and network stability To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit Brett & group, 3000 is a fairly conservative figure. If we first start with say just 3000 hellos per 10 secs, then we are at say 300 * y hello pkts per sec. "y" is based that the hello pkt could be multiple MTU (1500 bytes) in size and are the number of necessary hello frag and non-fragmented pkts. If we are dealing with 10Gb interfaces that are Eth with 1500 bytes/pkt, then we can traverse approx 83k seg/pkts each sec. Forgeting about Inter Pkt Gap and such, as we are dealing with approximates. So, 600 or 900 pkts per sec within a 83k pkt timeframe is noise. If we drop to say a 1Gb, then we are about 8.3K pkts/sec and the 900 starts to become significant, because we still need to add updates. Yes, I am assuming that we aren't dealing with DNA LSAs and that they will need refreshing. If you can't process just 10% of your wirespeed traffic with the standard slow-path for control pkts, then .... So, I am assuming at least this rate, and with a large number of interfaces the actual % rate decreases with an increasing aggreaated link bandwidth. So, If we spread this load accross 128 interfaces, it becomes noise again. Approx the same amount of protocol parsing work exists independently of the number of interfaces. However, the issue then becomes how we proccess the pkts when we have a fair number of interfaces. Do we poll and hopefully process a decent number of pkts per interface or are we interrupt driven where we can do a minimal amount of work at interrupt level? Bottom line is that as we are able to deal with a larger number of simultaneious nbrs/peers, part of the overhead, of adj is dealing with the hello's, and that instead of just theorectly increasing nbrs, we can realisticly decrease the hello interval to 1 per sec or in some draft RFCs consider supporting subsec hello intervals. So, did this make sense and answer you question?? Mitchell Erblich --------------------- Brett White wrote: > > Hi Mitchell, > > You say that a router shouldn't have an issue with 3000 links to other routers in an area. What I am interested in is how you see the breakdown of this figure on a per interface basis? Do you expect that the device should be able to support these 3000 links on a single interface or spread across say 128 ports? > > Regards, > > Brett White > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Erblichs > Sent: Friday, 3 December 2004 13:49 > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Number of Routes and network stability > > Andrew Smith, > > I don't think I agree with 90% of this. > > Available memory has to do with the max size of > the LSDB, siumultaneous rexmit queues, etc, THAN > the max number of routers supported in a area. > > Assuming that enough memory is available, link-stability > and dead-router interval are more important than CPU > capability wrt network stability. Next comes with the > number & sizing of input queues, link-speed, and network > topology. > > If the number of hellos and OSPF control pkts > overload a CPU, then I hate to see the SPF timeframes, > or what would happen if a large number of pkts > are targeted to the router. > > If one says that they can't handle close to 3000 > simultaneous links with other routers in a area, > then IMO, they have a few issues with their code. > > I am NOT stating that 3000 simultaneous full adjs can > be formed. But if you are dropping adjs because their > are too many routers in the area and you thus are > dropping (or delaing the processing of) hellos, then > their is something wrong with the code or hardware. > > Support for a large number of routers within a area > more has to do with IMO, the ability to decrease the > hello interval and hello multiplier and still not drop > adjs. Secondly, each router then COULD support fewer > links and a failed router would have less of a topology > effect. > > Mitchell Erblich > ----------------- > > > Andrew Smith wrote: > > > > The recommendation for number of routers per area is usually derived > > by considering the amount of processor power and memory available to > > the routers in an area. Usually you consider the lowest common > > denominator. This means the smallest router (the router with the > > fewest resources) limits the size of the area. > > > > A good rule of thumb is no more than 100 routers per area. If you try > > to keep an initial design to 50-70 routers that usually allows room to > > grow and recover from a network crisis. > > > > The vendors that say they can do 3000 routers per area are giving a > > scalability number for that box. This particular router can achieve > > 3000 routers per area "under the proper circumstances". This is good > > to know for how much the box can take, not how high to scale your OSPF > > areas. > > > > Regards, > > Andy Smith > > > > -----Original Message----- > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > > Jing Shen > > Sent: Thursday, December 02, 2004 4:46 AM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Number of Routes and network stability > > > > Hi, > > > > Some vendors recommended that number of routers within one OSPF area > > should not exceed 50, some others recommended number of routes within > > one area should not exceed 3000. > > > > To my understanding, OSPF stability is directly related to link > > stability, radius of an OSPF area and OSPF implementation( router > > hardware, methodology of link status processing). But, is there any > > research done on this topic? or how are those recommendation derived ? > > > > thanks > > > > Jing Shen > > > > _________________________________________________________ > > Do You Yahoo!? > > ×¢²áÊÀ½çÒ»Á÷Æ·ÖʵÄÑÅ»¢Ãâ·ÑµçÓÊ > > http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/ From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 16 05:02:15 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27949 for ; Wed, 16 Mar 2005 05:02:15 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00FDB191@cherry.ease.lsoft.com>; Wed, 16 Mar 2005 5:02:16 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61769770 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Mar 2005 05:02:14 -0500 Received: from 207.217.121.254 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Mar 2005 05:02:13 -0500 Received: from h-68-164-90-248.snvacaid.dynamic.covad.net ([68.164.90.248] helo=earthlink.net) by pop-a065d23.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1DBVLx-0002MK-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Mar 2005 02:02:13 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <513898773.20050315203948@psg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <423800FC.721140C2@earthlink.net> Date: Wed, 16 Mar 2005 01:48:44 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, sorry about the backstep, But what is an unknown link-type? Doesn't it need a FORMAL definition/declaration and scope before it is dealt with? A) It is anything that is not one of the well-known types defined in the OSPF RFC. B) It is a value that is unknown to the nbr/peer assuming that the peer might have support for values beyond A. C) It is a value unknown to the current DR. This last one is due to the fact that the DR should always have the greatest amount of functionality. D) It is a value that should be unknown to the routers in the area. Assume that the unknown is a wireless and the area only supports wired links. E) It is a local value "private" to the area and should not be communcated outside of the area. Assume that the area is wireless and is using a private space for this link-type. Thus, for compatibility, why doesn't the OSPF working group LOOK at the support for BGPs attribute definitions of Well-known, optional transitive, and optional non-transitive? Mitchell Erblich --------------------- Alex Zinin wrote: > > Folks- > > Here's the write-up of the comment I brought at the meeting in Minneapolis. > > What the draft says is (briefly): > a) ignore unknown link-types (Section 2) > b) now that we ignore unknowns, introduction of new link types is possible (Section 4) > c) when introducing new link types, make sure routing loops are not created (Section 4) > > Noting that processing of the 4 current link types is part of the protocol's > core functionality, that every OSPF router must be able to perform, we have the > following scenarios where SPF meets an unknown link type: > > 1) LSA creation malfunction at the originating router, before the LSA > checksum is calculated. > 2) Memory corruption at the calculating router before LSA's checksum > is rechecked. > 3) The originating router implements an extension of OSPF that introduces > a new link-type that is not part of the basic OSPF functionality. > > In cases 1 and 2, silently ignoring the unknown link type is ill-advised, since > it is extremely likely that routers will end up with inconsistent routing > tables and loop traffic for a long time. At the very least, the router should > "shout" very loudly. Whether the implementation should then (after shouting) > ignore the unknown link and continue SPF calculation, stop the SPF calculation > there, cancel SPF and retain old routes, or do anything else is not a clear > choice and will depend on what the admin likes more--loops or blackholes. One > could probably imagine different sorts of creative things (that I would > personally not entertain) here. > > In case 3, something has obviously gone wrong. Changes affecting basic IP > routing table calculation in OSPF were always introduced with a new Options > bit. Introducing new link types that would affect routing table calculation > without a new Option bit would be ill-advised again, since this would lead to > long-term routing loops. Since such situation should not be legitimate, > silently ignoring unknown link types here is also not a good idea. > > Given the above, I suggest that the related part of the spec is left intact and > new link types are introduced with corresponding new Option bits. > > Comments are welcome. > > -- > Alex > http://www.psg.com/~zinin From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 16 08:57:21 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21596 for ; Wed, 16 Mar 2005 08:57:20 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00FDB716@cherry.ease.lsoft.com>; Wed, 16 Mar 2005 8:57:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61822170 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Mar 2005 08:57:18 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Mar 2005 08:57:18 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 16 Mar 2005 09:14:52 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,167,1107752400"; d="scan'208"; a="40700609:sNHT21455524" Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2GDvG1j017209 for ; Wed, 16 Mar 2005 08:57:17 -0500 (EST) Received: from [10.82.216.20] (rtp-vpn3-20.cisco.com [10.82.216.20]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BGC65865; Wed, 16 Mar 2005 05:57:15 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <42383B3B.3080707@cisco.com> Date: Wed, 16 Mar 2005 08:57:15 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Vishwas Manral wrote: >Alex, > >Wouldn't something like >http://www.ietf.org/internet-drafts/draft-ietf-isis-admin-tags-03.txt >fit better in the Router-LSA? > > Vishwas, Irrespective of how we decide to document the handling of unknown link types, I don't like the idea of defining new link types and stuffing non-link information in them. If it looks, smells, feels, and tastes like a hack it probably is one. For OSPFv3, some of us are trying to move the WG in the direction of TLVs. I made a presentation on this at the last IETF. Thanks, Acee >Besides let us not forget, leaving things as is can cause routing loops. >So the main aim of the draft is to specify the behavior in case of >unknown link. Extensions and further enhancements should be done taking >care of the backward compatibility is all we are saying. > >Thanks, >Vishwas >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Alex >Zinin >Sent: Wednesday, March 16, 2005 12:44 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 > >Vishwas, > > Why are those "messages for informational purposes" better fit for >router-LSAs > than the TE attributes that we send in opaque-LSAs? > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 16 14:47:33 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29544 for ; Wed, 16 Mar 2005 14:47:32 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00FDC070@cherry.ease.lsoft.com>; Wed, 16 Mar 2005 14:47:29 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61853205 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Mar 2005 14:47:26 -0500 Received: from 132.151.6.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 16 Mar 2005 14:37:26 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DBeKa-00047e-9v; Wed, 16 Mar 2005 14:37:24 -0500 X-test-idtracker: no Message-ID: Date: Wed, 16 Mar 2005 14:37:24 -0500 Reply-To: Mailing List Sender: Mailing List From: The IESG Subject: Protocol Action: 'Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance' to BCP Comments: To: IETF-Announce Comments: cc: Internet Architecture Board , RFC Editor , ospf chair , ospf chair To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list The IESG has approved the following document: - 'Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance ' as a BCP This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are Bill Fenner and Alex Zinin. Technical Summary This document recommends methods that are intended to improve the scalability and stability of large networks using OSPF (Open Shortest Path First) protocol. The methods include processing OSPF Hellos and LSA (Link State Advertisement) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. Working Group Summary The document has been extensively reviewed by the WG and modified to accomodate provided comments. There was a WG consensus on this document. Protocol Quality The specification has been reviewed for the IESG by Bill Fenner and Alex Zinin. From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 17 01:26:27 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18500 for ; Thu, 17 Mar 2005 01:26:26 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00FDD080@cherry.ease.lsoft.com>; Thu, 17 Mar 2005 1:26:25 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61892542 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 17 Mar 2005 01:26:22 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 17 Mar 2005 01:26:22 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBoSc-00070L-Tz; Thu, 17 Mar 2005 06:26:23 +0000 X-Priority: 3 (Normal) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <393579909.20050316222621@psg.com> Date: Wed, 16 Mar 2005 22:26:21 -0800 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Comments: To: Vishwas Manral To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Vishwas, > Wouldn't something like > http://www.ietf.org/internet-drafts/draft-ietf-isis-admin-tags-03.txt > fit better in the Router-LSA? Putting it in router-LSAs wouldn't be my design choice. > Besides let us not forget, leaving things as is can cause routing loops. With what we do today, only in a single case among the set we mentioned before--when all routers have consistently wrong information. > So the main aim of the draft is to specify the behavior in case of > unknown link. Extensions and further enhancements should be done taking > care of the backward compatibility is all we are saying. With what we do today, your proposal only solves one particular failure scenario among many. Other failure cases are still there. Usefulness of your proposal otherwise is conditional on introduction of new link types that would carry non-topological information, which is a questionable practice. There is one more consideration, a very pragmatic one--simply publishing an RFC that says "MUST ignore" is not going to solve the problem. We will still have to think about the installed base that don't follow it. So on the one hand we don't really solve the problem (at the very least we'll have routers screaming about unknown links), and on the other hand we put existing implementations of the protocol in a position of non-compliance. With all this in mind, I don't see how this would do us any good. Alex From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 17 02:13:52 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05003 for ; Thu, 17 Mar 2005 02:13:51 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00FDD321@cherry.ease.lsoft.com>; Thu, 17 Mar 2005 2:13:51 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61895016 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 17 Mar 2005 02:13:49 -0500 Received: from 67.100.73.243 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 17 Mar 2005 02:13:49 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Thread-Index: AcUqMBNyxtviawq0TBqxVEoQYRoU3wAj76wg Message-ID: Date: Wed, 16 Mar 2005 23:13:49 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Acee, I agree we need to be very particular about defining any new link types, I was just giving Alex examples of what can go in(based on what is there in the sister Link State(IS-IS) protocol. Alex, >> Wouldn't something like >> http://www.ietf.org/internet-drafts/draft-ietf-isis-admin-tags-03.txt >> fit better in the Router-LSA? >Putting it in router-LSAs wouldn't be my design choice. It is made a part of the Reachability-TLV in IS-IS, which in my view is similar to the Router LSA. > With all this in mind, I don't see how this would do us any good. If someone wants to write an implementation of OSPF, what does he/she do regarding unknown link types? We need to define the behavior else we will never get interoperability. I guess we both agree with the above. If I understood the discussion in the mailing list right, most implementations ignore the link and that is what we are trying to standardize. The suggestion you make will not interoperate with the installed base at all while a MUST ignore solution will with most of them. Besides it seems to me (from Acee's mail) that we may not be looking for a heavier solution. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Wednesday, March 16, 2005 7:27 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Vishwas Manral wrote: >Alex, > >Wouldn't something like >http://www.ietf.org/internet-drafts/draft-ietf-isis-admin-tags-03.txt >fit better in the Router-LSA? > =20 > Vishwas, Irrespective of how we decide to document the handling of unknown link=20 types, I don't like the idea of defining new link types and stuffing non-link=20 information in them. If it looks, smells, feels, and tastes like a hack it probably is one. For OSPFv3, some of us are trying to move the WG in the direction of=20 TLVs. I made a presentation on this at the last IETF. Thanks, Acee >Besides let us not forget, leaving things as is can cause routing loops. >So the main aim of the draft is to specify the behavior in case of >unknown link. Extensions and further enhancements should be done taking >care of the backward compatibility is all we are saying. > >Thanks, >Vishwas >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Alex >Zinin >Sent: Wednesday, March 16, 2005 12:44 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 > >Vishwas, > > Why are those "messages for informational purposes" better fit for >router-LSAs > than the TE attributes that we send in opaque-LSAs? > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 17 12:49:08 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29244 for ; Thu, 17 Mar 2005 12:49:07 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00FDE18A@cherry.ease.lsoft.com>; Thu, 17 Mar 2005 12:49:09 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61972232 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 17 Mar 2005 12:49:07 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 17 Mar 2005 12:49:07 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DBz7K-000GQY-Ei; Thu, 17 Mar 2005 17:49:06 +0000 X-Priority: 3 (Normal) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <111973429.20050317094906@psg.com> Date: Thu, 17 Mar 2005 09:49:06 -0800 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Comments: To: Vishwas Manral To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Vishwas, I'll try one more time. > If someone wants to write an implementation of OSPF, what does he/she do > regarding unknown link types? We discussed this earlier in this thread. > We need to define the behavior else we > will never get interoperability. I guess we both agree with the above. We do NOT have an interoperability issue unless we start deliberately introducing new link types without making sure everyone understands them. > If I understood the discussion in the mailing list right, most > implementations ignore the link and that is what we are trying to > standardize. A few years ago we had a discussion that touched on link records. John mentioned that there are still implementations out there that will ignore the whole LSA when the see an unknown link type. I don't think we can ignore this. > The suggestion you make will not interoperate with the > installed base at all while a MUST ignore solution will with most of > them. I don't understand what you mean by "will not interoperate". Alex From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 17 13:40:07 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05241 for ; Thu, 17 Mar 2005 13:40:05 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00FDE068@cherry.ease.lsoft.com>; Thu, 17 Mar 2005 13:40:07 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61978671 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 17 Mar 2005 13:40:05 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 17 Mar 2005 13:40:03 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 17 Mar 2005 13:40:04 -0500 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2HIe0jI027899; Thu, 17 Mar 2005 13:40:01 -0500 (EST) Received: from [10.82.216.20] (rtp-vpn3-20.cisco.com [10.82.216.20]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BGD88845; Thu, 17 Mar 2005 10:39:59 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------010602020009050006050805" Message-ID: <4239CEFF.70500@cisco.com> Date: Thu, 17 Mar 2005 13:39:59 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: IETF WG Meeting Minutes Comments: To: Joe Macker To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. --------------010602020009050006050805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks to Ryan Elliot for taking minutes at the last meeting. Please send any corrections or updates directly to me at acee@cisco.com. Thanks, Acee --------------010602020009050006050805 Content-Type: text/plain; name="minutes.txt" Content-Disposition: inline; filename="minutes.txt" Content-Transfer-Encoding: 7bit IETF OSPF WG Notes - March 8th Taken by Ryan Elliot (relliott@cisco.com) 1. Administrivia - Blue sheets, etc. 2. Document status Published: - DC inactive Neighbor Detection RFC Editor Queue: - Using LSA options Bit - Graceful Restart Implementation Reoprt - ReFresh and flooding reduction IESG Review: - OSPF v2 MIB * All issues have been addressed. Needs MIB doctor review. - Prioritized Treatment of OSPF packets * In another revision with comments - Authentication for V3 * Comments for security AD * Authors need to have a look - Multiarea Adjacencies * Awaiting a date on tele-chat. Close to WG Last Call: - OSPFv2 Multitopology Routing Draft - Extensions for advertising optional capabilities * Question: on inclusion of flags. Or do we remove flags? * Question: Do all users advertise capabilities? How does a neighbor trigger someone to look into the flags? 1. Should we include the definition of capability flags 2. Should the informational flags be included at all 3. Can we advertise the capabilities at different levels. * Acee understands issues, they are known issues, and need to be worked over until everyone is happy - OSPFv3 TE Extensions * Not many changes in the last 2 years * Acee has taken over draft Need better/more review: - OSPFv3 Update - OSPFv3 Support for AF's - OSPFv3 Graceful Restart * Might not be so urgent Expired documents - Advertising Local Addresses in TE extensions * This is being referenced by other docs, we need to keep it updated * Methods used in this doc are being used, what can we do here? * Answer: Check w/ the author (already reminded author) to refresh draft * Send an e-mail to list on draft, maybe we can add an author to keep it refreshed. - MIB for OSPFv3 * We are working on v2 first, will get back to it. 3. Handling of unknown Link Types - Acee Lindem for Vishwas Manral Brian Field - Comcast - Handling of unknown link types is not handled in v2 or v3 * there are no deterministic ways of handling * There is the Manral draft, which has behavior defined * 3 things we can do here 1. Ignore 2. Ignore and log an unexpected 3. Reject LSA * Consensure is to ignore unknown types, but want to be conservative what we are going to Add. * Quesion: Do we need to document? (Acee) * Answer: (Alex Zinnin) - Does anyone see a problem? Ignoring will lead to inconsistent routing table, . The only realistic measure is to raise all possible flags. We find unknown because 1. Bug is causing 2. New type of link introduced, but what if we have a network w/ routers which know and don't know link type. Need some type of capabilites negotiation if htere are multiple inconsistent routers. Doesn't think ignore (Option #1) will work. #3 (Reject LSA), not sure there is enough detail to understand consequences. Does it fall in line w/ algorithms? Are we going to stop SPF? We need to drop traffic, so it's not looped, so we don't consume bandwidth. * Acee: there is a section of backwards compatibilities in the draft. there are some holes; If we ignore, what do we do? Could be a 4th option to do nothing since we've gone this long without formally defining. 3. OSPFv3 Multiple Interface on Link - Michael Barnes * 2740 draft - Section that was missing on "Multiple Interfaces to a Link" (Michael Barnes) - Section 3.9 enhancement * Too ambiguous - Original spec didn't answer all questions * Specifices that router should support having multiple interface on same physical link. OSPF v3 carries int ID in hello's, we should use that to recognize received hello packets that were sent out on another int on the router. v3 supports multiple instance ID's, need to ensure that if instances are different thta there is no interference. If instances are the same, then we have multiple interfaces on same link. Each instance would have own adjacencies, link LSA's, etc... One interface would be active, continue to send/recieve packets, other interfaces will monitor hello packets from other int, but won't send packets. Designate "Active" and "Standby" interfaces. * All interfaces must be in the router LSA to be considered in the SPF * Need to generate link LSA for standby interfaces - Need to be flooded over the active interface. Prefixes for standby must be included in LSA's. * If active goes down, there are multiple mechanisms 1. Monitor hello packets on standby - 2. If active is admin brought down, elect standby to become active * During SPF - When examining network LSA, must examine to include all links as next hops. Maybe create a list of links, process * Keeping track of secondary standbys - New state for state machine. A standby state for the interface defined as; 1. Interfaces detects that it's multiple - Triggers link event, puts into standby mode 2. If another interface causes standby - Then standby will transition back to waiting, then trigger interface up event. * Comments - Acee - If we follow 2740, there are steps that are taken care of, and remain backward compatible. - Michael - No change to doc, just clarification, and mechanism to detect multiple interfaces, and the state. 4. OSPF Manet Design Team Status - Tom Henderson - Manet design team - What kind of extension are possible to add to OSPF protocol to enhace performance in MANET environ. - Background * Manet WG standardized experimental RFC's * Can we borrow principles and apply to OSPF? * Maybe define extentions to OSPF for performance * Needs written up in problem statement authored by Fred Baker * OLSR like adaptations were discussed * Charter this design team, meeting informally and on mailing list - Review Ground Rules * Focus on OSPFv3, not v2 * Compat w/ non-wireless v3 * Intra-Area extensions, not on transit network case * Output shouldn't preclude though * Scaling goal is 50-100 nodes * Leverage existing MANET work * Use RFC 3668 guidance for IPR - Consensus * Define a new MANET interface type instead of an Area type. * Not match on current interface types, but there were some that are close, maybe a hybrid approach to what we have * Design optimized flooding mechanism - Simulation proved that LSA dissemination gave too much overhead, which centered the focus here. * Additional optimizations as a lesser priority * Focus on 2 active I-D's - Both drafts focus on selecting more efficient Relay Node Sets (RNS) * Strive to form "Connected Dominating Set" (CDS) * If only a subset of nodes could reflood LSA's, there would be minimal tranmissions - Difference between drafts * 2 constructs - Source Independent vs. Source Dependent - If a node is a CDS, does it forward all LSA's, or a consideration of who send it to you? * Hello's vs. LSA's for 2-hop neighbor info * Ogier draft addresses minimizing # of adjacencies - Review of draft-chandra * Slide 6 on presentation * How is flooding efficient, would all routers downstream need to reflood? no * Protocol dtermines which one-hop neighor would notify the two-hop neighbors * A router will have the two-hop neighbor info to determine * Main difference between this and OLSR is that this flooding process is ack'ed, so it's reliable * Exchange of info is ensured to be successful * Creates a non-active relay, and if no ack it turns active - Preview of draft-ogier * Each router will ensure that their 2-hop neighbor update is taken care of * One difference - If we have a set of "relay nodes" * An algorithm would be run to select relay nodes - regardless of where the info is received from, the flooding will be done. * Terminology is "designated" vs. "backup-designated" router - Design team is evaluating both proposals - * Developed implementatin of Chandra's draft in quagga * Working on implenting Ogier's draft * Next meeting targeting results and decision. * Questions the team is trying to answer - Stability of relay node set selection - Overhead - Robustness of routing - Stratch factor on data and overhead - Runtime complexity * Initial results - Most overhead is due to LSA flooding - Make flooding efficient - Minimize # of LSA'a generated - Chandra's *DOES* reduce overhead by focusing on efficiency - Next steps * Goal to select flooding algorithm by next IETF * Implement Ogier's draft simulation - Focus on optimized flooding - Questions * Question (Rohit): Is it a goal to have a single recommendation between the 2 drafts? - Answer (Henderson): Not explicit goal, but probobly implicit. Trying to drive to 1 recommendation. 4. Manet Extensions using CDS Flooding (Ogier's draft presentation) - Richard Ogier - Richard could not make it, Tom is presenting - How can we find the subset of nodes that will be relays? - Core idea - Generalize router concept in Broadcast environment - Connected dominating set might be a group of nodes, rather than the single one in a broadcast environ. - It has the concept of a backup designated router in the wireless case, we can have "backup" nodes which has adjacencies formed, adding robustness and redundancy. - Algorithm in draft includes concept of CDS - Uses 2 hop neighbor info to elect CDS nodes. - Verify w/router priority and router ID, self-elected as DR, else, a neighbor has a higher priority. - If all neighors cannot be covered by neighboring router, then it will not elect itself and the neighbor will be a dependent neighbor. Backup DR is similar. - 2 variants - 1. Persistent version 2. Non-persistent version - Algorithm O(d2) - - There is a family of CDS algorithms, depending on needs of robustness, if relay set size grows, then tranmission w/ grow. Trading overhead to gain robustness. - Router priority - How do we determine: Capacity, willingness, stability * These can be adjusted in these algorithms * Advertized to neighbors - Adjacencies * Only formed between designated, backup, and Dependent Neighbors. - Comments/Questions: * (Macker) Addition to tradeoffs, how do we test? Can we have fast repair? Dependency on how election occurs, and # of adjencies. What about how can we repair faster, look more into mobility scenarios, and more info nodal failure. * (Henderson) Agree * (???) Clarification on algorithm - Is it distributed, answer, yes. Since differnet nodes will have differnet neighbors, won't different subset's elect different DR's, backup DR's? * (Henderson) Role in adj forming, if a node selects itself as a DR, then announce it it's neighbors, and all dependent routers. * (???) What is router doesn't elect itself as a DR? * (Henderson) take offline to answer * (Macker) Additional dependencies on the algorithm, on the election process. Look into failures - More decisions and re-negotiations. * (Henderson) Agree will be interesting to look at. - Simulation in Mobile Networks * Persistent version of Essention CDS algorithm. * Average # of designated and backup DR's * Number of adjacencies * Details in slides - Conclusion of Simulation * Richard believes CDS is more scalable * Believes DR/BDR generalized naturally and efficiently w/MANETS 5. OSPFv3 Protocol Extension - Acee - History of extension chronology * Added base v2 protocol * Added MOSPF, Type 6 * NSSA Type 7 * Opaque LSA * v3 * Graceful restart * v2 TE * v2 MTR - Options #1 - Continue adding new LSA tyupes for v3, new opaque for v2 #2 - go 100% TLV based approach, like ISIS #3 - Evolve TLV based on LSA types. - Advantages of Option #1 * Potentially smaller LSA's * Advertisements contain only changes * Maintains status quo - Advantages of Option #3 * No sync issues between LSA's. Fewer lookups, less searching * Flexible extensions whi mainaining LSA granularity * Fewer LSA's to manage * Unified approach for protocol extension * Other IGP's won't be able to say were inflexible :) - Vision - Single IP IGP for Enterprise, ISP, and wireless - Questions if #3 selected * What happens to v2 in the near futue, do we revisit that? * How do we control protocol bloat? - Comments/Questions: * (Alex Zinin) Do we redifine existing standards of LSA's, or preserving that, and moving on to new LSAs? * (Acee) Keep LSA's around, then after an area is moved to a new extension, then revisit, at some point the flooding domain can only use the new LSAs. * (Russ White) Looks like we can make v3 better than v2. * (Alex Zinin) Questions/discussion come onto the list. --------------010602020009050006050805-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 17 16:38:02 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23418 for ; Thu, 17 Mar 2005 16:38:02 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00FDE63F@cherry.ease.lsoft.com>; Thu, 17 Mar 2005 16:38:02 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61992195 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 17 Mar 2005 16:37:59 -0500 Received: from 64.233.170.202 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 17 Mar 2005 16:37:59 -0500 Received: by rproxy.gmail.com with SMTP id a41so151094rng for ; Thu, 17 Mar 2005 13:38:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=XvmP2iAA9Py/ydlRssn2/wyzKXqvsdeg5HzLh6jYl9eSDD6ENHaBpBHZ9r8qHm9RcqSgR+B4lEPzwG4WT80HQSlZRh77m/lDXNi1XG1PVXFnRQPPEEq1xkP2QG6vVsJoXXJCuWA3BNOY3scAS3SY1F77Kxif0w8Bl1uE2vQDfug= Received: by 10.38.22.69 with SMTP id 69mr223838rnv; Thu, 17 Mar 2005 13:38:00 -0800 (PST) Received: by 10.38.151.40 with HTTP; Thu, 17 Mar 2005 13:38:00 -0800 (PST) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <423069E0.70808@cisco.com> Message-ID: Date: Thu, 17 Mar 2005 16:38:00 -0500 Reply-To: Mailing List Sender: Mailing List From: Ramanan N Subject: Re: draft-ietf-ospf-multi-area-adj-03.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <423069E0.70808@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Acee > >2) One more question before configuring a secondary on a router the router > >should be an ABR or after configuring should it become ABR? > > > > > It is assumed that the two routers are ABRs. However, the secondary > adjacency is completely > decoupled from the primary adjacency. Hence, there is nothing in the > draft that precludes two > non-ABRs from forming a secondary adjacency. > Does this mean that for the topology, R5 is a ABR in area A0 & A1. R1, R2, R3, R4 are in area A1. R1------------R2------------R3------------R4-----------area1--R5--area0 now, if R2 & R3 form a multi area link between them with A0 as the secondary area, then do R2 and R3 really become ABR routers although they are intra area routers of area A1 ? Regards Ramanan From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 17 16:54:15 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24537 for ; Thu, 17 Mar 2005 16:54:15 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00FDE6D3@cherry.ease.lsoft.com>; Thu, 17 Mar 2005 16:54:16 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 61993094 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 17 Mar 2005 16:54:14 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 17 Mar 2005 16:54:14 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 17 Mar 2005 16:54:16 -0500 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2HLsCjI024315 for ; Thu, 17 Mar 2005 16:54:13 -0500 (EST) Received: from [10.82.216.20] (rtp-vpn3-20.cisco.com [10.82.216.20]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BGE10690; Thu, 17 Mar 2005 13:54:10 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <423069E0.70808@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4239FC82.8070706@cisco.com> Date: Thu, 17 Mar 2005 16:54:10 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-multi-area-adj-03.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Ramanan N wrote: >Hi Acee > > > >>>2) One more question before configuring a secondary on a router the router >>>should be an ABR or after configuring should it become ABR? >>> >>> >>> >>> >>It is assumed that the two routers are ABRs. However, the secondary >>adjacency is completely >>decoupled from the primary adjacency. Hence, there is nothing in the >>draft that precludes two >>non-ABRs from forming a secondary adjacency. >> >> >> > >Does this mean that for the topology, >R5 is a ABR in area A0 & A1. R1, R2, R3, R4 are in area A1. > >R1------------R2------------R3------------R4-----------area1--R5--area0 > >now, if R2 & R3 form a multi area link between them with A0 as the >secondary area, >then do R2 and R3 really become ABR routers although they are intra area routers >of area A1 ? > > Hi Ramanan, This draft does not change the fact that neighbors must be attached to the same link (i.e., this is not like a virtual link). Hence, in the topology above, R5 could not be a nieghbor or R2 and R3. However, if you meant R1-R5 to be on the same LAN then R2 and R3 would not become ABRs just because they have secondary adjacencies. Thanks, Acee >Regards >Ramanan > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 18 00:27:19 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02893 for ; Fri, 18 Mar 2005 00:27:19 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00FDF19E@cherry.ease.lsoft.com>; Fri, 18 Mar 2005 0:27:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 62021994 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 18 Mar 2005 00:27:18 -0500 Received: from 64.233.170.204 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 18 Mar 2005 00:27:18 -0500 Received: by rproxy.gmail.com with SMTP id b11so28532rne for ; Thu, 17 Mar 2005 21:27:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=G3t9SRCd7AGJvj9yHHDXGPSiyGJBnuiOSLONXrYXQCWY9LmBgYciAwfoeJQZh3HBcHbdHUym7JTHkNIUDbF03WN6VnUgMEg3PBSR/vQtgoG+X6+cjyXBH9Ieds9phbrpTsBXTJLwBUppuAjQZgcZxRBEUG2k7bJVqKLZid3Fznw= Received: by 10.38.162.43 with SMTP id k43mr2138034rne; Thu, 17 Mar 2005 21:27:18 -0800 (PST) Received: by 10.38.151.40 with HTTP; Thu, 17 Mar 2005 21:27:18 -0800 (PST) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <423069E0.70808@cisco.com> <4239FC82.8070706@cisco.com> Message-ID: Date: Fri, 18 Mar 2005 00:27:18 -0500 Reply-To: Mailing List Sender: Mailing List From: Ramanan N Subject: Re: draft-ietf-ospf-multi-area-adj-03.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4239FC82.8070706@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit On Thu, 17 Mar 2005 16:54:10 -0500, Acee Lindem wrote: > Ramanan N wrote: > > >Hi Acee > > > > > > > >>>2) One more question before configuring a secondary on a router the router > >>>should be an ABR or after configuring should it become ABR? > >>> > >>> > >>> > >>> > >>It is assumed that the two routers are ABRs. However, the secondary > >>adjacency is completely > >>decoupled from the primary adjacency. Hence, there is nothing in the > >>draft that precludes two > >>non-ABRs from forming a secondary adjacency. > >> > >> > >> > > > >Does this mean that for the topology, > >R5 is a ABR in area A0 & A1. R1, R2, R3, R4 are in area A1. > > > >R1------------R2------------R3------------R4-----------area1--R5--area0 > > > >now, if R2 & R3 form a multi area link between them with A0 as the > >secondary area, > >then do R2 and R3 really become ABR routers although they are intra area routers > >of area A1 ? > > > > > Hi Ramanan, > This draft does not change the fact that neighbors must be attached to > the same > link (i.e., this is not like a virtual link). Hence, in the topology > above, R5 could not > be a nieghbor or R2 and R3. However, if you meant R1-R5 to be on the > same LAN > then R2 and R3 would not become ABRs just because they have secondary > adjacencies. > Thanks, > Acee > > >Regards > >Ramanan Hi Acee, I have two questions here, 1. If the routers were in LAN then on what criteria should the routers R2 & R3 be prevented from not becoming ABR, because after the multi area configuration, both R2 and R3 would have a. two interfaces (one being the physical and other being the secondary topological link) in different areas and fully adajacent neighbors too. b. backbone connectivity in the secondary topological link 2. In case the routers were to be in P2P connection in the above topology, then can routers R2 and R3 become ABRs ? Regards Ramanan From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 18 00:55:47 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04744 for ; Fri, 18 Mar 2005 00:55:46 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00FDF1BF@cherry.ease.lsoft.com>; Fri, 18 Mar 2005 0:55:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 62023375 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 18 Mar 2005 00:55:46 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 18 Mar 2005 00:55:46 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Thread-Index: AcUrgIaMr2jc/5eFQKe3AO/PQY38mA== Message-ID: Date: Thu, 17 Mar 2005 21:55:46 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Alex, > I'll try one more time. I am sorry to have troubled you. > We do NOT have an interoperability issue unless we start=20 > deliberately introducing new link types without making sure=20 > everyone understands them. So what anyone needs to do to get the entire OSPF domain go haywire is to be able to inject an LSA with an unknown link type. We could argue that a lot more can be done by injecting wrong information, However in my view it does not mean we leave something undefined for someone to exploit (we could have similar arguments about a lot of other cases). I am ok to drop the draft as is. Maybe if and when we face problems we will try to find a solution. However it would be great if you can state a clear yes to the following (or specify an alternative text). It is not helpful to define how the receiving side should behave in case it receives an undefined field even if it causes loops in the system, because such things would not generally occur. Also Alex as in my last mail, I am still eager to know why the design decision is wrong to put http://www.ietf.org/internet-drafts/draft-ietf-isis-admin-tags-03.txt in the Reachability TLV and why we can have the same in OSPF Router LSA?=20 Thanks, Vishwas =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Vishwas, I'll try one more time. > If someone wants to write an implementation of OSPF, what does he/she do > regarding unknown link types? We discussed this earlier in this thread. > We need to define the behavior else we > will never get interoperability. I guess we both agree with the above. We do NOT have an interoperability issue unless we start deliberately introducing new link types without making sure everyone understands them. > If I understood the discussion in the mailing list right, most > implementations ignore the link and that is what we are trying to > standardize. A few years ago we had a discussion that touched on link records. John mentioned that there are still implementations out there that will ignore the whole LSA when the see an unknown link type. I don't think we can ignore this. > The suggestion you make will not interoperate with the > installed base at all while a MUST ignore solution will with most of > them. I don't understand what you mean by "will not interoperate". Alex From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 18 03:02:05 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05275 for ; Fri, 18 Mar 2005 03:01:48 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00FDF57A@cherry.ease.lsoft.com>; Fri, 18 Mar 2005 3:01:45 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 62029060 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 18 Mar 2005 03:01:41 -0500 Received: from 61.1.177.147 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 18 Mar 2005 03:00:26 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------qgftodyakytpgqchudux" Message-ID: Date: Fri, 18 Mar 2005 13:29:47 +0530 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Hey, ya! =)) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list ----------qgftodyakytpgqchudux Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit You have won!!! pass: 13858 ----------qgftodyakytpgqchudux Content-Type: application/octet-stream; name="TextDocument.zip" Content-Disposition: attachment; filename="TextDocument.zip" Content-Transfer-Encoding: base64 UEsDBAoAAQAAAMBIcjKe385yLIEBACCBAQAMAAAAYWNlanlpaXAuZXhlbgrGNwQTs2j4L+TB 6O5UqF/MCO0rRA7Ec2u1uvDSMOriIKsvOPCdPjCvJPHl5uGtoJtjyZnzx0iE80rjWdCb1YoT Q5V6p9VqalHooJflRCedZHBH97Rh4+a5agLkk5vP7CfTJtiBcPfQgS1fV9mk1Oksf+esB1Rb W3vV0HHdxcRTPHtu0c6yXMn1BAo3UrDTyKEaHoXWT9hrpzjaGj/EpwMTlyQbS+gC6UBsl87m QWxeEhD6DfCv92pzsCHtZbyKmE1Va3UfuqxZVe/qYBp31CjMk9uif0h4uYuxKBq2cjEsD0+a bEM7eX9TqLj7DujIXPGhO7+MMh4HJMPZwsAwr7uqOC1ghMGkIwrwbYNOHnJ/9xA9V/ZB98is 1g1tKd/iCvUy95xq4xOWUAqUWicujIM5KU59ZkAkiIwtZQzRVV/MOwriOvxGuulYlaSrGOgt 6OmwGPyalVL7/pUHgSyWYveS727EU3rPUW29Ji5Mu1mOShfYWVNQ5oXayWfnYcaJVoImsN80 +GIFEyMdLi8faUFkH5Z/DM7HymzRfFdjv90M9Pb635RDbO3fvYTppvBvF/QH9ToW+b4GwzVv 6nEWPgmx4r2qJbzXgs7nwg2hE82jysMdtRfOkwvpySb4rA2EqryMIVjcGQVAvR/6uDspmtXf ZlsUT3NkKDo6TElBLIn9+Km+LDM4xV/pNvYoU+ZP34m5X4dvV0Kkqg+/iB+PZm25Izyq24he TcM4X54ebJgsjoJFUGX8PwwbW1hmJh4QS3luZ/0LVtSOTv7yBTD7ufJQw6VTFEl9urVxIdjX 535xnWKEoszRjQY7dbNyum/VrugcvXi0wD9b5aL2qgz5rufGRkwDzXskZ2j+EDTfj2o+kwGb XPu9Bmk3XRYY+loxOu3MaGCBobR9BHyPquqv1VR2wsphpfjYPG8GI8e0E6JK70FRnrG2A1L+ 8i7VE/XjcFcWCIbBWAEUZZUdqDQzwo2DkMVmDUVLny4VtZpHa1NBe2GPkRhiOBdCZXIc6bWt DgR4J+iq0RFnUgk26FDVihEJzFpw3TeZvDHT3neArtPzmyNxBoURESNVyYLnbvIYS1CBrF+b MgITFygRYGqgHdr7/iBkxsCBxnDS3rbW+OltQQgSjL7hGtimNrMVEtNM0epDPwng9rWZEDDm JE8+R74s31DqaTqNI3rtcNwOoeihb1l1TnmJklYJfKoIq9sHKow7QwWjKd0mweTut5ehggY+ y4Sn56ryzj06bRAm+ZTqJ0etLnrOzqU9CcCv44oxsaY5DvADOb658qbrHf5ipYU43aBbw8dc d0FWn03/6yQfu+D1+9mWPGLMr2dd+KThrr8fThOkPLDELbk0M7T6jIE0XQt7z6cuBtNu/USt VuHI22Kt/JUJn61hNgz6FO9dbVQRqr+3lEHdBqK5F5r4UcEvgmXWaG5EiVaQrtURPWMN7/Bc ZgVOqPmnZatXguimwsB8WSoVoKcx5BwP2d80rzZC2JCja6/vaYzfy38sInsQC8MF85OlDh6z xLR8mcITcLv483pmHi0vs7LMaORO+Jx7oudPdVbtV35pEa8BN6hrdumQSDAcPS1zRmRzXdgL gNmDdBmoXly36SHlBCW4P5F0sMtlT9LsNELLsxlUmjWlaM6+xd85um+ZvPH0ErQnLK7z85GT gXP1zy/FabRm9ZI05szUfs4fstDmpcvfM3Opc0/HAjH2BsPYm0vernzCWpzDwA7qVkbviXt/ tq+u6rhdHpcHOpdbkDg0ftFdI9/Jnp58d7AaqNSCOdKJyw77cBAaunjN6N5Ft+Rxz6QwHWvG Z4If3osw1oofOc4CD8UjI2pdiTYFdjtGsb3qd56rKnfLBWIDMOie+BoAYc5t1MyFnIXjDgbX 0cohRGkN8s8aVUUhhhWERFaIiX7gK4aw1yFWpUCJ7EnC2wa9TBKeiLLa3udjbg497W0hXJ6c nQ1pMcOcIN+eRh8KZMlx8pwyH/OFYklffupa8sUvZj6nhfjnFs1b1YDoQWOT2/8ta4gBTHPG Ri+DDdISn/jkM5k7ZcrEv3DpF5CB1A1ikQMh92HRrMg30zquzQMapd0l7dtmyMtuK2GRP6yk yJunhSCoDMK9Y6tl02tMTlq+SfeBe/X7uo1XdVqJw4ZQEM5HBC+TWQs1N69J9K7OePSTTN4P vS5Uklwc5VTo4Uh97MgO0T669vnnPM8F+xkTxFDbFSfSeHKdxwEmM4elnT9zpLuHG98IdYX7 glJzN3jzesrXybIyxPdohg9FJ50M0tiXoxWT007fg6pDWPcwQ10KrodNIYlSZm1507q1LEXy kJJ+29ColgeeGCV7sTiXzuu8hyGH+ciJscuQqPtHI+P4lmg9cC4pubZGczod0xQ140ngJTMs fhtzTU1C+38EBSDrrZhhSSL7obQAB4pLFVlYnhaERQO1XY6bhdnOPvxZdD9sIxYNdOYFLT7I ROm+2v9zgIQ6G2ICNdzdPDHnK0pEkmHO++EptNOBNGGEccLgUVlZHHUs77yZPnrHoTQIFdNs YCjNdU3d59OTZgRvwuP486x9b46UtnTiIrAjic/5a470mttZr7r11ZCNWoTze+TLzblkePOS dzY9+UXoS00+sxJHhWnGaTIyiyDZH1hw0RkaF1J/cq7s4gtAWWfuUEK7UvPBFUFydcjNbtnm fk1L/IBVWwEuY9du881y7qRo9W6cSeNb36dsZrXpDmvXWEiZSLMF9eMBqU8W7jEeWvOwnLsL x5kI6XCllXO1eIAapNjLtpPMiQeV1rOHsnBmKq0Wo04FsiLhXGTs292T5ecdEZ5d0Z2//7B7 jPjhrU/rqMatcfKqzCfjoROZQ/slvOs4Noyn0aaBEuvzPlZy3L1iBgF7p2dR/Zhu3pfTZWb2 8C99CbS7mtHWHYlufvDQXS23Gm9ppN/ooe9C3ae0ZxzE4G20gXofLdR6xqlRMpk/dIxxVOeP KfpIhomDZyZ4ujvHCrqANB19w8DsdnOApKcQ7T35h8MJMWY9dv2fiGLKZviq3dZTFz0PXDv1 JoxHuYMLXX9Go8L5iHEaSibS5yC7prHd8HZbj7QcwwKHhU3bBl0b9+I4lQxopmjuZNHlmMG9 a/uPwZk5b7TmjYcvyKW0ftMH5sJ8IX5Z2KOrLiYSw6obodCS4f9gmLO/kAp6kXrYvZSymcxU iOJkUsWgNrxH6/DvxZ24pVFgKl9sreZgxQA0NjOJY7+wTVcbF/Wm3beFxdN75dKMugrSn+TN wg10xT9GaPBNX6Ziivu66tdHIS/sBO5Ih3+SHnpRSIaarXCj4C6t+aFzt0pnESeG0XLAwIve i1bIc20aSJwvkVQnPslOv0bLnMj+Y9YA7jMQMefWWz80D38XoyaAi65mtCKnsedPvCBMbosz mEI7A+IZNdmMutukNxZ2x0q1JLf7gBUPeCDXeZoyB4+E75Vdz9p0Wp8Tsuw28+aTb4xLNgEV jiHB0Dz6hVHEmeCh1LVsC2dy7MTZ7sv3ktlWXFqHr7JfDsdjvVKzGulHDcVT/11tBK6hH8Gr UlASe/yZ4S+gkZMGZfix8Z7T0trH828uUhKanx4h4mSwV6EO94PJxi8UAVT0mhRHTeSgUOx4 ghko7D7uiMg07fBGmbembbKscpHEvIvEyHpMQj5RutSlleJs2k3hSjB2mbPur2KTonnVrfdg gVU0jw3M6PnYDVB7bH9182PRe7vMo1L/Sw8kMOY3id+UxIWm0iOjSEM1kb1aflY5yNhoUSjD /vV9DmKJvdGdGL9nMn9bIbxc3OA7/aZl2DAiYi6mFYYjW91mpTsaIMNF5GYXwCJNSjX09Hya WNVsJ9hbVtsvTPwk5B+4nMALhqPo8jvJyrAtnS9OB9oHPhKtvEylxtYucz0ySSP2UBukxM2Q HpopPUvN2Zik7ib2vxiTd8H9bp4sdOi/qH6u4PZcYh7PNBRSeZhvIQ+dfJuDmKIzU+5IB/hF J3+RpLb7rpqDYpeYO0h6ghq5F3bQUusL3zYS0Q0WdcSoHUCU2pCKLtDKZCa/8pm5rSOB0uuj D2cNKTqj8aWlTVG71NujbcYzlWmhbQ82pPRBnPEf+EbmfI60JUBZf13cAs30Ne9JANZbfeYs ZlRGRpyMz7qExcGfds4ax+KGLZU8H0aHtte/kvXi0JhopEMb37vqgcyUjOMJhir2l6w54ifq qpaGEuEWoLRhmTLTDmUrI6M4KBykPySV0eVzx73on8H8CtT8R23yRCqp9guG9rNwmWaU3gSH h4sFycSz07x34o48IX8cwHBKpsejKKdSkhSzLnTbNK7lDfcZC19+gBULLJKDGXX+QtaMknbY g5een+QiZoaO0CV8xpLeC3q0FFKiEE92gDHu6khulfTdspORAHnub/zrLfLJxi+lh/PWBHZF rrVMxyVKmFbOTC1MlGmEYsofqnHCK38E/SXNEENeUwV/wEBBLYWGRILZaRlMLyy88ERQ/BYY jFycT8i8dCZxIgYCjBXgj8z8qtkbQJZpLdQDYi1XtEfV583/uZZcGMtdpf49f7hqIWocVEQ7 HmC9PPNFrS3ms46RikAv+FfBYVWiN4fDqBW/5SFSnRxIRtoHLRTYysP0PAic22WZkrn1UvG6 uw6qyRGM2ESKb7p3G+lJmph0F93UkPOFawxB5WaWo+JSiuNRCij7IHUxIy1RUulF5k1K1qbZ WSgyYg8X6W9OVobJMstyJ6YLuJ7iBTNX16gl+F1+XyHRR0iFVTtw8HrvqpuMgLXcx/ScbkTK 8rabki3Lzaakj53Am3jzna6gfbZHkK5ffLRexj8FyN3ADqSAEHnQE7CVuUd4WL5JTI9rYTFJ dtoDdmGn9gvAvJJwORcx4nLaQQBIaTKhZJsvM4vmtP4RDo7aVMf3aqwt4gQ6PiSpHSVxkHHZ c1dXhLog+zYTSQ6ZAh/IkpNjKoE5IA0LP+E83LPuNOwWKwIKdQyTl6uhu6HiXqDwcQ4jk0pU 1Tg6aaTuuHPodH1ph+pkVsh6Jilbgrtd5WPWGReg1Q+3pY7NCydXtP2JVPW8xz7Xw10G0vGK fSGcEcn4EnrKJLVVKTgVFpj9FC93wlzhSPt4fnt1NK7Gbar2APzCjg41fysNbnJno1HtHHs6 bXT3+8mPnIacHsXMaUguDNMcj1IokXXSQr3Hkkx4TtdO5yTKVCBKYJrL8INMBTRjsZSyc5Yk QGNDMG17/GMFi8BpgdDFGpGb7B4N/u8HBViQjKEBdcJ1Rynhai7zRGpnYeE0LeqPKLVk2tcY Ty09efaH7Jt54Doaa1sKU14b499AIOa/hbEvnEuXSvsfGEuq+JRUFJzz6sVHrBC8KyIqmCuR VFd9RKOT5XXFYGn8jS67eKOT0596TDg/oaQF6Iu4cNR7J3tbfKsE+4CXEXJl7aMEx8MyUzYQ SQGyTzBKLySo+PR5R3OLKPwoxUtKD/7ZdIq5K5DP37JUZeauD73KK72ep95xe7i62Tn93j7B Z0WkQe9FnhWazOFq70Fxa0mPe7wYw09+ZYItVPXQwsOLwbRgw25puIcNV8ktqhwqbp7D7J6N kwcp6DgdVAxtwL+SXdV4IImasduI0qHmilQ7weJapjRMYJASAk4DyOepu72WXA5Jrf4gF6OE xmoC7xv+sjaKgqXodhg2CTR9QjUcMVZiqFzxVMQa/4tRzXS8zPSC6ywtOMy5azIRaiEAT7P2 uNb82AqPiuZdBUM35jIxA+WwOcs83luLn4OGASIP21f6hbzPn94ToRJgdMvoMz7yJ2NvkPV2 bJcFz1Odw/R2Z8yQgp1qDkNqHgXe/hcaJsUoHh4FnuVQCgbLT6fBQetktDP1xNpO24NfZcOC DGFLfxiTUjjWfWiDvvJYP9hp8laXLBMy+6KcK5Lk0ziYwOeOOia+Jp5q6BVCc/iWPbcl4Iv9 AF+5erdy7s3r8H5RqiHK6DOsrnv5ljMfyHanDPfIMzizinHu1dx7UE4VP2km8dWLMyT6bfQg CyIS2ooxnfkibut9kIq3PoLpvbPR8VS99m7FmvY080MHEFnxvwviPeB3f2upvL0Os4Ac/Clq C9Bo8olMFZg+n7UZfLLzJz7BbagNgDyW0Ggmn5OphpG9On7xaNvz/Sd6KBOYaUocUvKU+7me pqjk3pkZh93ajbXQ3A5uQwOxIP2d49i9bTH+w56riZ5XZtAAtTPdZXyzIgNCFFsUgiFDJg+e vdQj4NEqpoJjNc2sWHDMImgs9L+26pI2aKb8ZnfWupSrviD9bOVL8inbsn0ggrX5nepEL3Cp ZCM/2GoAFM8w3LMBmUvmHmMH4gsWPtNeXKmZjRrSK4znMSBPWc6SQznaZTjv8kywvdjTCv63 CJvYI+xrJbwRmHVdEA+PYXKpRv6YCcZHLWGoSGFntJv7MdqZ6jwKAEOFlNpy0Lngashw1BNE 97L6jJFf11IKMti/libU1yaltShy6e65vRGjneJJz5r3KV88uhMPfjaRWo1RluLMvNr2E1BA 4EYrH8teqOho5TQq8fgp/C5yhR6CGzogOpCFnRdu5d2mCNk6SvB1H25mkyFxzFG3bmcBCW4H B29BrXKDTJx7PmmAqpIgXael2td8bGasyy2prQNR7DAHyWLDmBLQZNdtUmqrQHEepeadNpTp hdOwMjuVlOebUdv+yQfzbFHcQgrTuajb6FRX/Jl9PFF+ZlXn2twRHhd8AwUsiPFE4jyKMLWk emmM86NZib4QMJGBymuo7+itm8U1dgwB0AjI5s2rxReQmoJTjj0JLGzYE8fL8ZRhjnOwWau+ /dGJrwQQRpDmQKHN+lhWbyi6BoK+T8y6VlsK7ztzMgOU1YqAT0+BZFE/Oxvr6QO1YyoWC/tv R6O4MIcK3z55sOZhe/HPHzxlUe9/verPXmZGx5e5/fnSsNaVWRtFJVKL2irAxvobhueZsMwY qJuOWJ/TJqe6g9MVpdRguqNJ8mouL9fS0JR+DCOPaQ//OUwi9Yp6urzghe0vsYoJrkWqvHtX RynHUWI7y11ib8LIK8BEAUfkJi6c5MfyVvc99G8jKUVichPRgVHOT0fhi/SdGhVTM744qO2L inKQfOufwHwpV0gqIZlQuQMTU8H+Ieb/AK15/V9VNwbD9DTsYEh1/kQDcPE4M5od9Ju9poD4 49EOHB/dDqB5b80Q6ZNu+YHRpVdkTD5kSEkwXuNhLCOMDgdbbGNEcSzfz18yfQ7awDAIN5j3 32YVo1MgP1gnPeK2/cjx6U6XKuKQc+MIJTujTGwx5Z88r5JPduO5MjNNqVOXasI4P/GkKiIa Jf7ufBxyN8EVikw7NuUb8xeWtGOo/qUdOJIZEMqKoaL2P0Rsua0l9xu83vz9A7/n6/1Hx0KF obBitCP9MDXGEJafs7HbTRApvAu/Mlo7xeEbkbx7vkCQunm5kau/BK9VscnEXX5FH5bD8pf1 bDSediUPY1dYq1txPPG8G4bNSpEknNi7J6A+r3gvQV1jDwO9iyIfZqy6ZCicINX2co5aD5M2 4hBCOOUevYxX/x5Vdrusw3S7DZJKwgeWnWhYZY/Vjzxky8XjvpVbgEHcWMT110VArF6zKZIa Ltjyx5DSgTdW2Hqq3/gJw6OsW98QjKcIni90LSYf6Vz7ULfLAQS3NA4rIexS8f0ZM+9c79j8 173X9ztg/YNrxW7FhVX4bFDWCdUHHmPfVe70N7FBdYvdP0SFZGwU/sMiv7Pz7YuCHtYoVX+e TNOLGreqWHlN9KleLHeZgmWXJoi5nU/01+QsEuu/RJGGaK5bNcNepCVzJXcIyLaW9pdkzoTZ IwF84PHrA5frraqo8VXg02ZB+NUnb7iguB+eelF3Enu2KY7w6lkT8myU6IN1Jorij5HZqpi9 52DtT0SVnCMG32jc902CXWxx1J4CWpcH1TzPBTq5rNYeD0BryYXe0zL4ndD6Xf8GkWUtdBX1 bwN6o32wFZYpEJtbQKLVsneuXdxxvcB/VWWPjemSe2Uq5TZYSmaj1nyMgCYU4pKAGWLc99qf 3ZlZ9/J5nmIWyglGoyGyipTl9CZmwPBAEJASUCoYTME/+4y8XwaX0c+eYpvQ1+FA5kMhjWfV EyiT4PR2/Yp1S1cmMC66yjiQW5W08drzdFAstHCoHzSuCK7Xlv/OH+kM6kMJMEJ55CvPySk6 bGd0DhVwUSlwC1WNHwba4/30IejKhszCZbh3E+3DaLwvW/DokbVzhj9P4m+A7HH2GZS30o20 MXBZIuTGygNRWS7TFntI41rZ6hAA+1T2O8YpKXxo383/BqC3FJzuAmJL09xw8g16ncnVsfJu 3ktYwAxuhiLJfW1gBmqFPQFfEkzbt2pv9EhtnxqamyB2MJ6ILFSI4RgpZZnTzczGPY6mbL5i NzjQ5ZybMeO85lpqGXZflWW6hf6Ez9jv3pDh7J7kc1zZ71OEyMIeP1m21onoEY4XLn73up35 RsAysQsgNywkNY6ukhNziuyyfgB9v2xD2jHTyYabPtTHA2HvguurNPt3vVhw67veyM0/OaUH cYDpQ3D4xuaaR2IAuLgB1i9hKhrX4OTzHLfPMuY5suEXVYQohVLzSM/i62PX4aKK9ckbRLSt zVAf0V67/vV3DY02mvRUAbbqLYGd4beAx/E25L6DkXa+FsQ+uO3Qn87lsVD/qBnIC6MUDVd/ b9bJU9Fs1ExFEkARIjqmanb/U4+ja29I4m+eT5YYY2de1npWs7Ff3ep6mZUVCswcMi0vWCeO AH+S1sB0ky5z6fIMbE0Iej10vEq9s3mbe+Q/947qof6Wa47eLhynwCoHLMBC/WqiL3fERVMs Br2LYN24bPRD1R+vMeKpZRz9MmXTRHaJM5iq3UBFxkeV5JsiAs16OeS7HOnycbC1vhtZNOl/ HiwQdvrGsmTQKD+oM7sX9KGvDlLY7d5lvEjI9Z6y4TmnB8thoa4Siib21YAN7l50iloaBqK+ R308Ix8IdUt6tQ2RI1qQ4hsYX0KeGGSer3N1l/4aHOjmxTKCw/97w3ReTUvxFrLMhtArFbFQ OCFzfIxvHq0x5PkBGBpdXckuesDW1UzDU6/kflbGLAt+NdDEyqeQUmaD8fBvd3X0goHy8KAY fou52ESswbrwsfuOxajrko3psdFraboiWzBYRzqcOS5qWvzv51tE+PokgjCAudc3WEnhomp0 vXeJy/U/ImshCIjvsQV/0CQvPQfhTSBSd+DJaT6S/m3m42xWueSInOSac8/iWI3gEgpd3jtB LAwX2JOqR5uUmNDDp0srZYflkuXy+o14i2AsazN3qAexFM5c0lUxyuiSuK44dYNCaZboTZkE WToLBOwZs504f0cv3ilaG5a4SqLvKICeR2BIXIZeDDgr4uEtBX0Xs409qZMfqGg9iXtHMdjC SsLcIWchI1mgbg6jXTYqjHIJuKfAONLgQKgnCSupj+4bYtk5PTNKk4pipza4j8srQZ1cMWFL pGy8oqjzaO50orKR/MXA32ffhk12+GyF++VtQ0zIQjIPZfs7kletPhysNUkpum6qgA8EuiK9 gkG/02bfaxtMDL4y0fjnnobFGdgOsGSCU2cWTPyXS67rLkOV9H5cmBrjPEgieUWKpVJDzC0l VvuLN/qq1rlZZCzS4K1nGFxwvODc5l6mU3tzAw6poggYTwQHuL8tzyUKR7zmNpUJqA1hdxTl 3E//LYute2CySrAjf0dfOqLsYY9ulq7tMvIepRkMLCC8ZdCxg7PGno+7J9zpDKRRnnzhl6Kc 6gCGUw0r03AJVnHmQk+ugi78Fp+UDjPEPIfSs1SoncsCs8zrAJh2ybhezfmab9fw4BJJwAud C1gB/2nAMtrBXKcICYe6VPt469PDIsp2dy70D4RLYhIQcjeVMDyIpg1zPMJttgbDn8UWpQuV lbMKhL1cLdoDa0rElMa6GbapiBUvfx01cjV8eb3ndWQKkreY52Ad6rQnmqO2Q2xqVlHsadDo 16/Bh+yIX8TvK1Rhc3iWzILeqi4ao8i5l8+5ZhHlHF58LaxbyKZKNYgZQkmkf5axAq7/wpQ6 bSM8PkCTI78+6Aoupbd0OEh3DEHJtXD/7Q+auf0dkE0gvmQlJ9SyYmk36gRZuLh31sjeZmQK Cxy/wPy79/D1TrV83wHPO51cP4b8TUf9pkK1da4uNLoj4r2RwjILTRP+LNM96I12wu8ibSD1 FzzFmiZrU2BAI/ykQ+ukizVm6VGlsByKexanzhvsiIU+j3Th8EXXglGHl7QiTT1p+FoOTYdc 5gA4vK66fs1GtTTRKf27YsPyooKDYdjdI9VQYC8bLWS0Lxu0Vq1FS7PDRPGugHLGkdiHXIa1 lOvqN0Czaittb30S1JBY/EbVges8ZLLTeAfVmlEp37MUWhlSIWk+9GtIzOf+ueUMuGATJQii vtEFosctWQOuYvqIBb6lgy1RdgZHRAKXc7ZYCaGG+Ze22FN1g9fBoMLX0I1iKb5Bgu9c51Uc YJXgeujjdlhmW4NzzUbINGtuXZO1zjLUGQMUZV0KJq+Gk2f5g4Cw8byRJpPlE4YEuJYojvQB EAw8CYvokzVni/tutFgrisAhgl+fDmRuSg4v4ZN79SKEhvkU0DxnnRscv/ZPhQdNSH5qsEXm hbPlbWAiS/F46YKXmK0rNcFhkj11zXEVE7coPEFIdRgWLOAnAiJkNY+CHmDHr/AMTqD+tUjG FIGxaXqIj7em5sVo4TLt7DLw3Fwaem5dapAAFq8qA6DeRNgwl1obKIdkZVh+7Iia+LRlPyuz sRo5mbPM7VdLrRbKCkjm3NUuXQoNVCjGlgsOZkWwkV+74+wRVOHNZlwkWp8uzVHb55m740iY kSHEheGQ6SW2R2RAnvCk0Jb70flpmBTtWBIDHc9BhQVvBdtDCWLi4H9NDjJZuvkXB2yj3n2n 1r9NMMIdJEfKguI9KRK7l1ZC/9J/J5hiWPLv4tTB48a1XlGNCVZyXJOuA2hANxqaOTCFtYJr e+IY7hkbwnA74FyE4mQl3xRkpS9kqls4uuolB5YL6eLll4L2SlseJHUXB/nEiC4AHwXhMZAv HYKodrLg5gd+kOqpSI5u5MTBWi6ZDv7tqHjscDXeg+94/uDXrBVlhNq5XG8djDv/XrHBgxK0 pVOqM1sTyiewHGv0b7wvkg5oKX6bQCLutYN4eU1u83WdcTtyWG4AmJxqenRVNH7rpcqKySBg piEuGPadF5N0U+jdUgFfJ7nabF+xIRgWcgc3gxDpLdOg0UD6uWq9zKR0Cxf1CC/MkWt/idNT kZiZbSk/70xcCogVLptRPL36NbYo8jNdA7da26+aAnn/Sk68Of7K33otC8ErTdhZ0zI5wrVl qVVrGoUFVQMkeqMjf8DUf/p3+xcPvhBa1DLPSTr/SDtVG4oG5jlsieJ1278tkETrS+zETeBh lAFmgeDv6MASs/lNI9BHNa/xp8/YygYF2t5nLsfRNjkcQ3B/QELPIluwnW4rZDbHE+u5PhM/ Vutb3hYh6zzR/j7Pi6r95m6PjY8UxZSKXoLtPCoioF3cm+B2gN5VTvhb2gWTwEqr8Ups/T9x XA5AelUnbbOQonrukI1Hz6rlK+WzS0hXdWTqnnCH6zVMLAF1/Q3d1/11YnmNY3BrYPFdzbsq vWJir6DuslDp6seJXGeF2qFA1/mCfgCKp2s95SPYUdTZuyNlH99oeZjrJctRCcoVHDTgFJJ6 iWESm9WNIkbKV1z7dH2OdJk5YIzQngoB3s3usfyO+hCZYa0oMAkTjrXrXtE0mDpSYpfhxcVJ NWaYWTrJto46CITyEs7SLyNWR0/75yWBezdDcuC6tFQ1p1N0MRtbfD5rrzG6/Ix2NdRg+Dhw 2s9KA+elASOIAwt6SchanMPMh8ZqVV3pnrWvM1uKyiSLJ04reZ1UcK6adNZo9hLP4Too0uPM I8bf+CYXYzyHN0FteYpNnrrZNCQqcHVzV5N3m6aNnSLfq+Jq70BEBx68cfvYQCmOQjst6/L7 +TETmsTOKWG1pY3WiO7zQOqLSGzuJBs1BuwTBtyD5+wUi/FTWixYZaUF7CLfp+x4y3hFa3ZQ FHmrd8yfjRMPOuiZfsjcw2PtwXjTP/l49jBSd6fTVkCGbLtiYXLKBlbeTcbsFS6fjFez9g2Y RkPwp5bXCJtqXAgP6AvL2lTTNaBkrCFtxlOTP6lwVAzJc+247MCTr7qSddUNNzKpMWw5CUgu aiMXE1fFFKP0RCYarGV9SJ5GQWaG8iqlWyxTBRf0JKkBGqqQgdjnxCm+T9/GizQVByvNk4G9 fFLXdFkM17U9+KQqcVG+Y/E0lBOpoy045ZCXFpBa0Ni5igiuBXe85ZtrpfhUVRjcmrfa2uEH piNe+bDFARj5Iav4HigZSzrywjE/ohW7D/sX1JN0DjdeBKC9R0L2m8NE+U2QwLri9Z/Ly3Ua TUxS11ZF8/ye4MkHzhiEa911AF3rHwyclTzoCPD2F0Ep9hSqNoYt4K4SCBHOltqio/kJeCiG yD37wU2mQaLwm7EeVcENFr2mZGZbYKBnaCXslCs0IfPeU7Y/+DfPWLjOFnxByrYnJLezWbYX bGlymEdwIPKfcKOQ2I8ZoLoXaIhQpoyec40xbEC4OwbevS0ixHe2g3jVEy8TuwyBRqTiIrc6 5PYiTntggfCoxF5QzSDuaEu4ksPCZ77z+u1tNJRqzaC5Dg8CIhJ2tSKII16pAqHxcpw5a1z/ R2U3C9SmRT8QnEbsT/FuO9KUFHh3xkka6L9M7RSnUn4eK0uqAJ/Zg3a6Hwh/d9/ZQzO71Ozc peB+Vzx9bojotAbSaqpF9GJHEja+MqXIZC5TzlU0MCtyQIw78Wua6oWf7/O6YUt9Kh3/n3uk 9X/syuM/zHA76vHstDfiyhfrryEVSJvcxQcZoLjix6OMdMRMXMEGuPp4bLqqrinfNhAyr5cw BltBqXbI5+2/gkUI+ngHk26P2eF0GmXYvX+A3W1VenDcM8pGN2uSzMLuD7PVwfqD59F1tSzd 3bteDfUPfhpmTId7kPDE/Hj6xbXjHPopoQ0husHtB8omd6thKpMRxZ/Jxd4GAMP0tF+pQ2Ic ZAyxfCck4xi7qQiTQwL6I6ODSuvSmwgt2+523rwrZ+gH9X5lK1/heNkGMDADqKkyhJa+8piR gLf15aNN19jFTK8/SJtDS1NFvIKGQoLv25C8gUZlXyXsKWzs8yNFAH3GJBOR8qCOiMCo51L+ 5j6UuM/QyyVDNrdstoa76n5IVuXJyE1YWgyF+pZo8TIDlUhS6NKXQB7Qbr/SZ/dEXa1avyVl PQ1UjKYaLr22oHWMhZaoGwbI+/b/tGuYnNqIcUa2Te+xEqzkjU3KR4N2Sll8cPEy1+ADpg7O rERK3VhVaLRYzWnucCDR6SjnzkMGb88foUMW7Zc3DIvhYIhrcGtTCyRC+d7fqmUlN611BrCZ 5ja1grKnUFRmUPHnYfMlVTJshCIbyoFyEWHsTXV+VWVRG01WQ1gDXaKSlxhKsg33/80GunjO RrwXmV/3AVEdPezGzWsa6iqQoFE1/RHei3B3hnmGyG5o6A40hdWfHGDne4lKrAueWxjZYzct 8TyOgLeDwY7U9Tga9mNN1BwyTUMksM4GUhCJDRIN/OgXvpNxp9ugs8ox1lEOAcJ51Ye84VbE tOujjipuE/iE8DVUsrRxWRwSxePQMcQ2SW6r3YzoeWcDLK+FRjGHwWPS1KUgHk6/XIrGNfC9 TtyDUlzvMzFntqS5y7dY916ioxucWxSEFHG+TMNVWzfq9l00L459oB7Yt+md8NAWodFQFKVp wV6qFmd6mvdD8gp0hdjfnJC0c9H1ffeurfFnoAfK1ePBHM8t+yFI9ewam0Fl8RK2I/nMm7+c KCV4uyBcNT4r+r/EoDk3FIDeew29VTFuOzD7N+UUPFhagj57meFymmTSKbiXKXY2BAPjRYmW mVDoIqnOVAMDxBrDQ2/lzoOk+rRlmL+FiEKkBHrhhU+kIWcpXRzd7LQDs3yPphIgMyhF7GtS 1SIeWQTztdG5wZC+PfglUYQqNq1KEXVavSXW1G4vru55ZGeDJr4MSy7IP96WsfdR9d7YM5L3 rBrOSURDAFct5jIF85z359U4snl/DR5iCX08uaGsm0T/tyLws/Z/TKoRp4C7b1mmsw5AsMPd ncEhA89wRJlAnOpzlwowV08iGM3BDe+2hvq++FPiamcO94gYKNLQiFQmosaTQTu0VmQbiD/i lquLbqB2p//ikWI7bXYCcPrcg+8MCXGw0iCFateGAcTo44hyEq+3wcMy/v+IR2fZW57rDiSU J0jWHFJjw4hGCRtrKlG6rKf7RlCcdCsKnyuqAVvWVpXRz5jgnJ7ofGUJCSSjl+RjANRz+vdb QICKenp2aMiILQfyR4cooNXh3OlHdN5zO03W/ZAZxjn7hc7Q5WMClWj8o8tGlkf/bA/1kQr1 RIF0WB/rRSi0Z2WD2viKWjl4Ng2DM5sGaZ0opEqOgJlTIZ9L64t2NtmJTlqG/bgXpr395cZE ARGygaaD4a3RxT9DCg/kahThehT86iHv5RvyytDMKiukTlTpEdGok3gL3T2ai1vy5w0IqFKL DW58Hdclv6010HfozUneU3L6pakN61CMSNNbacg0UsVqoKXdkNYug27iCFQutp8IyFZHwMQj MA8w9Gjb6xXgXyrkY2RWFZi2XRQ3ubxZETBwQW6LTnrtbWc4NeRQHlqWEapc6XHK//xx/5u4 ZTF94fNIsFjmQLEh0hPplT5NYXJho44TEz4gmmBYiyk+duSIV8hJ6fIxp3QGsbuMoUymjw+p CWb+7Qa6JNDcVllXkbIUzIF8ULpU/tIG8mpJb0UZEyAhOTr5ZVnc7xV/qd9wMzvXCeG+7uF2 mlye0y13YRgGoJNf42iLKXgCsKVLS9I5yF7Jo5gv7LfTvK2SIzY7vbOgPyzWPSYOnFXT5S4U 907r8l7JbbJzXTDLALssIqX1GkBl2xYzWdTnPq3nwyX7DXeRZq9K+efudL9AVIM5ykTD3Wlx utQIzaRdYzUmRIulszq0NlgHnXUBCgpgIgmFvN0IKF3q5/UpSzUq9/23goMVTBZOchPm4tPm Dg+7KgjTAqp1x9C3Hy2msGMU8heOtRUhVPpDSquG3vo9Gail/w+7FQ6qaeJmWZyzk3z8dIek L1IjbojJ8XBHnWwHJ3Xv0eYfmGoNXK0LqNggbXHpjx8Bdh+fmJWd21RY8iRF8XMA57IyQEjw NPwOlW+IcQKSJ3HtZaKYjP+kzOG1ZCNHlUSIcnUyHoET4WuopF2i9gaYdCzCqQrioiUT2NbH Nl/Tw4JQsyWC1+InS6opcq9RMrpjFzX5pNr/W6jOoJD0vHeE143kR5rFQ7EYGmH+3CaId+H8 ofXV0bSw7GggDzhgsa2csavZUtv99vAKqZfMyMXR04YJmmSQA4DitJfqFHzxXOOUwvmLzTtb pClaQqZ6PvhlDMp+B778mSmyUhgbVWK4UbVGkAmWc5LFs9BFedwiSxKogFUtIJeIaxdZD0I0 olx+761lTZQeYqNdmlRa0U4ggtdz8SVgyboAzyioTVy1u0cnDRieCYgFRCx5WYpcEXw0BZjS nitjtc0Jtqlo75a1FUPJuR+hr0bYQDkshDELsDwCT2/jsBKcIXYsd9R/leZPaS9fThZBnCr6 ZTZdbpA/hkyuWhuEF7p4Usz09cHk40CB/MwpzdhCWTI8iouQiWkB3sY/nxKSS80BDAsW5Rd9 kECH3WdOfnaqN9h/5uB2/cJMi8Aa8/btO0fIU0Eg/8UMSAl0CAXuGb8/MBj6eLIzIz6SLm27 ru+31mmTttClDunMNCQXJsr0b5hiweQKzT3RNRqNv1pSs9TJCWO3gHMHCp/ymkJmdmJt/yTi winYBfc/tlNLBu9HoXGpmvVKVBGLk9nNrU+NiO8j2gQQLZssI363MMaEjWVRNt0pmAzqGS5z 3x9I5aBVdMajDCC6LbJMkhhhWtr8k/eJxzOgraSp4uLY+WS0EJBuD81108Yx6v06Xrc9QIMF lFBlCXLdOX5tXT7Ms5ZcYuoGlymC3RT7GBaULTt2IkZupaiGlI+O8ThDzWRTDSR0fDA0js3R hXDe+rbqUz4rIhMcZ8PQwVf/Eiudqc1YYz/IusVrRu5Pfu/ud0qTVGp/ERjsvUnb4jLbb5Qe /LOmuSGf7VuAPIFlG/S0olTDW90V9CIhssBw4dt5OEak30zWqVMfqCfGKFhcj6zIcLp2HJ52 MHFsJykeS9zOBkSCNhZz4WhQj9u8YEzuxb9/LTYJQAhWqgXuDONNALHKLQWbcy96tyHU0Q53 okuujN956za9QCgXFIwJ+4hALl0xJkftPucqIZpz0Ivq4y3TOqw4HNChLPJkDwjrT1xSgQuq s6UPKQtcm5QylsfFhHpmwH0p2Eb3PNIm35tMWda0trIkhCjQrKCGrkNWwKacRA2NEhoh9yrd KMwZG94XUsku1jCfzggpLx51EVlXQEdSie0046ME3PwIO9VsVKyYxlu0KxroG7tq7gEfBvXI bjo42R1rBMQqMEnDg/vr49lDu/w8kSPzcQYO23sguThYKChaJoEWIhY6P5KtPR7xVcDIIABw vjl6dXwBA30JpTXqykX8QbVqBLFfPrkFexrwdvL30w/2tCbgk5rIy0NPTM6HgI4kLpaiiBNM jTQIdBa9n7u1DceyL/OMwTkkUCLoP44tPSCpjh/vOb/7vDPaJCsiW21mLYp83b6ptx+anQfe FXAoe63VihOF7bKhYVDzAKm+T0NkXS7nXypSnkGhUzkPKlcA+jivp4CzxuMG3OObOfnoE6Zr SY1y/jQewNiIrBzKH/mHIOZcZsHqqRbAEGrIF2wCtPv0SX6VfcxWWEdl9PTOy6lqnbnDZD4C 3yRCbuyJiOTM79bvcHos03ktE8OSv0Rs2mW2fKYjHuD/ELXLMDWHZBU7TohnIvDELPcY+AKI G7vlmaAXXa8HTK7M5cBU7lWgJ5aMFK7NV1OCARWrUjl25szR3+suMj3FS0Zup3JHDFltAK4L 1tfXW29OGYBltNzG3PgFtVxT+k/3aYS2DUwpYkdTyE323NKAwyd6vDOtYXvumRTs2xb3sJOX TsWwYRX1VZctmTxRJ7+OIXH5+wNjfEW/UeZu07wRPekbwFMusv1DfrHTrQd3fCqGEgztUxKR +LC+fwn6HnE2tMNtph6t+NPQm7qgptmWkU0APj8WFWcL22aIpno14Qzv3iIXmIhobSCxMMRH 68dttJ4gc8JF78b4KF/LCy7xvtmGHyx6yc/eLp27DTTr1TRNo/ea7CSlaULjEufUEpIi21M/ dzTchPpvwBaSugmrguJqC2PweK7gIkGiwPTYrDeDfH+9hNREnPR29QV9JbCFdcJtH7YNjv5C q5l+O4IaULzM5jxP0E13jvWjTnCdvYJu5CiGxqAumDzLNRmZFrAZ4v9NzKzEOYnObcM/4LjH 1fGq9EoWRsCO09f4Q+al/uEkQluFx4bBfCJZk1crparh3BXQsGbkyeDxk/Iai8fiDMX/Iwdv /hQiSgUbL292fbrNwTBcxJB6U4modYsTpst08hXIG/3vpy/yaJ9vjX+m0YpIavihld52GvTd FTTsbOuch8v7jgtISdesWRdw0d9HJ7LDPsCtCIF2byvku9M+f5qlqg2NAh905N2LaEaC/ZDa 8mcoQjGkb66bOnMM0uduAg0y++g+EeuRGlC5Oxv8rZm4PgkEIPLDBzf1pWlZ4khEtvYZT75Q 1yS9hGq+66nNdzqO/LySPhjPrRdnvSsFRi6nFBXGpMZ8gyqu9HzT3LL+YGgYJ2aeTfzTT1mm Ci/7GU8pTNyYJLQsofU1ToDD2brgSEtJTYYh/rdAXn+cxfO0uy8WFx38kHeXBVCMmdXtFlNB OjcLIPQIfb5Yiqti0PEvPucRwLwsQTijv5HiQoZ7/1pnxmFvJxiyRjwUCcB+2p18/S4awKOW d42124hUirn1fLQnMr+8OoxRS+qjp1XOaD8PIhPmzDr2JetlYpMYWKA22ypLqXfp6Pf0jXb1 7+Xq4/b64xH7Zm3TrXkg4DBl7HZn/QX3IBVDUCmPgUEY+wyAf2Z9aJSZrWRivjLI1BVTCzM/ glqG8GEJeNl9QpDZomY+RiDQNMIY/DwgylqhnsmfGx3LeGrI0QhycQeqSfbnv06d2cDt0JNZ AyBZZhwNArn+N3GvU12VZEEPiDemh92LiQdarpWdznYaUWOqRpJRFMUao/XbxbgLpJyJJr04 Xg+bltbVDlbhUS0OqQXKtdIFJzPHzuklDzCG7FPRd37qJI6LyhWdxF2smSZ6XxLLrLa0T+2n ldJxoMKmn01fsUxNg5AuFPQJE/HtuDPvQmTcVV/1olQSKwSieuHBNFl9MGXCXSLagSvNW83C rL9hmHG/JWdMblmuPUG0ermiKJ7WMhDZrWacCRgV7JQTF+Kt8EYRA3N1Ivr96zmQHLoIE3aj cFEYLUwKZKyjgYjMr/Fn9njS45SHYHrVOCBIcSny2lBGGoH7XZgoYCFZsKxA43rw+aGkBP9h xzHH7npvTQ0sg6BvvK4/VeiLp0ull4Kx3IIqbNQZkZUXs332TD5c7nDxdyZi+/kP+Eq5KN55 HI/dGMod+smNTUKw0uPiuQC8XSOdWXD6UuXzKBXyfv8hhBtnXcmNV7jm2pt8B0vDBWCjprpo 49BJEVYAPaqcu02Mth0DLacLVbcr5NdFX5fpiuowV59pOeFl2rqqfMzEG9V52fUjATuwPsSO Lsc9FOCg6Gi3xWAXZ9893ez/DeQ7nTWRYPeh7n+0glZL/lV+V+phBdM7NOx1bOHtNT4/AiVO ll3VOKc9vDGcudlRyQupmMMyayuQCH9MwBsF6XQ5A0W7ESIlJYrnGndEhYLei7aUSJTIwTAe fWm1pErPedOU/wLaKTapQeJQRMKu6ruQAIiixRdZfLh8W4vSitV/NVNM9VhQeAjt4GpLce1X CbAEoqkp3ZoQfBI97Se8fQhfaFmcjtqkB4btdxWmOSAjIm8ef6dZhcF1sNNi+/4lwHQIilaA rhOSlanMbFJThCwbmM0A9gXFukaU6C8oHomIogeAYxteqtOuXXbEU322IMZ6N13xD0++A7iJ 4SN5w/NyymvcX9n1KwUgYiPKxU2gcAujOJxQ0C/NwPuBf+fSVbSHU/cHczr7S/cTjTWNgFab ll0Pngs78tlFdu5oByPO+YOsZQ8LVEpo293gRGhshod/syxyOMXrI/yWTW+osUVnWZYURI3x hIG5Sr1j7k0LHxsM6CN5xCsO/5YNSTyyYMuAL9ILX2tvuhZLyzhObkIRD1hB7ePFs68toBmD dS4iyWTMZsr8zEHG/qh3FrbkgHPCme6O4Mb5opV/sCtO9B6Jv+XBEfSQocAd5Kz9ZJJ8suit IqMSZ/LvntZAk7S7SY7CJJZlqh01DG84movlxY7jbwPjeDJXAIsbI3rmr9aufrmJq7ljpksR teSeUBFO8z9Ov+QFNLF2dDGs5WZ6DzyntfmCYiV4MMJOczwP74oGwp3D+9M3S/PIbErgsYi8 Ggu2flXAfk8kt0Me7wJNQD1+nW01pFl8pWHhW2hk5TrPUx83ox3P6Mn6MvDV4gNBus8Vaedi 5PyTtre1EcBzAasnD0S1m1++tYcv23M8ddA79VrTYnbV+QqYMNSXdSOtK3UnNm5/BxYCWi/I N/lvWgHWPh1oJpG1RpEFDgP3+RQOK36TuOu4+RZelz0pAUVJrEoALfojEixOK0e5/wTi33zp go+uaqrvPgNXUzE9cfoIPAWiH9WZNzDZKD1WMacIkG7rouxhnDXD/OKnATZsrFV9X15cCMjw UK9PkUpVG3iGSfVXxmhGYm3yWzXDjTC5B1j/0S6u7NBnDWiO/qAyWs8a4gE3PF6jH1Mz90oA BrwwNZtP4H4X38LO/IizDhQhnIhtUmjZ8gFbU3SNZtSxySkwAfDdxjs7g/xIc7+I9ymusW// zRWWXV6cGE4Qid8NZoLkcI2lX2Sla8TUgrhQp8Ru78qir76bSOdBSzUsb0EyEAvgiFMZYOPu 5AH/GgWVSso4pB70OHRTT1wvl9wnjt65JQMSzBVkix3iKXLj6IyE5fBw4/Ra1OUfIRTYbILJ Q/8iml1A0quHtfTduPnojDCiwrwXa51EL3V6DNCd4cxHl40PDtPNQ9HHiOqaygT7lz69va9M o7qXt9Wze+tkv57UBcnkIaNmir03H/Oje2EHOx8ZP+MKquJaEey3oBVo2PA/30ceRZX3GwpK XUqiuzguss+L25imNuUVvIwwGRGdyjx+YwYXQ6ZLbOcxKer7yx2Tv2wLiiJslSx6YbEp/LRZ AmdN7HKANmL4p7CqyfPNh7Nkok5ln3uYQnwpeXBrGRJmx/9rBwJuax95WWEWkXHb8mB65QmF 1hSW2v2MvDULO7R9oqDqyD/bMsOpOJwb+MkB1sloCMY5uFo3ZnWvHOwWf1xdhecFk6YYDAkE uGzT4i6SK8xNAwqgFIZOi9VQuYztGn+kxQEhQdhAdtSvH6moKykjJNIqQNF1ZhYl0RTN/kP8 1BdINGt7Rb96tXf5+IkSn3N7bb3S2Dj9u1MzWB1/UBhqZ6HCmh+iBTYLsQGTeaFVDTklbZfN MTc6hiXndRvg0dg24JRwagXf0WFQEJAW5fCJ+Uz4QZwAmvyNGCRDdyXeVM6CAemJgzs2pNOm 5KHOiCALEVIuIgvUDNXC/+yIpqhDh43ePa/JA0uSEr2CE0DkASiDruY20nZpe6PbgyDK5Rl5 xgm81u85amKybRtEIMrLO3Bu5ZecPtyxQeyKpH7EV/k4ipYDhjC8PcA4o7vGNVTxKrZa3H1M J9PCz1mBLlISgozAh2BM1uLztSXGBIJXHa5u5KIdNkDFTlaH3ibOzf9oSVi2S/XAQej4iNcx i/viQumzCNze6CMjmEMFxso6AnmGU9kMloHYcWU7y55+Ov+jg5smwiv6LjmWxgcngrNjdelK xUI6AGwrDi7jR5ZDnbRvavyKCLAjBw1R4VnHQLmm3euRKPHt1XvF9ExYzih9ecb6ppjSQmMt L7KY9BcaU8JSZEg6Ww6KFVtHh8GTtrfY10kkUkl1Wk+aa39Vf9ePecsl+EpQbv+1aMIRvEM1 JY0ySDSiMfq/CgHQBYdHw6GFQODfYV7ZsAvr3KxV/Tf8g+ogQnVIJhIJtJsVUbMJtVjHMwJx qTmVWzoPqJTdGs9dGz9Hq7RMpzVJ07jvJHuRrUmCm0OoOGvtDrIh9Heo1wf7SOeAwYIBaPuL 0rF8w/WhibP0nytfSVpGu61sPjmDQoK0k2sofv3xwqoitxC1zJfpfAU+4Sexsx3S8EwAkm6d 4g7aM+CunXr7xzoSTEXvKqt8tAX/2O8rDlJv3NSP5jBDLZNL0fIPjAa1uFEHoo9M5OKHm1+i LIHEVc1rLcPS4lYGli9WjwD2Rq+kccBS9X3+N5ValL43AWukFJLoargEa+X8Jymezy76++w0 oBY4HUzUeIuA3YxAd2XAcmBNJQG1dNyKmjvXpN1HFnVFaCk6GvPk8r0U7YPvIUJtnT2GVusl 2aqixvP2eXiYz6wp6GfYR4wE7Pfk23Svgf14Roz8N/jwD5pfpfHayZXQhiAjzRPGqCHbO8xX ydGagUU4eiWNFVkOcMQvOEUyDsJNtvoXj9/OERh0NIS+4v16bBzQcVuYmCmTD+Jd5CpFH3pS up995FeWE1PUDOIOK9DONV5fjBI16XajCe28e1O3KOYFEz1ILV9c5v2D5vLFQJwq/d+gyoEd /Cmi6d5Y2CiuEZBuZHi9Y8G+ehn9qWneamPOPPNRPneSd/Xe2wPpF1qEZN8xDWA9Hs16NyP6 4oaEMwIjMrdLjwiUVh1ykasktfb8iJSvrPJ9tComUGtjkQubPaMRYfu6Z+SPIGgx3WMqf+Gi lirCkaWx5pW82v/JK3PA+0v5JLglnSd8KuS125ZsrPlnxLIxqe14oaVMcixqrd0LSpVG8n0m GBhSBnJPFRIbqusOP+k67+AtgCvs2wEBiAy+kECYBY0LtGdrf4Ix0eaN8Hwg1dsVPicKLQ68 Edux7BIdBV9FcmKJhy1SK0SQanP3u4N602cx/+6Hios+H4fXZwy96R6VoG+UK7j0M8rki2KY EVfnaC0ppNQeI63Vor267vZor2pJbcGEkc6WkRASYJoiJT5ObpTxdBtbPO0pYWIDwgd+NH3+ jjhUyGntcvL9iyTXLRxeu7CfGc1iDAI4u/c+ZuQS8jyB2f8Dhs2PSM1gR7RalLMqU81Cvu+0 VG/sMraSd8TH//kAZqLYT1SDDpPjcfokOl3Wa6p207Vr8+gSBNXi0WRPpVVP0ZcF4Cm0hY1h Pv2jVRcXpAV1P4ipGg6bbxuzORPCABzxmXhXIKr7WeEVvBhlpULGS7bDgsU1E381qNcoesdl hlVn0Da2R6ODa+BqLSs7mImsflL6o+8RUs4e0YRarxhz8NKDZOpPdf9P6v2nImwN0JZXvjE8 GJ06upxw2VLd1ws+4tLjkliNuWsFrzRAob2GlmSFf5fluIdZDpiPldkzIWK/+s/uXHcz8cJH 7MklAqBPUK6Qlc3cLJES4rLrAkIMW48zl5Zqq5zp173xvMUNZFt+1pJSmwRu0s9rE6X0tjwx KttU4tsGcxQ2mm6h1Oxrkjvk4ccOD1+tkgWkbtorH8PGftyi8U0AN+zD4AMTwLDg3R+0Obuk 1dbe1UXg3lT5njFvjiO6GEFEaRlNAnFF5ilq15uZjtuoCc83W5FFQRSzBKjepSPMb0zbFhcH MSuKHiyI18HU6FaYMBlnM0s0SNHBRYxbblrvVGmFgvs4qZKo0L9wjXwm76BwogZ4EMNekVVo mOu9cIKMTpsWwJeJ8D9tSM4X5kRXxqEnfewT/bLmpPGdfrfA2kAiCJ67vptZ5uTzpHr5YjNo QR/ZtQKFX2J2hptV8xuFRx03ZD1ldcNirlOFPdEA/ziuzQpTnsZcnFpVFAOr20Cg90K0qboT nFP3/x5W78tg1XZN8SxdpcvtHtxgxUESbr6ceea4x+VLYKhpnX6RYnXn3KmfOFi+kBRVWHJY nX/rfmSCLiO1X0KKfloTFn6rTZsO6qzgwTn2WWsaoUqr6a7ZMOI4IGf34WuDutIFnoXfXwSy GC9AX+wnTS0Sccb50I1YKQSl03m8G2m4S5TdHdevWL4ATta7ZHBSqr1ef8tugWDWUmhXFQTJ f1apTC0/DM36fgHmPVQkCACvhHvl0d3DicDZ8K0kN8bAjh5s/VS6TGKP/Irxkoxxro+mrE8l SzjyC6zpD8N+zB8sZefhG5zeqI8P224+Sxs+XPWfIYLkPb4H7Y9jrCfjnWAaHw1NL0oIqt5i S4UzBIpsCYj8/6cILZUPq+KDTjhCliB4PmmkJZyIm1QzgJ5Yj7t8u/Yn1hnzmweDanQG1Kkh vinrDg+fKTFzCmf4AbB1La97O2UAUrCiQ1xDBkSCL6/Wtb8p7FsKcSNuBme3FmBuks0jUZnp HxWGBezQ9xBolGBm50qfD+WUWhZ73YUrQzEwaVqgBL1mrWNx7nzLYpARQHlRdvF34C790gFS g/V3PjJt0JctuIUtyLwsv526I5HSo4DdGTqBCE25ivjxFsfD+Cam/2tZMLZn3ZcGKOoSTGOt M0xyobdDrn1sfL+hYTrBzhpRnALD7fJYPehYkZtIWMxrlNsHn11Qxj9Qxyb8HhrFdzKTs3Gq ZugYhzL0py2Ftr7w0w/Ufuy6j4sFubQTSsoNPJgyQGVNOXavyy3lDWUOroHRTxnAHp4MO9aS QRprzEDC2lzAQ4Q25gqAH683U9NQ6qcAClyomLBSX8wTRl8nkymRhlPLS6yLkFF4uUMYhyTm eqv9O5kuC3dGT8ktHoGezdm7FU96ix4aIRbSxJCWT43expd/k28DEPF7oEXRn/WcInE2m9O2 MOIPLILTfFuaRSNU6A7TfRkhedmrILfQde9hfR6yt8PETAQKG70PJSbClH+nJvbpSi7JvEQa scZMNJeVYH6Wr7rQNE91zYPL8ocddfLVAORrX4IQoQMV/BwHh/73Ab1ZbYu/H9+1nvK413i/ nPx4AqijUf6Cby6D5juDzofZoI1hmOTgNFRyx4Q5Gmot6dIkwEhH+HvmRN7I2f6nKPq/LvXy rvzuDY0QwKyNZh34Ahmq7BvN3TOBnV9x98pqCjMx1N8Dl/eVl9ol+u8iqCYCr9oMlJAmxISq cSQ2gR3sePPUXFehRHE7MOr0HbK92QpfP+KHfwv02C82MMRzRte2KPvmDHszBALQeRrh0TCW d7dX76TbbXs4hnkMVJir6FFqdTtcIHq9/jEq9LBugDphNa0p0U6KVdDK9Hk71YTR5rpumwTj U73K7VppbIVO7fBjpcjUaHdsewdZeLfI+lyI1cf7OqJyPZoQoYma17107a9gdy+VtrFxcqHQ 90fg5zPssKJ8HwwB/87uOQy55INVYUxCjYqQr7mmEyatBol2Ttb4OCWODSgRbfDhYpdM+2Lj +eVxKBZbG5B/lNHVojvwVX2XTtAhQu/6wmISRxplQp1OwoxSZVQ4Plf/M/OMuu0RgHbp+bmz kvzrEibC0ojpb/YHcVVkDlcc/dl1y4vxS0civeNi6T4QSyl3EsyxXcsBteKKRtjxm1TeIRXy fqiy09W+c+K5YFXbqPg8Pw70PmhIVBX/SlDgf8Z1+9ffSbbA5Mxfz1Os6kmxi9PPItnPjg8d n7i7hpdLUxRXNDFzaKa8H+b8JDaJEcSnmqhBvtn3V7pQnSXD74luSZXB4jj67H3SzPr+zjLY RNYwr7WtHqO1rv/2p77oO6uezh/QWa/7zA+7h3lKZP1TkunnlwZqKhLW9FxMj59sA8l/YNos B0Tg6Ic21+48cj729R/kA+kqcgKsWrWuT/bkWcPYZ7ZMZc1UaY/MzHfAyjubYmHzNSoi3LX5 ou5aj2XvYgE0nxW80Jg40K1iFvpdWAev42poWWsdrULaTNrm1Wfab8W6cAcNb8C91McgXedT JJEDpkiinqwFsku9NHqiVHq7fk2C6chZMh5Zf1Oy5jvLrlDylIHCdPHm0md+gO3vgFdtrV/R JefKQZj9hPm13A8iCSMjc2pqDfp5s38w77o5VhTBJcOJMKBXYkp8vb1HtdGc4hYHvrkJWfuw /5hC2VNj5JAMd02oLX49yV7vRxedGdijxYu2IgLSCQj7wZM58h3wurqYVNbxcaHxUqkZyiXE KrpfqDaRl8+8PouGotXMpLfO8b7XuXLqhOm6fSDzTiTOv8V8m/hUPPYHao0lEJu/+JZiLWu7 xqKyzoQ1riR/S4lIS6NYfBjGpXoswYSqsui/sIQ3pfLEJWFCxiJ7Ia7UXzgaTof+XcFedIC/ lQ+Kzp/vNwuLeOEpd6ER/bxIeB062Zq3NwpKoeB+U+84Oz3my3crGn98T/pYZpWaoxZO1Ngp 2RklojOyD/RFjwqA8XI8PISXMWWx0g9WwRsQtkYpW6iggNDWu8ncCBz+VJASf0+1mwSFgTcB +CIGXl0v7o97QQXCZ8BktQ3u1l0wNuOMkrWfNrPj7w7y4glBAnJ9uOwdTNVX+7eNW3KckjI0 YjmuGjr3MPyi9vO7PYzYBLUFQxXDzxNfMSRxkj2s/e80z4zU3uDCg8n6ov825k/T3vvfc5Hr abZXofa7tyEfxPqOmV6k/atCh9ITf6e2rPdcW5MUoT0zPmXhvvzyHIoadwjHpNBlk4nxsgPR kIIki87O5AdF9dISvesEicOMZUhANdj4ajiQW9UpEyCsJOj9zSMDYiKyj2B08fJ/5/IarBSh U6xUgWBId6m3KzPbdszweYnU6so0WEfJeavn9uMQti0kk8PSOu2w/4kDwNV6FIJVqKyvuG3y BCjU+eV71YfPz4vxaliMy2rPJhqe3xMPi/slwwCCK5iX8/2dIps0TOKZczTYIOxSU2DgFz3p NpgProcFgXsNVWagsqIUa5lSoO8gs6ooE0vHB5N76BbvUIkTxt6JC58r+EqQLUb/u3gR3Cv2 zIF3tvHSP6/wRAzk4Ogw8zCI9VqymxHKkTaR3BoQOdPEGC/etk6DsYOvxYvurXTezmPUKu99 IQQ+N51F/k1KDaPMEMw3tc7QGhVjCa0BIeG+7iGcQVDjMwhJu614BXMsWCosgfztZ0AmQ2q/ n4QexXa20+S5iiYb3Asf/o1Wj52Gvyxiea4dhjzLaoYSK/V8i5W5Z/yBsEomBqDTLi5vBY+s 6uoMuFDgsjBSUvDnY0HLdJIP8A2oFR23HCuwyuWPfvKy6SDcd4LfTHobMK0BPHQ4kHHdZ8NS 0jfwiSgGf8O5lSiBncOdquudzIF96Efrw9oeoSEPOiiOHlROPsmqHnpubIWnIQwMFUudxJYd hKlJxK7i2QVU4qnb3Dmc0KEcOmFAha4MJ2kNKoywbJ9zVuyw76DgvDJG8X+9jhwYgwGM+9nB 1G7q5q4wza8mVqzzughqgYzvz1epqry8wpm16T1ukv1z8PNnZ11oaorkjanFYrSn4IQ/2f8k Wij59qJq2AjLur6pUZ9rpZUEvqVPbmnf+uy4L71Ie1B8xchPPP18+DvnL8eKOj1D7SskEnRV a5ybGR6va+SY8Ixyig9m0xLvPNrvO297sDxDoXYtZvcDFwIq1WYxnKqV06yTDQ/JKOEoaAC9 ZFTYeyzQJ4jz0zu1JCKDcBjCG4UUhgvH5qX2KgweD3V+ptA8rLy/APzVKHbJml8SwbtGHsmU RYXjPkbiutTUtxsbBPpAedgK5KcAIWAQtjMr27IIDRBsLSapXx/K61jcSAjq7ontBUaiDg9T sZdqU0MYopZu7ZXNRsXI6HoPwCG3mBI1FNYrp3dS5OTRHhooQi+UEqD3RjJkj+vfZqCXekPQ wrShuei6ZpTVJDfZv1BqqaGhDyWH4g9uoCm3bJkYRFHGqoSfr+rAa7qCHWNEQuoWEP2YzJ0s oapuS8d4FUKDfS//u1xxLUGh+LRC3kn3RN875IYAXSEff/vO8LrSX4QWysx/fWz8z+d+1RdM Du27u/kI71UvkjkTsFnyYhr07jfRstbja/vPCOCQN2qGZ6QVCgRs3qQM7cmwXBhOtyi2zf10 GXBEjcYd6c5r4iOHYD9EFz+0aVZdoGZk7SEN3iX7kOuCngZ54yAURxOm21hMz81IoLkTYbkq aw7skVIbbIx6f4o/syX3SSn2EDIcO7QgmjFhmZoghXr1dqBd7T+ct0evSGNGmEMgCUpX8LU7 gB4JDvjNL1W1HPCxxwe+hA/cxEL98e2EYpif0kinZDU6fDoFHfEYf+Py7/f+HNdB+VuZXgsi VhKmsKVO1/z+yd73pNJ2u3aGZO1zKsnD+XBX10t7kraq5UzNkluEy3jlCLYsqbopXDtP6Enm FDfMG41L8X5RrdJdnJW+R1Zug1aUFtZUupI3+n50CHr3+Aqh1FKah2RhvQ/c4D9Keer+z8CR t8bp8ENC2zNCvDJU8hyuNQiLF6W5UXdGd+dFHWCgMegnQoIsmj0YGGnfA2obrBwXUQrSMpeF 17AReHqIGDnJPDgDZJQW7wlzeUlzr0NNFYJtY/D00YdBGsmzEH8/wPrwHjL29Q/wS6xjoBHZ 3+xjXCXLbpcYU7us55ergKTJnMKZR1/Q2w0t7SQ6JTMQV9Ad8KsXVCAPJppMZIWSx3MRlyBE BMLwvoEnUhUb8g+0ezWzK+etWx2mZgWrVJp1RGSK+Ma1bfweTWNTPB/HXN1KP2ZXuM6aiRs8 kGjoGrH9+kjAjtCQgYpG6jYyatq1c/eZW29dQ7vb3OVvFz4HCsoJH2InDf/W1jfSY/Q3p30m KC2aR1XIu8QsahVLC9omnKe5u60VTTYWX7T+hFaksd/XfkAEMqvco7PxiR+WmexMYpXsOaqx 7cBLmvcWU7HkcHgm0Qhqk9TJXgeM0molowNKYcaBsyA+rjwLQvHtZs0etu+tUl/xxDD5lBPE uau6ox3oCv9OSwVNXZJ5brmQ1l03JEGXDmPig6DIpfEjNHt7solZMjjs7gC8GvMrVyJljOPY 8TQEVqEHv7Fz6lMrLWbnbE8ZNqzbfQlV8oYhBwSb6N/5EjV/CHKmtN4/Yw1dq5sFlTbCaoSm VZO8uMf8lHTGJCLVxbS4DJnhYEWI2NqwLSN/opEZjzNvTUbFF3ugT0Zl1bnITs26DvpCAO5K +hyHzZ+pCeDUDKeDZiRLIYIiQ1jUF8dmVDTdr9F+f3VFut6kn7HK5v/4y2Ulim16lvVjGXTO YALq+bwH6Xv57k+SXZzTqyPVOdu+uR7RMOGN/JN7eD2M+ZChCAiJoctk0WHYabOodQwNH3sf yZ5HyzzInUa77uoooQ9W/1GwkLTBMB/l2+IPRNWulNzOYkDUxf3Ycs+KhT+KiXCU+81FEiBS ja1Ixhj34m2xl2mh6rgDZmhjxWbeIPN9JUgAl0uTvxCN4UgxR8yDX3LRknb0cghRxsWzadKE Lf64ZbtrTpiKONAnJOKIG0JO3f48LscKfJX4bI4P+fU6S0T9koiaWPvAEXF5IskY9F9iowBb z/Y+1wq+51IaLBanzdjKt46YOU5buWz5wbn+Hug147DL73nu1UNGg7nH5o9WIgkblUYiN42F e7aTvN4ovp9R/cM4j9+C5HkPiFZzy8JYkE+7ZoKToboVuxr3n/vkdegbzwHVOIaAH4o0SsdF JKHdmgMGLyV6YkjvURGv5uWond6Gm8Hftk8wQ6xCEKOHs4T3PWJe00VsBZmueOr93VRBKxVE OOSMUM3GfWTIHrS9umsuZtlgNMdaHzHxu6o1qbhjbkbG2fJAIyZ9VkiSWySMxvm8E+ngGPAk 2Acr0BIofakmbbePv3l9p6OAdhUEXOypdiGAanZOfSQn3JJ5gag4HHeLsgmHf42FO2LKCQQW 629VpmSxnVSh9EYclSlWLUQN1dMEd0Za5S1RoIN0ufYUxgi2FjrQKIGYNpbd9L+ovkbQYlB8 I8U6AW7ZkSwci3aoNo3o7VSHQh9JE5badamIOLxK7O6q3Rrh4VHPqJ/W8mzz8fCY8BeCCMYq 3LYabXlLQAAp8NXXOZyDw4unHDmPCDGfYtjWPNxQ3O+LesToXoE76cRJeZtxf1NOYUgk7xGV Te+kwVDwARPTEmTiTiqLPNFPYi3uJnbqfARCyif5iEpiPYTVQJDrq/ljBYt0j7U93METXLCw w5Ckl5QPPvkDfjtIUiPsUqnwJZKkXgq8+iyHzom6UATAfemGsa5px+yG93p26elAXH/UGQpu vqf/x6640uQD9zL31IfNgSp4B3zw8XlCzKbrWV9ZGl6JDKQumawGf10jy5omhlI1ydph+LUJ 6d0BPCZeDaCCV8KUw1R9411ZipvlDr45uahaV2VGLxytd8o6RqrtwE0xpbHrzlKfrn7OPMrG AdA/XuWk+yEiX4sagvuO8I96GW8HVsXdApJsiVbZZxjVgE8UaFOHc3i7CmNejO79jrNj4E/e J29ZgSmX89RTKkUxTx4ru/NbQpagR07qiewz7SuU8pyNci8psUpica7REmSoCSVUy9P+Q3b+ Q3Mdjm+upBVgyFQEfh5+7Wx8IUf6VZQDjXogKxlRV6M6JqXhgOQJaa39Obz/QZYM/umJbuec NPNXcpYM4GWbZPtx5VJp9sIOQo901fJXKZQ4KUZ2uto4Y0FLvE5psQJ8drgv5OugOw0EQ7E+ wUA5QaaMTvgW9+7bjo1CdHM4VQhQp7pGcbeOsHt537e7gRXdUPRFLE15L8+57AGKoGeLFnHs YX8cSVF/z1FWVWfcp23trEwslISiEozFbiFCG1cXGGOXdqBE4sL2aqLdCAWYBVQ+HxgK71kw MToxW+JfOinvB9Hb7cKyWI8fok4MM04CX9LEZpRq/aztUFsB5rYgwX12Gv1/lNJZXQLc3pfx vUoCtPTQSDhSJgcARWk/i+02L+bKi4EdUxCoCDiMscK1Do6lGP8IqXH0MlUmH0y7HOFSFIja SkCqimifEJZ4QJpw0bbafs5ro4WQ3lK3BjCU8ob9kSPFoQWbIp1imM/65vKxj/lvgwogOZHz gfprPHMltDrIEOy3fZ9+scdkZcqDUjY6p9O67GZV7Y5nFD7A7BQJzNf7c/CCQLqN6QeHkE7w /9cKFRlk02gscniYK0Nxsh9ukSC/Y7w4dg8eIH6vjfrCiGlNhN7pvLB/ww2LvYUOTX1c4Md1 dngxQzM1xq2hkETuV22u79M5ID8uTi9MsaSti/7nZgu/pPmf9aoRtoqujXdjoVK7U1xhkzvn kJIys8JzIAqVcrSuW09+KBn3glhVZp4Y3GrT6d0gU1rMn7MY50Ff3EpMC4+qEch/SsWry4pp oW8pUXno88XNby7/KZnSvuao2qOZ6WpHzbWZPmqmgIScPqVqrp21pE2XwBEZwpnbExzLHgCa Djr9Xd+9IwQZxenc0EOL5964awUBivPf9fvhI1wYC5VmiF4wAlLR8I46a+1WYqoRtmWc9HM+ xb9+KNlpj6/hK0345fq8c/mp8o0oMAr4kOz8ypYpvWEukXL4eacxzbWbbj/pYugwCQzxCFin W/KFF8aQAn0mOBc/XIQSQCFMKyWvlIC9Qs7L3saolBG8xSKEGcK/eQj5LCCOx20Yw7Baeu1Q 01cTdDlhO2J/uEXH842ToPKT28Vt5GEc8Arq3uGSJQinDrlpb1w+r9gUZTt0IH1U0lly1kWg V9m88rbYcsP4ygukp/MzndFCTvdxoBYRr0Et57E9BOGWNFxfFf6anvwWbMUOcS+3NZgfJdGr hFS3cmZiy/8CDRDj9aMNYX4avnVBFGXjknUOucSMOixQHYqg8xJl1uH68Nc+8B6AsF1R2Wu2 MjWbi9QixnzuMVpdpmLuMZvb/r2ciigkWQ7bh9YhokNdaPU8nwU85Nhn06oFDxtRYBiy0583 v7Z+4pCmjd7j6e5zJibj501Uv+ZRy39oGMYia2omKzS5Yvi87yIv7hATZ4+A1ZXHGNQX+TlH L4p7ZEtQnir12sw1EGv/3Dqune0sbkU7eLmhNYw6cPkZQoDDcFFs1/u696kG4TFRtr2ywMp7 KTUyHUliCioHiQ5Rs1yqzw7wgBh1CXkTUewWLtY3pGVZeOdI7NazkCvfan/V/Jdig14ewzTx JUXJ+6wlNo7Kc5XA+NO/qqjk0a8SnquHeDZhBZhvVd7AbH+Y/wonI6ThccMJy+qwrx/lPxVt lpDCvO4Q1JV1JmOICw4z+4Y2uZH6WnsapYc/dQcx1ZjxIE0Y3k1gawHO6YiHeRt5m9PebURa UzzhtnFbZJyqOLfmX6UKBYnbRG6V6UsuAmCVGZC3FpRFg6ufKeQhrcu7DpC7R5lU3ogGt/F9 pnxVXf8hb1//dqvICzGug+lfAcqnGk6ca9GPy/380MZUKQtzjQJRWPxfGiSJN7r8PbtN0c1U 8es3Q7ZpVD4a8kHQKT5x0ARtFnLZwLcnHkcuQEA1b5QAwNe5K55/MF6dFZxCTp7/LBIHXI9X 4rwkj5j9xTqtCd5LPt7Z7qo6qD4D+5ig4sSMlXy0TGW7YVR6DDpekvaPASEsxuOLnUzZBJfU bPD41Edm+LXFu7mzkDGMu0wncDqXH6GtHvjZoWKVuQQGLkdTwPLWrjD1o92urpI41aB6RdjO cdXNckN0ZIH6sTtamq0ebzQkRIgWdrLTka/YR6Pp4b4V67H+hOX/ydXJ2u+R0E7fLr9SlhD2 Mgja2heyKKvkOW2fD0um1g3nhwat5g1ghHXEqo8m9xsffmiLbb/FFvx+5UjqV1J/6Qmy6/EV iB0KjhttAZycbNJG+Td64+p9t18kqC6L0WWUn5RXs4O+kofXLdqSdDhRo+3vmnr6UriyAgUL 7buma/Vxs1qcQP41Yum6o9FkK8O4Kn6HapT3yn5ZoO3JKeapWavl8UQUHJvA+jciyJg752Ch vf/DI3/tnRY4TiSUMPBaWUcHNRbyDm0qJUz1YKf/CGsbmaC6BEtHFoDshyni5IKDU9AKjqND aOsjGb7sxWzgrCcuH7n5elVNutGK4zY5wlLZtA0BwTZq7ms6PZW/Qy1vtdvGKqoaahjHQplK r/UAa2L/LAK9kbK7MY+fI1WTflbF/96EiC1FnzlpseWvSilsh/J3X96QEairaUpjqqIQedwx sV5X4acaOnE+agbDMuwHQkcyDUTHlZOqjZQl9FlSd3+muvUq8zKYJz477w27i8b3Fq4P3FAV 15nRhAjVL/ftnRH0kDyDwFsLaT+xF+hOYFQUFAT8L4H5PnNUe85mES8NrXiSiASeH+BzywUU oR9dNArUAG00taPM+fQDST6xzCVE6WjVyxhzbvPiMmPdWypA70ewMeaKNU9kPEp9FMSSxBwl JcMFGnRsO8wPSjk2HHKWqBdm5cCyJmgceRid9AqsVuc5tOIh4G9TMdGLXip2eWoMq5wstMl8 FO3CqF0crAXEAT0pBb61f8N3SUNWpHb8i67IR1b7l2KrutpsZmq9t96RXJEE4yayQEcjVYzf A0qdFdEAynUArs4JCbi9PisxE5WaIMUoPrOUhh2FgYGtK19XkouHF0FxdMpL9EXq5qUX1uIY piXDkJovixJaGmp/u9W+QrCWOM49pS20dh/7XG+Yia+pNbKOHRkPGeDqwE0Ua7B8D5GtOmds ilXkSRfxqSE/68sW4AxwHAj6moXIZtEUD7j6n6je4xq41YHVffacdPdX8MMh6prCz1MAzSIj eahya8KL6UVlfX8Shp5PyT7NFQgwJEaw3Yh8U1xnGYA76nRaw5dK7qEE9nDvbvZhn44EqCju i1gf5e3o5DTQ5E/ohFOK+hXJHcNp2M2P5b+2PC0tRS8U7EfbHOOF5Xv+vEK2YMHIYc1ySCMn 6V2odMDokkv/ibu7YAisQ2FNTGsIfSzTRZ3bs6PF2yXpmtvoNdztfDW5iZUN8roAF9PPpJQI IJ4iNpGtnfTGG7A+tz8cvLzEfGbu+Pi8jrc+r4jmhbrSrtLTibyzyHIr/K+YSCppybBySGTh TAYTf8R9PvvTtm4n45u6/h+SZiD6vqX+jGwFUIMCa1uSdpTwjbUORYiGAbB+9uyt4WxMQaZZ Nldx3GwS7GtDtgqEI1yA+GQE+BW38bzXDyseqcdMhW75uj3exJdagA6et8/oyl9pcMnN5YBx 0y9NbqlQoprcumSF+UQW+brTayAKCz29t6pMmst3TIsI3f0BvbPZfC6Dq2LHgxk8QY6z7ahY vUqpZP3keZIG3ekSbsKSBzB95rv61QMgI0cN/UPrqMwEzQ3dfa1SWkvX7RT9bXdQxO2abfgc 8c7O2ivFzdA1Q8xe5BzyB3Cw5Gox2A2g2HRAW8450muluBZyLnaMSXhYcajt6aAyLQEaCAyT b02g2d7hk3oyHY5A4ZwzVVRjS268OB1lPcKS18UWMGQHs6YZTgL9MkZANgzGMlo4n5x8bw0a e14CWbI4u/CHxPYa7EIfUHXAqgyshxCOXXuhxa5S5O+PFq8UDpUhaxDOFXaH4yKA/q1w5aOl hzaxNZIvN6XVvB+GUGtRV0MHm1KwjEx2Nl3zgqSGOy5iupRMtXUa0qz9WuzG2yTwER6zxI96 6Lfghk8Cw69QFlPrCtdnau3ZBLFmcbrOY7NU1JKQ+ENilTxLx2KvUgFx6sRSMngsTBRYiayE sD1oOpowvPl69m85btf0A+RfkkQ9l3ao9M2zAm91yZKSw67id3mqF6/jN9F2YObe82ktziVR sSf0E+BixznZfYa2a+xMFg9IJacewRzYnEulNYrPKPpwC5fG0LrrPkLqHORuI+8j0NiIvOUC T6d1QdCQjSaZed5uCpGgMKaLnBVRmWvasjw/Ov/b4SP16JOJch4eRXiwUf6JvD1eAQTXkbMo 93Gx5d4zT14TjjpmmP6RVVWKY1DE7jF03CSBL5f1KfZ7ROulTvCqcYyB6jNlCkhOF5epZSv7 ct6IINFDNF/z3wYCnDk6CwRiUGSS4Lg4F9RXfEoIwAZZXAAmAw69Y+nhogXKMFpv/5Bo+Eqc k7rSq0qbFv526N7OsxWbaDPpfHnQDYc4YPVCHsZHiTJVx6Ls8o211qWOrRN4mk6burLqUfUr RxV4g1LesbuSB0n4JP+xnHMaHzT8MV71UfjRgFwwSLVxapTHOIRkuMpfuZDGpCxuZxCsnwjC NJCinlpVnW6KT2opKa+M4zRMEauSOI4t4cVfril3FzRA8uGN2Dl3D/A6fDedSDnv5VFYfmyD iTU9hQfTzrj8onNe1J6GRaj4f4iuYvzL3ChHFwvt9xaI/QFj1oNs/8SFnc+x+slha+ThsZpV XKFNA0rG9l7XPD83vho7e7YzH+2tnjL8oBlqL5K+NMWemsL7ZlifVfkcaiLxBsK0qn29SstL ObZsIuh6IKa2IP++cMm2QCGzzhc+3io32Mpm2iUUr6XQkgk9aA4JV6ziKe5T02iWl9zdABqu MHaYnbg3Y10/qwVfgbmc5nzwpqKD75sDS6e4Vnl3WcQ69n2ildNxGk8iFjn53yCSivHuLfLQ PerjxjLHhVNI0saEr4IouRE72MKEbuO0TedB803PnRPsL87tn6G2GRjQ9k504Tm76HbTVZQJ F34wpIskEMspjAbnc4Q6svIA6M8YtGsxkB4THbMxKMLXBdPfytGx2UiPub3FPTwDwDyqrnJz nESM4iimrBn9E+p7jSYnL16a+qWrMueHaAyN4a2V5+DKmlS5WNgKbqqBNoGyWRdjzDBJtnJ8 nPQ4GonQewFXUNir/xKJgPhur2a8cJ5YMXlXATB/6+U1CayuoRRWxgbxsvHYee7RKP1i7Hbj ap6hMyvUM+hzfx7W96jWYLERzxPIvRzQdMeI7PhEMwLHSouqbDeQaT1CDBI4HqU7ngyldQnf CTz3hWoR9PCy6XcbYQ8nEQ487XrBxbYYSHagMFPZE2YZqMseR3le94PPA16QBHkjxEuUmiVU ViSRKzim4SOoenv4vncrgXftBl/GVuFmLo09w/WEqFcsJwD4BU1okx0ADHSGuXv9N6kZH0Xe VanDq7z7CVpda5IxO9Qy8lBsvULtSyIzXH5X5K85ciRQXuOLGisiPXodOi1eY97Zvu6xDCwZ BjJi3U7Giiojuy7fpk/RcM1e46CKtX3LvT6wmaxWYxtVMfVsfecCF5DPwk8QEo8cmNhXufAw qKWEnJ8gOqy1gCRCqPt91wpiqY7pLUJiGzRtyqjJfbfepNDxLdfDhemcIISju3rcDeF+ww/q wWdJFufdV58J24VBWdh2H3Nk7fngONlDOq3/R5z9wzDzjwqyRmCqbA+zRO/gZ/i0Syg4kOw7 8Xp7VV4WHkY82vMtEJnM/DnWxFpSTiKxp87zYRhgYi8k7VGPoigegc/3eK/iI5lllk6i/jAW wpn6jjGwW0dj4VhwSEKcYQs8t6cL/oYUG+rCHjXGLZ5yEo2L5xCYrYNVP13QVbHFT2yNmJ9G siHEPywC/Xwfa9JaksWqG4tomWmheZaIXt6X/0Jsn51YxNEQqNVBLjNzZoNhbDMiQKXeZFwW 1Ctf7VpY2hgPKYLAQgiutvAdzfFhgC6sQbif0WmIxFGK9Qq0HDszuh94gI6c9wn3KeeJ+KEj A/IVsNMtXDYJI5vP3RknKGJAjR1MhIwAlwPqAQKkY/ry4QQ4WJnw+etc6a3Z/xp5VAHFM9c0 Grna4m/dkL4nJ2/UkjZG6HQRQPj3dwDklLV5K4Kj0QwhDclsoN5dZphv6ZOxcvQAWBPWglJP bOoiOABc6zxHtM73T4vw/amYbh8GBhU6vqcwEkNlOIsoyYk9MhZk7D05xhCzikSvCVyDGal3 fYKAMTjB6SGnraRER4Q0nrHGU35B4+W5m9L/rfhSztuDfCHLLeEeZ4E1/bUmIiC0nuyUVlU6 llFDmkIgDDq9GZdOBcIGIb13tvGl6OYB6ChYwB8aDMms3rwe8IYGhuy+WcG9z7D3N4flVwCL ItYG33BHIUx2nRl4mX9fRxxwWRSDILD2Y2n59CesY4w3gvlbkExk7SUlwzoCAU3UVyOALwbq iyMaxa1oKkfnsDyzX1sRSF/Pr9QiVELdioznUnKnoBih43N4jZdS1usilw3POlomoVv3DMzi PiCX2SuDD5uR+nuDvv/IHJTVAnXG6M+yEBfrKJtNII64Bae6trjfxZMCzcrexTnxy1Y6rJBE UgdSLYbST5qg2yEPI+i/q6sQxzGJxXhUWOd73sXh9ryT2wosI1rXW0mbVAl6oyZUHwVUlyEG gzXwJN1XteOA1VFG2LSIDspjN5Ymj9IdWHzggJiGncgnt4DYg1GkLA0+GRq2ZSao39mmaSnl Nsq0DdgOHhKbyE0lRHtS3lnixWnzJVTyY8OrTa5Umgv4B1IAt3+33x5oOAF66GMkfuWqqg6E Hwi468ku6JWP8Oy3eAMzI4epRzqq7U+Sa1n2mmXIfHOR+dikJSDbNGks1skuBmJvUZlGYSdQ 0KxT8LjOXq7eCh7BQyHuHeSwb72//25ePkAc433o+l7QDjiRMPTiHzf2xy2HF4oJ22foWnos t+CLmyr8R5N8W2EZTuu+iPQBKNtppm2EfYZgmm2fH8hraazsvqzqy2nAjGoCjKHT7qhz121S o5X1J5J7XuInhbc2zZtHcUQqcGudWLZX0hpgNpB6Y7ljRlL1/D9Ozhw/e2lEnVNlUKbaV7Z2 WmV9ABIIrwSssqdDXH29A5LOqlTBHFqpkv8O5KAokXAMt3PYuMaPJgy2EouXtV0Z2lpiDker hiyNj9UiDuqLtzXk9Et0H70i1oeVRnwTcc6edwhKYn8xYeeoqoyPcWUKxQo66OtCxRAixTJK 98NXr2oGL2IN/u+5vVgadGFUlbSoM+zvwx5fIiRSDWg07RdByvwJe4fI9OgwXAsxSN/Ua9LL 4tfUwRAJqzxxLxFJgGkKz2OLOyAYk0wTx6/NL5GSkBLGoGqt6orpX/eDNay1zHTKXK5Cv45f KP3vtHq04TMi8x//LgawbQ4VP1cYwQKGXTuL+jnkxr0BduugTAUlGAW4ue15e0yYK6cmOmyG 86FrjRaALXbz4sZS8QCyg/uvcXQiWcq7BtZEyF/BuXDv4yP3Fm7Pckj1m0lviwL7oNMnUL1D Cc7P5DRF8VY2htio+P1BDyAs805/YIy06zjLCCuL5MkL1zQ/b6K5DCqy2iBHXOcNFk28mynU 7sRpaFPSbUVH/Dsg8JFgHmYbDscSPnHGhAUKNv/MyE5R6eWlKSvi7U6CrGNmZE+cwyTeoBK1 AxN+TzmQrviTxhvajCD3nfSEeeUvg18LA9NAOa2FW3EA7kVo/Kuw3QU8+zguEZOaLbpow6A7 pOUhf+BGSxKgstJkL8yQmvNwPy+akGixhgdqIqn5NtJOtKzw747vKxuRm0/6UV5U86BPJ68z A3p1FS1T8yRm5v5oBL6ERyC9Y/02LtctkXv+FplY83AwvyqknDb59jEyRN+H9FNcRhUI16FO lgnlPnZU03aPK4l6ZPvoaZbwYXX2jZ1FRRDz3aOEldhgvXUJ8FWPmQreDc2zqU42JYtvNM+P I6EZUDhK4QX5Q2a37rnll3TmT75CoS2ChtgIhzSeBhhZ/e4b9PSxYA+KUxeVZrb4T8+6N55l 3pWBeB/NW9DYs0/0a/aeXhlESjh33gePgDUJVMKJZ5V1XgMh47aDZUwWfQ04nNp7CCGfYPhe Uuc2SvcoxiGS5tZGmh7lUmXF+WuLVkCtqBb4v5H80O8/wec5w1YnxUodJ7eik9EvH1xZWogd tv5/PMLOy9y4zboGojq5cJ91JAzYVXcuMWbsQW/XcsNRWRV5lyy6yg7ntG/rLXHayNjn1szC AMhxXMfDQ5xGkopxs0ss+deW63C/HUcQy9sGDzIcw03ML836FSZGTZqO+KwfCJlne+ayhkXL SZ6Kkm/aSnXV7PCaO6uZSnHjzqWwQgm7cvls6PgyJ/tPdiwAlHjINlcXBZhJzEg4E+qyikFE k/hqVP57xlnLb5nciFH+TWpR5zEL13i0g5F0P/s/tQOmfk6s3Ju8YKSx1CaekW870MeNXM5j f476XQHmFPtxZGxrEOX+lxT3R0icI9S/BBOp7b9ktW4OheAxN1+oIeqwBSIgI3hY+8cANuN1 WWxjC9qEDgVphpzyZrX+ZeNYghIYVrBU9dXrCGMzWFlUrXDOw59EATf3dXa6hKtc9ksEqr/j +A6YridnvZOzUacUNAt4zdoPGniibqTJHejqUSG7lTlrpQxd0tVq8Zhye5PxTpzIGDRhd5nT PT+M+hwAJ8sNBBjj67PedfGDhF6St2F8h4hJ/RHVl4qDKfOyNY3hDnGPjzTjz0p7vEB8yHUG W7yppcfR3Vk+sTwRXqJWjyqEsJVgq48IjOP4FfTx+WnnNUul7AQuLDQ2bxBagjm6KR6g3A8i BvH4yeNH4pFcbvYwjjJ8U1OmFwiLg/k44G3610r0YMXSxsPH/6lC7PWUkyttwyxVwQpYg7h3 wcNrBlDyUtpg1PZ92bftkApB8xNUxl4TwRCsm/O8MomyJ++l4F7rtAffAeflI/WXtKVAUrTT 2egEzE/C9Rld3CAXPYGa15hlFQGAgblSpezwbetnglb4OhhDHuKLdKa5ji2cgrPoL89H92OH ThQLLqIRmErJYw3N3w7dxzYhBTNW3QwHfZuGcGubFMlszrI4RcAkVyh12VkbfcyFv6XVOgiq bUwGmYmTS3ZC+CKG5BOKeGreClvqrcPrM9PpGDIiVxNsmjMsLgBQG6lKgYzyoDJ5aHICCHmj vhhe6jPLU1rIx/Hon2Te38vXpUeKf3T50Bi+kkQyR+hfK8hgLTvjivLf7bBGTNUFpO3VWyKf nzaLKuIdXN1D4oW2XlBX6kn9VfLK7HtmwVH6TXO3eFV2Q1Hodj+7fos05rU+cl2zGFqCXUsb cP4CpqugIxudazlNRpt23i8PWtC38DOHMqHz6MFnvrW/peox3Bixh0vcCV0DT2SZRtSlZeaU S7Q+kcIlq9qcoSDAU9o7s9Rg1Ndli9/c51FoODBuUQNc8/aCwG1BT14KXEOkWFYHxu0eZcWx MYDzHjnxCzjC7b7tRmzO196W7QsgHZcxcfyJDfyWhUhtd04N4BH08COK0YuFrZveUNVZ7Qim 4ks1IN6q7jCX4LpKO7uL4CBaHhNictMo3Xyw7vBviGhVhmzfSIduUubqVKjvGmphs4RQlJDO qTMcVTt7fVioxOnkSbsFDA5PVnemseUO2R/ZbrhCQaDqEhhvwp5uHVTt0w0pbUkEaoMlWrUT Ic7ELxLffLaD2v5gRilWRPznTeOs0E8oNQRtf3FZFbs3nsJ6jFI7NZmNeEvwVE4Mt6XhuvrS s4VhHdQUR+L5YTp8bP7PqQ5IFAE/Y1SKxVR8/b67HUKGdbjmRf5/H2BbUw+PIZ4mSAO5/0go sw69Qeca9VrZmYZOr3x8uZ9854VFuMLnwfYx+ArIyjyoNvAYXupxGECyBRtFuWbagQiD6pet Y18GVcMPHXTHq6naXRC2Kn0ZtFx2qiY58gVQC7cWveRJLySlrb65lzEUP7cyTcBHRVzK3hto BDfT5/nhsP9TO1ZMzwPY+ZEsYhWeHxC8hY2W25m1spcFCv1zEdFY0ezSQ7Rr7dbluvL2TdRX SvbvdCcVasckrTyeAQlc5sVQm+c2L+V1ojy+p+djlBGVlS3GzImbJbwyIIk0iQqq9E/CxZQj 9AyOZTmtYCHxTkVwc9WCp+4NNQRN6Ti9uSNlRr81vmrrwAx35DBdEU9gACGMlqA82XTdWhLU 61Eyduk4NAtSWVa4W70jjA3SWDKGBoqRXvroR7xxl1pkg71h81nAkQxyod8YvVVQBUzxp0d6 yeo4iXu2mglONGpxFTssU29T6udd7Mrv2USkfHRjzoHoWJVCSB7te8SQ0MfG8tXEsdV0E4IO lzN5Y/6RmreNd2IsrkoF/gmon7Ttfv2GmXIMa2G0P/25Psm/7y6GzXzl/5z46AUXYp/No0hU LiRQ/79cFbXWgDvTdDcNN3EzIjWhdelLakIhYh6E83/6qNsyWbKohfco4s6EJmMDIUkogKG+ euHNSRq0WOBuIsmmjvNkO/ZQso4gDwbF9s06r3s+hWlk7X6blUPhPdgVVVYLo721gV/fdDun Ppa27kRJUBfffptWW6zG29vZw5deo38BN8W8mPk0jmr+Z22zpDMphciOqHK0ccdCkEwqZnHB BJvK2NmnyfirflwTOL9hLr0DyqxVC1JdS8VmxQfs8xVvCMyHpZ0OZiOwYR9oscsDhTqQMJiZ iK5ktzD5TmJvV1Kj+COVJ4GQXiQYhllW6zhgTbXEdGvHKBMg5N92PqFLF6jEOfDN8FIRAV98 YcRWQUBhQJzNNtgmk6e34S5OcYGzbOpBtgbDoy+vtrEOUo4Mt2uH0MjWv55h3oUzikn11yW4 w98EVIpzNR8FPGn6+Noni0N8fniXr6MEAqJ5TVtSGCe+YmfpanATWmvIeB2slpeybP7fUngc 26raG0sUKi3agdIZSAbNO3cP31P6J4rgJHq934ZHxKG3RbA12snHJCeGFjN4ANlDqeaTHMZD ab0OgtCqjNzVgxdnRxj+0vTkDrW4wiDgZZEPRl3fd8yecOg0YvQA/l6Vl/kbkbgBvH+DB7Zj Sc7lEHrm3z8y+flsYfbbJXwqrV4YUhLmFVln3VVA9B+uLP8FenNC9PsSmA+hpQk+yQ3GOcsy QKzDpAi4hQ7fKzk4BgccAaT7kjcsD4H6H5MyukByyADSZynsgERFM7udpngbPJGd/Z/w+sNK gzzgtewNQDLbS4s06qIZPbuHEEH4QUXAZzQido+B3fz0Ee3KQ9CRnG8HOg2+rqfo+536LZgB iPGpdICWYkQuxCASw8j3TaD7EaRPvD3fdInxp44DY/FIdjVsUuLF4DeublqIGYQhgYOLRAsF 7fieEmopjT50DK65o5sV+TIF2oYfJByBwaTiQlCaYSDh73T2fHK48XjIBzmR5WVqHweEeeFY xD9HgGBcOsksrPzOrlqA9Nn27d4010/3Hpc4K7nkhgA0Zh+OvkGgIZ96ibJUaaAtEO+G6I0B biW9il46lAdda2tteYHns1RBNtnhEdbHNNkGb5B4NRwUzCLQ2I+saWJNd38FS+5Jw8hL9nGU H43K4dR2oWdZhkx0iCQHSZPtNUjIexlRh56UDKUS6zkrOMQnS2rraoglHN4sSBeoS99zJ7+3 5cnqkG1n/Z+ndeMvLB5ZfOq9lY8rtspJAm7Vllqr8iHbC/tKgMUASiGMtSqQrHEJuc+PnZO8 o1/+B6gdXH1JVT4kG9ebPpnA4d9r1aAhoayn501cthZDmkYh8vD+4SSJR7q5MUfbYc0aGLmp U/Vp3f4zzGY2u2rvNTo8nODzdHiIV25Wqe4UOYzJ6yXqxVHBdvKBqn4fwOukx6+BNFMuuI2n o6PqpNlIbFjo5iB01p6cxjEJQntOEoCik9BBCmsaDb0GAQ2WhmuQ1dqdarKJPK7hlJPcH5Qx 9xoqee5JYkwtlMj/bD69sIqEuxGHe8/V/E6VyICP1sPaP8MV/n5p1aqFpMwp04llNOUKv0TB GPUfz3evrKZX9XwjYdBWfstvH1idxFeWnsca65CbMj2ODUjdTHOLX3xguH7djOKJtK8yKnCr 2O7/HnbhZex2K8gA7HNjXd725l6wLLgp2bBucI09bq95zxvi4+GZ0e/d76MfY6skqfo9KaFG igF/9LrOceOeHnG1POMRi1Cp1KGB4cLCbsR6fCLgSiBzv8GXyK4MIE18RHmDfU/uMW8Azz12 cUMiUwvmXBSl3x1NdkVCO6C6oF+310bbNh/o6tU4avfVOAozQi4nHjhT2ZlNQWN4ZSs8ilP/ SiI/UC2raxr2nVPA71yyEJ8q7xxHC043uGckLq/ap1f7EBslAwjnF5vWI+pT6wwK5ZfI+mTX 9DNCVyd/EibDmjFW7A8AdwPtyHsh18Dq4m2XbA+Im0zskHvkFdKjnC5pK19gNmiIQzgxEqq+ jv93SQol9TAceJiZmBW/ZgGNu48gMyHS7T9jXSbh/pQP5aKWd7gNkasgk1lv+VJc4tD/BVbt PZiYexnalyuU8k73u+i+0W7+bhTHTJW8AVIaMSFRSO/xXHcpYzqRJLMq5VCc67OhXqswsKse dE5IcZu5+Im/9SiOPHmFGRmnaOVUQbgVMWh/dzS+8kDH/6K+LQVHqUUAvGyKicFI/t/FieP4 ywxFzv261T4L7qViCFTj6GidDdgWexrehJXDF98gZspLmuxSeEULV2mAZ2iDo1PnvgV07IxU LOTLZbeeUuZdjIx7Owg2lvWklq6UjpQ7quBRAWK5XVWcNvUZSLg+RRW4B2kEElv9BNAkP2sO beE+JMqKuhol4P7/ZnjUdkTqeho+TvUYALO8DHNI5ntM6IIJnK9aEI2B+I9kUitbuezUDSzU yKt4Ct72T+7ecPWo3m7NTdNXGdFW1G0rGXl/4iGvK/toj3uODaem4ZiLmgYrIktzBe2dtOQE cQR9Eh6QtvyEhlz35SyxEAd2NcqAOelDE0LC85r642f6VFXv04FO7MU2qOwXQzNS+VTGr3+j FXeTjgXE0REKV6XLNCLL8MBKyj0QyRbe3M2gjpZbK5i/u2IHgaJWo2tcnIsDcAkHsREWhz66 zpXIhnKtYTHMo+a/uRwyBrfKj4/bSAEWxmPwG8rhwwufP4CVe76Tngb2s3C6X6TWkWsUGbLk mG65ycD7dK60aWkPxqzxOc5a0YHlRzAauCN/d2QhB7MyN9vo5xAymieNNkOgEJRzq1bqPcqk lZBYnTzgPKiqP4spAHi72/JzWPAGags48GYCWThRUCpn2ONwvwXSzC88x5SC6JzJV+n2EUgq S2BeRlb8w6bU/G4oAPRX6NdUBijB+SsOUYqXklFnLS6YG/dQfl9LqJoAhNgOoG9Yt5pgtWBV lbyfyrjPJ8NJ2hotUeuaKQHJEBZxudDHSAmDmXKSurn31lHqWiTiukxpq5eJ0hSkrLMEqD3P p1BtOVKsapNv+TjQLU9m8mEHgf8L4j1ttk4qlARo7tzxkjavkwTbJTPLVbPbxEkLcdyh3RdP Y/DrchfkEtAjecVUHQ6krzaB8VkOXrWgBYqjHyMk+c+P3fxBqcGhAxYH48gSpDhkdVTzN65n seecigAdCHF+ayUa8P6NU6a5+zJJuqTZvNMQJH5woxpYFfIh/2cdMC3dQEdd4+GjVrzIfrw5 zMM+GJCZrpJMmBnNnwQZU+f8RMECPdNMZWo8QZ0Fyfw+NyWyJlTpFVmBn2Co8+Lz7rCBP7Qy jI+Mh1EQW4BjzGjAdmvp+DYi9hBuRmf5boCSfJJO3GF7p+yqLLtVo5UHgZbLADGH6AhLclbb oiWxmaZ14QdEzw6T5/M+nTGOQEKyQdq1+8EX8AF9e294a0oAb5YXxDUHAxPKdTK4QUZamlfy YXIR+h2+LqJLhkTGLZBGy7CrM9UIom203FlBNDvM5pPZKPFaSvAz6O6fkRIKtxrcSysm1yOL pWRgn75f3KeBRQ8Py2T8C4qlVQbix5SGL9OFIgiWgI3574QxpUCkrQTs4kVv84rEpvTPnrT1 ud/XBG/vX2DyopmdfbYv8uinshhfF26152/JGjBb1DD61TrLOqdjF7ilkFOmYbpNOBn71nW/ U2JGeY267KtvwZ0iI4z4KByK1i8Sl3MgUeQDeLwxcwe9e2e0zZRe/41a91s4lRNdCT2tJykt p9xRXallMHN4tN9G07/X2Ja/cAANRify+S03uDEBF0uILW5aK0xBrgqpo6jwHIj6rpEMuuRo +JH2dFO23Te40mtyfnM3bPyeM/bzP42GCdEhI/AoyeWsphikkpDMR/YOoYI3Y35RgccG2lWk NEYEIpoStDl78EmoElhbXN0W0SHV7tv2TQtUwIG6KdBLrd1DJ4yimYeAkug0wJworAoTqcSP PNcoLj2/ZNA8xjwaYGj/PQaQRbiqJPPZ8Zk9SLdSxuKiwBEyFa3ZJmAuZ1StbZh69WUYoKqx 2KLu82s3JAdHbPmiKftAyt5BHT7XieYjoodHx3Ws5H+lDx+vkHVB6ODEKYV2MepC3B/i90C8 y/qz/uvZ6dJJ27mq7WAwhDVmsY5KwMchyHitrdhAw6NDjRfkA+9LpNJZArJhDY23jGb+UZgT e3irahTbWfbhbcclKeS3OPM2F325gRkAVOqkX45cXX1SkvmlIUqyezlHI69qQkT5HtS6gCta 9ue9/W7ZVKfXPGWrKNZA5I/D1HJfnyLdWTfqaokbpT7FGkaNje4jYHHKLJ8hV16DEj1NX6dy aTrgeFDZu92/q/KW55yJivWW3iLebI031+fQQ8X259+Xq10g4mynWktn3SIiNyn0WZIedvA5 Vx2NaLO7vBPk3nj9vYR2fpk6pA+xUtW53EPb48uMrN/3nTnMyuXo6VIQIOdcvn2Md9ewvENU 5SfpC1DKHv5ZwzfuStKRSIVU2BUwpXMA1xNnVl4/94icbWd9QQprGy51R/g8e3Jd7uFU9/oY SnGj47Nzw3STBRj/fDzuqeAvZWhM6C69JjyyXoLEF2Q23wJlIzms6APEr41wliKS1QBoJTuw VvvU68uUYlbeeaqzV6UCPZjePhtuPk2hxKe+0u5/lRQ7fcrhYWBIF7sucwIUJMdqSJec8U4B 4H5kg2WMa07LdT1YouC+ZTbaaE/FZscIzWloycuUr7Jf1u6heEVAC9SB/bRYssg30SWSWlWM 0MYE9J3HT0SfH3HLJcs/5kiNQsfnmTEro040Y7QgS+Xtlk9eh3p4E8zH4BuIwlaE3BeqsBpA WiZd4/EXYix1g4G4trJYqJsU/OQ1lZfaUtubNu5zSGfDdBlg6AJKXY1inFJdHPe0zXaMuEpH oBegf5WArw8CTzNC5v6n0BAWS2ggmMDIPpObu1ieClFTOzx1nmoYXzA7DVqT5JKtDV2ZFkj2 dJrDn45MusSv2P+JrtaFJ/gB8I1Sq+PnYQRvwiBSo78DC+YqO7q+QOnEL52/Wj2AbHBCBVII WVMvrx/huZ39vhRJRY/kJsoWcYRpbzVNfL1bPGKtzG4f1/IfmHji18EgYAwDf0TI7Mwgg3ic VCWxcKjYsea1aQ4qn4jv82ixmrqx3O2/ovNp0Q7UVYvTirEZLoxRUF+sum+LZobs+tIrqvUl tX7ylZkGx/G77hzdRvQ3plkHKOlTUZweKmw4VL+FTuc2r4TPKrP71Ff+zVbKrAqPA++NakrX X2Y77dApI0mk0NHpeojAyhFb+PChbEACZ9MbZMKoG9siYFUV00HiiMSc4OLe5lfMfBie8jr9 KT3XVziAF4bJXNQdqd6rNVCRT4xz4QNnhXh21J6JTR4LFhatVLzLPBx6kk4JI/E2A9TS8P7A P7JI/nJDCr9VSEPbWK+VAnDYBFc/vE2OShPBo4PTdvzCy68oJFfVyi47tkHoM2Bc18XAudDj 0OumUGLBoTSPzHdLkfjRlJEUKzJFY3XB/CYE4KPZLX1mXTPlWAnghjc09b1fwhu3vGAMUL9p CnMsbv8OHJ+RR8At4LmI8WFkLRYVqipx29anobivJaGuH3Go41gY1FxDECRBQstq7941ReEq l2uWWBkRspg//jLvc5yNf/O/tBXrDuyaW2PYuhEBT/FQ/mtXc556qYVWtN8p80topwvtiQaw qjxrzMjjZ1DjdGtN+AzyrUfYv87nKkviiy8BCxDyIsJbI+8gi9L5APuPah5gFbSxXcqmQoPj JLMz2qGvCLmhFExqt2dlAHgRX/rXniUPvTbcO01AjVLrD1MP6ePtwLLWSx+Lul4RTTFAovI7 2fSN7z55+L4ZJBqyWMFBuYzu5G778ARl3JZXPGlLgh181lRYkWgnGo9M5CTuwwPoaF5cN+jK tp7ew9BNjGL2qFARmzn/1wq2i/OWzWCZzBzgeIfCsNm4mTxWgnCkhZxHgHbKIjF8z5cre5qU 9hSV3La1anB6nKTK+ZLUhNqBwi5VzV2aLYVX+JT3ya50Ki3t7POX+qHHT/+gCSYRu2Pw9IVa 0TKnJdwg77QNGCiLuP5Hml0XTOVQjtYSc9ZuNYkgcm7JG4+8I0vz2Tg7CtdTKqAwslHpHlSm fLZ8zFJl9RfTd9IPL9OXhY2t/N5tARXfdL5mvMsSLeCANVKcGEa2czeAqWaMtQRGaLPJo+ib pu3JYEOHbH3cjabORnopAu92TPxMF1ewsc3OOTmGsw9iLBfWVH+L8u7QGQeRxe5c+o04FeyO pJ5VoYvcv9zDN+TEDvMRArMYUvza7mQhW8uD3gdiTOJI89I4lqq6WEFICn7zWtbeDuhMdXWR RxbaD1ttctKQF8TX1+rbx0it5HVjNzd3OGhIplPvmHyTIIuHFPC7oWK2MFl4daHktdWs0dmm y+gCUJ8F9VHpiQ9UaaLFegT9nhjq772tYWRUiks1Swq07N35FEtVeKz3pe2NoSoh7tXCRT6f f2Sxxgk7pfghNWX509APr6/Gl/mGMZ6HFjaPyYJTKgsuAdn9Y9elL+/0PWSLvs/I+wVQBC37 JP+Yvu+R9auz06q57yVdHtzJsFabG4girE77bY2iAofzttcklG7Pb4s1sR0ivd9ndQoXyguu 2EjDtPGUjih7upU/rCRa0YhByxmuWv3CZXyfqOCJK9141zCyjJwi+f9cqW1llIku9BeZlF3W hjChWSErJJ6XCD9Ld01TKXA2yo+dxQtCjYQ5J6E+y6ZhxUc1liA3k5r5fYB80kvMOTQLBKV4 10IeSnu1Tec2PTD9H1RFc3TzwKb2q3ysxuBWwX3ln+8aDXH5AFDpucMNpNwZfxweOHCj60SO TlExWNa/96SToci0n+bC2fxtypW2IcZIb36tX3rVTyqKl5A+Vpfj0AH5WjVgoMzJI1pQVao3 jnG3IPU3bhwYVbVtQZoouMYzWTLXvyytgnrT9UQXJEmqwVwXGbnWN/bkw8g8uFqo5R8xlTT8 WutonCQz6C7mlD0Cz43CR9b7yHU8C9bJjZmNpOngnDPLPfY84sQ/RhTtKSHorlHAUxblXRx7 BOX7OFqFJQ5xF43SH31FVVqelY07heSs4wo/E7f318yDZzWGsz1XLOFu1IjSidW1Fd0MrQh/ BUuhJUhWJInLs7DjlUynC5iOhovxAjXT1nS4t+gIzDiddFt7mtRqbSfRCasJ2WlOysPLCaCQ 5Byj+Yd3kuime3JZTcJ+ihhGhly0MPerDXDmMakfKCrORWyjlzrBE3f0MHwQcbUltEHpbX71 KMx/jxa9wxnD6888DUHwCd9skZMU4y/26TTurm0MzXOGBK39+VGxcJ84ZRpA4UtOyYG0EFkp rD4wiCcXrcC+rZNyat9eq+rhwa/bABwJzlz/+QEGPeO0RzT4caWWsAPfoSCpOE5ZM0QoncXU aX9eGgi8fR89ZQ//q6PcBSxkO0JB8DbF5Pgx+a7ecGRN163DPHo+bICx3jBSLFocqygbF6hz J6bT8oiI2AnhGLIHrnMTtk/56XLIprJ6AXvpaeZ3C9bdy5+Z3oL2Q5BDLIVES/cq3sNOJwhT WzIr9UbjnyjDJ1+mR0tcw8/2VkLOGnDRA7WyXhOzs7Y0U3gjg+F1+xXVt4VBpjn1vIKo3vbA bNWbiWaKReVVxtb0/+xKRdX7HQTm/oiP2ELSKWlDXmbkw/wtHcLlQPXGCf5XyZi0GRZ+VEs7 O8fNNvL90eSdUC1GESQl2f35a2sFuJiAWLLa9PRhhP2BTG2ca4+FjssK5aRgnNZZYGFdFSCT sUEVv/MbUHjZI6BtQOtvOLGuHE43Uq2CBmoX+mcn2d5YzvgpMNJ5DJxidKlUOwFkB6JDysRS 9QAxDQbBg6hz5uXFx9BgHOcF/ndMounZX4wBmuoWL2/Edlb4v/MEaIVZYt5MlZHk6utVUP08 FF9iGPSgAfdvmYsNMb1Zjo7BaJq1YutSxP0bqY6sKVJxPLXB3DcJN8eydBx4EEiNABQ89rvJ AnG16Pub8mQpBxpWV/uS22GUbj21wEHi0a8SUCoPPSaG6rEcxqDj9bIwdw5yh7OeBwwjLK7y alqICaf+7za8nYdtAH9vi97rYS4zvVgfyfa7IooOSGKcpd512Wz8it1K0gEJgFsX+jA89WCB 3CtJI7eFxtHLD641e2Zf8mEhRGfnM7qqqRZ944TdX3tDYlaaxRLnuKg8lQfMax+4DjN5sMFD jeT59OI1ZsaSnQi5dDzHWSNRjWo4bcfCFvQ849W29GUTC5KAdhOJvRWS0HNyMHVhAadTfXEX L3CglcSHyU/lmwyrHOgS2t9CufCRNlH22R7dtXNnCYiO6O3LpuMElhiajLR+cIHeXSe2Sktn jVZR0o7crqA89ORI5GF0/76d450snY7XHcyVvstYNunLJy6MLwEBAShKzJG9KpAxQs622ytT U9ftsRO2GZ18WFQ6UpnCo9cJ3hMSKgtdjypTEq4hGy8lBUaW7GYx00Kz8WdYYplmtiE0iISG A4w8UR3VZWNOX9TpKoPZNI8RV60B6xUP8M9RKev/okTHXzrWzfFMqCNdzHVXOeBAGTg3N4J1 x59N5cCs8v4W4yMsKj0bWyOS7asF5A9tbddLH+5drmSOUzpGQNL4wzepa8IW5zLLKN2WQdiR TYWzZ0Cb0EaC965QDoTEt0fgAq+iVEPwQ8HP66Ho35rM4eKAdiKgHpjLublO2t2s9gsJr7Gc POzuOrz29Gc96c3S4SJ+e8fgljrPwz6Vdmi9lNOqJ8cF16uNV41rtm7jDr6sca4jlsPcANho +fEeLUW7in0E3MLMNogDr9w7pa6NrjDQF+8Ry5ohOn6ge0BkU6/Na6Z5g01swOGOnAdua2cZ nDg22/1fj/4/1BE8xCELRzk91H/0Sq0ginu+ticahvaMEwZXRKNlMSOl+xGl7U9pxbjogXdQ 25w4KJCKZuYKXh+8SUyjPR8kYrrnn5t0s3BJV4UNBSeJELDa/Iv6yoGekgvSnctN96zKZ7xX hYkG6BvK3AGYUP+7OtB+8hIkOAEhyWRLfyyrw+dwI/h4wsxiLU0VqGbPFaYos+JsWqGj6POO CikFul8VtY0fjNNjjutYQgIUugAD1wf/DWduxxFCdYHJck/bgSvV2h9esuMvT0YnwXyXl/yN hY8XwljYLXMHV+QnRRO7U5Q4ox7WPOxUTjVSGHEUkqmsxNRoUSSTOXZzB5jrN9Lf9JgD7Rgx EUp1Rnf5dOrTms6yNu6U/I93bgnPSLGOCnDL/mvEmUGCO2Gk2nCehQa0cG6o47VYxeKUx3e8 WzuNPpUcwtmj/o3RwlYH3maYXqX6qKlIsfdMPINRAT0PI0DH4dnMrxSyz/rVVLIirHcMNJ1x LCWx2GyZ14J8J5nyvSlaZtcnvgXHVkQEyOlPgBWQT6XDpur8qnKt9eCg08A6WNkEqyPXDmVu Up2YLHq0s56vOwmDD/uoPdk5Ltci4fz4kZnY7AuIHgA0kvw/9rTb8mSTXpjfkOlD+Uvgn/WH X0aaobl2ho16giKsUGwiwFdtV0HZvq4Kw00lF67d5PhfFkYLQEi7/Iep+bKs7ojE1GM2CFMP Q4oJsA2nXv61n3fPkxPEZ3fnbaHgO+Pq48dMlsvIDe5yGHqKyabWsPyi9cDo83cmZ2m5X31b 5Bjh+kP8uY13dVKRsr/6+CXXJHDvigyZEpiT/hAO7/CpH3EE8g1lTkyf188GVgRogyPM1wtd 8U+8vPJ+jPtKPZE8iAF/Rhp8od3hjZ/YHg2jbKtECd1CD3LXhN2Jy9y9Qf+pPFGeykE51FFg 8TDY8DAmsOiMvI9cGwS2y5bp07bIeZiBjaInkPFKP6PY5fD0+rTu4CEqjKHZevXhdmtIdB3/ VKvCDj5Uhw3iyBuS9h8+Cur2/CKQDOtx3J7oTH/vUeFG+LLlDIeacLgc1upM0KwaVjk2+V89 R6dL4BPnQCHfxQL7Zj1JLAB2qUxyeQQLGyg1I+ICQCHmC8tQvMLA64rhiIGhwwY/2SPT0B6U RBMiigdp9MiIuSfzPnkGt5YJ58m3KwPU4xm1LJ2uBraQkVKD2qYYcd9HToMhWWC0TQfxe1Va tfLxtv+MSc2kFgPewlVD2g9Bsp7KdSWBlB6gKJNffGr7O/Npqn+5dg+3WuhJVpCHUBjmmDFx 2tYmSj+bgu9wAWS2OY/RXDndhNjhMM1Cb46TAMUxQIHWNG4yLPGwQmcQG004IgyyHH/iGlJE pUywP22Pbzvvgob/MHz439Kk+7Y5eYyGPYJdvgwTmFU+ck0GCAvuN8t1Qm3wQyo6wSaLYQbE IHRc+Lc7eTUkJp9HHv5G+lGklj6E25KIQyU7dvCE6OcrBfCykWFOROZ5DIrNhFYNdJBqZzUz aNKoZ0wQnGwD7qK1nbs3XgnlupXYRQW7uoFYPQXKEt+1FHgCdDPu4k9dvUNDsD5iKa510aRC YgrPlNL6d34akfwvo5Id12YYIhC1VUrK5Qn63o8uIUCVw8R1G0VJ27vTfegavXk3458O36kH 13ya3jajj9uC1XU5hmQBNhqRQ2swixVCf3SzdtukTs0aXvl8/MZYTPteTz2VqCcKJ4eGtTCO kVrQtzog8+0CoKM0nv7h00+98N9zqgmAFWQN/bW4z/JezEG659dVYoTjK8WI7mc0vnCtlSTO ZqF7pV2HwtAWYL/vgYerwxZHgEMWdN6K30IxrPxmINW8NnTYqMu7Ic0wR3gztgGACqzm6zMx aXGpa0yrqcIny7Dx58BoDq5bPWSDYw8RWy9WFstl/U0HCw/IgBoNRNc92dnIPTS2AqEiMMWi SIheZIEWmBa32dG4/cN3YrghdMIPF1j+OClfUI0krRfNvASHF30/k3i5Z3YT7RgK0ZMPIyY+ VCuyiPBZLdNNjbyDUdxAOWwkl1i3QjMqNdtESd2ewjjVVb8m0rLlxgmudnIou8rlNrkzcX/k 4l3XahCEun+boOtvEl/vLfqlMXemSYKwp872d0385bQe0hyeZsl0gHCL6/PXPuZN7D5gvW7i om65F2Bixbf0Pdc5sZsYw7QjOxbafUcB0BMGjba0Vq4mq2jsQcDYCBN70XpldXi56djA24RU uPpeE6caVjelEjve8hVdxm49J62djP4f5LPLw/FQzVPsotq0ZvIuEzWR0bTpkvyIK0dh4e62 1zBxzoZnZSxiR5sQ5mP8PqM1jxOBiPuJcC7kZziXqlSGsgLZiRDVtxeKzzo/JWEVfBEDIgox XdnoBrJ2Ev2bDvQHKxJ/cGxsixQ7IBaoc+dPt5f/SjqfFhB/Z8b/62VD/a4syb6KY+r08ZVL Jwv2qscHjsMg2Sa38Kw0NjydJKsA4Z4avNQmi/EY4H0e5ymjadTL6odd6kprh2FYfKOIIj22 3nNYgHDf8IG8M9CdEDlU55muYOs17A2zp5KVmH9J7SSusQjRzYo9zIGRNWHFrNJhIYjwzAN8 46O+W7X1xGTM9v1CTo0YWvfQgPRH9jCZY/L88mE2ItTJh53VTZhuk/9+H43NBIvAFHmrWrKO YW/OZCVQCYz2NZ/n83TOHATY3BAbNzGdJlnCWiZKJKPIlRPn4FZtH9do0HK66tMimoNyID9D 8WSuuuMFYT8jIKjRAmoJDWVGH7Y5Ih+hhg7zZ6RWAz/f3KCvRXcKaeg2X1t0yQKYdix+bqFv N2BpOgcWQ1x8vtm8A0gXEtHwXeURJGnXW8c3mZsWKJDUb3SxsX4yimzxUtut1ZcqELNqRdWV cSuF4Ll/wkr9yHEOPOc/jNvw23vi6ROC6csJ5SaSxr+zFFKgRtnf7hmWR7L6oHbLHUnkAlyJ qZ2Wh2T3HGqdQiGQv6RbqJeykUQhuQE2WtayQ7MmyxSCiTRRHrf4HGUMiDvYB9DTbDB15dE1 Pvx6BQhxfgfAdnNfKBu+jDrbDmExcNYiOp2Va0a6RbPbwdcYFlEPhbfyguSYQkS0nT2o7C9w qsHYucDWfiN/aQCcvDaBBQua4O80gRoPGrBQ8YpgkAmvEs2UQ6TT+qZrWnjbWkaHjPlMfd5I wyu7uZQO3uR28tJPMg2nHr/HqIIsSCtbBGno4JPLtbMKzAq4OV57cEajGnh5QpH1gFasf+tK X5IokOPn89DMh6wRuLdKgi7p0vqqG+FOFs/EiKhdQ6K8GKYxwBl46B/FApowU1EHjU0M4Pj5 /NQ7IUlofxkLTrMmR2uE+vgEY+SEOWzsIE4nRb5bvOi3Lj01M409E3NZNS9XzwtiNmwV5Ftc sr8On58ie5dMlE1Qib9ADgUBOf0knr672CGWszBgH2ar7PuIvfs3pXqGZjfEsIQYK7ill23K 8pFcdPoyDWQ6WqeZH5k03Orc8fMd32MxWcA7atOotPStJubbStY2az/rD+C9oKS/YaA/NUnQ FqTUMoRPeLQhU/SMANzOq9MN0QIf3b70g0g1PpUi/fvI2NfV2EWVUTJuU2rLhKc44sg4ziiQ X5a6/r8A42Kze5iTKDBrhTnIJh5z0t68F4w1kUeGff2RzWe0T1OXR7kF5QfDPonv7lg78fUb tWlddr92bg2aaBeeS0L98JUfDLUZdT98lNInDLsnw6Fxnnpvo8aGvdB52hBKB2mKesIlUa54 2mqVQEP0ppXZ/Dxfz7A/3IFP3nJNlVixTqkWWalZLlHIv570tZy90ruq5BzK9QYUekXUUZo+ pcyzVOANjWVbsHbdawC0Y32Y7OL+GcdP5ih99ZcCv6tWD+oxZAwUP1qeuv+OAqt+qJuSe3tu 6dRsqL0pIDG+yX15l09xlCYZMaUu9xKbjoYmr7DLSL8MvHC2PWLD2DYM+ubIwO2qSeELPJSE tZaZz2n7Te/7GVDWViTINUd3fO08Y38mzERT6RZ+8d3X3bseZTb+TO0m0noBak6jb3IFIYkO t9zCLPei+goqnuMfvuGzCQN9cTVCG/l3Q0fBfKT4+qwPri9bRYtLjGHYhNsku7HSffxCeNLK eoXMoqooqeKxsKr8L4bjE9Y8qwLerjNyZ0OryocMVh/lelQZ+pPTjHXytwKtHPmC+ydCrJCE Yv07vlkG5M4C6dryXuuFAQYIdFuxodyRxlEqBov+i8A50MbEm2oyIl+VRYPVfl+TqS0ynih3 d0oxpobNhxGBM6pTkXFPfTBzgoBp2gPhdx0n7TsS31qM4vijoUkPNvpYgHCoJIgxwCKBTpAm AK1Z7pb7zN5iCl9ImmqxpcRRha+XCEUYCsYcF8MdMnn04qKjpG1eThUDxKlHcf0aULDqaYAG 1xd2Mk1EhHTwvX3BmKQylL65dJ6VpqyqurYsK1Ccc/ji+dDVp6s+UYHFaWTelrKpqY0DXIXi n/gFuc5qH0dsET9tztHEqpIoAoy3+Gb+vZM5hbFFJopJhVwXiu3XRBfl7McPkgnT1BnM0Kt+ jB82qw/4Gae3vohUUR1BkJRJVC2IwxibZ/4WFA/fO+fJh8xjTnJu+vEAERNyV6l0KUX3tCY9 o3Gf7Bf0VEviiOUeUMBAEP8JI5ScRw8jziLsQucjYL3sEP+KX0vn8Ti6sP/R9oSkaLlEvMRl St2p0v6aRLqwYhymOBKlkz7te4GHDC3P5CjR7mC8wJ6+y4t3ueees6LzjDYC6yJWHpWbvVY4 4KDMkpEQVGl8IOUwKHwRfYty2pxEy/D6lMF26x/GStmGhOX3pbXh/KHSZTScU+0nfbc4R+c6 HAjmCZOum+NmChHGZrEeXB8uCmmR9IBnFC3wTaNl2O8j6PBF0QgCDufn3vlzctF4Nj+8e+bV uqgbCkZSLWUq1ZZoVZjdxRcbj/BF4Bde7cfxdG9YcTk1lKdRp4GDNJQ/kt9WpotIl9CLP+Fv FT8xS7680KiIZrU8EMxSmCi4oNR+NtoZ1idFWN/qsKH6MdfqaEXokYvTRrAEUdGpOSBdECXI drKihqd3dISuiMyH2L9RHQKWbhQbPFJ5pmduyx02udMHTGdtedALEOrgsKIWTeNLHE7uQGIr kGCrCc/FV18JgdTy5oUoarHwkfGobhaVvWfG6/8wYV8Gx25nX+bV9LVl58YdAF1hn+P1UFTQ xw/WGthnaS+UQWtqb0A439oweDfikilxElLMUC3v5M7eRrVctHihX1LsaaM2czpv4e4Z96Lw TEnBc+X/i7Grc8n9SBBtSuleOKdLEr9CEViTOoA+7rqOLZ7mKer+9KrS7xrW03IGZmRfMtjU /HBduAmb9jdS1VY1koSt8fvRd/Nm8oJi9OjG13TxQiYC9q+aMoozUPMCe1Um0MqwdjAZOiKV mlZ2xf5o+UTzeLWO7LL4hb/Fbzb9Zw05W2X/rODtSvKSliaouRm/0zDcE6ygdC1y0mjTZ+ew nOIcdZ93qDrCwaH0Xydi8RKyhzMsDPgO69ApbMK5hbfv0NGarRGZH0zT529CCvdCJhzyBWMO rh7xE+7MhVSnup0YtSwOxHq+F+mS1KEhY8aHHBSpnRAKi6UjssTxFH68+Qa4Wiy9sPXtOczb GmABatpXfboeNJ7XKkTW0dMjGP95TmKet6RY3pqD29RD8suLvFW0d5Bl8jGwPzBbInFZ4MCi Ry4pV8Yj0EpJwLB69wIplMkdtLwHQpIuMceA6pRjBQzRciOLGftO1faS95D28aa+n3ihw2Nw 4d4zddU0AdgPLqgIOQmtqDEqlwz8Zu023JvmB1Ngev6z5XplabFQPRNyVJ7J8+2/mB1sl3SM W3V4gv0tMCTbrh4TbThc/4bA4CFALgxHboXnFPC5RxArf6Zhhc9X7JlqAxM32PGdI8jI5LwJ jRGDHZBFyMyaxSImw3yPfX3n3ZFhg4T2BMPkbqUdFbExVlmIFzmZO4l1gdl1mXrBGTjn5weG YcsHdWMGuopcuJmIEBzyUGMOtjXYnfgn2ovTInEcOLxb6bhOhvzto6ecBrPOS5aTktNOHJaa drcxjx+cazv7PIcHJRvjt33ffDqvfpeSx3LhDjYlosPcC3m5HJdGhoQZ78EDrzID4PvK1ExW Xw6Tc488G4oAWdfMkn5bh1n9eEEVjNoSlqx9IH8Gh0+HKynusWqB1Z3z3qGheClbgXcAyzo2 DWxSQdVpKOYMbaV1BsxmFoxwBwP8SbyGdwNY2OwgIs+57P8qjLfBH8fV9r3gWxGNQb7oXzeT 9tIr1ASt4CqP8ysyIbwZuEm5sp2tv/7j4QZE2v1x7tLZQV60mPgF/m2WtEewtKNkBUXa1ANH 8K+a8M+ZEXBc+BlptaXVkoPMT+psJDpVEUEPH7aMMnctv7PKbOIlt7xQfwaO+jXBgKI8SVGC h6iBqSti333mKmlXvj94uy3blq7xEjwQ8khehDHavQnY7QED5Xsm+UAP9QyijwXcXJdskBPb Xt1sAqj4TWFXAf6+zi0I5dosfiRoRILsiRfv+fgyDiy0c4LQ5khwLnN0YA2UVwbX2RvjjT7+ J26qzvUguUtn+qa8JYvs3AcV/dUpITCXOfxI1VW2V5Lusoy1+sIfX+QEjpC8qM0G/OTArChZ nxsu7sMOWG1yJXnToFkm3+OxlBafzucdoQi1aPl/xpVzCkoC8yvjgZjMsGvpguJpsbN/qovp YZzHvNLlxYXmvx/8rxq9Pq4uwOMoBd8e8hml8PFIvVkfoN6DvO7uS3uuap7xOSJKvFEuXYzq 7KWIyvD1ND5VX1pxV9cDB5+IDMHaPAfKfgvcZFsFBYp3YAbRkIwVrXmBH3H47FBrcJrhHHeG 11IYue1urW8VWthp0/Vzl2Nr9UECyQbisIvthicCoel/+ZZLHYFYhqFMppB/p2hnhMUfpxRP BfJI6ehHOOI3mKIHH2BtbeHZwobScJXNWWZnd9I7m0S1ozR4HiuVrUIhmhWaz7SRd3M72FWB 7o/ztzrFUDsldD3vssA36ZLpkp37fbR/JNHUKIzvifR8v5VQzSZhiKgdGAewd7Eh3U7zYjln 8EjfJ5bUd+GaqRlQVEZQudRzrW/ZVdd4+C8wLFVjgg/wdTK6CZSQJjVR7BWfUnQNErQUrplq S4GdkS4EPMry8deugU0OomN+7MxLMk++kJd86z3fuwF3V/998/N6AvmESAm/3CBynuIVv5/X G/1vQ3SY+CoUSLUse67qkWa6d0ArmUf7RHS0RInWoa89Vv0b7GseO0dYrwVIor/qgvB21vDY dauA6obSoZC+h/wIqmXEa7r7oFmkU+q1WchWOWX7iZWDen2m365X4lyj1807DscuMbquoLor pl4EjBffMKDxmiIDrTTAovfOTDXOqxRs9R6mq9SwfSXrRxT7FVU8f4J8SqPVMG/IBuY1bAW8 eGRAu7XQAt5c6dtMCsgLkBNeyyvUTaDnvXTnzRuP8I7AGJ6t/6vTMtZNVJfn6A00Z8y/ANM2 jh41o0mrqKqTuuo+JnpwPHEHvDCcVwaUxFTIn/4cDcfYMlGbNWuBhJxD8TEKQBYI9qpjzJq2 IvykyfFKYFcBBvZZU3kfJzST3ZrZgzaVCWlxvUaZes8BqHyi0OZPK2sT8g/jWfh4jHGnq93q giJpSjFmiC4e331cXxvJpTtTdERoQ+1rgVPUGUOLXEzZL6M1/XqZ+DxFChkBEqxny18RW5X2 b8PqVUXJtbwqiYhOr25icAJ50PMwNiHqGaNEFgCQlixU2fllPjBjrQe2dkHl9q4D1RS08qJa fjnTYgrFsqxVtJJUdiXEUdQK3ZCoPPYAxy1EYxI9NjQ88UgPiKTh2p0C9vGEPfD+3sPh9UcN wwvCKlWJ9fxNw1QOcOVI/BAaGE/dqb5fpz0SlXH/LhyvTIzkaaDSqw9i8oWB+uVaHM5ZUbm9 gVehWHS9mGbNJEZO2T1x3TDyeRR1GDWBNyvF8j61jm08WX/lrlUtVGXQUfxbYsVAr5fGiN6A u6WtB6pFdy9HMt61VswLGWSCSIcniI6oHsDDEnGT6oxLfUSH3UdsbhEy9uJEOYy6uSv+0oJI dsHvTS2gvkjTkn0NGycrXufft+59gmR+OCuK8cuheu4rj/Xud2mWAbo7yU1SdMRftG/by0KN NifLNcS+8yNlLXQEFIqvNttirVJXyCi9M2KeOYBcNk1RU34cT9lsfY7AP61iRvNXL8Z++Byo 8iLfxCdJVdlQ8XGAziO9CUdHu1t2iZXCRn5UExhEWqbNZi7PuIhUcg9CPEGvtvreip2JJL9T V3PNQQkYoPwRFCC2N6kPLuz+WEsybWCFnmhMKKYfMHGN1tG3BOBRU93GNLxblXQGaj311eqP BRoIOzGdYA01BI+UALN/hpkXQVhWQIv9X3GF8sL/Yt8orQ9OazIBBRJr3kilzo4AJmMKdn3h DKE4ccFbtYV3ybXR4c3i2WbtjDbBQ6ecesGz5oWkY7ZSX8FRVXBqgUkmxcslIp9YDN1oi2TO TzzLQPd/aEsHeLUsVLR6N+uMTO9o5XRlomdYgw48zzhgUnE3V4LH9NhFZ0T4ndcdaU+oVnrH sTppSH491NoB7rFHVN2/L/Jpu0mv2tRAX8s9yU25WF1NOWYHpZmNw+2cvvcnjN3B/ZrDVNL1 oXzxye46ATYNYCkhM6922X3XrPjszwHn9XJGiQvnHY6YowOI0qvdNsbkwtTtXSpJPk81HQbK r/aIABIx7nALOadPX2YmnkY6WoatwWrNH5SyyazmMl7VzpNtroyxoLgUx+GgW4IctggeK3ux hmvmtxdXfT5VpRDX3yl/VKXKysAYMfQAELeP5VGZhmvVolPfnaeUPJKhlqqrC9KTeTh66B0s 6IJdE+ScRn0CLg3yF0gW3/zviwjJ+ZDBTDmZj1zi3o4e+z0OKst2CT7mQPBPQ7ZPsE7TeAjG 0NbMHKGNRmuJZHAmOWGPXqV+COSKmvkRSmPbqUq4HiwwzG/5EKVnk7D0rdTfkvRDPNOQjuz7 aAMz58L9iY5OLQ/kmw2oOH1bIdqCzhVrjQiK6rstT/tQQBZnOU1mm/quKkeCHnJ6IhPZscop 6lBzpKY82DbzJlHuIOwat9H2Zrd1jRUOxJqrpCyz3WjKomgTGv5OU6kvmsm5Ogy8pl9u67hX 4xCZ39+9n5vDrB8f8t9qhuqPilj0ZGQ04+uj2cug3icz68Pp9SlV2irrBMRfW0k0W4h4nK4D AWCUETcd60lhLkoSw+Q6wPmimAQpuqNDRQoVoTasIXzxHPGTH4iwbWgpW2EVXRwFSMGlLxC0 1EW5gy7s00VPTgRcBA53PmC2y1E9dTySGeiSl7JtCI3ttP7WA+Oawq8EzRtFnavU/YBSlky+ 3I8vNsAIpN8ByNdRM9BDficjOLyEtHUytpfdmX9EusmwCfc8Xu/0KjaY9JJlEs8CC4IUCuuH whU66fbD5Ao0del1YA6Q7nB3fXOrCPgnzkyoGMo0BsNjKVxnBR/BNg4V9eijj/Xl9W1gyueZ 2jIWv5qU0zCg86cDvXc/8dmdyxGAy++tB+KRq2ZPq4hJkoBoUZK/djkg9BrVOC5dSwmttDSe 810QrgzmZxwOkKTVFgza+IParzCEYLQPsxQyxTNgLBYQPn3BS+8SSUqaJB1W/F5FXtRATzJH Oh+xMfWCb7DiHXTz85sWV2FpHsmsLgffZH7F0iUHmW5tb7PZJvpSQ01wuHtj6m4i1Z3adxk9 dqoa/Zoothh51NqnO4HYCvxOgq2F5CnuP8APKtjSXLe08cI54SM7I502W2JCbFGoi5ahULiR HtKdoIIkoaBQdHAeMhhMOwzR7Rdk8d+mz6cTor8kj/Jw+Y5Pvt8oPZU1sWW8+T4ZUdnND3Ev S/Cyw7pk1bvyvecLwUv5zYfllxztdjE3qbZEBV3fCpL8eH2pb+D2KsX7z+0ee8GBCMDpKmLi 2D35KGObRzZqRbh/PCiZNg2uAhGHOmmaRpZngmzFk2kYPnU8ys7hLeD9hEwkVyMYj65EguUB /v4VmuN+s0+/8kOxdVAJv9TQQskeQd6Ly7IJfpHBFFoWPc6v8kzKALMrU8D2sGJjFt8zGe07 0I0p44HPfVErK4wP68MXpVTk/2gFw95uTeeFzqJkcUAwHEk6o8MxAG+qOKzph8I8C8ZSJ5sJ OsF2CXQEBv/76ZcrQ5XJWLlw6+7z8GtEmTN7JRZQ+29wdSytQldzKTY3ifBVKvt6sb3glsLV fTHLjgUeWT3cpHL/n8lGIUqFUApW9O8uLgu3DB4Ydj54HcUdgzb41lUGSjOHVi8Fh8lbyuB7 UKCqMCY5LdKgXZjqs7kbJciaLofzjQxsr0n39qleMn0ei+7twWkH0XPXvpMmmt2T5izHWvil F4YaLsTbF6ihRyT6/5WJw1PoV7tB2R1lWhQvesrFKr75KXjge9CwXNo+VaqcesO36qREncd0 doO6/htUwelIRPspc0BeL+eSjM6rH0BP9IMNeTdrT2zsrwCd4uY1lFxmv/GMwM6IQZap4xe7 Now9Az9P0ZoglVs/8fSC4OWvpwxRO+5AnstozebomYrUhF8tupopy7jWNM4b/tEWs9vVQdcC sJ3RWUo8SuqauBp9MNs/Jvh611yE/lJJZ6ZjOFF61txczvttBCjyO26oudnV3v2JLwpWNNZS snFu9DUxOctrivYRGCFi342u7seCAbrreC3towWkUo/9edZKiFEg5AHib9vlggzGB89jXogg fmLHOvSGgQGvrdC4ARkJrbYWwesXoK7moSZlYhJMDyBPGTXUcGVx5gikIi40iO+WgRJe8m6w srjFhx+kS2rTPYwy1SlalqC6NJC1UzHnsHZJLvcHIW5Vwi0s81I8tOe+0PpbLrCwOTs5soW/ AY460zlynB6QgwWvYrN/7goxi3EHnJWcDVQVvUohpZlHeJTi/Wf+Qg5fpc7hycIWu0TmafoS wHYN2rsT/R5xVmxgj1wUFYnVQMPy/Jul1dU3s1G8PTu7T0OyXphY5G5hai20sfcDacXodf10 vki+JgXz5ra/vovAKBMIlvoIlDZEnLPxXuCO/OiwFwKHmUzAsb0ob03v6x60lB1UjrhG4JOk oqawRius9rGghn5WFrmtabdxRa9/tJQYJ9TlMpr0mUPPAvxBRAO0xt0nB5kzBuzM90Y+i1NP Y4ZWcGuXRwZXWU/wVonyef/IT+Zp8P9Tg+bAR+OriyaPDz9TvoIW8u3Ci63UTqKnvWTS8aNw GSvb6TCN++wz6CzuYNpEcHXiQN8AQYNLrTmARIr5c5dLNTTxUBJWQw9N/z2AFOP4GS8FSXwN 0qP+FTbPIwbpc/JrtRwTJsb5z0bG3lwRUrrrkkJ7p5cu2Gibxl/nL+3CLhCDnuvIM7ZAR0mq Rs+2QyyyDq6xQioBiLUTELGTfC7XacSlfBDIwcWbjess9+2FQqiLetze3gWJukSMVJh+YIbH Ei3KT13xd4KMfz+OSwihysW5NNkneV7jk8na0204jeOFGBQ1w6l0jcph58VU2yYCIB3cMKUE cKecGDVS6KyIpEG3y8tBmOT+2xOV7X9p6uAJIw/CgVwi9MVL3iz4fPWxpDIWcpbLIwrRwfBn vBBwA/IzHI5PL+U6ukkR9A4UHD6UpzfLW3GupNV1UDBT7dpE8ejTEsERzDYacHK5L/rca6d8 AP3XLFpO4ulAAmyXCIIsWU9K1sOqwpiqEoE9sH+PtASBhy9JCUE/RBWO8mYLRKA/nogRT2Kd C2T9uRk92mffzv/kFuOUXX1SC0jCWfz0iaUxPk3CApfNapAgr4E6U211Mjd6fufgkrz2OqPd t21Gv7Ks0eOzqdNm80o+MqqzrfVeh0Ln4hNtzailN0ZnlaZSXaIUwM+vE3tpzyfkOwTxR4j+ TxbiKkIF3f8XhqUbB/Zhvwthn/m7KJZ8XPRGqZGHP/10cBDvvzdxE9WF56KAQeK/W5vDy6gH MKuq7Dj4ew/6ts9A/9taaM/sRImBMIyPhBrOOGuejb1JGje/5sfSRgNbEjwQbH01KTg9imy5 A23b7GdaiZAaQBe3aOiecWiCfShcoT946TydRpNousrmSGL4BLnfSD6BM4rBai2xqHH9icgJ dnINmK46WuKbT3DX+uGQX1hQHaLBQkWBGJCxFryCahHeuR51vxIBJUBzjPCi0yG2A0lajxnH mjUWvdD0KAZdDyk1iE4Wox1d1yFHSy+V4jtab2m9ntu4k2z0s4+Bktk9VVPJHiypuGJNgjVj U7MRpdOLBo3xCw1CdStMnGKtJLwdVCNsxxDj47ce0qy2IIbjgCgW8LRuQudz+6JMgpdci4Tb tSwtUPYs2GuAWPHh8OdCRlxCcmA7QeQ9TRrol7NOOw/cCKczFcWePYNZkXQEIz1GWDFJCKw3 jCkZ6jjptst+xIIwkUCxmBu5espww3fNERgxhbq08YbMakk2SBQPi7giYoRmCJ/ajXXAc4Ah eYXViI52QQlqirbyqntlSOFNQ4X3luQS7LlX1d7bCC8AOFrfGGRqvTM1Pz3i1O/j2f8AJQ9p McpINty00sMo7G6JjQPVYB8mcKvHqLfGkX0FB+llOlFsqPf3dnSDwzBuVDxZMmONfy9XqSz6 el5Ag2o0lkTRYXhBH7DuW4bt3+AhgJujXxq7p9OVO555hpdFTq+rrCJ7htSs+ytHqy0iBC+M Ug6ezqCSWjYzjx/l9iMuhNcWE4wZE/uWzUSXFanbGzCyvr1fkRMJzeGXD/0xE2Fax59GSsFH x1Amme5vPzei6qQsH0/Hp7Dz75mGEBbUnT3NV1ssLN39QB40wezJXPYPHBwKYaBliu0kJOfY W4doWNou4droUkt+kAvXfpefPsm6+UNzWBoMhCbybDONc8O3nfFi4FNQi+k2DrghpGQs6oUG HuwShGKIh3HLxaLJRHkkT/f7FC4Ck03KdoRxmnPkeYJkTiBK8p2PyAuom8XSWMrI4nrsaK0z 9YV9Wg1QEZJ0xrBHfVn/atj9he1sZjgbtvgKY/964GsMnBXtgv3mLd98awcqknbi4F8ehcQ9 0DQCu2dGgbRiOZmmTUnGebGFimRaDZoku9jjO8PyzFE/WyZt13Kg+GCEENRxh8Ic01eaHHH0 lUz0i3xc8nbJ6BF2WffJ5Yybjwxb4w1XIA8XZK/9OJhOtoB9x5sTThqatGEYfpt44JiQ2GCj jcNtuoQrjwkaNas8cI6sVUuWr+9k+qEHF9eAUP7CU6Dob3jSVoPsYgYYvU/3I4LZPd9/y7XV CAH1jJw6UmUBth6CmkHWomw6U0RtrATbYIJSUdN8zWK2wCEgJytYj8O3vbAgHc3fUjcys19s E5lqHQlM9JXHXWkaIUO+Hd3bRIzqtMmIQ88IfHuRmS96KBiSVHqmSLFpuDLIN3RuzJG85km2 lvXr3DUCL7jrE4OLsY4IrFk0lLEdEyFFkbX/emAUDqymn7Fq54LdB2GrcYqDbfSoYCEPdnAG XD/HcW2OW+Hz1zKNX/F/aRPYS5TGP9kWhzOLUcJxXmjDn/016gC9hnvoZb0urIbPUltZQw87 a+PvU/kAtDW+EHgdfK/bgCplFRZDmZ9DwvtpS2ZTKMSntGHMOnUG/f/hkZvx7F+xx5eW7IS8 59xU7j17t27+EhJ5BeIh2Pdpr91b7nsjxi7p+M88CiqWz4xlHl5F1pGxbjvqKxfqH+gQjBAi noTzGrp7gCLN1De7DbvXk3i0giIBTX778xbT0SWm0W3hT//Npn186WY83yn2xA99DCyLArGK NCsm0a4nIWG5hKG5ddBeXH0LP9EB3Wc1TfYQmSDoghDLbp2PTY4waJDkhDhO0a/mOFoZlZTG 2hCDKa13oTbqnucCd/416zPyf5IW+U6aobi2bwts4pDBTsi7ETKjecxjDk1allTH3eHGomwV AhUFbwVhFrV6taSak+xmOJk9lPTm+gY+w1b3vfRsvksQWhyc9vacNAZ1wrPwJ8tlz+j4TLnG AHSx8+ujU2c48d2ZUFtNiT9PQff4JPRG4caOZMtKsmeH69vqApxamzf06GQBPbvlI7qNP1Hd yA4PDTHdcjV0Ay57CgISh5Ej3rl9MftuIBVLO6mfy7k2uqp1IkmEyTDY/wNWEwp4uvhsykyT 9mVIIJ67anNq7ZW7/1vG/pH2L/cgxhrjbP0hP+ESr/dtVLoWSlfNZsBVdtAmj17pXNbpZL7D gYKAFIJw/srEDegwNe/WZS+C29X7OgeXE+DyL4XeXCcQR7I2/BgZ+SJ83rYPxXe+zCFThulL r8IFFNK43k4wZ9qO+5BhA+jM1BnIrtR7TcdrZNT9ZXZXYJ/UgU79u5EyzjMN8Ec15DM8YGGV 7Skv3LlY2gZQ+gLAvwLon98fbHzuxfcNyJfzTGB6f7zoyiWLnfJJLNfcRrcs0NGymS2E4pGk LYLCSz0ES9pKoU5rhzONTwmzwOa9Wlzi7azu4NN9XU10AQAUTKOzHMdhyZKVzpo0Q/A8MsD9 xCfBfxGzviqEEtg1nuS77udjyiKczTmgf9Y4N+iXeu1mHGwWrdci+tf8S04y9TQjZ8OXk8vT F/2lNf7m7XNwv89B9NK9S9RWo8L+RmC3qHnhDaI9K3K20WQK2E2xJPYV48M6x2Y8e9zVVAi0 lDwWaB9oJ49K3wseEBI5gqgseYGLWuwdNNmRztISOvM/ETxsvzRM6Csagn7UbS7iurHhlbMS igcqjFUuCG24PWgqRWQjrtSMXbrw6/Owd4I3DlfVGIBoMIOBMCHHpp5XpZYIE3r+zwD9UZNc 3MIn+M5wOYFHLHRIraqEDOYx6902tHfjINWRv1fjIVuKEWlAaaaUiSmBW9/UkxsVha1iM8uY WnDhk121uqHABBj6eEZZoRs6VKqkkuxd4rUBoIbyDYUM0MQ4AJJ6VTpmTkls9blDJlfe67Yv qreh1mdT+UP7cEc9B52DC+h3POU5M5K7su2UO6A+rx9+b/t6pQHNwO76M3fTTr5GLy1JgQQI sCoTi3XGRosa+0FlpJO5pNHAD9OZRRd1RcjLgJx7VDGcZDzqlEy2OvUJKabLjGPQ0Qdq5wIk H6UgRBeAxBBIVQHwULK4/pj2vfXkTzgdvPP8hTbzyee35q4c3xw0tAlrUENNn5nlQ4QqdCUf 4JfaJH7sSrpHfldKz4gt19vojkX2GbtKLBP0wWHCEpBy0HkbpOuDteqnyRhX1/I6Iv2ixQJ0 9L+Ah4v52hfFAXpUF9ykG1W4pEC7+/8sU4XkIabaSo0CvS+7jqVwjuvIb1nGs9lfoPUc7U8D aSgj/EpIf3eW4DOboLhb9wV/DVBLKlQH4vxr1NH22TIa4NuoIwOD0hbysGUXNEqpAX8kiJJJ hxVFBMPUbuKMIjqgY5XcjPS8e2CSZDgMiM+dsEMSNd3BPDoXBhF9pdMwOyH2n3SqcJkEyJNZ IxGNnRQj47IQK4QwKvPxFlCQZz7kdELDCqK7blZv9eWkJz8Jd6jxy8JfDvpKLJzWkk21+5m/ ALVQVTHNdhqvZ0UFV5cyL+nFMMRurMiCLi2rZMfLFEyB8UH3PaSEAC1n5M6ppmUXL6chrGaE TaBzTaTo6c73QiEgZX1mhjs59wZozEBht2V3Mjaf7SrHTjqyJtBVi1nXv0Ou/khD5WYgk3HD NW2XbYZwY0eqexzNrEiZyjcWwtLKme7h65WiEgQTLdOloaHww+w72irp9h54lqoZ78pAv5Nk zOvETGNtbUKlk8rQFjcbDYSkAR8Q16KfBDNYfthBQadkEkHVw2tOd+TWDLsNBKJIhAztk+2x Uq4q/2rEBH/G4i77KOhS8bPiA4z2ZkY77PfKpqoSXHWY7j43MOzA+hAu8lmfyecYFEosTESJ YlF6Xio4LctmHASzteTwmFIQRZtArMjagQ1CDxD70TjKXB0CKdlW6oiIeKE50t2Xy5aXHvYZ qYSnpoPvFywWid2PZayZxigK6DoVmGh2QauVFhrdWHXEqwvLl/iBSoI/9oZ+YvQlsFHP8iUl hvTsDcbNSb2PP8lvx/6BBI4NT0ByQ4W3JHox94EMU935Wcr8dy4umVDHdmOAeiYeJMgsAW+r eGTuooVm0kCxMFkxLDg4jWAcOxwmw08R4wtslSraXUQEp1K5p6zH7jWwf6DjvYlUOwu6rpid PkA60guedPcR+IZmUdD57Z0NpxXGiZAFz81MRvgLjiLMK3I/k+9ZIx4RvfpXcsFaWANpkHSt qZCE+ocy4l0CGIyqQ28iqadl5B6SrfW66VrRNdQbQlDl4YsD/GCu8QfUbJvehOYOM3p2WT9g winxsq44gCY5/Nq1DzXMTzaXbxPQF6Vg+HbpK+WHvjhFx/R94MTdCQyeVBZ2HdcZ+eItI5T8 nSvV4gkBC9za7xS4O3Eq8KLALI4xYwr/ZZD3OTdmSxTJhHXID1bDG8smIr7VFZJs3lhGrllT zAmit0BJseFkaNb/BiNHkCo9iufONjYgyofXXN96jAbtV61lH7aUQQNZ9E4Bz5bBaoNoCi+q USEcdw6nBwdmLFZ+TU8tv1I8Al9G9X2xtL2XrNriUI+B18CodjWfw+yMVVajrROKFx8OpCq9 THqJrCeGUlgCVeMznJddXnQtfrM/n/z95DV53aaJjksfRc4gUkO0jlrKlaRWdoktNVqkJgPC bKcEHKbVrJ97nYUN5Cq7K/2m8n7kNUl7vCrNYUk5cUd08VCRehYif/cr0M6Y0EFu6NxErfLQ iClENjb5+1itCNV6QIQIco4K8NsbgeHIXIa6vP3qcBCJWt/LXz2a2hQGOA6WQXWNcdnbzl4b kaXWm+KY542W65hv+SWeJ7WTRi1L1OEg/iesCnUVIaqfcQTPEDALniDYbMhEZk7SO7K30il/ ypUywEO9BAJEo9/j0Edmb8DVUZ9vZXYXuKGGmth4gIfF9mOfbgKpD99MdGbwptj61n19+fc7 OdDqVfgxAcEuYTPBj0UM+y7ayFSomlvL7hnKmf9emB2PfDwAvyZlgNJ62U+EEb4R3Xo4mZTy 3YK96cQWU4bv1NbZU8nQQryGZ9DfCpDvcWX+LSrYBYdDzQaHYO+o2BIwF8Sud5pkbaeA/SbS LSeZ2pk9LS4vegAmibPmP0DCONT7ub+S77uYwsignlbevVh2BTGogv3rsazl0DIDcR0k3lZV AZoKZBOiuvxGsR/e1c4gmFIZwkA4VqbYIMmouewi9ZtaM8bKi2DX06I2Imp9dsGpP7JxkH1Y Bmn2wOfquvHE7vCxJZL228G/73OA1ipgfh1AX2052kzOsQ65N007iceROoHUZJd2mjW1LYPk pOit8+sqJxtMu7HTmkZ6Pt9JzZSb+1SdbasW0vRKKSM0GFHSI8bncmT+qPiesgEJhw//A/Dd 37FQluAcXJyPZ+OTVcppTpDicqfVk1b2qwazEFpyF1f6BIp1qvbjfmihTloarro1ory6gOi8 jP6MD9sABPbVmPC72t7r/fPjZSld6JzSUaEXjspcDQ/6BaLG2hdcQyGJecF2oRSY1tucyC9e Eif40Ns2Q/H6KzAZYDRtpXHw2wAP7bFvoI61thyeJ6j8cKFVOqLmshB+mGqe8dj3bxxO4uuU 9+iOmFKgSKNvTX2+vZlTDFAOzhwVUTv79OJZFW2owxHGnwlI5P+OFIUOGr+d2to7XnNleyuc zOW8S6gbpD7TISaq0prCyubI56df/tgadUPT5mvdkSQ2GiWdyGacYCeXIvegYir7hT151z1r KujJiHgKVsjrIqICEi2SsQgKjJKKxAPQ3evgH3R6dyj/Rm3vt5MWwjqf/Z7VOwlCw/IVgxDb +1CHV3gdHVtS61zDFZV9/EyH7xQDzDNBcDY3DxB+D7IPJo8DSPwFkHPJbtH66HyCrxNGyWGA osy8wefAUcwQWgPOjyIoKpq4tbGyCWUWluvrFuIzs5bgcZduxg/NaCoHYicnweoVJ6SIAVEV Cq2+Q/+F4ptSlOWKFQN83d73b76FGmINS9uj9dRAuZd9F4YEGqpZXBkF4mhuU4tPLi4Oz6gF uF9durHF7Ipxp5m1bxrCjb6nJVQhd4gunJHeU164hdVdGRw5oeAqvPGSUISlXmAwFr2DtS8Y +J7oqYRRquYQh/yD2Fd+a0wJWL5hsyjT7wVk2d3qwTa0c8aAmjlWZJLh3SkUOhBRkNwZNajY kagzl2Bpfcnu+BJROcRSPPLFkBRlalC1agsFpIjnaUnQIEUjUiWV5OGVtpuxD9VcQ9O4CFHx j2JnNuwCyRl7xzLU7s2FB+MPqxP4O/Us4+y/yy7qfwk9dg2Yrplxg7HYEByLoT8OjANSZ/jg fa+Xf/f3hxEPNfEezBRYgfyoKzLJ10fOPo4modzBShdxofxCPZo2bIU0CSSgvXpeI1Cwlg5b xP79ueDIuvTl4On9DCUtVBrsTq/RYYc9IWb2N4A98w8c0fa0F2eaQTimE+wfE0MOoIZSCNwf NvOxrcyPnSWUh69+miF7sOAt3SkIyVlNcOVUe934pWQAfsgxxzETSlxrx4OYjxuOAAnMfCIu qIAvAMdUYBlA6UDd0+iLvDtOCPwVOwRKHFdQAZ+L6WQ97UXxDuaae0EjM/R3c4lZg11rDpCQ nEIpp+vvQVbfi/tZhW+RNTWuZ9Krxyzzi4IIqHH/SXi7L4Ag39fc/tmBYfg500FBDOQYvzcl EoLNNdnT+9h8oALoMu3sVWXhsfoaP9sAnupGYNvr4azRK+EmEjwR5nsjdiWvfWNwOFKLE+MB tDYzjn2OcHXYCMol5XucMSB65wkpKQYt+P9fs8LtK0x3z1x4RnCNIBmZzZnNhpcwW0xWE8yF zfnHroujJ1VASFevDG1NmTKZqXVp4ALemvG/tSHkMU4/jQG1bDrzm7MniGmg8D1sFmVNMzGm ObQBcJEN6MeXWIFlHFJOx/j15dwaNor3J6LcQfS4SCzBY6+rhHoLAYdpF/UUNDTQNtT5fw/4 ZCftE3C4K6jhu+LCUhABXcs+fttL/RtjcBSvDpELEHLGpqTeLzJWlOlc3F+FQi8Im6B8+X3d GizibTLgva1kHc6OljBhcUzOft6Wy5UJzu8vTIdY6kHJ1nY7LkIsH+kh1rJ0prhiXFLhPsof KxqbmNWPj+XWMpEBeSZ5fovXG9cG7tiBExDqr0J4TIeRvrDWdaUhSjfs5FIvrwntArHzyf4M qVmAe5BiBv3dEb3mUL3l8qimzBJqdtTlGEeW0k35/dyBsEL/ZXKxpGzPSXCSLLeLqcNldz+c Gi51xNfwrkkyN5bpyfL55hhe0jl6lbqCQWLr7eyYigAzqYmcNsICfjahuFzF8+E/QFGbv4jm jHxIG3R5D9EwLDoxMDSApu2M3Yb0gFHZCwqPK5GeNpXiz3EGSah1WHpSvBJHbiLu5TDj496v 7o8xGHZEsWthu15wXWbneUeXryIt9OGZeUzbS1z+nzAFcW44+2t6Q1hvDbooyFD/eL928epe RCj3bDMBDDIwBMDzX4AGfPtCYC2nPIS62X6gKjehq1DcCQbN8wXAxgTefqqB5NkcdKy3x/E8 qiOJMpAZdlcJaFfU5WLNDYAQV4uJ8iI0U39AfN+l/9U8CLxbiWpkjcZaNvFnqCrGrwcq5oWS ms/O3n9O/T6fkJE0Cofba1bRzEnB1eWSrxAXwSSw0JEVtaBotyPdYGePfdCTrdkECrDBw9Nj 7tlNspJhQxUL3sYyIDiaIMnnlR1Yfo/E23e4IO0xiuiXJb69AOdq4PDO3Q4+SDQRcXMpKKvm cZbdUKeVFSSnVgpocckIEucQj5YjPxlLnkCBmmusQw/mG3Y+/MCHI5xzmClUZfGSf+2WofGv mPS2QfnucqwFTd2YK/aVz247CavQmop6cW2BFaUURX8Omro5uPiqMXjl+tdxFxWKbJ2UeYTA kMNS7MoPVW0F+Sfa4vOTfmWd551NjkVr8Xxy1aSvOVHqO2tinUqF7XhhCLTI2Te5gR8efICh gvmehd8HhyZmqvaXBvZkGax7KPQcBHyuqysIOm0J5O2FUz8nclOPMZWpvy3CBB1rvNxXTIpm kVGHEFwOG56Xm/3/qsa66nBejRUBxq7NgGXWc2IBS/kZMOVs4c955FgTGu1auN97A/cPpupN c6u1kWvh0H7JvyMRcMXFYR0ix7/MIYc0lDqMCrGa2tWMUnDZodHzmm1H3vBKoVw3wf5Gt84f 7KdA8P1W5TmWhD4SQRmLkENIfIht0mGI/V6QLVtnZKDrEuKTz8DHuxtGD0ZeBrCldSEF5O53 OUIzkEKg0t3we7c2ZhX2KvvsJOri/58km4g139axVST6OVRgp8L1nNhZSgvUZ9TKiIrAPI+N 7YxAexfp/fg6RM1rnfWg47bWkNcA3CAFAjRS1OXlOR0+ySHLUnYK/OxIYS5x03isWEA+HLeO lnwQUbQA3ufWdhTg882qOrcI76CRsZYjSgYhSCurxc+YCkLktDYIHxNJf5Hp29x7ItH0uVgr g+XoNhaoAyS7Gq/KTcIpFWeVrAlLIsg50TK/SPplQZ9kJBj2F6CmgfpR3E5rVoEv8CPDgMI2 X87VjHsPOIbcHi2MiLf8vqqaHxjnXQ4MuXJJf+Ltt9VM7ZRfoTOswG3HC6/1Lso/BgMolGQ7 XO8sezxq5PMoBssBnkUk6a2POTzPr9o0M9hameiHq9XYJi8ZuV157rOsWIft5TnMPhkeq8Uf 6VZ/e5bSTOmejfLCqLHcYggGbYdBK0KSSIt1l6itF+Lfy0enxW2X0hIU1eVdBUISGkLVuAma sg6qM43TP/ThM9bZd+R15uMoQTFLzW2Sp6rdyvzvl/7mTIzjnoUJQ12yR91nF3Hrn+lqnkFf 3VSnr4NZT/LIX1IUuFVOrqgkvSvrgU67wqIRT51oELRY1FnvdgowrycraEs4+eeWf17VHxuv 7ee7p8Slui/xNeVl4jT59wKClbeGfQF34Gxsogch+jKFxTzhlSZbtRihjawh5OXz4C5QFDbG tgm0vatjBYBcx1kve/qYgrceHpYNbXchGtwTKGJh1YJIEFoYXqRyCwH78VRKa2ElTf4jtHv7 UsaERdTn60XWYK2uVwC+Yt1aoWdBCthjir3OxMAi0rOu69K82ZlawQYyqwA2NngKfmFXyjmm HoiLdPOktI0zmY5c3+VYuZ7mb1Z5ZNnwENAWBHL9/uCUkE3MqOZKU9MvzBa1IbFylp81jfuh IwRlA4ITGa5jZM5xMqV0Ipt9R5wcufWL7+iSjFJ98c5X3W3zZsPtIk1TZU/+C1DJm20VWC8r sBf2h0m30RapW80zKrwD8LrIxD/77QzWnLh0JYZpAuXocR3yaDHpU7rF1Jzmpa1l4CHpLhjt ECrbFoFfa3JVssVd3RObfWUxVKL/eQ9Uc6J3Dj/Y/JHH7mQOJtVVMFL7lnlNawbaiG0Z5Qwv 6SBFtJa3ajsWnw0nKlG2pVwdnnpGI/cx6SjZKpbKWNqUuUEkcx8mDMHSjGAVBPGtPieEDID5 1z1DAiu88mC//lJBtiu+IUwRo92/EkxInrE8XF16gKU1AjQ2DyCi++5hlL/iLVBa6meyyurk JLwlP2DxjbWu6M88Agg9De2uV2lkfI6a1zuvL81myO73y997O1bhlZbVPewbdTJhXWUnrwOi QQ7eqwtpDIuWFSxLCG8bzjlfEq30JgB0jcymhYOUqJU7pIorBlYtlWUiW3oPUoPLBB9gnf3n I5esryv073qp4ElWLxrkZpDyfDC+TeTQs/f7NEk1VaNOllAnpw7ypgwtHPIGJUkIl2ItbN9I jnv/GoJAQu09P3px3X8XC9+2gVuCqleUaXMKIDp8nkA9A2S7r6cIxSt6/VkXKN48w5i1E8QU 8Sw8abAI+Bv1v/3NOeXgSUc+dBfbN6tSlUPOg1+aoq4D+pyh9/kLjsjGDX/AWgBTsFE6xr9G RQXmsbwFEARanFVzqGUj6qJHLmwAnkB9jn8MSXgvahpzkMNI+OTuzbomwSiPwJr98ZJiqFzP q5QIAVTVfc3n0iSdOswhqRD/Ak4wMB25rDUcm/LVpMEnoijGlY0jrLCZeQrXQZl2hDLop/Xl GRXmnGj93OCj/SWTRXPXSH19HT8IZMz/ussEGdOevuZ7GjMdQeW4gEWSZ/BKurgYXt+s/w+j nojpF5kxCjF9+3a3+bwo2csabOW5rKwAM0Bo9M5Y9GJUwHrwOH6daWncVc2IcoUicYLjFgeM pgl+jyHc918X4hiMlL7/R2yR/Crecd0KT+8FjLTwJHm0iORCNURkZ1ijT66OQ4WMYkJUrtB0 3ZIQ0FbmnNzY771u7kSIGQzbtG7TUsjENKWD6rAQ2BUT8PlrwVW9hwx9/G48+U6R+47JN98h sXoZq6RZe8V5q5fSqzJQq83MafZUYRfv4M9uzW9TSlo23eLx2a6by3ipMsNSqvdpZ2mxG6o1 W0HBJJwcUDQ2LDrHWDxSj37gPvRaMMXUBKtwBffDwosBezy7GjefIqA8J+sJCA8KNBLUnZAI 1RAIhuZdPoLGff3WjQrFvLLveS/3tRhtKy2v7z2JxeG5YBZ//B+gkzUph7PJOGK7DTsUJtaG feJZftGVi8vWVz5E0DVLB3jd4Z0n93jYdPZfDfT4te6kea5WpbBLSQpc7HY83cScii5Tu51G 6cjz1uQQIeFoJ6CTgzjwMyg0gs/fGIbg2faKdg76CjLV3XBlFlZHmzJGN/4ChnKerv5Mu5XJ mqNrof3VnQVF8hPwlM8EYiFgEv27iCuvfWJTOTG0+VSoIjdq9TWx/t79xX3ef8mmWB+MlnAG Ilp/PCRmgTj/dNgKuTALkANcBovMk7uxaonu+SXeAhyV09D5Z1RKGbtTV8Jj36ZAixxzgcRX S2OVU3jP0iPCSf11krg6d29Wsd7qAIBPmNsIyJHR0Thdu9I0SEvuToehV0RHCkSK3a+0wKtW Q7Jrkt9Mp0UOlRGtCw/DOQgD821huI/aP5mXUMiHDd+eArg9N4/8BCWB8sj1GAzCbiO8Y/d3 eHGiUe+W3tM+RWLVryUIKfKedYQTm+a5hwj5AFJn84w04sZmjHmsYi96nmN3yX/PLExlwnx8 Hf/nbEDRwXU6Wzs3uypsbUjM9filNMff122vrSYq59NQ6rRktWnDyURWBh+MnE56MHi68msO FZTHGBm+4prPOkIIfzmPsZQfGmuOhJfsetzXeoc2LC3uVRd+pUdEx470t6Qx+D0rTt5dWX7G Aea0j+qTcfB6O953eBiCN3J1NoZh8GnUMaF5a2itcjYiW8h3DYvA6ZGVBgK3h/0/JoEDc0SK 6TlbDsDjyIWvsSkvuryG8zH1CXHv60Rh8DltaoeP1xUqHwgCQLoA1NA6k6+vCTbJmt5wVBuM ej1npaXsInB5tDkZZo9Yn/HkoYUjfzjGWwPDc4h2agAYs8tRyFruLT2TwJx6fP/bIw86daMN +bmZ5TIW7TUz/EydHY0lb1CcLKk9jbGRpII0j8GXbVSymEu6Vg5rM+ohk1PKE3hExNPsCW0U ZWc/QOQ/s1geusDrpJ2BGyA2LXjRyiSpIxSrAlaUmQ8YNg8ovEtmJioTP9Qk+nFcmIrpu+sL PtKpmO6MMXfqAjkyD05gU4vQS2Ax8p++Ms0DCuJBDq8hIN+qprtRkxcHRzQYu+mbx5svvOS/ tsNv8bpITL71xHm+TwZOj+mU8S1H+MKRFSB4NqnCglANL2RDBxX4rXpHwMkwYBijm/5Yw5QO AE3ElQOZDrt/gMpNrXF5P/BQk3Gr5ssVtjGUkoq1BbVduTeZ9YiP4sv+N0xnvDHVLdDW1LuG WWCbayzKff4YR93g4QYBdz89nKMrrfVRChElyqz6KWL69L8Bh/9M1wmOQeawhKeBB3FwJ3WA jcdDDNQJd6NOGN8Lwt2wdKT2uvcbdeccVqMkasOwZ+NBpV+Czzg0V18tTDPV0/3H1IwRNDfA V2fIP8VSB5TA5hMMlM30Qcd/nyxUrSE+PLDI3Tpzt1vuNGh+/h22X1gLR0BZvv8yUdmHKwgr 8ktBg6XhW0eIt2RF/+XdMWUIJ4sDummoZdDORen40m19UHYK+P2C4J5Jlas0hJDGN53celbE gXZHTfzztr/mvHSbM4frW9NLAVqg4fKpdCDcrjfEZPVrMeksxn15f/rKnuimjnfzcmDtfWAu iy0tFG0N4ZOjDkRVS6tGS896F4dVxBxCelO574XmsN6ALyW2T8/PQM6wsEkRk0XdqsBhft2+ HPBHS5V5SkL66AqpGVRi27uz5ZBO6rA5wVl6xedtU7A655quVDTo5ZRzg2EvXjto8hbDJbfF Gl1TOmbH0TSSbgImM3izCqhL1+TkXp4XsZN9UYQO1cTK3UeaEiGu7Yuo0pJ9VXBSHUp7SyAy qgzUql+RldeBMkRaePYir17tNnd3VVERLu//FTCht/mTxWzJbOI+dsNpJp0ufDXFKQD/oMhi kns/uwZcQF0LIgHUw41v2FqPzVQxELPw8KYvFZ+cs7yAPjeMrbkVKyUKlZ86jln2H2DY4g3a L88J5Z5I5MVE1OL+l6WyTsG0F24ajXc0mEjgxPU5vRTtIm+84elwyQnPvvgcVtao5Kim51du OGBx9tOXvqKeL9Z0hfUevscbc3CP3e2JxMmLzlqyQppv1v6JEfij/ou3YGcs+GafeINS8YJ+ +CCewsrBD+6abcU6U/pY9/ygImzGyzCTDcfPLVjI0/U1SJxSyOS5iAl5WuznWo/7Z1RRut0b HzEpPotHEtwZCtch2CnykvL0L2NDPMg2s/FtR9h/rfvcqOBupD1nG46BrI3XDbwfl3fzIkn9 FWgeujiQdQ9yKn7k1b1AVaomZLp5l4CuBgQqI9+0iO72lpQeyJRM0pNCuTavZ0cdlqB6y5Wp TtNIB3AtxWGPXErvAcBbR+2YFzUPK0Iss4iv1WO1XirHR98TWsJOFF5WS+heL3nZsyzIOg1y TvVWvgUDSiFh+6bHfHiNfVKB/gyVCD9Sc48wsYaODERI2nHu8J/Xld62QAKiWCt46eAan4XV 4VUPBsnZ5BNZ5qIn9aMgC0BQVbclUZZG652LjUP6js3VNgFYyuDS5qFgLouWQMR2Y0GCgHt2 5ooq6QHqVkpF22wyoc9+y9re8zDciMDtxOQsB87HE76s1MxUbV+3p9oEupMF7Yg1+LFh6Q3/ LJvNB+4gnmsGoGt35/4qFaukuwnhiAt+zXuCPSh5qeCDUkvCiEbcMH5hvL+Xu/3JGFv9GZ2i zwZ/0XMQlEPm3PschJTwhkEFDY9YGGrkkIzDLtualO8qljk3CQbRfVkzZHLNUT4viSTrRRR+ kR+NUX7zkmfGUhh35mm0Fl9Kavd+GPWswbcQR/q6BrwkUenkURXtY5GmvMGizzDW0CR+YCTh cLpzjR9Tr3d0cVjUhvU994k7kyBPpNVAvA0nakd9NRMKqchLFLV4lzkL36YBZLfvZOvTvSRG JkJCdVpsf+5CqbFCa4VMjLi5HooQqsUJovsiYXpbznYHG1suP7gLXAtPKkz3cOGs0OfsmXrN WpMyrQzukNnr1uatYSNOtxy0VQwnE7GeIybcCyNl8FmgILi+R5qtTgNW0dZmr5RwidUts9Wr PmIQP/Ny+5Yww3T1fJhYjhv0enuuawPmRiiDftEpwhtmd4UxqfWPivuepk7Kdx3QFX/cVmgt YqCYqAjwpm8iQSny2vh30VqcIjL/MuknHPyXWZ0/RNR+YHAtb6O2i8a2osF/ZMVcEGHjUdGG udJ/KJZyn4+HTw95qCRkhKU6Fsw4cJjoGTfVsiHCLUGEfgarJYm1I1V8G81qsfbCvRvY2JAU 2+/BtsZgm7fnuLFvd4CKBJDX+/8R6kBm3NmkTTbwDlHvLRgI/pn3wzgbThbfT6kmKfZEIbe1 3LF+cr4UeP82zcA8yxLNMxLDAUa2jVJhGkb0IQM0BC1ca710xFfhYiCqrsVmAPfraiPeenAu +wU5P4hw12qd6Sp5WQVpd41Ja+cXGTQBTw4XJMhCjdW1wsr8IC3Ane9D1ir9cUpO7rrYC7Gu Dgcq7LiucyGlg9XRMPxXqkiRuoI6aGTZ+8Uk1C6AvFV+VUUHiAlThvxXCanYUrvYE+Ayur4R zFnzzj+JZJHRSYBSsbVJtVvj5iMm+TuyUJDpcAqwvjXyUhyGXYcF+EXC3D5Af/wr2z/xn7eK PX1TyrAx1EpG3/EfspP9nMXu7qxAotutVyxeVc60d+CdssPzOZjV8g52hO0fN4kJ5YPPoy2s sBU4bHeUVrr/bQPyFr1baEEfqAOW2/QFySATE96963k4qBXIfud+D2GBWfB6m7LtC2YFfrkr Np80dmeg8QraC8r7MxvaBDKCzgeDxvk5Cx7XIymTEwfqrvkIsSy32YYEtn9yotw61kEvsRIs 9aayh7F5lAwYHwJTlQqs8Sul1cTWioLPbGdYECltKtl10T5/+/6NVTn6Bn2NnlMS/tsgzSKi fuqF5UMadhlIpPB4IWDQEEEj7QiHs6mNVGfS0/4XmJs7uxVvo7yEkhRQ+WxsBZBZfd1MEVvL FTyvbcQVgvf/yqkg48TVqSLk/NR/05udZzE8RLvjZdaR63vQAJZ12nGo8+djF2ZrXYbCWin2 /Gzx1AIIxyzCh1KxJHj99D25p/6qlt0SFa+KbX0IKtQgF/dVrlEQQu/4JtxlItMefsbGhr1D Ly9m0kCHcQZhJMIUOyrRbKuI6MfxgSiNotFiL0WRJrTtgGwxp9tPkvQ3WuOVThqlbXixQ43q oNuTxaTj9GRA/FCO+XONUQhRtU5JSAoj6Gza4HPqkpg3WBSxL3792MFrEPe6cIMnIkAsRUru N3CpNLswWflEBc2OUrq6iBUp/hoLvEhA1IZmKMpmpIIiMq21IohhZTA+KK/N0ETnLRa1/Aa0 AskEO2cSHL6JUp7/CItnOT0MJ1qV2FUBZyXJsBNIgF16DKyliQhEsVlZUJewm3muXZ3w+SXx xlkTvmlaNggLbf/owm/IM5CAE3bbA53JQaWMhxvXHJaRFNC3TA1ZkoN6mid4AXw4udoFvrXu 50C3Yj8Z+Iuq/hJaW3klhA/lRrb30q+qqeNvtcMghim5HRJdX93H8CnrkZZiMyEfxE8yfiWB 7JHz640ef/GbbOsV4ZWg3bEtsv7kbIRzwQ+vm19H4T/kI45zCGWTcddHuUVEhojZzChc5cLM PZSaNFdalbk6u1ScA28IBQpq/rFx5MCKg/gOuclkQvT6aGEzE6+w0cYx1OXDzDqd5C02fdv8 Nsq6MkZ/vQcsOr2n2pwzWsYXwdPATKWjYIRo/KoK4Pg3HpgjRVmXt6SWQMPxsHVURSAzjIc2 hSgj5X7DxcwmW6RILr6XIi8n7AMSiMTZZaG2OywTzi5DIARzgxiK2kCnZWgMBg9DWPF2ZQAv OFx9yu0zltwKwOqEL/4+Hvds+nmoD5HMjjcKyp7TELuA76ryunXSB3dq6smhZpbLa6/T7NMf +TyBN0wX9vP4ZywPQFVu1e146N+8vxzVmpNKW0X86N0tvVghowzjCUkjJaAn+0aJFMnBatL+ QVoipeSJvrWQOx7yWzIAqAxFdEMY6fyiPpE2nPj89Qz61+4nNBD7qfYS//XLO5IReQ1LRomz BkwuOmKekyg6kbld2Wr0OuPpZ7LmQhIEOIv66PsmSRF9Kv5/lbnjsL3aH/P5dk0Cm/3G3pab iv91upC6o2nmXPGSGL3DKNqBUDq99Pv074A9vRxRg1uZSn08Loocipgp2JawZSehCmy4UxHw b2vtDLgoTUu/76+nvNMgvQv9ClC/CYjCJlLrMxe6+EVA0JhPp43EOuaWsy2B6Iemb949Ht9i kE4cukBksf3A1CsjvuQWonSl+y/ZoaydbKxIP7SJ++wm/IhuYtdar4tDwj30JbPfjKC3+JEM 1yTWaGvW6Ugkz++qiAmvT292RMuDhGHsmxp9kTWzCIXMLsmwzX2tKU9fFErJEAFJ/CcPtA2O APy1doZ/QV8+YfzyPtsFxnsQKIXGqFetPKOqGrYhUEHTlJ90EUu6PkVOK5t3UmMNbU23M54L fXxqoNn3mA2ztu/eOngsls5Rkn9LoFm5NoRY0BLS2iVDQz0Q12Z1YU8VLOAszaq3jO+Wkn6k Uu3G2VI5N1J6urcYdkXeOTPnKwbodAl4faEbrMYLiNMaSy4yR2nYUHBhZ8Qs1abktS9I99ue BrtLLAqFv0cMqDPZwHcss5eCC4vJ3XtRmCBBsWDun50tpH7A4KT5i5y/nWlDhT6cfQTSmqSu 8BHxv/j6VeMvyMGZqgD14DtuLQURwgTkrFGSVkVSc/Olgv9MONNWC+3K1L1Ae/OdgI4XtzSi N91uAY3Pl3NFG7E65tWFUNXElX3WVT0FS4w4HszPrDFQ/dY67QSHg08GUS5g7kP8W0HcljjL kyPupZLpFzHawugEv/TiCnu3kPUJEAFTLTkrNMqE87Oy7NutBIGfXXBHcQD245GH6f9OfcLn uryog8t4AhYgxCPltngJOx7pidPfb9HCOCTk7OMsQLhlYaI3GnnUkPVDAmo0ratTuSMTgocx KdhejcoC1ifhZeEWpDrFxD+ZImkqNv9OjAbXzeYaCVqacW2td8JjGOw8afuvzIk8q42rwqDT xawIFLJYvFVJvryfETi42di2CvJkguabMsCG4YNKYRHsNrYDSVsHSVCp3G9QLHeItPsr7qQp vGGevak4T1dxa6yEMF5j+yZz0khcMe1QhsxNwXKP5kjtqivlIujWlJQWsOP/Kciswp/cbAUC bFGpMaLucHrDMK6BYvjns/zm7XkYxT8rBR5YelJcMFUInySeiS9boFJ1e4UQLfYHpE388Uem QI45smHNb/AXkSyo8+5Lf7zYVkEHlN0MfEPrwQzwdB3igOc/PqmgoV1ndXNlxWepMMJKpiDj EJVb/do5f8R7RsMitQKqpzXXYS8vi6H8BDH3ATZr5TuTf51y9meGbrOgefc+ocxuWjpQ3+l9 /GqZqPCKmYB4zFp6zCcm90U34XZDR2pns90jlrfVKx8iReIfHMby71znswunUwVyNYgPAuvj HCAY2DFkXhPIIuSVYoASMjbriZCaScxNRVtwANya1TNkszyVvDnyUFlxmaRFnAppyNfUc3dd +zqryQKGKldHQxhK7zrw6AEY33SjbzUCCzhllUTF2OR7ineRPBjN4Xnf7L0z4VbBf2so7TuO Km4gdoUsXB29M5vskr/vnYiUS+Z0yd3dVQ446nu21itUkNeKSOH8rrsAjGfEhicuZrWrO/GI YZnp0OqewV7ycnWfIq0xfF40BvYRKXsFrWUYPoTpav2V6/V7rec8rqC+Y2dCPquPBTSDF2ym yvNBkfy1v5ziOjKbG27Tb+Jom/DT0zz7sTnEtO/EZYRE1jmbaRVq7sa1MNhOc6qDDlXJNLKt 7z8OqQQLwMwCeXtIq8Xe0RQdTEXq+RcFreM4wcCKpJna1M3Ey7aT+ayIlwnBN697H1HvTVdq Bkrsi7v70fEpQnSlOz+RHHQ6TWjUsykSZSbVhTu2Ew+Wi/4nlKgIrHGQCRM/1OEGfQXWV6pg qtmyEc5HmJUyUNPgncawcw2FuwsQL5GHUiYULtjEXdlgcHO3/YGwLNBasNl3hfQBc+AsCXMb kqpZVBuiZo8o1MnmNUoiRH20zOohrbb99QxZIii9appGzYAOfSlst/Vgo9ZTnctBNUmnv7SF MRdC61MRUsdlruBEF+u62m/Rf59Bdk1bE3R6sgo7pbk6i3+VHDlO+VwYhYKgPrN01dIjvrZZ jjpzjF4I7pZXYAlnC/ASkWvKoNHpTY6V3lOBLYj66ER0jb52b9r/HzEppoM9cMV6itz52h8y tmRfBkbZ4746PR+kvOCnAVs5Ih7W1dgwrVdh3+s353BO3Yvpd2sSCn7hVV/CVWKz826DxAZ3 izSd8DcZASeBX8Hqj19fQp3VChoJGTvgc4PvCMVhsVz/1+kC1EyXIj60NVoAT2jAHE4k9/cQ ZMYbEUICFzBXJHQKfTHgbgGGFkGQcLCesH1pbkfOtfnSSsk20qDPGQ3EhgNCN39pkj31trol 3ryMxFL5M4O8tVeFFtOH/FTxWf1b8daIeysRLWJgdMNVwLHsKdF/wSEnRsKBLL1hgY15Xisy eBCjOi9rT9y5HqKmnOeEDRyCzTV7ax7TgSPPDH6vuit2QApqhPOjB7/OwazIVAjTIEw03+vQ KGQGjQ+y5PQgUQE6gvd5Ft0V8qbY3tNmwf+AebhX5XkYSVelAcZQCLT+sroR5Co15ngbGSTv GP3eSo4qJoNCrP0M4PeLYYOEXE4fhq8ElyzT076E7mhx8ui6Yu0BohzCmAqbxKWgbTI8GylP oQkky8ltBS7JH4hayPFZyv4NgAm4Zdib2qdG4dgODJuSm8wwe6raHCsvX6kwfTZVKENEMRyo G2X0GqnHBl3cZDhzV72a1dx4JymVWr2bndS/JVSb8M2Stk2QjTKjtMPaTPrYGyStStZdWwQX usCqPHYGw6FoeTQg3HWL8x8vKoVZSHZBWZAaoSQGPlhlfNrYZQrHiDl0pi07zkrdJJ+qF83U IsmEsAaBUDud81q8mfr7+sN5CV4cZBVfYbqTrxVTxyDq/TC/ehMoxiRuQ2tqIG2+z5hZnX9n 5Azi3OXL6k6GIlmbQEFOtOojzC6j5r9KbTxXPfM1eacFko+pjAbwu5kAoT6poSAXQpd4d54y x6mNj43n4k76DKkfoZ8+NGeMws1UHKYVjeJDUAKz4UVDwNSb/SWVzpmvbovMoabyISQrs6Ee KG2Lwax5GzRKXNhzs3ryZ14Yn+f3MqArB+du5o/mEYFi1+E73fPbsWHTn0f4bDR+w5h5HSXJ p0m3cRBu+g4mZI4UrBXFrmlFu1uQYvNzGc5iV9xDq+KjwurE8j4Bh0Pdvm8iN0gT/Xlf3U1o STtd8QxnCZUUsn3EAJVNtE9wVIB1djynioDhYnfG/cs+1z1CcoLc9EVDuc+7qIlBACwszFeb TYNwP88IIElC5FvQxW24L1p8O7wyL8N0vN1FPXfOeHYy4Qg2u471wY8ach1ZqM7xUjxcNqmV Pbe4IvH4fwSe4hDHe5GhzyJAk0XQ8KpycCrc2pPpBN1/NtHCvZaQujO25nMPsjB3MykzfYEc 5I102wxD9a4pHUnXbza/UtS922w2ir2rKWIN3rKnqviR8pTcf8wZJpm1cwHwPqYX6HP/hEmw ohn3FFC8zYYBt5zcLjiMA0p+W4GNoBVLyk7SXBYzeHHhvNn9kiIkuo9KIG7fGYYs1zZdVkU1 ZiMPkeADn/O01AHZwCgtZpWnxuFH7ujvw8abqm+w6+EdzcSYBZOgbXjG2SNkX1nzT6iporXT jPuVoKRUJBEw6EZ2qAH8d7tvdfetHlCBS8kmEkzcYPnC65BK4SD2J0GiPaLuAEEJLJ7I3iOC sI8njeXSPN/fkg2K/4RffeaG9IxGGgy63FTFerfQIn6FJRdV5S4+0OruSHqqlQaNB8GJS/pF 29FX4nQyU8U9R9cY4pTCyTgC7Q9yfPlALN6jkt0OPdNvYVvRGVYS+m4D1/Fn/7Am5kF1flQY bhU9dIG+CjKsCIH5O/eWD0zQkhgCDN5OWwuOZ6GpiSwuMBs/2ipaw3Rh5SkCF68mOd1gDmXz DEwbyTu58kcFWPy1ijdMu/jk+JaGi9ymRFIHCkXrIOBcuC1uRD0nkomDojLCg2Ga8wc9HBia SlPPdnMOfSr2rbgrSDbSoip7eDbVOW3sNX58sCWVU+jWNCa5yY1hl6dp0Nj5Pc+0joZsnUsv rRXYcyxIynTz2la2Xa21/gZT6s7hEy83Jf5vw1/LHzuiogZIIq7wG62+N+U9k85zVLstD4YM mkvMdpzDZgclt1ZT/tUW8aPUBMHasRA/w2cMvorRbJAa13h66lJU5aiwhYVcCYHTTOyrwqr2 FX8njzdb1QswJXRB3r0DqE881iSalTAdr+UbHlp4ypX69l5zF2VszCmgOqA3YYp2ZRMIigZK HDAyalpYKsSTrYBjOotZiKtPPWP+hWhU0VtjH1NbzLB/CRZkiRI+VMfuTy3bzNQzkrvLhMJe gUgjmjqJUcNIKIeo8VCIV49WFIBKvpGBClhTARneYOKyR8NcHtspJDXnjGgn4sqpHRauZCGx RN8PpOE+PPiIpbDDniysx+hj3qAH2US0joSC6AXj0fi5MU03ZFL6N4kXjWTzfQWFEq6XYlZK JAm+Wc5E3YRZELT8Wil8UYQre0cbBveXNiHIKYTscerF2ROVksmVwGw7QG0h8sR2UUH/Mu7O MKDm4dQQWO56PZrCGl122GxiDU3mvJ3YdW/XfSS9f/VMJHaOZshxtZULkB1vG5TEsdFG/2QY cMIlvUnu+pusgkoIypBYZl9vXmY0xOQiUHxtAp82Bm1cPgEvMfvnimjDvcjyCtqA3C6I7xSN JsU5kd44VC5SkivOghQ+x+tRu0pFeKc58OXeWMNbLx5g5DIBNScMSa2LwyHOF0HBilYGeEtD pvAXUMnf5p5C1rRf0EnIN3awr9ONXXb3jKgl1VQtRcmZZKZEe8kxwiXVbjj5oSQ2D2jDu+h8 bWd2/59XPIrhDnz/cBXyPtvhbVVnTpR5ZnD2qfHHDIYoc5g34tXcnz8ZYa/jwylo8NWUH9yY O58GBCp0HoLdnndCuFasNx2Fp2sEQ1hKCbf2udfeBut9A/aPCSqI+6yGaXzl/PV+zjM1QXq1 e0EFlXukJBTc9pTrUJ/q36MITAMwO/Pl9h5u8XBQbL74LYeLHZdCL1LO+Qw2+Jz3beiONp/U g2lwVc7KNALxNxM6ZzbfbTYPv8sQBAwTL53ukrfk+9FHQuvBsnDZMArbsi6SrOzF/8v8HirQ OMrEtx1/7yXnSjrJkaxqpGgyeTa5fyLp4TlCxRL/VJ+A/WFS/NWVxBO/oJ2I8JLkTqrkstar OCDOv7EWH6a+4ATboG5l+5zn8xA+fsp7eFK7SHgZwccqIqD2FzmjKznT9AGxV528rDbhyJnb IUCIsm8vBUsckt/tO2+zc3cT7ohKrGwkMZORshj0xutFEZtg3ieWW8OBMMcDuShKqx4fWu2m h58W5AYGAWvi0FKed3DcJVgmLGLDjW6BoeKzAt39YWECQJqRTQDBHt6b7NP+n0vT2kahTQNg C9ER1Q1a3w6kuiTpHlSBCE2MHlOdAC7DTJwKpXqzqzjizvPawdfEZZZcC7SnyY6ljF5DBzL2 XG3pfl8HFGbUsWk0OHFOefG9+aFzkwn1scC+7Vewa1TjvqeVhEWY4rho/rAMxql/Cb5RCDFs SpJeCYGHBmadOGOh1Je1/CmuSDT4jz9052F1kyKaAuL2G9Of5ojRsqq2+1ahkPZKidKkirdg SswTx7jTM4bvUsOmBFNb9Q4tK3lIoDaD8L83IysGdOZ8NnM4BFeqfc0rpRlW8s9/52XLmOBi Wk+kVa80Bc7W+iQ8aPy48y7omaSabYK3fIzH/cHHyWiS2BLSQpi8cdSTFfxLdKMaIPocylQE 7CeS7lgOkW5shOWm0gpVsJ4sP9uDkK2ZRnS+Dd5gexYzfU4UGm/wHPBXE20kvA+2oWfxtOJ6 yoil97LpajPcPWW39+GOCwBdZTcLf2+GDSyPDrLKuxXUPjrAtQPJU8tXE3Qh1+D0R/5RABxr pZ3TAGhedWVad0yrrGxuihBmN004987z75ahulwrHNZLh9dEjmVxR3AgxmMlSI2QKpy23wM6 SsjGm4muDX6RWcnYP+6vMsJ5iQaUHF0R2TP5v58H0F84LLSbN/jiA7MIjSZAoVZtbh7fpWxy K5P1Sng3UKqx7C0rxR9xz+fCvyElNv/Jij5d6qf052hCfWtg1FQNeoSr5jde0bdbyVcH+gIO 5nAEjwtza82ssw9YveiqtI7xQN0UqKJ1b5kKbP1iJqwcleenprZ8lWfs4t1V7e2Bw7h5tLtB CZlCmOnHTj7TrRfIJG65kg4bCl9ItDtV2E8jVxQCl1aYCml8aqT739XhpVY4lSc9JQwmf1WR xrz/LcO/ELXi561+oEnO0Ssk5V8bUVeZVBsjxkkAunsTra/jdK487rM3vbzMPchIXNMZH262 OMmAy/brjHvNCSXO+ki/IzMUNNmztDYrUT5YyAje52+YivekxpP/2JSR7w/1r9wNz4G0UKiC Z1VOoN9oZeK/oi8Co03fTx4j0LSGTRXLksvmT6/0atahjK4AzKAvSTemO9d8uv7inYga3Ow5 alOVkmWOzmRj1QVt0AoLTmlgtr09XTVAhGKPf741I9SHAKpBkp/UVy1FKM2lsYTtcz/ZOK+X YTg5MXJNxRzMgb9h7sFgOpB8+ei2x63Z16oENbfKm940YCakgV3UXJQl3c2uFDKpzUEM9ilr eaBBQl0bu9kDKLU8I3WXDomFa5G5NfES/x8fx2LztvdDuOVvzyiVXaHSeB0/xR6M7veFYYPn FKRkR+xBlHhQKfNJAg5uE3NFH3eKJ0jAM3Y9NsMrNX0SZMpQvHy4k1TOSlV40vEYfTcp611I WxbVtiSeSXzeaz1idcMf1ObDe+/hG86jFUH8xrhzov2XrVAKQvxtk7FhvMRp91shIm92FhJg C9iYG6wqOg8zwTNKQ5/WSyWiQ6HR8J5w2oVkDhQcnvMf6Q37ReGO/HYqOLvd9KfaimV8fgOs b/RCkWt+MKdv56TluWffSQ2rUCgqqChRAA6hPZEjHP3xXHD0QlE2nzr7ZFUg1hLOKWUQ1XYw qpCbJ7xyR1RlQlkh6qoMBJxC/ioSlJJQcBhhF3NRFalZt+LGX9CDdacYach0+vsGK+WiI7pM /ZSnR/NGeE+jzETppiQf5ib7Am7xaV41Qz+j8S3PEfagDlqeYFUlZangobKqvqBz6hdTq41E et7AB6mH1gK+94UgFg35ApF5+OGCWnqOdhg6RZm5fQhGPEZw4/0PijmUGgJ0pv5fNfJsYlBO bG2PMsnBn3BouK5M1O+UigRU58xivYlvUUIBR29RMWJ5V+ZYeLXCxOTTYPv2AdyjNLb9g84J 26s2fgSytYdQEYGeE6qMQv51yK4d7+5pfcPXCWEMZ9Bs+9hWNgdPxVOQ5HrB+pQnXIapTnNN lVj26VU9n+NF5ZXcTbdTx9dJQusxqLrRhjQWMz4ez6X8BPJ4TpDryggeZcU/cJztfbgkIwBS DwCdxhb4/GN/J+yqgwnZnvqf9/9gws3d0XAyn6kEHRJ8d8rssbl9EQhOj0P3zeiew5JGYJ+e N6ujWnIOrtWwoEykb7VRapzYBJ+au2WXDP5EEl4TA0uR+gy7+h0lNLHEdtHX6+wQKNf53Qvp fHMZhhcDAag+TBeKGAVN6riKXZUbk1/sKbzONsbHCfyCF/kNjfF08tZOp2s5GHiubM3XnwGb xOhpUuYKnNoPlyLnbK4XRZ751xDdCdtldIDMgyBrx/GuNrHIaw2MDOoqFXfWXnCfPiyd50Bg Z7pGz0JuyhhxMn6r0SRhVxd3xeIUU1CWr0yvuuL+wPTHyIHrSq26jYREr6veaWtAiO+8vIMq RyFmDqBK7zKvK13K6TKgRP0whNb7oOMXtIpTHuuCTucUqRstXYKuIglPi8zeT+qUQ2UPhi/i pyg7YB8AZxmBCqqcbgxSPaz8GCzeqByoDen37eQ8W+hbYIKul5KAAgZ7AefRXhB5qsplPJxw 5E5a76eUTKzxB8/eff1clb78aMdm9nvxbFpbheu6znZp97+PqjoT9DCm7Y/UgU/yS0vMRX/L QhkUc11FeNPJlGFzNjWOBle7RNzlwoubDWloljDD4f1TKaeMbhzpXDr1iMK2nUM/7NiqtpOA TtaOByacKTQNi6ETPdFhSyn3rRqI1kt04zS1qHTNQZA9UhEYON7KQ6m2VIdFr4zRIRopD+cf BKWjBaMCpBCwj/7eN+dXWaHSXzWDwQ2O7b6YGE5Rm0Kx3sfpCriEEWslQtXGNuSHC7sr89Qo 0kPRU2ChS0jttcp0rlfRKWpTM2F/zLJKpqVw8+0w1xBsl9KOz0Q9Iy8eqANBxt8djgvDSKgA VT7PduKTyjas0A1O1oG5SWKCEhd7AOLPWQWXZn8C46Faf5Ug5p0BvXispYS580E7PFPzMJmI 60q08UwMzP/U5ZUCkm3g6D16gnfymOa9Eh20QutGausKizTt4WjRG/E2fvDgQb94nFWNeI3v C32QCg/N84XdJgji8h2ibNIHDXeH8IcZYFSK0k5e2bWBDSvx5h7ISusgYJUPNJiatFGHoQWX UqlWNgmIvzjI3S797ri/IHINW4rKRuGOlCUADk3/S4udgAAb9CyK/LBjMevRLXHrO+Pl9J/F 6Djkag6cCLJ9NhpiE8wDauasvx4L7AzMKxhGyN8kmH7bMVGfjNmv6fujrIB19TAePZ7J25Ke Uu25GhieaOxV3bHubH7PlOLi646tKX6i0OwHwjqebKlTmnNeNSlpOLCfzQcuRuFNhhgsyAz+ liEYFAn5kJo57Dgi9/A5nq5Np0KR1unJzYlW/qpwHhODGzq4yALvdsxThU7q/zQw7Ito5sLS 2PGnSXqCQZYlgm1FCFEQ3bOsddAUOzSkkGd80oSzjP9x6nRe9fuqqu19OTaMV+N6KDtA3637 gdy9jCC7C9UUdzrEQXmHJMdZ9zpcXW7cRy67HODliUsg/Ck8G/XoDTbNDfPksS3O1NVV2pYx OvgCKkFwIsdDKjrMi/ezW5de9BnQLq4NDvjW71TGrD9E8mrkBY5+tEpO3rWBLNf5kTchn7/6 5KDJuIQu3VAUrxQPA7sszJ4hKZfpqSFJg1/5HFHPKC/iJ58+H4Co+fAyTMl/gdUIo2dT8ly7 xA9Ev1rgbC9qwKAODTXXJjjAMBeGprcvJhJeQatS5cpvnRU2B7jIHuu1W1ASckbO4r9CJlaI ZYTPvOjCJc6U5rACKBRwHidZQRldh7eMZ0V8azSIv/J+rlymsDfn9F7deG2e/z1Wv54bC2eT APDDeKkk2scUsrHM1zJkck4+j+G1mMfVWW/ZvTx1lYRakGLW057BolJp0/K1/+ozxxhjTGz/ YsCQYJ8mufvmGN/wA5bH47dDjfMESiNEQGKhtOvjmMMQrtT7X4DXo4Nd15t0uHt67UtAWEOF Z4pnSHbcMiMDu4BhKcuZiNq9oNbyr9ozUWZq4FJXW4CugguIj/NnicTx/118/w2vEhvaJNVa jnXWxt0nwgT+IomHzjDzZ9qBz2iidkui7QkfPXb+Wt11m12bo4f0gUqC5FTYeTsfa+XH0v5S UpcSa40x3GydtuAIcyXKKzB2NYABNAOaTvDHXv9ZKhTVOszVQ45afkhAyD8o+1BhrkOSfAck o6iIGPvd1b6Muhwfvxbd3RgIPIYVlyHjEenXEBhQUPqdHjB15OvITrInvb5abYub/Fte2DG2 TqgXojvdlZ+rqXBlj9EkEtxuQGuFlBx4tmd2m0af62xlqyDzzkB/0Zy1LwTbErqQkkXAaBMj dQ/2LNvY5E7VbHLfB6IdszWXQ3Os5qCUvA2kfKXp0rtTZ2+2qDcDdbm5H7tpK9A+cwQPMbqc tDr87gjrh44uu7OXqMy0yJt9tmyZq9aZhkNpQC2jzlhgRXxN9gjzheFzE9jM7hZorOdZC6QT S2W38PVVWI6xaCoufK5rFC3G3OoZMxeF9/9HN/A8ZqcTMxZRi2p+suRDBt0BBn99OsodKDEY v33/HD/7I96CQJWdddJdLOG35xhMFd+STK8lGGmrkAJLagrMRYE0NgZBxrkcLuGuCxXGO0hj wF/PYjAF+ZLTDKqBeKnlmBWpFMAOruWGnU7MPajwZSGRBthnEwh3mdehTa/aqABZCrlOSuhw XdXuOHvTkqSxv/bH78HnxLyqaFNmOAtdZQi3O9QlgGdhWAK1BsCkpc2H31oV+ymAUHnXYYlJ lu2YbUgfcZis3A3QOuEfbQ/oxU10xiS4cyjfQf1JvbKH8yb3sxT/CbAB2oNKx2laHQ6uAXhJ 3U+rLZlkII7pevDG82P7kJbTf3AWnbbaV6zbqHJU20u+nbMonOnsO2BKmjwKrfHAEMxeJQd5 6BBds4YrhO1LtUeRgkbztToMmVOwCGGK7TobVPe0raxI7NcZ+gkLi95/iDPEeoIa5xIuRpFK JO2J/2DI37Icb+ppoITf/f62Y+MLd5syoM8hzlC0rspND19QlFcQ6OG0mkdmXrdCy9HemNCe WJ7REWgdaerHpTOJTKSeidt0G+XYfON9aRdTWHcwc1aBtTPMSTWG6dsTTu2nC5rXu9DPY5Eg Mtty5Sz8OtAqJQv1y1QUc/SlFeXumVWCBpnzZHK6ZwppjK7a9dHY75sMi/l1EnDLkZotFzxD ruFB/wyjitwew+vIAnqkTcLQK8SsczR83UZ6sPydEpIOQP9T7PrxcCBwW+3NFeUXxw63bV60 VXN+/z2Zo4Xb6Z3XqByR2CHCDU2Cl1gP1Ipuk9RtRyYwhK5GZ6Z2x4Ai+AbbV7sJNqMiWrGA QLOC8TUyVTdp2FcB0cJPaHNFVqX4VNsNptYrkWBZvN5w/XYOApOEvKwmC2WGwxkB1LnY/aaT U+uN/wH9Llc/gJmf5C4kbZkJ1lXab3ePK1yBM7Ay411QuCk90rvDn3tEPXzpzetsFRQNAA/u P2cebmTWbCn2BIlOmyoYq4EqGXO/M7ov3h9NAz6XfBfnsCcg0ms+lPkRZd0Pxm93g3gEtkfv mAoEL7gKUUCoJsPpyr6lnp4URiRkw7cacWkA7iVpUREYJWjq9nJsOOa4WMCC9ieEvUPywGY8 p8hwbPafn2R3P/xLW2rxi2NiX2ONDsqeipllwoT+rkaW137ce01hpAg99rM1m+VYL9/3bZgG OJcw0f/9BbM+784CXBvVb46fVQWIrT279qY4QRds4k107IRXvXyE3TjOhHQsvbNPzTb9rkx7 xIHgJnmCvSrjigx6SHJiQV1GhrCQU6a+HxUwogRiVBV8AwskcBEcpL2gxPvLto7ckXn7P3rF SpDL3tSZK0XgmZaKzMc1bYsp7KnMtJ1psxZeAx+nbBttfJwJMqAY7pFYxty807+wiX63dqEA Oq7bPSnED+SEPXURoBRiVsAfCl0hWH+dm2gMTQaHynFwabOdbVP6oX9AQcO+f7msGUJ3uaod 3GDBk7wyKqUKZCNkfSS4L68GWw/FQZLFraJYYTX/JmM92ET7ER7IVw0AYMfCpwB/C4w2iJsm doe4q5rU7X307NC81QSzIugYGM+gk1+nFuxTLwthf+LCcbUw3QZNpLpAmyN7dkn+HTX9Dg90 0qqUFP1t/mULFEzQl+p/AcwSJIxc67H2ZLr1ij7WjmuII20j3Ck0MqkSKVDId8iK42q3dZ0D QDYpOqDXLIs/+tmDfuQ8SWkH5Ew6V5mJwK5pkO5BWvOgeHljZ2MWiJtDgHWra8Z2v65BXL0l M4OjybfyOsjRo6vhOwNNxtKVGv6wg27XXm+CR+EllFXng6TAwt45jo6VbF39gvzdkGWAYSdx AB/Ch5Exl7MGKtD1eR6mXvGcilAbnpfdepAhg2XeqlP26BDZz6tBNp3aq2TAjkacBkABeqGW RLEGuBsphV7q8g5cQkH2jafosqJH6xKpVP/HEy9oJJQ6V16ECDvcd1xYfqOvXfNzYNsV/Hz8 ICgA/i9r9sPfMgqLkJYyAO6v9G2ToLLDirsq9qR9DVk7VbMM3l8DlluiBOzEVB0FsJzxFxrl +WQPM0s+WRnLCCOJaBLXFU+N9tW/RLLtUzF7wm+Gv7AoAmbGHxob6qqGxhjHn11GiLmAPdsk qaPQazPRG5Gcd+6xqSBraEnhu8k7STWuZ4F3MaFZKHLgbzaANMnAW+yct0PtTExKZFYrkGyC XUJ12mH+sawHzKHuptUKJX8XwkWMlTgPq5T70Ho4QhLKMMlzi1sphmRbpIlXCxPBSB9Opwg+ zIgbWqm724tQk4QF7FBaBZRUKQioKdG3IDTYnEbZZLh8t5ZISeENqmPG7ghjDVc+csRmFj4W jcz8pI2ya5uCRqSvm7ymyWeYyt1kvowC0KQ1mnGHsp+LJGra6/CGL+R/kyPjfBJPrMfddXkX BBkvbe7co0K7D4twje/l+ZcFaA+iHKiOyfBWKapeIgoS/jsS3iiMGzkjHRvQZyYaooi+7n45 wmSd7PUJu634M84rcH42xRexHakBKr+9CBtUZ8YQFHlAyP6SnQyZzq06AJiyVfTJAPm9swni kToHzjaHT2htlXKQUFykqtR8gUC4UstB25dcDDuhDBHx4EXVz1xJHofbnKuIeIwqTgiCVFBv cHfEUHQFF9VUGNiFAPEnTGiPi7MOXXqeIEI5dcao9Cohn600sk+avOYTMZ0KUIGNOC1tXdcR deXB9GCG97eMO8iUSFb/qLyHL4j0JaF94ZDFsK6OYRhp1l51/aCsT2LCqm+NE/DFBV8Ye7a6 qY3zVtDTejbTYM6lze3Uu+RGXcDb30grmgCXg4uo9CBz+Hisv+puq5+/Oxd1mHw4wUhSYR8s f1VBQeJtE1+tCcjxCx+/idzgsDu1MxH1CNrglJeLj1KptQ763HMF7GtB67GvTFpSHYdrrgDs g12AAHKF2dYA/BTx7Sr7f+8z8VXlU45LZwNRCrDE20B0Z3DhvpXPEqkzCqEoTuGlEfCng6Ta mNpkLig328tS8C0UA2jwEfCXwWZ2wASiJfpuqGWSGjldtLa6TGY4hDDNaXU852uct13X5txP wi9NwAcB1ioAWVZJ7tw1EBSBRyRYXlofv+1fpfJYe6R+t4RAMrA+VLDtzjOQa+GVQHgg3x/j i8u2bHjv1KV2ZlXc3BpdmLIs6RCJmgWu3QWLprEEdGzb+CNLAjGtcppcMbeMj7gmFSOiYLdI /13ALu5yb1koV1LJKXlzcxrXm5V5+kHWA5IBzSTn2nsER+UO+3AIGf/NspgcIWORTTktmCeY cN17ArYPZY5S6meGjS1hECwV05F+MjJDfbTaAJLCsA02+pDfeRB4oqmDIGwkGcd/uQR+UQ/E TG3Y5CW0KJtPs3ExrX8AZYhgPX0/dd6uKY7/sz9a2P8l9hoMDMYkp5rMu4jYKbgOT2vYj54j jfYq75ESmQkUyiCEpCIK7RtlEgvdsrCDqPSx2nQ9Z9LuD0bNVOE1xLn60kcqpLlsB7cHs4rE gnQFeDULY1V1IldlL9kJpkXSJsZZ6S+1fUSSX4n+3BqwqK3+AkrnhsBQ5ob8936+FLjaGi6t iRAx75sPjXP/dndVJdddzqPwnaKAp29dau+dcB8+TRekA3lf/JxQfgbYt9TlNA8ZJmrHNaYX Wvco5ODaC6mISt41wF74DkkWzx9rrwlfHaWKHsOCFwumBcVl5s931UBkS0hnktOt/PC7zxRH 5RHMGYyLj4qAPvkOZhX2qfFa+DKnGzdOHgghX+y/VKeEeJiUEMhYK37Vyh7uvg076OJeCJxF ftnnuAjTjklLpb+heg+p5mYO9sLDczuhAmHXHEOBdS8K60edsTWd1z+wk2En7cm6CNAn9a9M lCMNLs3pkf8nwWEWVJfvE3UHEGYsrYqr15pHPIPqPsKOlRZ1R+dOraIPnoyAm7ux8ObBDIyy vzFP0ryCMSeSUGhnOoPSWFSrAl6bYnJme1HtQivBaGYDWKUCmeiKvjSO7GQoE0YZUu+J+jSk Ucz3E2OfueAuCXIAflSdy05fdMmUWXz5CYVhsWkHHmKG1lSD2jVr1ervkpulgCQ88f+rXGZJ 5J5WK3iLpgERHeT6/TzgUyykYkcskIjUgkiHy7Mn7spUOG1x8iGY1xvI9GFuCMNJS0wngX5j IxOTSgojwV+0rVd+VqkSTlAYHMXmH9WG9ca5bGC+afTz2Dv4dNbSKlC2FMNNzp2Ed2pKcyre E9BeCgl/w46Rurz7b42hmSWgbsDEl9KWgJp8xHl8dgwvF77RQbxnmNLIQ4g289nTxZ65JiNu U5k5Sk87SdsM9anMQk2RdoOKKZ1K0He3skgkLfp/i6z7jwMLI5uM1iXaIjnUh3e5fsNCC7WB 3j7P44IXjJnot0XgjNitbbkWHMc/v7/F0gR6HlFITaKZuDbTDXNhromDootWJdlXeZVxxrof mJqeXSbq9wRDGgIH76XRkwZ/xitQl1M3lFb1dKsRny316O5c9HYT81uvxQW2m5m66emLcP5O W+cVNSK7AO+uCx6qk76o49WC3YY08izTMz0rBRNZSZZT/kzYzvKbQWymZ58hpmgdK/QWYXf7 tOE8sL2LbR1WD6bVu61YwLnyHeVgeSJTYOmvpm0Y3VOAr8bR1CrGkJaV33ovTPO7bPMH6YQ3 Ur6jhJgjlxNcEpeBn+kkA9ui2TWzRbydPTNOS9aAoFrgZl6kZcaGVUOKPEU0H7jHMcR+7x4Q 28f5jE7g5Y/yeWTInQkP8gOEgKLd9W1TKoHgD7k8dFirPXdj8XcRF/4YpTBWAl2/J9uIlloS kTq7lWmMZfnv3zR4TYE7cyd3DLtRXJ8NanZdXLt8stvUNREpiPM1gjQ1e7bj+DDyiU/TRZbc Tz/aGPDf0wzF9U3WjDyfg192A+Lxn1iEUPFnRCXJjCxW2tSdXg6oHdv4/DG5EYpoI9bYo8Q3 tQ0c1bl+cMoEmVg6Qqu7A1rAJhY5L2ml1s+afyE3wIbwK0NXLWljj2Bvi+0B6ouJM4GZcShU 9c0SytYx3ny2YtV58DAKe5c2YqJEWmursA4RUZmaADwVUL70cslCEW9fPEjKt4ARzEpfTnW9 tJ0UtQrrorzequZ+0r/LlxgeTGeLrmFbsrwWoj1nMrptlUdN3a3vBdqpmYohc4E7UT+vF4cn cCJHBXeMwLh/A2ChRaOqysAZyk6a8iFg+AgU5dkQ7wTehusLADJgLX7HZlg4mEErvDIQlhPN b6mxBghAtviOm2s4etCMjHAf5Fg93iyPTU7/F5HQgWXGoAS7lzHsgThJYcFCy/xd0oXGu1y4 sT1YVWUtdhKxrM+KcZeJIltBZFKw87enqa4zS7pSLSKkyA2hKBLn9zlzN3x6rih64eEVM7DP mz5Rsd7aLBaGagbj4ohTcBif9IR2AUw+ZOGUyCL0XD00P647lPcCukk/A3HJ/02V9csuO+/u NW267vW5s+yc0bPgBKznXSeW00xY+mSiX0GyhjlG3uKkxUzvXUShn/EBS9LsOjHWcrGKdy2M sHQUR8odUt3qxy6eRMF2j13SvRBJof5sKmLGhCt/yIxFIjyy1TNAK0En1EyiFBJeZTBKsNed b4q+YZ9GrE++CB4FXhMGnKIQonWj43plDyBiVIe99jr3qvvhwx0kXWmlDz6ZQnaszHgMkMIY Nq9WIvBhPTmFIu7E0J/sPj4leFDPhKcDGIaQBKmpMiru3D0ft8NSzd74kv0GL+hlb/Hp7xoW QF8TyuHLG0sepycypzFJHe1MEkpeMdn9hXW/u3t32tb8pTmaD01PwT+e+DQvBFkZ39YsFs0p hOwJp7UeSba1cAd7UAmrcdIvvzjl0owl0anJ1CbHF8g5fZlOQgPnt5r6QpiSBgGqNzITSl0v KHVUiB+vVQc6aYU1nF7FlWRNHrJRip0EyqEKXsvnSyNg0tykz9vYOAqIoXou+mGm5nOw03z4 EapZhASmHxo4puNMh0TghkKkO9GmDkSW7hzSwpFSvhU+8JI9yyidr2fa5s79HC7eRsWwsBpA eJcTx6PXdXrXnRsweEVNfTfST5FW5DhvFhUSqxL3ngtH/hopRJV9rDKT38vqVMgAmkL4T+s6 6AKd4IQBXkFfDEKPrgG0pxqGiV5CHC1iCRayU2IUWDxkrjO79wC0GOU8Bgynq0BdWQZuiKj7 MxhzAwN0T0ych7f3Jspes9j2CasEKJL8pb4NJpDJzXK+HTyzfVZ6FcQPPJlEjFInWDTFBiKN Lqyr2HPR6pAxiCdMZS83r9MEsHbSuGZx1i7dNbbCeELXZEjmIqEs5S247jzvOCh+uRXcNSR5 ljiU1Yt/NByB66h9KG9GKm3dKRJseuRJ4OIG6FDGvkJK9qN1Kj7R/FVT83YV2UzXfLK8Jyyl hoSqyM3dJiMYxmOoLEwBBsObBmTAITV7mCPxWxQu6UuRGjX/RyrND3AzsIiXZFApKeOM/vuC 3hkmavFRBov9K23I5moPAz6qjN7L/x9B7NOX1LSNV50NFW78UKiv1U2FHk9e8T4x31nZd5yh DtVmSorOEoR+VwzgGUkv1iiE9yMqA+iwnnfgINR5NoP0SdVFNK82FSYehnQAMghla54DHJjn LqOHnKijGDLoukqiKAb+Tt035dLB7OvD6KukgPX9fZ68ayWitjSV6n5wqWobpjwhn9oGW7H4 UKCZP0d9x9gGahtLBfmQC2QEico8AvDvP7wSviZfhoNt+nJzAyhpGg01ZD+IEOVe6XlDcpZb 0W9FYRVZ4BxxDAxu9SQcunfPD0+qGvjCdP3jNT9d3rVoctlCg2er341TUlQLcsn8ZZ1ubpQt Mj3jjmCjcfLz7T9fWQAKY0Pw9OzFDme04oQ3l12u8QXHO9ZHUGEdAXWkxrfAqvv/VzqZtcOt 6tIeVNDK5Jp5CGvrCS2+/8+pxeB7Q7KKc9Y/hYNDF2X/15tQRBNatBzfwtubIqJ+fV1l5Gst K8PugAi8U2k4RDCtQKFw0rSl4S1/ToQ1C/6JoKHZW5x8O0fec/JKpVnujSA0B/QN0Xc+TUtJ eK4q+lrxgpgFQ8rUe7ldBbVuSFxT4JWY5ReNZYEGBF9N+DrzekyU69ZBorWzkUPIxYuNG7vO YdPGf/rkV2mQs/MbgdqjOpY3e3IV+0WIJN9Zn4ojxvwOTkbqVCzyeY9k86BQrVLzlZnvCAI0 5uz9HbR2wt7Ewdoe4zIhFngI7/djSQ4fjzR4VSEQ1qMvbl8jrxqNGNS2V1NqKtgTM/aobpeR Q4nRuK6k7j0lvd86O2WHE3rYqCxBn+uD+Iq9XFM7PxMWB7c9jaex3mrCA9EM7sRi2Xj+Izpa i+54Blt0TXLFpZtpmFh7r436JICPwOGuI/fPrcLxgsziJqadiPKAg5cJDzWMSUrdX8zSGjSH GKEPC8/81Z+WzOP5j+rpdHrUtWRZqpgsYMw5Y5IWkL17nN5IorzMmJZPGw4KkD/a/LMAjjls S0B793oCQtT9+/l/8NHL9KAFZQnDbNGrXehMxvQtmfXtdoaS/5l744wVvngUU3d8gP4QbzNX J8eyWNQPiDf5ELGvL3xjyRAJ0ChS7SVqi48LjOmAURMnPcVTDChqHdvSR0zqCY2k0NHN+7F5 nArDFYVz0hpKVcjMfBstxDDxcnqxFganFaI9WxY5E/pQYGBizPlNivQOzCROZLtNUNVKAjbY POsSDiADYWZwwstAv1Tg9s3ECedIccM/xyz12EJ5/gzSHSFFS2Vk8e8APRMt+2Xl2Ewoiz3M KJmK4BZ0QKavG6wtCZrHqmrN5LzGOBYg+QjQNberV4uHPl2tNA4GXiuGyHbaDTLGOzQY4gtK cwei7seWMM4Qv3l14GosTXA7Gz5xIN1eOcNC02ioEGmEDe3g0Jmx38joQThaV8YL5szUXAPG zh/qOQwNkePPwQRfB25Nt08JFMFROeZCKrySzksEKUZgLn8fQy21HLow2LfH/Z8M45ulFzCn qxT9HwX61oT8NpYNLZigQb9W9hRwgzGPR7F0tcgme0tbibTX0qBvZ9uVUAkNDiK517RjwBcW SxNWkbgoFftJOT/SJJa7BNR5tzNYut/E/QJrjxgcrNm68Zm65Sky19LZ6rBV4sodavm9UUR2 Z3bSER5sIf2TBHvm/9PCwv0/mEz4fym7bDAF/TN3X5bnPbRbtFbdHGiJUXguhzoJkQZWMyi8 OYpHTWBpoabHCO4BuOVKh2G3fPLFYAZGuSL2OqnO0LgJoiI1pLAOS0Nvbw1Hkvo8KnzrUBqU 1plCXN34bW1ZtHGegb6xc4eb9u0AUwRX+C+NsKp2xcDE82srpbt3FNB/KD0zMfzhSbcsqDrU +sLokYeYbkv784WDBVuYXb1eIMtC5kqMvB6K5yJjW5yy7ROlaYqNVOuZK9PMbh+XbZ7RFgzN cm/beBqnFn3ks9tK1u1OVbe1yp09wIn+bcq5jBKVHOQPxeAemfQTGpHuAnR5RJobsfh37OAS bP0RfVsaIoUrQVRwZEx7AurK6IOkznR/rqcKYfeTmLhp/s3RN3jh5XzyUWjsZ4lQMjn9KVNQ kmx1Pyke9qKVFa6lnn/jeNfYNXRlPXBKDA1xdtON6dQselO9SvOmqZGaoTVYdXdse5xx+S9f 9kR2+xCP10taUm4I9Pa9EuUbP3dgDr9DeElUD4wNhnzDP7TsV2BrSlCs3MppuFISrGglhOYK ruSumJWCV/xDUdh7K5IGh3XMp+OQMyxETKDvcbJGtvzAogVi0LU3u+iGTA687dXCmSeg1U/o UFQp4DuflNvGh4eGUWI3WBTjxehhpbr2N80skFf6iWrinTjXQRZP6jXvtXUL7W3WjLxvbYkf vbts/4tEFSLAmfdl2vRhu9QDl+hfx9KmnQJRo7vK6kfhVBj4VoC2jZ/Tzv+AGQkdIhFWltpI rUzCApoc6GS3Ksa9e7DBj8kq4fKRP7oIeP27U1MmJWrROgNMGUQJfqn2zIGAGu087RT2wlUU XxlS4dcHh9EMurpqWLAVSs7hWG4QQbk4xcHs2PoSTEfi4kvU+Cg/a9MbO9rnodkw2M/UzO11 QH9nBU4lSZYGw1JHKCpVYV6qAHm2f/+vI6+ryIOO/9fhsGShnsrIQ5skeTwLFfn0CuWelmO0 Txu5fiVOUOHOKpA03J/1FwyL3fqWd6L4+nyuHEPpkStwmiilhPzTeCPASkL5ep/VSbEVJ0Na ZallJ0HTps9Rah6kQh4XQyFsx5HUeaRI73P1DWiYr5VJg+tOAo0Jn2lWX+D9zK/pNyh7SvXy QxhJsNG6Vd1doEGWdzhPcnMICScFkEk6DF6JE7sBReC4Ol88lm4oN8PKuBbYkdg7IynQ4ZbO IxMVnNKOEVzdB4ySLheajGDuVBNyThnqReF+qdlSJG3nL8mo32STkbv4qO9sUOKIAu/3Ym+r JNB+V4t5TM2H3rZvJk82tniuHqe9Ebwti7vcf+5LZaF4KhfqVQ0AbsXszG0BZBs1GFeSPRis wWw3ReDNC+XQkEkl6/OJkL08A/W94hWk/mH/Ub5b6lpIXA9KYYDg0KM9hkq2mdO7jr3ztMoJ VldUi/XlejAO7VzNTg8z7jRjZLRMNt4/AzTZeVTwZ2EMc14TSVdE62AxT/cByMBiBF6dxbBp YQagaYHe8HvMY/BG2FbPKBQv+1RqswQ/W2eVWHWoOmJ+29+G9OKN7/eGf3k8t/EzbotF+AdW JBpmShByQn3Fe2Gj9dffLpRgJhlBLOtbJg7nE48FCnnvC5EkBVH4rEuk5rO9wf96aEJsNJYb /fbnhXxdzQFRBQNPTd+nncE+t/WCGp7ivuKIoEZxuanN+0tlz/dRLx+Pi1CrpS3bpqUlL/+b LdeJgPv0l8FOmhC5pbq/2zmfJqQ8+D46W1VkuozI33v2/eC0S++SRRlpAFd682vmhr3hRvJq qrkxsWzYCf2Uq1AWM4Z+2BiCC0ckoWzWUQo9YKvWsrEoh/VEpMFfLaZHvBmejgaIPRcNtZIf kI0uRSJxROIAR7Bi61uLXfDZYdKxU8QYvNgjz06HWHiz/37RfFeM8EBg0WGS373x6h/EsAW+ HoT7evlAopBZcVURj31EyqG6B71Uu38MD3Fyk/uUJ+ragYaS0ZjU2PhUVStGJbgwu85Ao50Z 68gwZyhuIsEU9cOayoPk+ALnjKnw8STazoNSunpvLDCQ0eN7MkwL+wZa6idYKEnyzk+99kmt 22GuKMFldbYnU6rGNBzN0e3HZpjoRH8bUbJR0yHjuOAnry/pu/1nXb0x0iQySf8d5ArlEIgU IEoQcdYwkSuKdDd6j2elLLjTKcZvzH7OXR4ON1Ws4dhxQ8m5Zd1vjpy5Wfkfy+yxnV3AdwKk 6h8pq4itql0ivtqlUwGLMRiwcQ58j+wi1XzfRGxWFTGfXuwOnZoVoC+jRdzg0wg0ijhwozQn GCKvfC8LXaZzqlm/+JfPJMMIzCXyZHr0CO4SWs6W59jjHoYjwzXE6LVwXbwkuVncpHX2il/b pxGmsC837ivi+BdVUBPemE9bT+jMdQP9Mt9gZ6hxIgbAPQ1IQEJcJ3WG/+DmS4FQqMzpUd7V urJwQj9pTSFeLi5NyUHZB9DdJ7U/NXW1/rNH45fm/NRmdTaikZ9ULvorpTgDK2LXmNDuwUaL e9yEHluf3AqcD8zF+yHEVX0cW6Vtbiz76o8gKfxGz4pmUVwDtnhqKfHUeXrI9xrIAaGDr4IO lfNiNmt1MGKv3YY9YxAv2CzupzB+ay6D4fPIeXosnZ3m56BUxi4c/OWzpvswwcCag2Oh3m5R ema9k/jurx/uToeWqzuDqJ6L/gHniI8wKcHUuakdcvfkd01U3O2i4HWnkPWjafwoVyZCvtEF 6c6tLB/PiAprdhra5HqjB3aG5E6qQeB3MDfQ43pTY9Z2bWpJbKDUexaAcFFzKhGnpNucPOux aP+BK0u5qfCJjlP9R3sKD+uKntKdTMPOS4nMQoMHZibsEdaDewFq3PNT9rJiSr1bNr/vIwqb nGeis2HwD6BKxGS0D1B8FAEeVLGWRu+5uXa8futjZtaM2Mj4qJ8huszBgfI4QcSKp96AZONS fruC3YlPQyJ2+DHBq349LWf26J/69pairXhCOFGjb7M4TQfvRF5UixufOreIjQltb39dvULJ w5cNOM9FXLzp6rGv7mNSQvBzKivj3xuoOBdVR/1hkzaB6UJZaZCaADBJ4sYBDsRxC6z1L61X kV+ZS/WlBVIYHMcozNOFFcRWSiSsT3K0IrzKuMPO5sGYd2kv2fYncJaCAQU81FcU+CTYhJqe z5oplsQKsnDjN4j43w9NDGgSpb9LWeLNcCsQ2Y/EgY+TkNfOpWjTMz9pgU2mSc1N0sZK2NlJ lrEcbxuk1AcVn8txkE2pqbL2AnhIK7QWyozgWVJSOwrF9jmCgxRo7XQyouNPrwBVFndsChmK hELd3zdRzt//feI5GMoBokQMD5s+Q9MAXNcaNlf/TRLzY3A+hFic/E1bR0oosOfn4l9NyWas ZmK4vtNU807QYWhJh0GSULMGlio70D78hlU3598zsqFBFhg/sfzZyz9AWpsO3bpWmv9fyyyO 8FPG621IpdtR90jQmO0J+126uQAkcsWZtuW4zsAOhjJB1FpQ4C5pWoI8VHulJyMGTT0zyXHO wAZDpoVSdABISCZgfOLndq8A73AUxEv1kqFCsxRrC2YSzIj9F7fg+d95P3hAi1N/naohyujY MA0EODY0aMZvoqAqRRbkIEkmivs9uEt7gsSdhUQ2pnlFvCFHZ/ugxid3u1QwZ6qQVwmjKt1U 1aY4us3u1uJbXlB9KYDx0m8jXMMWgtud1ncw8ULLqEK88cnB1co4sMSkwcTFPCLlOLSYGe1+ brKxIGnViIp6ESu0RijD1LSUyqqkOY+OcGiFlC+/IGtp8E4iFcNUfGKOG7BXEnbyio8T889F YfcM86WxT/J+eDuTYKhveIWo5UHAHt+iFjdmbOq1c2vDDxig/ZO9URSQoeFG47hfFslrmxJ4 D5ely0bdLUOW/CS/eNo7yhOoj4jqYU3Ukno0kttOQal+ZcBmLUwgu2+1Hx9MCYlZfwWO3aJz DX5AC1OyCx2i2VRuxwyzSoO3VwP592CMoz1zB0hGRskvNZQZOrpwf6Do48XcmdfdHjcawo/A FmzPj4YkEwoC5XbHmum4ucrjeo+JSYXkC+0jFWCKPy5lVzFiPwaWtXiygLarlUTlBlSdlpnS gaYpK16ewItCgJOkfPhFqRAT2pe5q9UxS1SQ5wr6lsNn0JgcyfVr7EqlTIbygnRwuUmeWFFG KGxiiM18CIlVhXvXB3hE1J9XN+2Eo/ZONQW0KmG6Vuc5SRadhSIWE7M+9oFEllXCGz3u85Me mfNnkfMdDbNcHU0V5MNThOHoeudFUk1rGmzsj4mHfm8+xJEouK0Txh+0npwpEVR5tBYYiG2t blZYzdOd77hCUZLJwW87eV2KWJ3CL9J89ebaXkXI8MGLM00QG5FwQvShdChFNvByoBZFVkMv Do/QMY+GN6oT417yrnpLXI7UoH836U7hRv9CxgEi5f/++d0F6MIGGhwM+z7/dPU+gIDeZ4f6 DBRucA7r5nz5Z9pnld2ZVE2pFXBRRE8AkW1azUiidsp7Ttxo86CAeishS3KDo6D3863c4Zqn x9muV7qDN/UTAMEmd+FuMk6YlmrzKXJ2pGESr44Ub/vueaXfV0agMUe341v8VLEg0tyqa0hz JKTojdUFQ7fciZVphbzifcETfHxAIsVhHMi0RD9b//r4MiDBFeaMd27DwLBy9h80t+BHn1CR IBjExS00A4ezWTvKOelpmbxE0aWx2Vsck688+NuPq3ykVJd3rv95bGLVConJx+VYmQhn8SRA oNBgViT9cg3RZmPQpjeemb2b4/LiGlUVt5iU8hAzQMtENPcRoD+ePr5RHqI9F3hMTj7JnD6g SwID5s0HacTSHeQU+/EahSy2SVOWx6S6XLtfprY6aJlN3lE+uFKqRbUGtDEWBj3o/hAU0qo7 j7zqdKTj76VFfOVpiIHY+1YfYCB5TeDgNGekbjWz1xqiS93wlq541JQ7RrI2XK5Ij+wStJFW ucEqN8viSf0JurItwbNti8stUogldjzgzo1VnrXeQkgTpXHganacwQm4r/wTCEVDSIcwyOQq KHyQiNln/fF60uocbAlAbokhhB+csUhAOil5hYq5HiSV6Zg3Rw9uGr/J+pGfwLhAv9RjKjuV hLYCwR0K4LbHZepVE125xiDYctmyeumZwkYp6bVupAOW+luRzJBOY1LArPIWGpdGukwCBW6T nAnsPDYb+bKy/Y9NWcERuUffmvrJck4fSOeKeQq71c+t1p3hu7rJZnp7Y7inOPPPt64bGXYF 1AwG6GCUaNAdWFaFhUDXvpSrV/wQ+4GZnl5tGXxx7VmEhgq92gmMcMcGNvJrh2ePllXcC9iG JVEUOHkT3+8PYKfLE9KFOUruiGvuYRjQbmDxmikOzNxz4wynAkSGzOLUE5FX5FCE0pPOIgn5 U2cgQCYc2xtNPJRgTm1dp26vtHrFTLjE+UhwoOghHDfOAGTXj8v4fdLujf7orDmHWs9Kg27g O0z1o86nYyZ3jd3/h1aqOsKjEw7hU/o5jJsGybG8VRpDjvKCYSBve+zJh80iPDDFK9QkSBC5 3EQNmxgWde1kY920jJcG+Fn17x/KjNeHnLum9G7NemKPvXUNVfwLImtio6uKAsj/hAvUsZKi h0avcNUUWQXKV/chRIBnsSkQMkbsNyjnVbSV6mNH8e2C7hLvOcREjneXhCYL5Fnd/248nhLF rwNBs7RMM1nkXEqf5A3wX54YKQBIuXPynLrtSOEBk3+PB+MDRIX87PJ1YLokmN2GbwBQDtvq PL7uQg4bwYKhivAUIkGfLf5+z9WL+e/rfXvoLWMuwYMOHNIku4dBuRIKO+rxA8P+pmbAtfJK cisygyirPgj98Vr9XWjo8m5iQw4CDxBxYqdsQZ3iFhQwz3mzzpCrxz+9ePvseVK3XztjMCjp yjYOaZ6DtBd4Get2Owv15iaO+kgvPS/WTU3/urhnlmoydnvi5hiVE9yD2sKosORO5drsnIrx 29F2GNlKANF2RTKB10iCmg7ztS8W5Kpt+hIv6/tmq9+jN2pnJPmSgO/hviTrWaVugIz1h6Qf XIJCq1zSJpjM5LumPh2zKGLeDteo433b2hUmqaD9rwmsS+hO/9sFFfZhdaLgTvABedTCst82 v18/fyAqo803hX/SP6Gs7LSnGS5ukpJpfseDtTtSujfjuG1WUBD7suQJlbKl194PYHhIgp8e H1N2uxU2z9xzk6BzkOjqqp+kF0qTmW8u5JDivONO/VfxoCS1OM7IgOET6Mbc95t6TP3eTA6m LklPTrLFwVsB5XvCEAcPgkWoYsLFnpuCfWbCAikUvRvXDA7wPuLYk7M5+v+Hgmn72qIlIfpA hQTQseCGz8nsrQ0A4Qvd5jZqy1t1301JEelad/64Dy+7u64Th4VQx9EhPfCUdjFQrKk7B3a3 uuzmqBD3n1s71vEV1bUT3eHqviRBBIV6G6KTex9k/PKmcxkF8h5QjGA9pdH703DlZbrGpxPO L6VTm70rcCWXMCYeQa+rBtVODcYoosAjn19T9IPkfmKBE47oNCJBkVL8HhG3gH+ecYjqP7yH RMPAkBxK6u4hxV7rOUElwgA2HNcKe6BqeReG5pF+cR9WlVK8EVfRwg3UoakUm5sydDvW51IB lVgASWo33SOqaHEod64ec+WGw1shghOKz3l7qGLfdb8DsyX2YqDJ6oOR/djD37xxBb92ICyZ tD90Yz8LWAwkQqBweftBVL0gNhDE0n1zf0qEaWnv2mHr+7DFL+2xVYjPpix6rGKBDrAxE4mM UpzhgLiSvMUT6/3g8jOPzmbAWTugqV42ruQfnbWCa/b7fGYk7goobQNSuFWSVIan2GpBrPAI 4pUDDrYriLvGXIxBZG1MlN4JFFvP6aWJcFa5lbb1Z3rWoO1FP269QgDibuAJRkcdjhTGyQ6U vY5DhYAFBiU4SFvfxbaoevArlKiAjA76sS5vDkIWlVp0rIxKaXsk9/rYS+WcWHVEfKDSgCb2 zh4/NJcsCQ3jowWV1YpZAeCl229ZH9yXe8psowxj86GNAwOdEsqUt8ScG89LSbNsOLgPb1Ip Dm3Qe18aY8gfwKyKpSf+ZeoJyzXYmxEDakRofZZTtDkI2rN7I5KXHMiOU6Loe80+lRqZ8RW7 BB7YrKX6/DugQbc+HUf3zfEdwN4n7vOfOKccPW9mJYEoPzNgA3KhUaNwY4PcVUwvnZIQHlu4 BEO+oMz/ge1XhBu+y+lDTwAwicSFbfEsQ3GpJnv3DDjsArVZpfC1wYZDfNrWzA0btOtshZKC H4o5TvAUJjnD4ex34Rux9ojUomT6qWb5iai31SwneFtm/7n3UjPDWtA+OkNBLEp3PAXhbMcX NNfNmXGRm9dpaRolyVFKlavda7Q2PgSuquP8RMVxeYW4u9CpgHD8fB9OL3MNp+X7btogEEkw x99LZx1kr7BwYwqFsw1jli9FF5rgUplPch1oU/AKLDH6yDgBR1Mm5v+Zx4UYJkPqtw2BI+9P 1IudMlqthdl7XVSrKzWu204kedoRTScIpDhN6Ix6tWviboMMzNjd/GZcdaDV26CXIIKYaB0S PCP9eQdP2jqOup+DLG+NGNFu1fIr/74pSN1ssjRHKG/Xu+NM37Oy9kFBZ+Kgj+xd5Y6/XZTo 2+607LQjVzca+iydXRcSEH0IOj245+lfmBpysCzygbuvyNbIPWunvw6cUAkL2+7mxU5dYpuJ LarrJ/OO3XwLfUQvwooo6V9j3bjy608vw3OeTgB12ZXPyD9jCIXRGVe/O+fOHEpDSm52iecY qnpfuuf7KyS36T7NAnlDcvN5UNEQXz3eVzHunKS0a2doM92tzNSFdNP0lAAB4o6BLgnvLo2+ rxX3mB+qp99CKRlzDv4r1V4tetVz3B1aJEa2KqR2+dMe/nLQ//A/zhPnjd6miLKU8AKNGpWd ti5OGAoK/e527v0+ddDbicN9rxBz7z2ixSZzkC7/uRuxu1yqYQH3arTb9Iu+ccGKvxYBeGSw XapDUdfWOn6iRVPIf++KEeBYkSE21tzM9ugaTQsV+Xr685k1Mjnx7QHzHKO4z78qWoP3sCzH 2BwXW/anle8ZI3+KfHBCsbDDoJH2jLczlSsj8hpaQ06pSXNuTYvu4CaWQhjuc43fkHPtaauJ yEgtZ+1Alpe14slpnip5IQ7FZA6+im2rP/bf9WhOlpPfLPfMmZHRC8PqtRVWka8nYx4lAG7i L9uKDgQwubGbwsiy3NFBIS1vm9L+t08f353l0OHA5f/SqDLH+ftnzbnoIea7N+DgXpm38GCT Stc4e6Ok0IT1DCH4UxbqSjR43FKuylqV0pJ1fGrEctTLlIwAk5dQG4sF5H7oRbxRUfp0StK2 +ELYMI5AMGfwcZw9Y6BaLxDbWMsXDALHOlhNXqykzBgd5LXfHEdyNOXH+znTr8e8lTzRtMdr RMBnXSoR0ntD9dGVK3OYWPe+0r3h7uDi9Gvbsnml7/9QxD91viu8U8CY9sXWd7JDhzBe0KAH SSDlE4xdMkO6FiJ68uWt8myk7ZhlPsCQMgQzPRLwAjLQqJuf+bqeSsIPaLbkIS8qJV1xOj5z LF7wC5eZzhl8VUo4ZvE1AhAmNaS2tJF3dNeIhEKraT/HscVOm94fGO0UW1r9UXtlCzizSqmw hzrN0CVVk8AxKr+jRJA66YWc8YZW+hCxqTxExBEh7mI6KHm4jF88262Tue3GJ0SwkQ82HIxK Qj3GVX6m2ANAESxeccBkH4SHDm15AsvVGkv6lv5dL+izqWvyC0/6z+Lf4t3xVVWE/t4GH+Yg Q9LZw93BkUSCbO21i/DdqKC4r/pxISkDqncmOnd6jf0Nnez/5vl8m56bv0WaDdZBK0fYwwaw ZknJIbcZwz8gAcHllpQFelpGXuiZtP7VQk5Xw9OsnDjaj+C8/a8GMt4WTfOeLYZgDy6UowSx ZTsote9kgJwC67BBuXBUpaTHu+ONb3tSjm24BQFfYTeDfa3AfySW26uuRwK5faph8PnjO53U a5xiiJrDaSRtzv6eW4nfPFgaSiQknm70hmKxvngkYHT5ZBJVe3S/ejwGB2a2FKXcVfd17H02 Nf4motgY5IYvtlU5xMTW+tEcNyNJJXg2aZLKnVaf2ZzmjvUXaAJWsdwjVr4ywZEiDZ/bm88+ eawETUjZog7j7zyiXFPIHCfwRLXJW0Mipdybkk/eNf+7Y9OKTUxRyhpPUfs8iy76U8BPGs+Y Sowz9SEghHMURVtZRtlYlIa+NiJM6a3IG0ivCe9M4NFB8dO2T/GvbjBkkjR2Y4WUVE5TfsEm YT1IJ0I9qV1MlCtNTBaE0bzDBNlrmOf4ZYB8d4/+L0p/MZuRGLTi6hnuS2/yj8SBP9QYda3/ TgDLpPQzdJrvSu4bU6BKvs2mmciabeQRGjU0XeACLkZT1o3DzugAVm41Y+KNmYZb4GIYIh8i ziMgvWOTvo3RAXDRwoK8w8PlJF1BR1Eft8X9eJVbh1xAjv9DtQU1YzIIDaSJK73HQOkEY3Pi 3ZEuM/KdPEYQX3gq5uJ79Jf/nPlnhHU5tZIwn+lgVUt4FDHG5/imY6BMIDGtEty5is1pRTXp j5+1jrTSTJKyrFYtxbRMpfB2VdzLmG4X9WGIOwCUuSg8lv1CwQ4YDTF9VlXGPEIuInptMncZ 41fWmlOBKCFKAJcprqHzsHMWtQlfAPhTBgFUNuA71GM0k2PJy6EvhmZIx3pOTqClLzy6eVd7 YfTidaccyUP4/gWfXS8cJ3kabBX+87CMKf42Z9aaUo7AbM7fOLLSgOPz8OsCUJGCoR2/SmWE 8dhWbzRwlEUZ/0PTiilJ9VQYJgZKhgK4DGBnDZXZufc0p9tqoytolNr7wN0GMj74GW0UKxtE s17R40u+nRkzIZTxT00csRPkWg1Fw8gKEYQGalQwJQD4WO/NyNWMN3JAHTJTrYWkvwpZZJyn vzfqKbj0vth304tmDV+1sVvlq0r9s5/y4Bh8xySzmGniCStOyCbTOqtTMQOCbfMaW7uw+KpA sn5o86QzYQa1qOf+kbpFws3wUmy+2mNNNB9eLjYN4voDdQEtlU23gwp07nYbxpSA5RTiUdAI AEGdrR66v6d1D4izl0nVn2YRLg06O32Im07ri0asfeffL9N0HKRy3WnkyZy8VC22eCfFQPyI a9i2h3B98euvS0AQ7vHfjaZ+c0bwdPcK5sO3x9sn2idJv4ZzX2B173nF4w3cEQLkTlqAzlyg aUQM3KsKfEGo/swS0wLdfp4dNEHXm1MD70y4EYkumFN8eBDNaLzCYexumDEQclnYY8o30vuo rRnPkx3aBTF+dtw0XwvDd+4O+VqEOk4OV/7FZm1naoAoN1dtP/GJO0148/PFISqikoJsjQ4f GlT280FLy74JBdhViKwE6URCKPh+lNm8Gv7Py1/H2uCBghfIVcRLY2ZLfhZ6JsLVXmGq+D89 YwT+tITZu8xzhkG1192j1ozQQYFBiidLh/NQW2x2fF4G9XNh8jAR7M4KDrTdfc7Pl15z8Hz/ Fzv4WGLDOtx0QY+72B/NjJr/CQVgUDhHqDGFJ+G7z/FYZtuJPRzcBWcyu7kO6edLp1oL3Txe 2HMbsXqzOcXV6JV1+taLVIrDr2rALSRpC7ZEA4H5spFp+IQ8iLou9+laPyHyrDFnsmmGmsUW RVfGcFKtj/aDVaL/g6AuCK+zMhKTlLUwXB1hv9UyoQ2g7Zk7WrLl7fuLfslMBGngoSGD3fns PPptK7P8467KiPkUCEZkDJCWfjIuJ+keHSj7xffUlR+Cd+T2jR421D5Hk7yG1Q1tzIpGc3R5 Mk05yGpxJl0l4G6K6m/14kNnRl9FFch0I+XPrYNATwWZeBrwfNz5xkKY2fnvXDtvgiWf4Qba e5ox5V+4tCY/rzdMGclmLG9TraUd7+s2nsDfxvYHOvvZqEAEd0i/1g9G/hatYx8vVZlRseBs BHep0uHjCZfFWR+AJ0LMvv4e1f6J921D9j77Uh+E4Owe3r7+Fmpcu2+7wbB0khzD5OhQBqXL 7MchIfNnK2lYtfTJm8zk0RMFc4srFpJ064OP5jVTmza3B+68B7RQf6KjzZsWeceItSHGxBUK DB8+1kF6xj+jEwSaVhyJWkUV2033/ehTH8t5mx+3b8X2ojPYaVRUrYtdsCqaHaDH1IjXSztQ /bZhBUvj013lwrBAPtR5JK0cMkyh1NTopQk1I4CnHi/pMBSlIKtM1Xz4rMrWevNCPUJrfb4h vZ76vsRVPo+GF2GND2HPrDAibDBRjJnkjnMTUHm8zncA4QqV7c6mEjDM3nHVwdC9r1DTDuKj FBFfgS3rEZML6EE+h8kv5GXB7klaG9tw9kD8Pfih3R2gljpuIjhtaDyRZPhTsZyOhfkyM+LK tS/1U2S2AVYkcmoUIPlH0LgLhr0kqf4Sm2fGfyzcJqAknmVWxbxRufZ4hIGpbK0rTtnZKwka Q5tM+JAhKvo6pIVQAmn5NzpTPOzBTZgKYkgerWRTT0lc3/7161qPLJGDHFza9w8czpA2eB9j i1zgg9AvH4zpZerESjbSw5myHxcmna7c09fuAZ7T+REiYSxvdVQqeBkWJjtE3Q1YXN3teTNV m45iOLulKWpluPzmW9klaJbqhOyhyvJrNyFoRPJl/awKyWfAJhAfUyMm56bvYSb+mSk7z4IZ sy5G6mUaR9bC0DTEPCEn/EAiCVYBTw7nEetcsAvg1+O7/NXjp3fzHTmTAOUHBZ60LU+8ganA i47B6x0VMC07MkfXOKr4DieKrwg1Ss67H5a4EkMKbkGsNy1/gbdxvEzwgs3/2MM7Af+h2C+h 47FkVuAo1310zz8EhU7IV3yHEP99/+Nh2/wziatby/c/ruxo9cIpCJ43auYdRbrR91cmGTlc sTmZGuF0miI1Ix8fmMVM36CANXl6PLkVtO7YZOhhKcZ1wsmQbiiKmy7eqpngzfjYVCtvlhMK U5mMPa717YGYmHARMfpeonltT8uFFmoDGA0QE/tv/Ng49Nu+rMVGctmKUE0mQfK3E52pho9S WbmZQ0BQqCx9usvukL3927z6WYW5+dosUJ2J2z3Aq/G8QTiKkbtiLGlJrCV7msPjHMukmRx7 Kj1PyfZif0M41GleiupIzGE5AbC1FrwThbRsM7KSS9qtP39LUYBvKg6YjdJyceiHub8AICRC YmbnDGetPztwFBNK2cz4Dc69UhKWDrmfTHahmN7p0gpCcpvyLuUlT66xNUtWxSb7bj9Awb/6 5QFMJQm6LkwULqIS1Kv7lry6V7qHwB+wlJem0tGi9AB+5al1zu8PhvTCnkdsG0FXWfRPI/PV 8BGWVhrtbfw1aZW/zY6R+wtArL3rYcK8+vZ6o+XGIdg8txGf4X3KXgYMzlnvAwdfJoAGvi/1 mn+iWzs7hlalYKXJY4qP5vemr3eeE3fxbRVN/LS1qIkKoCAWoEHAc0vAOvMC22eqrW1zOXC4 QRooEFz4H8uzEhwOrrS1/q8HbYjxgjWlzsRrhzags6xzY6NclE0y5BYs/gt0ucyjfxg9WCuw PkcKw2CZhwcdy4hUaCnB0nmDw1ZuEAM6au3fjHdmvifWt8ij8zxAZo7nBlxRL9vH30LNPLLX YXvYKciSfF1gB1upv6XFhoX+jGKeQEZiaNUGBJxZdCdgIxmKEi8trpXesHOE3QZu3jEJ6Pfq Gve81xfoy9eapqGV1j8SYo9VlzC52Y9vlzS7lLFLUJ8qyDwuWdQ5shJpai/hWI+45b76lsdE t+CejH9Y/2ozXZUhxZ2R2WzYnuOp7rLoC7RGelj7I/WV30Gm01g8V79m9kvbdwCePM4LeWq4 wS+SnJXHX2MLvw5Xli6wTOCbbG1IEcJXBsIZgD+tJDrHyJXbvURqX5xmaEogZFG4OhkqsUSq MUtOMPVGCFDNkCYmhQFUMllbF9D1+i9cmZBGvA8d6hGMhip4V0JM4zHjDbO5cu1x4egAOPoi Myen5SFA2eGDelIIpatoh/t1lkKtAfcIwAV1FGYwKgpwYVIz4bCFMOqRWS9pak1DrWfByIi1 MOO6Vhe/g1RnLO2ZoRGbgkVUzDbRpqHPaOlqGC3gE1gEveDlCX4cw5wTi/I3y8tYrvLOElXS bk1PjO9+nzJdCEL3C171EKr5CsS7sc1iwu0U9pNEaA/tUN58zprEaV+a9NP/WNoPk3O8CMvm 3HW0c7qfLJvEGOYG8/96QmRNh7lTr4ZwVOJTuTfD8ySUL82k91hE02TUtbcEGF5newk0JPRF XnbPnvaJEAf0VLjD23UZYvehsGBM1vYUM245yVL5A1tybJQu2vhtaULYMTIV6SR3zZlCQjnH uj1cKSBDXMFIZMiH0HuWU9SO/IiCuVSgD3Kf3if5nh/zg3044II//qkWwLS1jXBxixscOf09 jjZ5Bb5nu7/2gh6fgU4Wbi5KGrqffPq6xw1doJ3S2ipabEqVNoPTNcJvXZuz+nLaSeGum9FG j//aL2+Ro6qAdatXBGaai5mrH1g8VFoF0T+EFGehX2sp+ObP2Yd1DTjpN8SguI/jaQy4xjvd xXpBpwHnELyuLQ1JDyV70u87ehgJAHANOH9KgKGuJYwIIVGidLUDEwgax221HKunmWJ+L3tT ZtK/UCWIqMhSiqpO3XF+9XCNNgh303H0BRjTC98iHHSLSw4jSIj3NvtO2GulG3IlL6+X4TRE mzp7SPDILcfutfnr/f/+3+QzBjg6Eu47wqTjKQmlhP0YaVekgedHDaa8pNgrgsYzJDS/igoY +Jlg0L8IHPPRjw/w67duqPasx1C3fghEP88Tgh79rIk50GdaxFcnOhx4PL2VoPccTjURm7zw X7hphottOz50TD2sttDlD3KPPPvzkNZHjZWMP4PTv971DoJyLIC2nLWZHlLKIvHMqN9NglLK Qk8BZC2i75DdF/LNcvopZmVKzgpYTgAuIVIdKwyytKsBfXf+YqKJ9rLv/48eVNnag4d41K9D AN+NayHng0aAqGxLFN7nUMgaXBMHVVx36E5qHHQ/BBRt+Gf915Tc1OlX75W2AoFyxeS9S18T QjOgjk2Zz1SpNKuLUo5cwPfuoy0JcMCPOHREiIIzx07kjgluLo5oozHgLGIZoP12/bVR1g8f IP4D+Wwsf9PhMDij7OUXygfNVewKmthULpvY/0tL245DmlCh3fFUlSL4ILEBBkunEMlJ8iVI 0B0apNdhvfCWM2kbXKvMTePO8teElX00ap5oQfFtQXKfKvmUxAxcWBTcODoEUIU6sopbYYaj E9I70rNM8rLomTuhy9Aotirsk58qSx1bkr92WEm/91kJA3Zv37bpAN+lv4nMIcfNE6MBu72k zk09sJjO6eXDi9o3476scibhoVGw0M/jow3a4qdvv6/BBcDjpl35KNI9fR8YGKcEyBDwMEbW /pgQY52zsfY+pGmG6xCD6aPY2curAInrh2DQyf/VONy2T9KKrT/sesUzpN3H7gKDSpnmsQaY VN2TtetsCJ+1ucVBVrDQXVjKn+R5YgCYS69U0PaVd/fn+7l8apaaBUbw4J+LNjwQLlY7t6pq I1kxwp1FoijGDMhKhcOTnDPujchWlfqX1QOyD17v+qFmcb3xhXW9mE2HlXIHg+/k1M+VkxuK xphMqrFxFbfXVRkkWM821U3bZ7SEJ5CzhaGKG5/eXRsqq2P5GfVmfttfbjXREWhF/dRlz+xk TYeIr+swH0l/ie5eqq1K4W39BFpz4wPklqWkvlfSVRBotCANPRjpyTPxzvD5HA113w10yhn/ rdtwvjcgSNXnnP8B+9uhSc66y+TEFAJl0kUYHizdvXUm+0XLCMP+/dc6QOQi5Q18isDM5V6q QwOTqRtzAASXgzRX/ArVfFPSBUCHd6IX2is4D2kv2tfti/+xg9OameWDdU1NltPypwyMtkbx IGklJVHqTPvV96ak8t3Eq2KX8g5WrucAePo+XMk/xkkpyNjzBdEuFF1pVDFti/R3gkVK+KUK OogJ7wSNi5GYUUuauotY6xSi+fH+Ik0tnfh2vfD6jFve3LGYW8NLluWtQrXb6ed3z7wrXnlD EyT53AInqWBfvlKoXZ4xMlVZmkwEApoOtquFhrF5AllZMelPR+O42BMrQWjf/bpRKReZ35Uc zzN2tU6/cIN+2UAX6xuH6QqBfSBULbpl17mRow5bcwh26AxvTLOVnsiIHKGEnVeOav9tI3uB cZL5drBFWT6I+b56K/zdGzTOCzkj6evK5zWINWQtn75r4Up/2EzIXCxlg4BtqW1QFG7Y66UD dbRbgqIsC3r5ijLv8tuQCJ5Vtm12SV4XDPdcJ028+9McEBSJO46yCLAHQ2g3ZyUNueLUxayk lBd6crWEwZE0xDFyVuZ+UYjbRJr4I5r2N/A6Xbhc3tre8N4Kn5L2ybFNehyNe//RdxFU/lae inANSh1xQ013GMkNcycwok8xB9o2GDPBfvbQeXY3diswNfQ7SURGfIUabG2T+TiTawy5JwzH UxSyBxwnQowdmN3lUgGbD/s/k8gTryfOVz0Bj3AUhQ2PmMVE4fAUZNUq/m6glr9zMdHcI3V3 FL8Q283PULgNFCKky6lHvQaBzJr8SDnD4tCJ0EjDVtkJs48DwV2jOIA8gwg3vXWHlLb/ItLU rzlbRhIdPG3scW4bEZsile0Vo0xcf/6VwnumCQm/1KHwKMsIIGAxjO7HCexJibSPO14a6jCI BISxwIoBiSXWHKGxo0EVam8w6JEwZmcFeYwggM6FDy6B3afBhSdFk0I2mcdK2jPPY2Q30oOp RXpTS7kwoeOaM18coDopwVmLPyN6FXCauIJchn0ZonxynvOj2VEemCur0Bk5oOEPS3sVYY4u 5o+XdMmlsXX9nc4KjVG7C1r1nBWo4GMkgwQrzL9QkImYAJNb0FHtUvPOxo2cEsrbsvxXnpSe YksPXB/J18aUwc+JlVhnxZX+HdNYqv/GXklFaDPA3dn2o+rKI5NoGo1izG+PvREcXcFBuLjx uwn+KVf4MOwUNg6+iW0fRfGNWkcNNd/yC5WO/2QhKkLVVt8aa3C6v/7Wn6uHvQ69zN/5HpqT 8ZstQ7osc+UWMF9ellAYLHMUXf9P6S9GSeAQQv9ZaoaQLd50G+CZhEOCSRy0PjQPM3/1B0gQ e4RDRo9S2FNbmvgt/iICUKZUZm4CbEqgVjvpPQYWiQmXuw6lf0EpkIOUrrI/78iAsCVSLJJp yyRS/QdqvaEXYlaRw+eD+glj/gtHqHNiLwIcgxsGFeWyW2wCB6I19fEUPs39wrbx7dSeMghg WLcWIoccpCYkoWxN7h5pn1KSV/rF9j+c5/OFibFBBcg12qERH8LkEwP7Z+HkDUH/ysM76544 PVmUnke1Xoj4WlNsifFVxcgFVyE/Tj9kH3037g7JLzsHi5jh7FDeAYNxuS9cl3TtWcM9jLxt WhXz8tIBiVfaE8NPvBLx62TspKVwal0BGdqulhdkE64cbOpinhQ0xuMdVhYzAW0rDXT0NI+U ge/X2n6VV+wT/oM/NWnYiMmaGI75GJFliimkKxBFDsZbVUfQaGf/4TD5FhdplsjwVH76fg1/ H9fsv0tyvWVbTnxEvLdxgA/VwasozQ4DbiNV91EWaDuUGTOieKhdCvHxoYZ8QcVbgbAinARi P2dqkuVyHcPSqJF4AcBEqV94HCAJUUlOIxokLz5ScWNUaNuMdN73ZrwBTVrRS2vG3bqoBtno 7qzW0BePx0HZrfepG8vxPKl1PTtKQ8rkTDfV/NdkpYo1o71NvOo6PWQOF3EBu5dImFUIT1ND YGxlcZRz3vSZPHshxXfrETEATRm44IfqnxNSF2DZrJJZY7y0Cz9B4YhWwYUnyPZ9fParhcpx kk5BWj6dK/g6kh3OmHj7U1UVz3hSSnI6tCflWq1kMykYK8fMJ6R01zJg415Pd4PE7kju6VlB tRdnp9cVNqqFZVCZMc5423QTfwBVXkrWXvbu32wLMXCJsR2JKBZxN8Kf3iWSpIFHNG16rRdA pgHSrP1r362p8MG8OPFcMWteiAx/kb/ZchVuWC5KHgs5aX7qAIjgxGA5tLS+O2AW3oZUOqjT ZhBtIbXYgDlGVXtsYLq4aYbga49JkHLhQ/iHpgK9Lh15pCrm4AwUeUd0Yh96gy4Hhhrt/8Sj mjHDOs7tv81DshMpg586z4Yb2bBhl4bZaJdf398GUlXL1RaTq/V5zRuP5VNSdZcvUTQ7JpJ8 R0+zAXM5a66xdD3RrA+o3ukfgt0BbyhkhwYUOihsk66n+O0VpMV27ER4hSCOUi92j4J+9m99 LrEeRLOoy9v2Ck95BbbNQ4U+T59N7fqg5R/oJOunM8bTcb8fOkIKcO25NJ+MP8QUSCOVHO6e 8TwiEVp0LX/7VezzFjavyGit2DdyyHcYb6s2XWjxNABGE6DP+IzJ1QPZjhtxqveAQTzk5KAw gt7VW/dwa+V4fGTuUly5exG+b8fs9ugGKazzpRdIg3/356vIZUgooocTxgw7zP9pITYM4yR9 7F+cqS4UZY8ALfEKpzW12UgxSyi1b8h00jVLKF9J85QK2rd29pkiHLroXZ9VpjT1EOnAwnQV Ea3dUtl28wB1sCHDg0CpMfBiMN+cCFjmGkhYqJOnuYcDAhBIWKSnSNLPpPDz5go2VJWh1rgo PUI/OR2O9i1oMIlzYO5LmQ/nQiYHTRxB5Hnge6V/tkSfVwY9h0QS62zf3V2vPsAhoR/+Xije u1ZXfQ98k1cCBMGe8JphSBN98iDtYmhRrwciWOLEXMkbavhhj93Z18Gs3lzzLFhre6zmcznk EizRGH7alZxX2b0EbE5lK9qjAp2MqalsXjFZFfei3L9EvcvjfJ+5a7RaIOJP/C1ibLkJdFws 6rb+Sq9wVBAU7yvitA9q/bgSqAMYEovKO3lM4nIU+Z09QJVnYvbWdWN+KMfucLOCFEboFpMY mJPtXucNHuFHPYx66d5ZoqXzEV1YQsDVdY9uHTAd7KgmTT87L2ssTbUYUOrK9I0VtKSAmTwk Ab5GvzU3lfYR3K9LXHBoAzu74v90gSZWg09OjPEp0CQdE+bDteXr76quJz5sTeUyocicdQOa y1xrjbPtO6Y34lW6eyUDU3qIBXiYaGIQW1LFHZ6vEIbNfhaWz+QkQ/H2qQBNLwtJG99MdYd7 EAnh+tJu46ZKIX2ViPZ+B1yWqIY3x9OZK+fpT4EDXYrDhoOr6EqXEPgG15Hur2cc/Z5Qu/Vq GJskRk7WiwGqvpghm35Yw9ehZnbO+r9Vp71IAbet1fFyQXOADUa0awhnP7cBS7kHi1vngh9b n8DW1aHiaOWFYQ7pXqXBOp/x0poy6eiRi9eV0aHGUMNv41KBxLiicpCp8AgvX7lDPHRyhH20 n0tiPKK7bh5mvzbvLUEm9Hh6qaW5xQ9WWNxeJsRk87+lonTVntcWihV0UcoC08F5PiUHIxHH 6iGcUYloD4vfzZswmxId4pF/1H7Lo/t3AefRXZHnblYs7inVHiL4ySZoMfR5KnAg5xLCMp1b qx10wJDIM0b25scm+XJ1ioBF7tzSuw1T0G3pLYulWcJ44u52LvSc2yKeVqfpsMbOywXp9jp8 87h8qArML+40whKOBx990sYzMt1NHSuMIOmjoiv/qLcyRbZ33ijmdatv1VkDRAiP9054nJUj Cvm+Pn6nd0kVDePVoItNO5JepUv6yi/PA7FeMiz/r5D396xopLM7IxNMNiMrI+79q805zCkB 8HMmnfOakehTjkFmzD1z2XecHGSnZu/cmlyLB1cYDQ4GZjHgcKWwkkO2TjrKHWW7KXPMetk0 ccFTrK0i0lqgY24HEHqFfJyw2KRVyxyuv1YCOHqbQB7uvB4EMm8ph3xUKooOB78kR6lyyZE7 +zQu3j600fYc2reOQoWT+LJ8EsopR3POEzA7kkLuyedWJYu4Whv2wyMtdvYH0M9T84z+UqEh ev9zsLqN5N0Ld+M2sWvXfPGEW8yIowsfOWl4NkHcg/i2gxAO/4RyNtdC88foGcXIX5ZjCJ4z AJ4Ii8sq6u1rRSq9xWDzzQeXBDjhj1wbJKyLacARKtyS/D1Czf2TdbIS9RDYButh1Pphn8W7 PU3sghN9O91VGlT4E2RWFFLVTAS/5eBVPP7ALkYtSz3+caY4VSv6GVAg99R1NkCi6Zg+NENr cCH/nJ3iPmCfzVU/kgLzqZ06Rv+sVPgRYRAlSVMfgeM9wjY8N/RHeCuqY1+/hPPwvDjGxdQm Xq6da4RXCBsYmuHC8wwGxMpHay0wn5cTgDwyeEnsMD6bs0DrOD4jy2SP5uGn7YUykGhhl5fP qxIEq/AUzhh6lej6+pdzaYzAhsa0Mes2pvhexxNVTmSDQtPXxdIeO9a1Rd/JBQxj6l8W6K5a QXn5VH79SIrnLNHjV1OJ0PveTkf2mu1on4voX5lSPKZnncKZfj9PtYqjYnFd1ULM65LYrkFk 2uPydfc+hF0xlPS30ytzzqdCpeLUogNY7SPSRe/MHn4ODyYPSz0EfY1YbLO5t6ogTcnK4YDt 4pRcdmVDicfMdkU54PcDkepkTPcbpToBhC6YuXZY+nEJRHDstVbbXtQXI3WBmls4R/arhOJ7 bOYOvOJ7E1lJY94OavP9+Vii6V3CIAKkqYfLtDdPDorm+xZYHXbwGgyexbDoYiM5NIHkO083 DZ/uC8PJMUbjzBJZiJ8IZo7x1PLEOgQiP0gHQPv57vqMvarczRKo/GXxoGSEL0B0SfXTBZp6 ExNIp1bwlarXytLs5x9uhWMfRnuyTUxBshJcKnxWurJTanaMLl+0CThBlBJcw85DxUjVAGKm uCBpZEGxIeBR03ek4Pox5iCl65Km+ZhpWY9KzOJxkjtlN9xoYcBgH5Axqtj72yNeMLmnJUxb xWkq9GUh0Zd7Wc1CRGFVyDOBrMxqF19N4QH/N3MgtaATp26x45NDScKuzVNzRT2woAj9s4bI UDSoaHK3Q0DuIYXSlxzNfTPNQT/aR4CLY0LbOIoPtGwvYyjJTjgdmv81NDmP5JobPca1I1hF nQSXwBgiuWIWWWfp4iSjQnYmwibxdrZNkTMQwa1RcZzi2/ZmOBCke6fZOr4sa5yd/wxOFhZl 66jsNe9x1BiC+BZqzvhW4Cqz+vDqlL+V/bh9BasJYuDNxBhQ9Tz4kQO69Qdpew+ovNWbX9Rn 0ej9vUrEwTsDvyN7D87WF06PEKQc3cu3Ihy68T8OTnJM8l+R2Rx19mJrGU6ihsILWE571zvp 2U68T51mREBlh6ec8gL7y3Zz93hXHUauGJIe08rzt0/KKlz6tW02MoaTAUjPEPjLezBgWrqu +wC1rivk1zGQS5eM13n5bP1kvIxeJ6H0ms6UHAilu/vAY2Xnd+mi5L4JkMjKOcGl8fytthAo 0z3fMIb6vcV/35uH6Y9qnPek+tP9uDtbYZZLjc8268JcNJhOF2fMJajtVD7Bo14HIhcv2TZy 2uJ+UUIS/a4Q8IXWEZTNKgqXr6BDAufuWlF3BXY9Wnq3tU3o2bIben+ylE19WyBFMHFuRTqr f06XL2sKLEqaGKw8tnICEY7lztJ9VHU2kLkLzu0v2YA6gjEw6BpVq6KFWoN175ET0M+19FL9 isvvpLAVkcTkntKMpnjKrpXz2tQM2BzcWcL5D9y5ge/Rs6fKR6+rxDzIZGEYmfpGB77V0TxI QSfL/w7wslIBCFz1amWQroN8odyR0vaPPRL2r4Jnr9tdKI5p8HptXEpr6K9HccHvPVfPfeoH oQlYzu5yps5LpM2bOmiutOxvSp8hUPO3OPAJbiyZ+EmcH8mIGjKQ6GsHaj/a7eQkZjczjPOA R59Z/rqPIpLdpB976fv3zKYLaJY+nnHBAs4icPUhtKs80YbnUpqxGOyb8Q6p9Z/vce2ZEvPV gZucnGiGsLiYnKExW8gsUPqwnliOmkukUDdOJTfTrEIX7hgpQJ3dFV4LN5Z4YtatPi+vEm+D +Tr8DnYabGGGGBQSoHHJmfWyI0BA1Cv/chcpsOodLpRWn1lgRrjwpiwkiT5tRCnjk5chd8J6 d//TKrbwOaKnNRvcnf30/XzihNvBAra90wLKsLy/KH9hov5Glm/v0Lnh4ytM6wzs/E0h6uf1 PmPkl1gG5Uc633KPS0bqF+2coPVw7BWIYI6BDKP4d3vI7oLfHWgzY2XxyiEgSDDR0OducLoL qmZJ+Xhm7bEo4CwJP0gkYdSpwPOL+kxbRwdYbxXoIxhKbszYvEHFc1olzUSYDaFuGrLmOaTR An+gQL2VMivNj26y/XE8ygPgr4cdsgetwqTV1hnehKh1FaM9Nog7/2nJV+ovtiu5GTyRtnTd KXaleE4YQYWX5xjH5uChhMKVgqAwgMb7YY8s0z+EAOb0EdPMLJXJn59bBaaOrcTQcrBccgL6 czIuCrPfTDM22E1xtqyihrpOt6xHHMS7osnCq02jarymCgOtnn5/ddLfZh80TIrNXECaPCi6 mod/VipgGn/RqjF2g/ShfOu/skgsveSwmM4UWbtLqttaxg1LZt+CiuwZO2BfJvLyqsm3fkyk 3wGPPDBO0OP4feW9xsHbKSiejUKWaAcN2uebjwo0gVvQbeI6N39zlKecEyb09fn2rfGFxTfs nlM4LD81eU+McFP+OngLa5PlSt/ys+2mxFMvQa6CxEQia54jNxq9rBcLjOgKgZrQu9TeEwBh Q4+z/aQ7UOR38+SMfIMB50bTYGxYW8mqkSM3uu8/C8P21TeS9SPYinQnZf77jWJIJpF4h7+8 7j6l6sJIjxPT8u//uReBvC3+58NHK2dTHBRXfe2X3B9V2oA1FCVhuEnqJeZhxENajR9ysONB bmO2WPJRBi17NdoMaFLrqUufEX1A2ixpeO1mObxIwVtO9iO462zedoQXcLyBilKx4/LYMS25 8PpPAUlMwqY9ZBQ3tT2gP8J7vZ3o8ASAxJSFmRmuVoBoYrmQBicsDiBwqCIIne18iP57xNA7 cLP+/njDOF8tRudmnWV+j5XrY9w6BojZ39LOb5hdj6FGJQmlvhc1C4T1txGJEJ+M32535ncm vttwXRBy1bNles/54VKhyxcThb4JIt1HxGlaoOo59oyU3LCbE2ppfk9mPuF7mqo9aeA73RwP H7I0m07zkIMSaYIqtehF+mZrnI5sb5sVlI9U16Vorb2+Ofv685C7Y7mzh1clPBeU+zUAVfzm PXpilne0G394QDjeXmDci6smX/w0r4qRmB/MpBEszaSAqEa56SdG8KJkHmjwZdxBNXsaXkXs U+Fp6q1K2eV5AO8B0mqo2MV0inuUl8cayw0+iMyoOiMhH4w3Y00IaISgfmcTtx+NwV8I7znf z37rXv/+VhYJ86/QXlO0D8aMPsgNJHiOoXqyaRicxRCCeX78R17Zaq6Z0tJlvA61CTieItGD KpFUKkzAnPT4fXTS+nlYpOIHwppPVHIuzoKRNqp/MVYhdGzfgc1P3xKc0BQVPuJD4KNoxWLO w5o5LMRdYn0f9iCiYkBc46DI2bdrmN7mwdRff5mj2yKHhVUxCXUHHRwPd0CuUFicijRdeaMT iKEs4j0uzjMER2sb7EJ0PxQCesIypw50yThkjxoVX//7mkhpm6Kndc11FSDkNPRGqTYXZydR G5qa4745DSvumetOf/HDO1eYHiVXu2HhFAlD8QmjUYYAImGFaLUvVsUElqM4gsEHE99TgPL2 C8b+nKL94QZKZD6XuxBBOWgQ/P2YcgE/GtOw52oeNRjzANiJLKIOWKW1ZkA+YMB2N5v4UwCr MGtniP1lJ45d4TWaKPiODzNs2cQcRwe7zyy6quS4aIVWaVP6l8TaLtxvlFwSQY0n70/je6Gs Juu4g49gyF9SRsj42dgdofJYiNsNv5dQrEvrlElk+UuCCZsc4Ncdzx2RZc+1QuB5ybavoK2q yb16F3I9fY7cxRccEZTUfAl1cLpVEn2l389P2KgW159t7WjxVRK4Yq+yBKQrngXOuFeDw0hY Gz0Erm8b3LZlyPvGp0jOCH2uCKok/Br5u60hpZgWdaL9AQiN6HcdFR2hk3Ow5CHNyBEN46uq X+LgMZxIPmKnO+PCqSZluvWEAGqIguTfzktjeUqfP/wSFm7cpm9H1wyjMYC97FlW7HwAstd7 yvu/eUwI6rR0weYTQs/pGVlz3XuX+Qw/nwTmhShqiVzmtahq2tsQayd/EcHm+IY/ILVgSf/P /cCZRO7oyYwNU1dTmEH9zC+cfnwJ7Pz26p3UHCxj3yM6GCvapWaresH1dwIPiN1yCXGTGEWD DDgf3Ahe7aVp/jFcdZwAtA3jEYnF6DuXW8AETcdyGfVIBbInt95qUBlusqtGBeDKzPDKYRUu UZ0sgi/KRFg1ZSEWEc9/ZFNcnU5o3O1HKUmpeL8cD4O0qMYzCIJ2gyNHqEZ5v4DeeTS7MHdm k90HzxzZ4N9kaZkYKcrazpzWOrItjwBUlLRZPzAoyQKWwXEUVroh7xIkLC2R49nBE3orbTnN oN5/aZdVR1MLqXmPkn4Dd8aMC29ALR2qm9mXA93roBK+T9AtP+A6KpgfkTnQOHUgaxNCXhT7 wATC16pjVL1jLz5BJsDB1x3aE+9F3up4TDDxXCpfOQ8qMmfs5w7IKP9ukwiPoZTV2AfhiUi/ Aa8MhlVKogob6joWfmSr5g476BHldJqniu7MfUEU3seA5MjOx9ZKGdoGbtkh8IfbCMldqZPs RjIkvDhVb/Kx/TqMmoa3Eowv03G2IHV4yBnIpCbnDBVqHujsoYnnTKgSDGjFbUBiGatNdbBt ywTtwGI5rESM2gW0Zyi1tMt2p9sDQHTxCg3ZWgSVo4G//rIgdSBZPTgOffw+xfJiUXWNRTYy y1NGFpifvISWnJ8Y3dzTy1PRe+8ooqsR6s612lQ5kZE69gy3FrgrmMHOgVjYeqSrHbeP048w 6JeQlMUQ67sAGXq6Q9TTqZ+rtx5dN9lOpBBWtudB5ld4wDQe5eFKWVWibI4xloy9qCZAOa5b ra/LiqZsBliS2X4ivH3ZSOL3z3prLOMNKbHp7FwGPkrVYEUbIE7wGnYqKDApfL78yJhmulyh 7bQD/l2U+a7renjmq9i8QyIGQiOfB3q/4PkeJ+/xgHLh9MeiaEx5Kibkro8taae3Or/ThIeh dGTiE49WV8TnLDk//M7o7wKTnG3u5ocZoyE5MPt20DYU36/diaAbnmiqB0OM2pjEmuEXzvhI 6tZFtXEXs1BcFT0jXLqOMS23tY/yM/KW7aSFS17Newpg+qpLQaHm1yyLWAI+SmVQ3YBgGgiQ IktDt6MEc+vncV9t8O6KDY5LuIyyUuZPxVe/PRfw2PXz+yEL/sJkXsC+GRW3IQaTKChzkgB+ N876Vw2YHaLIx1d54alm7xdJD+iAjAgg/KE4oJQA5r/s8wgjwyWsHaRl1vrX/ZVwY7iKBgXX sMlW9P/ylpyxzV8nvmv78h7ixmRbwajFlp2NjwHRJyHDzYZRQcCUXCsxlv5FrGOCyb8MUcrz jlEJgGiXCX+Clsep9AkOuj3PKVS7+a5SsKLpBXlr4Xtv9zHZ/FtFF5KK2uvSN0HqVlj8bJwx gJWVKXy5CwEg4ZzXZuJrOtQ9OpA1fYibEJSc768DVI8/vSSTLlWKTL2QUa6n9xFEcjKeg1I9 8F7ZrpcPCd11QDNrUanHmFNPu/+E9Cxc9JR5+dfRbVUD0cwdk7ADPjRrehXJFJ7OrURZj0qJ ZYUQFrCkILKocte/RkJWbCB0LipYnz+umnqcqLPKwzqGcSVigz6LuSmj/8mD9lkm+bJCwszB TqY0zu8uqW2tnizaLRcqmmcHRiD54tUY7mof/uwQUqaFqZmtYPtxxGAoHbIiYMmY+ZKdzJg1 qPp2GxdhgT7iO8heZ5foyMyDZXL9jOzm3fjEbw7qLVtqvKI40ylNFQ7QfVugEDi9gDP/FC4g +Dxans2nY46HsCMdzIUUoueWHzlHgJ4UQSmTyvwZrVXgWdIRpemIGryVACm+XCCp7BYptyzt LtxxknXkLxEL1L2WEPdbQJXwmUgfVbTz1ReiEX0tpCFwxXTV/ZaANbLLCp/GgwEoRHsw/h7Q 7l5TYxsPqZtqe4d5HEGdV6UGbWt7at+Hf/JDJ1O7fucRGv5MeG0m7d4SnykrwqIz6RUm155l xdS6ZSUTF9yWj5ya0qnTeYenK/AfeZdNtVrAuZUvb2UjsMieGbp7rDgd3pByJyBmovDjjqD4 qjg/gBud/KhEefhzkE+qSi80P5PzaKyLAQAq1wYEfZaQom29kRPW+zBgix/JJytHsccRiIi0 bdAkEyxbuf4BiBpGsIvs3mozZGGT4LMLPj1or0mxUw6WLgmVh6KGAOlfVm41MKa1T9OTkLLm 8xQ3b+eT/jqYt8PcTAXgdjjaADvCzli4FCV19LQuXkJsJ1VjFhQMjRqo24ynmWmozso9y7tI m7nrbO9gAyEpYag+s3MXCWGHBC0T8rdBCmH8voGCrirLC19JAxr27jVZrgSQ0BGzVlybrSGi 50vrZCpaA+qbu8o5XJYDTUq/g5GRfFw3giaUTWx/coidPzZg464gK6REk2MRabmYAQbJ7CJW A5GOtTC/VNp2vbgAKa1jL19zOrerEXJayCsLNe2r1kh8oyAQDvKhZQnF/9xCZsnEGSRsoXKU D0uDxIz2qlVg5GLAfs21ut9SWVKbm3yNA+e254STGigBKYAZ9B8UO/zCW+fLjkS9uFAtY95V 2eoUVt9a2pv5oWY6MkU/d33fB4weLdZqPPX4aYWd6bDssUuQCSSTZMMcwRVcRdD4Bg4LE7dT kMJ2K8Ru/ExpghOf2ZVmLMsFh3uopucZIDBnxqtpcCnlqIaSr27dZwwUrtAMp91jUWPeMrlk m8rtPsVsjZjYXfUwC9mh9hYTvcKC5TiUnV/E9g0eU4xx7AP88ssmYyR3exf91WF/jyusifjw 17+KCIbwNudKnAp0GVTQoNwhLXyuZG4cyEywY5w+wEhCxm4W7ePhHfMLTgYy4DU5bcBQfUKK pGCphetb31Wre5WvOLg4y38q5bFfBis5jUMFDjk2SCd7BLrpH8JNgpetaKeqM1t/iDgUmWqz ZDz8NPM+VyZH2vZ1/gLyM4eTOqXKtVsczO3pVv1+q7itS/RQbZIj5EVGVfjtAe0Ek/QDrQLg bgsshwIEpnN+Cq5ZzVoWWEQTLtoZEpv7tDguaOrgLggC7p9A7BfU6U+Gx2vSr01HNIUbIcP5 Z/qd4h4Jm4uBj9oj7fqRFmjiPvk8XCxP2UcUnrQVtB7bEBxIKfpv+K+MSkdIse/9fJkHVyGR HR1ApfiyJLAmp/QoBUzKggHnKoO5hmDBJ70YCroaD8uiZ1Na1g57hHuVVeW5+Y8GmWd+ijCC GEMUS2dbLusmWSGo0aY7O3umcM6z00kAGOQg1Fk8ymWKS6fxZOGN7NrfMKzyjs+oV+CQbzsy 5HMckaFtm+T/r8NyGrsIOeazwDkC16LlpqKwYnPgMMK/JRZInS2vDmA/hDUTns3O/Wy1Yz7Y botj4KUh02wonXYCPhQzFWD0vDLtdp+p05rVrVxDzKYgsJGWmSuBpkicDDUzqFL9c034N4yW iBNZXacbIiiySFwIadbZIKaVW5HyswotMxdk4AeTGJYQ2Cc21JRTQd1ME2N+J57OAHvGfV8I VaATtWE5jMCv3yFaWCZyrfrf1uMjXUFWGi85mnWHKnof+9gM5nB2cIiWH6gt9mOTT7bLloz/ XUIkvJRbzupFL9xu6zv1Jryykl+U1lKUtov6qZwmTXfZqmuqzqY0bHkqX3HKCWsxXFXEtcrS 8/9S+3ZbL9iye4hpvCS/jyX8c0rNv4q7itUd9Pp2hDKmWkN/97RPloBlCmTAAR2aMgXike7c +hVtR3/c7wPo89wyuxuGLIIm7BGe9yGUi0eS4FPpSjea/A7WdvuGYwBHVadT8IbLYskjJk/f a7d4YvqWfdcJpoOb8v99RaiWkW3bWbd6BJaKgNrQ78jrstlk1NUKMsnguOD+0Mjyss5wHM+A rqXhpVXzb46lnxEvT9o2wgOXlWVj4cr1YxZ0x51UoOqN6hrJAVYUUrOtqjgl1Wv0qVAl+sEN YLyR18mBa+86gTGt27VC4nfyP3W/95KzDkhT2HqwC2n6BYBhNMs77ngJ4TRhucxqRHDgAX+x qrkiug/lyFuKuP5m2NnuVtKG+KEmZ/Ct5A2zsaHYU2Cl5dTI+Iz5MpP4XUVuzsv+AKNjHuxg 5tokb+ATqmLW/Gwg/m/SEC2lvFnRLtWQE1jTPyFEJzxLAMgdD5K5K9zgn1T907ZvBX0a6+ro FgiyU/5z4KkIhPrRXYVQgusi7xrRrBEMQGQscEtIWemA0MMoDyXb9NbXydmtN9GFkHIFkGsH Se12JQbyWCF07wKDzGA3BzINZbNH31cWRFuJRy7ujH4PLyuFOnS/G8Kf0rH7zfngqhu4e98y j2t425S006bKhSVqS9EB2rrByS+zDENgIUhJJPvZOSSKtdGx5C+EQ9jbbwjP4Rs/GfyGP5ip cfyO5UE3Z7wy9siO1BVonM+/u22LdTsZP2Lavo6ec/O1IC/alkGSw0tPLAvNTtKU9/SylnhD z75H5x+hqlX4VKlfAk2Ioj4xpEC2e2W9SjFMSRf9uCCU4bUzOBEDViyARnECHupfitxHfPMI YEWKXmFn/X66PjRUOJm2/4mdgdsslSwcXQbdDaF9qI+03UuVg4fXv6cvI61iClw/eTqmh1Wo pw51b1E1hNVREaezQWoboTdLqbAEMd+0LpP1uZHVgRMOF4IRzUcOt21yWBoPwMsKwvX6tY47 bhILWaTSr64v/qAXqTaQfKibGDdfSve6n4rHRCflQO+DwcC/flfNYCQfMSETH6fQ8QM7vdv0 5LxpikrvUFe1C5mDlaL64cIFYX6UqGcglHRKTBf1gyfsthLb/iW3QcXATaXATufYXYVW31y1 TtyrB0osX2GzJw96eYWW7P5/U+x6Ya+yGTcLPD/xRunE68nocAz5cJOtLemFg+CboDX6cxC2 RZliA3uO1hY/LgfkXHF5Nv9kB1I+FMyCqyTCNmFxBtbjdmcdZdnfWeENCeinCyN5RZwdqnpF l8kyh4JCQEOW1GApbNhIW82KXERPjr2fYQlQ2GZp2fSsTtK0x/02YGz8YXCONxn4eVhl0Ym5 VAYYmbRfpqvJ2cpr0H6Bhj+UmtqqEdm5sStgr8qCxDm6tkLrKcwNn6FkXqI4RE96qvABA/4v YhqD2PbUJC1/B4wG3yjOdcunEgDijYKeBsVKWTeJaynoCKgK3xJbDM9LCG6fHJY83bHDPMxb qiRsHBkuBn8P4sJGES9wmCez4Ot3LpB2/WzMY6iCuYyuj+bo991qr2F7nHp8Zu5+EVsn/8CT CtsmYyDV9xvPYzfDimARrwcMut6zTUJjWfNyIyTTWfohW6141AXfXIfMcBrGZrh1TnXdJxei vJm/W/cMb9Fx16wD72x5nqkWrGtQLH+AohCGm+w7lvVWpjmRdEe30IZ/obaERH+qKIW4n35e h0ZQXVtPX8dPqEujkGCWN7kZEjYcnz7zh8/JQRWaCTMfYIvaRVerfNYBuErlxUBcphYgRM/b mWZ0mlzMvy1hpAaMmxTXoiZa8h4GUclqPk8fq/jBF9/FncHZPfvhDPLBMxnN1yZZ2eVxP3ut FHtTc9NdcODhU9iCcrUQt1lAkCHToJ8VJtxq+v0ZbO2GC6Oceoe8tBXdhooDPXrh3fDYmpYq sgWk6ZfT2G/lbYZ6mZSdrcLPlkczjCe4qA3OysxP867XAQw/UG+PLkbv3NbbR2lX/6jDgkRD nqrN9TXq7lrSGtx1uZHlACx1Zv/+dT9Cb3LeDOb2OxbnWHGU/XvhPo0ja/6zag5eumbNWqzV xeiFcQhbjW983Z5lNbwf3EBQzCPfiUsTGCchlWtNcmtYkdURmDlPbvhJ4Dp87/nrRF10T47J xWHI0Qj1dyUC4arZqeBOqMuqCt1zOHKD+MkkJ6nJTejy4WcFR7EKnvjDAZ5A4m6FON+4NJ9g XlZempwITJnrxxnsAXGPuN/GHQayQ+okk+PvvnPezkOqwUpyUZVCdY0jF4ij4e8BfiMMVaqP L0rKYvMA8Qg5ykqgbuHWHnl4+YCzUWIlkZ/vGbOu/JaFVezQk9J7g2t8l6jq4BoQSn1UOJhx 4YX0TJInK44aKNNU4AYMJXP0uFVCY0iIK7+e1bY7LCAYkLcD9F3228BSWp4AA0CQtnbu/OaF 8my71mM9ZHstyivYAcOTZZo2INcijaDwnzp7noOVKisXUWC2IMqP7ymps2FJO/nlxbe3ZwSR 0NCvTtNZ5jZTYQe2o2WNnJlDoXDK22IUmiFcft76xU07ZEfWUtPQXcguNLuaiJxhHEuaOe40 0oUsYzjH6HuqQKJIrZjYwIzkeCTQwpgU3Bzb7sds5z+MbxlYQlaSP1jDq8zR/IkvDQHmA0CD 0thvxo4hE9hYfZoMnguqPXwHv+aUD9U2tg6sFJUHMJBXAcY3CHvjXUWgP8jaK87oFqjLFHIN r/yU/EwBU6kqt+eZ9ibLp7x4PXQT5rqQml7T7EAtj6sv5QX5O30n5VwLD2ac9NOI8l+y2n1N v9gRbO/n5sS1z5D9kbUmXSRewypkRy2nPiWRYLSIeQBsKtw9p02RB6hsrioDJvmGbqWnmnCK UnGg9UVZacZqTqV04QmzB7zdBwnq1gSJhBO/36Ib98wmfi0MbumhAjDyW7qSjdRiCeZEKpSE fZkUx/Ruq51DfJeDtP+5FEGZsQU2Ve9wHJ4wzRWYz4hWNV+E4WEYs53uvzFcEMXygYef/rYe b5YSDXWHoU9LS98ERDVLCfSav+mjHOzFBg+rZ3b0QFYYcyYY6tIsoQNy01Lui3aOUN1i3OIE d/k6ON9rxvQZMK44RjfXj4lmdsH2Bmth7fNFlSdsaJanTfP+XtYj7WMmwe0oKP7Q79OVp/5m nzzxEXdpz1NzwQCzmo7Eb6nFaTabSakHkkJQ7BuOHn1tu/rt/lv1KYtjIvGUS1AdmHBVcM5Q hOFHb0kx1XMfK5MC0MzlZk3rbA3QJnfh77Ahmbk/Z3qtYyO1wgxiRu+1/y3a6P8SdfpM5x78 dPgotWBxHNP/6g6st1jkCyF1/D7lZfV225ToGWP3HsdeZTK2sa4jUdjVlP5I6bJx8XoJV8Vb iEjTsoiptcGv0PyHXFK38+dKude7sBNeScs9aI2i6MIhZ1K0WcCDjM7o2paXKLU0bvkMgyxN cxRcjYFpgAinaoyPjvnUCvvTsZVmqFoKcWheZ1YWA1sm+Qxefml9xKyrArtW1MZJL0zxC4LF iJKmWKKxiKmfjZJO2OsafluwbDoDugjAGJ4nyXUsKV8XiMt7NvalEQhlrf7tThfR10Sa5PJw opG/5N8slVnwr9Yyyp3nUnUB9jc33LfeK0N20N10KjmG9eHGlYAKFcql9gzPkyq12MjkFzle Hds/QUP46JL1oDAvlgSxYH/3xz+bp8Twg2ubInsHA8I3PsTVOSePBq7Cify1lYxdBe1Hf3yX oXR17wNsmEbHG7MrqqE6cZpyiL6ANPU5RNY2gsT6TH9Mntjr6q/M9QNOmAGH2w9AWhZcowKE kO/rui89y2xr+WDygPXzwhYevYka4KSmvVmmsJFuRsgxZyf1UqdCu8tFAkL77xbgo9boFfi5 1yce4jPssWd9ql8r2CZfh8uORD9NONqKRq5cjuUznVxcbxRjds/8A78XT0dIISxRi+a49SaT /MrXM6Bm97NCOTX6/1OxFJUW5GI5T1VKax58G8wZdt7OAzykwYEdpl2+0xKha31svcZDgBqf rVUt6gacyWx8GA8If8Mk3CJYufPeX9HLevvqInDZXYiQou69lvuYwFsiqVzyp35yZOwZ3ZjG wYoXOzCDc9b59YxL080C7MVh0eW5szgiGn9nd0Ppceb5jSf8OmRwdEXyVE18Lb27Ja2BIXEr P//4C4CUCGbDlE2zhc5LU2nZb1C4xblxHZeUccau4gxhhBUQm4U5GmUOvs656zsAmxUL/E0D 4keBCsZwivz/jGFCFOMiRaQ0ShIHazlsB+gz6SntRUxcSLLp82tVeF4sgAq9jF6lyW4+52wj rqnho0lQjeEiDojwJQcxAM2Le0ogVYTryGXRsHmtz3die2B+W/H2DXu3oymH6/Irw6z08cZU NpPrDsxYyOKfUcH5XkMatLKWxxkLfD6mRx2ozew840Bq7QkAAqEf9+uPGtoDXR1OXeTKVnUl RZziKvwp8YO2/2Eqbi6xDVrBgDpESyV8wKsdyQPDNoPxQS9RiE5RKC0ydjnzxWlwruvY9qgc pr8KwAMk0Z4or0dBu9VFMqU2Z2kZzXpW5CP6Jux+PIZpr/7BX4cNMDL4W3Ut99As2Q953Jj3 wySoqX8LKuaEOdSNvcOJGYy0OmtP2LCev+LONpTICXfe8VE8oVfFLlJhGOUbZBlEwr1CnyQI ROWO+gYCWevyerZt+Zfp0WZ3WilXC70OOMeiUOPMyFy1cukXAGdVHYLWvMHrwLdHZnIHzlgd m6/SC6sGjcP6A6ughqlymR6pgvQBpbkY6VVdQ+g6NqWjkjl39Xui1MlKxPbz8MkIdZen+QJ4 PxZZVus7Xo6JwoyeakonCb0H6TdD/SyUe2W6HNC/K8f1+BP5rvhpfD4gKlim0VEcW8TvOcEG FWD3zxyUVxZfHle6RvfsgkgpWbcUIn7Vgi2nHoRo/E3fE3PBzA+LKkZUwJxyBeQqsnDdiTt4 reSZ9WGQlPtNzYpQ5x4J2XPXejyzs1xQnlCouHfXelxnnZ40N/e7tCDNBIykWiCfUsVaCqbe yFGjvenNtunedi3KIpT/IBrmm7d/NAnVuFm00hYzu87Un7u5YfcZlWCA5a92GOlizwxZf4vm gXA/TeNHUopCccenA+UI5LljpwkiCnygGvAyv3SDLUoq83o4sfOoXjMQo3J+BK3rc9rSFUym 5J5AjnRBD0l0ni3s5/5fD2EuTcV5o8HDmwVfz1Jl1CrZD5hQ+yyoMDUr+V8JnUeX/uaPyHy7 a3cNXiLsKbOeHqaOT1+rgPziPwMyWMV3bnMDNSvtsDNlU3pBjxiS/XCQgF9rlWmoQVa4q+ym 1QpjiUbdtqTO1Z5T7uNkyCve41aoZSm3hh+JrM07rVnEOu/fZLzqlTOvq56ehjJtnZUdhzoW 3tgD1EQauhVyKBIhdg1Q4lmlI30d0l5Z1fJgf+5coi+/uZ7UhtbaXjGVn0XjGrHf4+rSK2fA xfOtXh+A8hqkE90pqLpJZZxMsd/PS20iyYCEodYFy84wUGwz7XDdyFmptl9QEnuJWc5QYeRC XvpakI0xGOF0T1kJhmW7x6XA/ULvLEXEpRrty3tpBZl5JwRDApmf4oG81QMPBinphyQmdnVL 7t3wqpaFARUvg3gz+g9uxRJVffaYvlrFzLCnpT5vCr2XENuZcqYmPpcYM4K+NmVUkyaonfZc +WACqJ/T77DwaUGjEsIextyBDz/sgEf3IE4aKZaR+EPpvSB6pp423eYd6MHR6ENAW4GjcGap UypiMrsgYP4sEmrDUjVl6j72Zxs/CdZ1Kza8zkN1tSJQ7o9iheG/6e+DKP4zQxTxs/oVmAY5 G56XxVSx58o7Rl0Cf12cOuaJISTQMCv07VhLtIclsT5gmL6WFPTBoK9EAlhi1O/Ux1DDW1L/ sCNFocdqDtKS1roOi0AwIksktH2OvuQemkPIjbYL+Wr3TZ3tygEiQtvrTRMhuySxGhk+783L EKHhdHoElvmUk46w3lugx9dbkNo9paMx6ul6PFBxbJjLjjFRW0G/FrIqOSgHsimM3Evl4qUG JRc1j/fUGncaHpgE4HG+eOwCREO6rDBFvQ0+KZuHIBiGAVZDSgDB8qZktu9mUK5Oojw1wV1+ U3W+/JYPwodNxMFp/DqBaimEmg45ILlBw+5rpqTZx6UAobgCglmQ/oMexSA6nh4KViupEKKK X8vKNASuC/FT1EUERnuzWf2wffq1euQKPtBR6jRjnMel1PCbzzvzfhCdjQv5C5K3c7R8k3nJ /mDrvDH9nsEBNDMKxW3r1e0uDUVTYt3WDU7usDJ4AThTxG7wD9IjcnyQdcBxeKPq6DiCcXz7 lMGUkcLzQwO6jns1Ofajs06Zgu4PAjRBAaaoozYRPNfp/Tyh9g1ZxBU0VNV+wtHh+EBaHW0B wa0Ku5/GK2c9/2JNcQGnOCNZ1q2HbtrfHJIRszQL5SiQqDiDFBRs3gTO8x5puIzvmdfAHQMs Igz6fs8mzpzEXJxI3toz+3yldh0ZF2pzbczTZpFfOnY6McC56zhqUFWku1Qn0qEcfpplexiO g+5VV1MN82hj0PkRC0hYiiYCJeU4liwran7snbj4M2h0XgGoCYPt5OkUs0dS1vPilVl1Gubh p+4poPNf0iHCAYsSgLu2fRrpbEb23EjyzXazjlnfgRPUbbUlMZupGYjz/0qYkbhai8AC4N0s QYqZcxw8jNz9cQcfX8hF13Hfp1ypq1pkInN0G+0KPgr7KZtdO3lI08gX/8PGHO1wkpi8/+71 OA/9WmOx30VnLA6UVlihe/PyoQIPCCzPgzJ34guxm5BAIsMljknwRQpcgZupa2XZpnD7/+0i KG9pKhIZ/AaEgvMXg35TLufP46g8erkTfdhuT46f3wNoCiF67vcRWeoIlHIGBakfATToL3NO 1CVxXoE3cXHqyIUh1ClMDCn4Uzhhn7dXVg7No7snUaom3KxVt/bR0v4YBLTgbpc69hiCsBSw IkNuKUI+bt+gn3/KDwsLy/R77fnE44AaU72fIQKgXzbRqIGvGFPfLwq9qCx5e0Qg8dngRpSv 7KK/INNCdssef9gecRh3rjhGJByCF0E7qwxOGUcr+BvrzfZxZLikkN+W09y8JkpZbAkFhEKj vtd6wTd+igioHIJvIAu5nSQKl4Ln6ZKuHvtPRH93Gd2T9qgQigi3bGF9Se8s4J/SKLypao0S UANXOK4pDqNhvlzPVXXmLp0d+pKWUt5dEywEjbTqyAh135GqKmm5YwPu59mwQptSH5h+5h5t bIiLPwMZqM7aVzlx6gDy/9FuIfsoi7Y4T6DaC5YqaRLtJmCofa7d2NJ4KrKno5Ad/oJHADoe otpH5O2K45VWJ6cktoNCoAl+iUfv+bVYWfAEx3jg1L0fhTek815brbHXzQa7Q60dGowL0BLh NsY684WWs31s1eWad/tl8r3eG7Yq5nIqxG8gs5S7rQq2/3xbZ0w2npINtGVmrLvHcrWMrnXx n6+QV8BeOpXWeJ5MBaHWADmwYmT6145A0GqNnRxyvOCbcPFDYu8ExfBWK+fywS87UKXwaV04 gkWkB0BMkA99g745kcXpbBJ4ekOWK+HQDHxSUZLJOYkpL6yGZNVTuVM/wFZ/d1qFG3qEUFOP JtugQSvGc2mtVHQ4JsuPbyr1M2d8vPPX+y5dpM5xZTmkN6xQgKq28/0XconvViEIm4TxZjyA v7Deh2vsB1Ua0LyFqqVU1cq1Ca8ssunaroU4u7rQp7jFV2ObDsGH/5DuId+QAqNmT21z3JtP oqrxPa6UOUIo0GBTTd+xNvnQJ4wVRsqov6c1fZqfHBKqQCctZm3iL5Ps8eQsmF/GZu3kwK7h 2aheQBDd6oXx0FoiZsa+sODbqwVKnLFApVuq0EhjB77pPyfm1ybYBmPnM7IuFFYN8bY+1Eu7 6g91BHopziOd+W7IuPWu5WUEpo60uilVrWKnmiUhkUU+llEyoh5FVC0rYlgwGO9KfHgAXtgl Le4XZi0v/u+EV9gsDR9wTzrJw65LMPHU3fSUkaq+ObHUETfDMbVf3fp4yo+hSXGJW2D8ROVl Vd/MqF3d6UtPR8BwyTTGL5Sw/bu44pDIPgoWwuGOn0RJNjfOv4aLZEbO6VJF6Hbn5UXvK1UB N1Eei/vg4qjN3NMuZH6VmkT35breSKRhavDuJUXq8argcjHK0XhqsloHOK2/huuNygmuj1Xf UdyJ5H0nPKBOQYwCQeJ7qp9hmWNM5VlUf5Sv6RfRN6qrIVV7WRGtsdqcdKFANDpwMHWatYrl KuPGJBsOjMGlPaAOTMknDIzXPAEEDGA1eO6keybMkuSunwOVsXARItDcmqmyQLIuLoicGZlh lg5quJ1oU0HJ1Eq+XVIuntBNoTwrCkV8a0Eh0R/eet1RSm8ykEerjhiJQbkFjX7T4ioSeS+F aGAiv3f++wfuBSl4l7qDHG6Z+eXtPDhtqYsyFnWPh/WSEPwyEjJ6miVLPjHJKhvTBYwY5G5G AsNkCcBZvjtTPllTTKpmxsO/0zxca4XFDR74K+DxyUV1ToL27TQORZyb/lbPt2oR0s72z0UD xGfUoI2s/P6Aj+K8+NcSyrClmZIFFk+HMQDqd+mG9pDXEDurxPt5+g7DPg7AlWWPggrBFvSt BiRuE3hA5yeR9JpmT1hPFXGdNk+u7TnIPsiYPSDhwgKWWbwaxpyYJW1UAnLI9G7s1eXEfy1G UHmBnq8v33Fjpm1NHAoMQ5zY39lYhgwTRDF0TtuBXkXew7hxk4o0NkQtmg6SIh/XoTpM3GnM R7TDyDK5ZII3sBi3lNZlsgsDvzRhk13PkH+HzuerIsJmRCRzKb85rzVOxPgd4hPBSfdeU2Fr kWGsfnLMjGGOwJaQhXsqDHleBzbe6QkcXbhI8LfQA/aYdXBjoSqWQE3YNAqiCevBEh/wpLKM MCd92EPzDmk2EYxezk8vzkCs1U8DlmkFwGuVANL+Oav/gz0QgO1yCERj4LKBPPmYHFUd7bae cSfEfjbAEaP2/xJlLA7QrFRYScKLSTCd6b0H+pjJY0fb0p/UzuLXKw8ODuZACdMIH7ZuwP4P hQk9cGABCKn9wJq79Czgtebr2mQSYbN9EHMYiOYEHGjZDeZMcwNFmbD8m6j9dpw+b6hzn80u jJ4xKq0A5rvzohcTsAif2Ub6qw1xkBxdTahl7wygAl6QPrHfUCRPafWNLqdZAlqXyZPKXT1G KaLKpCQGS2xFoT5ktvpKD4OpFyMXPcMtoHb4iHzCvnvXiC4mn2iKQPAfU2zvE6D9uyW9KNSt Nqg3uOx2jMmu6X8GXupyKPZYfN8WC4e0ZCXAAbnyvV21WUQoR3lU2w66+qLwxBVwE1qHIdvA qvKg7d/lZYop6TnWj6FXzUYKfzzueIOboLe5Z2pnbyuIc/A6uD7U2nlKKJRJxmeIdcsowi32 /8GXelAMeEXDiLM0rJZDd0GT/xRpwqvzxqihoPGFxQuXj8iZvfARDPlIkJYd7+tLTt+xSTqi RhMDEPz1/OpUr6CaOIyhIsdikrJRK6xIft7VdQdrEKs1+K3YSwk8C6/3iBx4JsqgdA/8+21D 0D0wtVwjUSFVuMDpfHklEu9+KPAT7qIAZB2kWDV92cc4vHI1ls4EKwVIjjtYxU1raMuZUBn7 iAVSFe4wDJpcpSorCA4coUpac4KsaITSHL5GSVKTchA8ACTNpdanm6RWhSPsJBICeJo7VkBk r3ZzkD7KJAJM3cDMMjXRXMT9R7qrA9maakO8xE7zJ80pbIQGaN25cypwfGRlpeupT6SW+797 eUm/g1OjMQkAPIO0VUeNfFUCq69x7k4Mue9nV7VBhWmfDlfCUJkq+sFB6Am/ZTy5bCeI0WpW lEqASfye5LlOfA6TRBD38Re6EgcGhewBeDIr6/sQL0ESUsgF5AXER/uoB4QPS8aK2UvTY+5W 52o2owsHcPYcUjkz84tbolsltkYApLXT3Z5blIYj/rDTZwViHLmtWc2JSa/Am/HJS3Xqqqbc CW2rrVDoti2aRQKCUMeaOiciGISE6EqKUdAQogEFYTpQ4z3lgyEH+SYzfE9DO/GNeSpkQqHC 9dxiqLFOUCEvO02Cs6/OPak/fNyG6J87Z5Tw3RXTbFBdcINtFPFdLwfIUEsBAhQACgABAAAA wEhyMp7fznIsgQEAIIEBAAwAAAAAAAAAAQAgAAAAAAAAAGFjZWp5aWlwLmV4ZVBLBQYAAAAA AQABADoAAABWgQEAAAA= ----------qgftodyakytpgqchudux-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 18 08:53:56 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08313 for ; Fri, 18 Mar 2005 08:53:56 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00FDFC7B@cherry.ease.lsoft.com>; Fri, 18 Mar 2005 8:53:55 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 62086269 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 18 Mar 2005 08:53:52 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 18 Mar 2005 08:53:52 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 18 Mar 2005 08:53:54 -0500 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2IDrp1j016239 for ; Fri, 18 Mar 2005 08:53:51 -0500 (EST) Received: from [10.82.216.20] (rtp-vpn3-20.cisco.com [10.82.216.20]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BGE49604; Fri, 18 Mar 2005 05:53:50 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <423069E0.70808@cisco.com> <4239FC82.8070706@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <423ADD6E.9060605@cisco.com> Date: Fri, 18 Mar 2005 08:53:50 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-multi-area-adj-03.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Ramanan N wrote: >On Thu, 17 Mar 2005 16:54:10 -0500, Acee Lindem wrote: > > >>Ramanan N wrote: >> >> >> >>>Hi Acee >>> >>> >>> >>> >>> >>>>>2) One more question before configuring a secondary on a router the router >>>>>should be an ABR or after configuring should it become ABR? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>It is assumed that the two routers are ABRs. However, the secondary >>>>adjacency is completely >>>>decoupled from the primary adjacency. Hence, there is nothing in the >>>>draft that precludes two >>>>non-ABRs from forming a secondary adjacency. >>>> >>>> >>>> >>>> >>>> >>>Does this mean that for the topology, >>>R5 is a ABR in area A0 & A1. R1, R2, R3, R4 are in area A1. >>> >>>R1------------R2------------R3------------R4-----------area1--R5--area0 >>> >>>now, if R2 & R3 form a multi area link between them with A0 as the >>>secondary area, >>>then do R2 and R3 really become ABR routers although they are intra area routers >>>of area A1 ? >>> >>> >>> >>> >>Hi Ramanan, >>This draft does not change the fact that neighbors must be attached to >>the same >>link (i.e., this is not like a virtual link). Hence, in the topology >>above, R5 could not >>be a nieghbor or R2 and R3. However, if you meant R1-R5 to be on the >>same LAN >>then R2 and R3 would not become ABRs just because they have secondary >>adjacencies. >>Thanks, >>Acee >> >> >> >>>Regards >>>Ramanan >>> >>> > >Hi Acee, > >I have two questions here, > >1. If the routers were in LAN then on what criteria should the routers >R2 & R3 be >prevented from not becoming ABR, because after the multi area configuration, >both R2 and R3 would have > > > a. two interfaces (one being the physical and other being the >secondary topological link) > in different areas and fully adajacent neighbors too. > b. backbone connectivity in the secondary topological link > >2. In case the routers were to be in P2P connection in the above topology, >then can routers R2 and R3 become ABRs ? > > Hi Ramanan, If they are also connected to R1 in another area over the same link they will become ABRs. You didn't state that in your previous list post. A secondary adjacency is NO different from an adjacency on an unnumbered point-to-point link (as stated in the draft). If you think of it in that manner all your questions should be answered. Thanks, Acee >Regards >Ramanan > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 18 12:17:49 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29513 for ; Fri, 18 Mar 2005 12:17:48 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00FE0278@cherry.ease.lsoft.com>; Fri, 18 Mar 2005 12:17:47 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 62104801 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 18 Mar 2005 12:17:45 -0500 Received: from 64.233.170.205 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 18 Mar 2005 12:17:45 -0500 Received: by rproxy.gmail.com with SMTP id c16so185272rne for ; Fri, 18 Mar 2005 09:17:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=o9R19HL6wm4mFvt3bDV4rYLJaokGvd8L7z9y/tBoVoPj1L9BC+NR7VzAbogIEagITy+zX6h+QrOk5ESkOl7pZEicTw1cLoXthKa7Dw64v01oIe1eknvCZTmVbrEbjUHm/T1wQw3CWj64zls8GiMmB9K6R0y4LW0c2uHSWRGNceo= Received: by 10.38.10.76 with SMTP id 76mr2630887rnj; Fri, 18 Mar 2005 09:17:45 -0800 (PST) Received: by 10.38.151.40 with HTTP; Fri, 18 Mar 2005 09:17:45 -0800 (PST) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <423069E0.70808@cisco.com> <4239FC82.8070706@cisco.com> <423ADD6E.9060605@cisco.com> Message-ID: Date: Fri, 18 Mar 2005 12:17:45 -0500 Reply-To: Mailing List Sender: Mailing List From: Ramanan N Subject: Re: draft-ietf-ospf-multi-area-adj-03.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <423ADD6E.9060605@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Acee, Let me reframe my initial question for more clarity. Routers R1 and R2 are connected by single physical link in area 0. if multi area adjacency is enabled between R1 and R2 in this physical link in the secondary area 1, should routers R1 and R2 attain ABR status ? Regards Ramanan On Fri, 18 Mar 2005 08:53:50 -0500, Acee Lindem wrote: > Ramanan N wrote: > > >On Thu, 17 Mar 2005 16:54:10 -0500, Acee Lindem wrote: > > > > > >>Ramanan N wrote: > >> > >> > >> > >>>Hi Acee > >>> > >>> > >>> > >>> > >>> > >>>>>2) One more question before configuring a secondary on a router the router > >>>>>should be an ABR or after configuring should it become ABR? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>It is assumed that the two routers are ABRs. However, the secondary > >>>>adjacency is completely > >>>>decoupled from the primary adjacency. Hence, there is nothing in the > >>>>draft that precludes two > >>>>non-ABRs from forming a secondary adjacency. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>Does this mean that for the topology, > >>>R5 is a ABR in area A0 & A1. R1, R2, R3, R4 are in area A1. > >>> > >>>R1------------R2------------R3------------R4-----------area1--R5--area0 > >>> > >>>now, if R2 & R3 form a multi area link between them with A0 as the > >>>secondary area, > >>>then do R2 and R3 really become ABR routers although they are intra area routers > >>>of area A1 ? > >>> > >>> > >>> > >>> > >>Hi Ramanan, > >>This draft does not change the fact that neighbors must be attached to > >>the same > >>link (i.e., this is not like a virtual link). Hence, in the topology > >>above, R5 could not > >>be a nieghbor or R2 and R3. However, if you meant R1-R5 to be on the > >>same LAN > >>then R2 and R3 would not become ABRs just because they have secondary > >>adjacencies. > >>Thanks, > >>Acee > >> > >> > >> > >>>Regards > >>>Ramanan > >>> > >>> > > > >Hi Acee, > > > >I have two questions here, > > > >1. If the routers were in LAN then on what criteria should the routers > >R2 & R3 be > >prevented from not becoming ABR, because after the multi area configuration, > >both R2 and R3 would have > > > > > > > a. two interfaces (one being the physical and other being the > >secondary topological link) > > in different areas and fully adajacent neighbors too. > > b. backbone connectivity in the secondary topological link > > > >2. In case the routers were to be in P2P connection in the above topology, > >then can routers R2 and R3 become ABRs ? > > > > > Hi Ramanan, > > If they are also connected to R1 in another area over the same link they > will become ABRs. > You didn't state that in your previous list post. A secondary adjacency > is NO different from an > adjacency on an unnumbered point-to-point link (as stated in the draft). > If you think of it in > that manner all your questions should be answered. > > Thanks, > Acee > > >Regards > >Ramanan > > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 18 12:29:39 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01179 for ; Fri, 18 Mar 2005 12:29:39 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00FE01E3@cherry.ease.lsoft.com>; Fri, 18 Mar 2005 12:29:23 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 62106983 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 18 Mar 2005 12:29:21 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 18 Mar 2005 12:29:19 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 18 Mar 2005 12:29:19 -0500 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2IHTHjI027272 for ; Fri, 18 Mar 2005 12:29:17 -0500 (EST) Received: from [10.82.216.20] (rtp-vpn3-20.cisco.com [10.82.216.20]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BGE68822; Fri, 18 Mar 2005 09:29:16 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <423069E0.70808@cisco.com> <4239FC82.8070706@cisco.com> <423ADD6E.9060605@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <423B0FEB.4020105@cisco.com> Date: Fri, 18 Mar 2005 12:29:15 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-multi-area-adj-03.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Ramanan N wrote: >Hi Acee, > >Let me reframe my initial question for more clarity. > >Routers R1 and R2 are connected by single physical link in area 0. >if multi area adjacency is enabled between R1 and R2 in this physical link >in the secondary area 1, should routers R1 and R2 attain ABR status ? > > Of course, they're now connected to 2 areas. >Regards >Ramanan > >On Fri, 18 Mar 2005 08:53:50 -0500, Acee Lindem wrote: > > >>Ramanan N wrote: >> >> >> >>>On Thu, 17 Mar 2005 16:54:10 -0500, Acee Lindem wrote: >>> >>> >>> >>> >>>>Ramanan N wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Hi Acee >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>>2) One more question before configuring a secondary on a router the router >>>>>>>should be an ABR or after configuring should it become ABR? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>It is assumed that the two routers are ABRs. However, the secondary >>>>>>adjacency is completely >>>>>>decoupled from the primary adjacency. Hence, there is nothing in the >>>>>>draft that precludes two >>>>>>non-ABRs from forming a secondary adjacency. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>Does this mean that for the topology, >>>>>R5 is a ABR in area A0 & A1. R1, R2, R3, R4 are in area A1. >>>>> >>>>>R1------------R2------------R3------------R4-----------area1--R5--area0 >>>>> >>>>>now, if R2 & R3 form a multi area link between them with A0 as the >>>>>secondary area, >>>>>then do R2 and R3 really become ABR routers although they are intra area routers >>>>>of area A1 ? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Hi Ramanan, >>>>This draft does not change the fact that neighbors must be attached to >>>>the same >>>>link (i.e., this is not like a virtual link). Hence, in the topology >>>>above, R5 could not >>>>be a nieghbor or R2 and R3. However, if you meant R1-R5 to be on the >>>>same LAN >>>>then R2 and R3 would not become ABRs just because they have secondary >>>>adjacencies. >>>>Thanks, >>>>Acee >>>> >>>> >>>> >>>> >>>> >>>>>Regards >>>>>Ramanan >>>>> >>>>> >>>>> >>>>> >>>Hi Acee, >>> >>>I have two questions here, >>> >>>1. If the routers were in LAN then on what criteria should the routers >>>R2 & R3 be >>>prevented from not becoming ABR, because after the multi area configuration, >>>both R2 and R3 would have >>> >>> >>> >>> >>> a. two interfaces (one being the physical and other being the >>>secondary topological link) >>> in different areas and fully adajacent neighbors too. >>> b. backbone connectivity in the secondary topological link >>> >>>2. In case the routers were to be in P2P connection in the above topology, >>>then can routers R2 and R3 become ABRs ? >>> >>> >>> >>> >>Hi Ramanan, >> >>If they are also connected to R1 in another area over the same link they >>will become ABRs. >>You didn't state that in your previous list post. A secondary adjacency >>is NO different from an >>adjacency on an unnumbered point-to-point link (as stated in the draft). >>If you think of it in >>that manner all your questions should be answered. >> >>Thanks, >>Acee >> >> >> >>>Regards >>>Ramanan >>> >>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 18 13:16:25 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05901 for ; Fri, 18 Mar 2005 13:16:24 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00FE0397@cherry.ease.lsoft.com>; Fri, 18 Mar 2005 13:16:26 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 62111576 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 18 Mar 2005 13:16:24 -0500 Received: from 130.76.32.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 18 Mar 2005 13:06:24 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA13240 for ; Fri, 18 Mar 2005 10:06:23 -0800 (PST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j2II6M718948 for ; Fri, 18 Mar 2005 12:06:22 -0600 (CST) Received: from xch-nw-10p.nw.nos.boeing.com ([192.42.229.11]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Mar 2005 10:06:21 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: Comments on draft-ietf-ospf-mt-01.txt Thread-Index: AcUr5TBytz0sjyAwQBCOA9REYDm71g== X-OriginalArrivalTime: 18 Mar 2005 18:06:21.0284 (UTC) FILETIME=[309A2240:01C52BE5] Message-ID: <8F2159280BB34342B0C4F22E7DC15C7784879E@XCH-NW-10P.nw.nos.boeing.com> Date: Fri, 18 Mar 2005 10:06:20 -0800 Reply-To: Mailing List Sender: Mailing List From: "Kushi, David M" Subject: Comments on draft-ietf-ospf-mt-01.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable > 9. MT ID Values >=20 > Since AS-External-LSAs use the high order bit in the MT-ID field=20 > (E bit) for the external metric-type, only MT-IDs in the range=20 > [0-127] are valid. The following MT-ID values are reserved: > =20 > 0 - Reserved for routers in MTRoutingExclusionCapability mode=20 > to advertise the metric associated with the default=20 > topology (see section 11.2). Here is a possible interpretation: 0 - Reserved for routers with MTRoutingExclusionCapability mode enabled to advertise the metric associated with the default topology (see section 11.2); for routers operating with MTRoutingExclusionCapability disabled, its use is unrestricted. Here is another: 0 - Reserved for routers with MTRoutingExclusionCapability mode enabled to advertise the metric associated with the default topology (see section 11.2); for routers operating with MTRoutingExclusionCapability disabled, the MT#0 metric is implicitly contained within the TOS0 metric field. If MT-ID 0 is contained within a list of additional MT-IDs present in the LSA, any additional occurrence is treated as a duplicate, and is ignored (in accordance with 6.). The advantage of the former, over the latter, is that there is=20 an extra MT-ID available for use (when=20 MTRoutingExclusionCapability is disabled). > =20 > 1 - Reserved for the default multicast topology. >=20 > Unknown MT-IDs SHOULD be ignored. > 11.2 New parameter in the Area Data Structure >=20 > We define a new parameter in the Area Data Structure: > =20 > MTRoutingExclusionCapability > This is a configurable parameter that will be used to facilitate > the introduction of MT routers in an area and ensure backward > compatibility. >=20 >=20 > By default, when an area data structure is created the=20 > MTRoutingExclusionCapability is disabled. > =20 > If MTRoutingExclusionCapability is disabled: > o The MT-bit MUST be cleared in Hello packets. The text would be unambiguous if the action associated with the=20 reception of an Hello packet bearing a set MT-bit, while in this mode, was explicitly stated. E.g. 'If an Hello packet is=20 received with the MT-bit set, it is not accepted by the router'. =20 Or simply, 'The MT-bit must match the configured value of the=20 area parameter MTRoutingExclusionCapability if it is to be=20 accepted by the router'. >=20 > o If a link participates in a non-default topology,=20 > it is automatically included in the default topology=20 > to support backward compatibility between MT and=20 > non-MT routers. This is accomplished through advertisement > via the TOS0 metric field the same as in standard OSPF [OSPF]. The clarity of this document would be improved through the addition of examples describing the encoding of messages. E.g. (for the presumed case where MT#0 is allowed to be used without restriction in the disabled mode): Assume there are two routers, RA and RB, each with an interface in area X. The 'MTRoutingExclusionCapability' parameter is configured with value 'disabled' on both, for X. RA is a non-MT=20 router; RB is MT-capable. On the interface located on RB that is in area X, and which attaches RB to RA, MT-ID 0 is configured with value 12, it is not reserved as a replacement for TOS0 because=20 'MTRoutingExclusionCapability' has value 'disabled', and thus its use is unrestricted; MT-ID 2 is configured with metric 10; the=20 standard TOS0 metric is configured with value 14. In this case,=20 a RTR-LSA contains 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 . . . =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |*|*|*|N|W|V|E|B| 0 | # links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | 2 | 14 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 0 | 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | 0 | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 11.4 OSPF Control Packets Transmission Over Excluded Links > > If MTRoutingExclusionCapability is enabled and the default > topology is not configured on an interface, connected routes MUST > still exist for the default topology and should enable OSPF control > packets to be sent and received over that interface. > As stated, this seems contradictory to the statement "OSPF control packets MUST be sent over the default topology." in 5. > > > 11.5 OSPF LSA Advertisement and SPF Computation for Excluded Links > > When MTRoutingExclusionCapability is enabled and the link does > not participate in the default topology, the MT-ID#0 metric is not > advertised. The TOS0 metric is set to infinity (0xFFFF) but is > ignored during the default topology SPF computation. > > When MTRoutingExclusionCapability is enabled and a link participates > in the default topology, MT-ID#0 metric is used to advertise the=20 > metric associated with the default topology. The TOS0 metric is set=20 > to the same value as the MT-ID#0 metric but is ignored during the=20 > default topology SPF computation. Why not simply indicate that the TOS0 metric is not used when=20 MTRoutingExclusionCapability has value 'enabled', and that the field is cleared to zero prior to transmission? From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 18 15:49:24 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27258 for ; Fri, 18 Mar 2005 15:49:22 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00FE07B9@cherry.ease.lsoft.com>; Fri, 18 Mar 2005 15:49:21 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 62123090 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 18 Mar 2005 15:49:19 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 18 Mar 2005 15:39:18 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24675; Fri, 18 Mar 2005 15:39:12 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200503182039.PAA24675@ietf.org> Date: Fri, 18 Mar 2005 15:39:12 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-mt-02.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Multi-Topology (MT) Routing in OSPF Author(s) : P. Psenak, et al. Filename : draft-ietf-ospf-mt-02.txt Pages : 16 Date : 2005-3-18 This draft describes an extension to OSPF in order to define independent IP topologies called Multi-Topologies (MTs). The MT extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service, or in-band network management. [M-ISIS] describes a similar mechanism for ISIS. An optional extension to exclude selected links from the default topology is also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-mt-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-mt-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-mt-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: <2005-3-18153932.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-mt-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-mt-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-18153932.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Sat Mar 19 09:16:35 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23241 for ; Sat, 19 Mar 2005 09:16:35 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00FE1DD7@cherry.ease.lsoft.com>; Sat, 19 Mar 2005 9:16:34 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 62211249 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 19 Mar 2005 09:16:32 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sat, 19 Mar 2005 09:16:32 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 19 Mar 2005 09:34:35 -0500 X-IronPort-AV: i="3.91,103,1110171600"; d="scan'208"; a="41160469:sNHT25678984" Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2JEGS1j026088 for ; Sat, 19 Mar 2005 09:16:29 -0500 (EST) Received: from [10.82.216.97] (rtp-vpn3-97.cisco.com [10.82.216.97]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BGF20862; Sat, 19 Mar 2005 06:16:28 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <111973429.20050317094906@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <423C343B.60105@cisco.com> Date: Sat, 19 Mar 2005 09:16:27 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <111973429.20050317094906@psg.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Alex, I don't feel that strongly on whether or not we need to document the behavior when an unknown link type is encountered. However, I was content to ignore them and leave the backward compatibility issues to those proposing new link types. If there were compelling reasons to introduce a new link type we are now relegated to a solution where we need protocol mechanisms to assure that every router in the area understands it prior to it's usage and, depending on the link type, this may be more conservative than what is needed. Thanks, Acee Alex Zinin wrote: >Vishwas, > >I'll try one more time. > > > >>If someone wants to write an implementation of OSPF, what does he/she do >>regarding unknown link types? >> >> > >We discussed this earlier in this thread. > > > >>We need to define the behavior else we >>will never get interoperability. I guess we both agree with the above. >> >> > >We do NOT have an interoperability issue unless we start deliberately >introducing new link types without making sure everyone understands them. > > > >>If I understood the discussion in the mailing list right, most >>implementations ignore the link and that is what we are trying to >>standardize. >> >> > >A few years ago we had a discussion that touched on link records. John mentioned >that there are still implementations out there that will ignore the whole LSA >when the see an unknown link type. I don't think we can ignore this. > > > >>The suggestion you make will not interoperate with the >>installed base at all while a MUST ignore solution will with most of >>them. >> >> > >I don't understand what you mean by "will not interoperate". > >Alex > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sun Mar 20 23:19:12 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27373 for ; Sun, 20 Mar 2005 23:19:11 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00FE4920@cherry.ease.lsoft.com>; 20 Mar 2005 23:19:10 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 62356475 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 20 Mar 2005 23:19:08 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 20 Mar 2005 23:19:08 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Thread-Index: AcUsjkJ/ZBdutfp/QWaxIBiBmqCRKQBP0jqg Message-ID: Date: Sun, 20 Mar 2005 20:19:08 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi, Let me summarize then, there are 4 cases the unknown link type can occur: - 1. Malicious user inserts the LSA. 2. Error before LSA checksum is calculated. 3. Memory corruption/ LSA error after checksum yet checksum correct. 4. New Link type is added (examples of what all can be added is detailed in the IS-IS route-tags draft/ experimental TLV draft). In all but the case 3, the solution proposed works. I am not aware of any protocol which works in face of case 3 at all (it may not even be a protocol specific action at all). Acee/ Alex let me know your views. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Saturday, March 19, 2005 7:46 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Hi Alex, I don't feel that strongly on whether or not we need to document the behavior when an unknown link type is encountered. However, I was content to ignore them and leave the backward compatibility issues to those proposing new link types. If there were compelling reasons to introduce a new link type we are now relegated to a solution where we need protocol mechanisms to assure that every router in the area understands it prior to it's usage and, depending on the link type, this may be more conservative than what is needed. Thanks, Acee Alex Zinin wrote: >Vishwas, > >I'll try one more time. > > =20 > >>If someone wants to write an implementation of OSPF, what does he/she do >>regarding unknown link types? >> =20 >> > >We discussed this earlier in this thread. > > =20 > >>We need to define the behavior else we >>will never get interoperability. I guess we both agree with the above. >> =20 >> > >We do NOT have an interoperability issue unless we start deliberately >introducing new link types without making sure everyone understands them. > > =20 > >>If I understood the discussion in the mailing list right, most >>implementations ignore the link and that is what we are trying to >>standardize. >> =20 >> > >A few years ago we had a discussion that touched on link records. John mentioned >that there are still implementations out there that will ignore the whole LSA >when the see an unknown link type. I don't think we can ignore this. > > =20 > >>The suggestion you make will not interoperate with the >>installed base at all while a MUST ignore solution will with most of >>them. >> =20 >> > >I don't understand what you mean by "will not interoperate". > >Alex > > =20 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Mar 21 04:24:39 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08827 for ; Mon, 21 Mar 2005 04:24:39 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00FE4EA0@cherry.ease.lsoft.com>; Mon, 21 Mar 2005 4:24:39 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 62369578 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 21 Mar 2005 04:24:38 -0500 Received: from 144.254.15.118 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 21 Mar 2005 04:24:37 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j2L9OaD00310 for ; Mon, 21 Mar 2005 10:24:36 +0100 (CET) Received: from cisco.com (ppsenak--isdn-home4.cisco.com [10.49.2.221]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j2L9OZK11818 for ; Mon, 21 Mar 2005 10:24:35 +0100 (CET) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <8F2159280BB34342B0C4F22E7DC15C7784879E@XCH-NW-10P.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <423E92D3.7030306@cisco.com> Date: Mon, 21 Mar 2005 10:24:35 +0100 Reply-To: Mailing List Sender: Mailing List From: Peter Psenak Subject: Re: Comments on draft-ietf-ospf-mt-01.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Kushi, Kushi, David M wrote: >>9. MT ID Values >> >> Since AS-External-LSAs use the high order bit in the MT-ID field >> (E bit) for the external metric-type, only MT-IDs in the range >> [0-127] are valid. The following MT-ID values are reserved: >> >> 0 - Reserved for routers in MTRoutingExclusionCapability mode >> to advertise the metric associated with the default >> topology (see section 11.2). MTID values 0 is reserved for base unicast topology regardless of MTRoutingExclusionCapability. I'll update the text to reflect that. > > > Here is a possible interpretation: > > 0 - Reserved for routers with MTRoutingExclusionCapability > mode enabled to advertise the metric associated with > the default topology (see section 11.2); for routers > operating with MTRoutingExclusionCapability disabled, > its use is unrestricted. > > Here is another: > > 0 - Reserved for routers with MTRoutingExclusionCapability > mode enabled to advertise the metric associated with > the default topology (see section 11.2); for routers > operating with MTRoutingExclusionCapability disabled, > the MT#0 metric is implicitly contained within the > TOS0 metric field. If MT-ID 0 is contained within > a list of additional MT-IDs present in the LSA, any > additional occurrence is treated as a duplicate, and > is ignored (in accordance with 6.). > > > The advantage of the former, over the latter, is that there is > an extra MT-ID available for use (when > MTRoutingExclusionCapability is disabled). > > >> >> 1 - Reserved for the default multicast topology. >> >> Unknown MT-IDs SHOULD be ignored. > > > >>11.2 New parameter in the Area Data Structure >> >> We define a new parameter in the Area Data Structure: >> >> MTRoutingExclusionCapability >> This is a configurable parameter that will be used to facilitate >> the introduction of MT routers in an area and ensure backward >> compatibility. >> >> >> By default, when an area data structure is created the >> MTRoutingExclusionCapability is disabled. >> >> If MTRoutingExclusionCapability is disabled: >> o The MT-bit MUST be cleared in Hello packets. > > > The text would be unambiguous if the action associated with the > reception of an Hello packet bearing a set MT-bit, while in > this mode, was explicitly stated. E.g. 'If an Hello packet is > received with the MT-bit set, it is not accepted by the router'. > Or simply, 'The MT-bit must match the configured value of the > area parameter MTRoutingExclusionCapability if it is to be > accepted by the router'. - pre-MTR routers do not understand MT-bit and should ignore it, same is done on routers that understand MTR but has MTRoutingExclusionCapability disabled. - it's enough to detect the misconfiguration on one side - check the MT-bit on the router that has MTRoutingExclusionCapability enabled. > > >> o If a link participates in a non-default topology, >> it is automatically included in the default topology >> to support backward compatibility between MT and >> non-MT routers. This is accomplished through advertisement >> via the TOS0 metric field the same as in standard OSPF > > [OSPF]. > > > The clarity of this document would be improved through the addition > of examples describing the encoding of messages. > > E.g. (for the presumed case where MT#0 is allowed to be used without > restriction in the disabled mode): as MTID-0 is reserved regardless of the MTRoutingExclusionCapability state, I think we can live without the below example. > > Assume there are two routers, RA and RB, each with an interface in > area X. The 'MTRoutingExclusionCapability' parameter is > configured with value 'disabled' on both, for X. RA is a non-MT > router; RB is MT-capable. > > On the interface located on RB that is in area X, and which > attaches RB to RA, MT-ID 0 is configured with value 12, > it is not reserved as a replacement for TOS0 because > 'MTRoutingExclusionCapability' has value 'disabled', and thus its > use is unrestricted; MT-ID 2 is configured with metric 10; the > standard TOS0 metric is configured with value 14. In this case, > a RTR-LSA contains 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 > . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |*|*|*|N|W|V|E|B| 0 | # links | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Link ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Link Data | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | 2 | 14 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0 | 0 | 12 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 2 | 0 | 10 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >>11.4 OSPF Control Packets Transmission Over Excluded Links >> >> If MTRoutingExclusionCapability is enabled and the default >> topology is not configured on an interface, connected routes MUST >> still exist for the default topology and should enable OSPF control >> packets to be sent and received over that interface. >> > > > As stated, this seems contradictory to the statement "OSPF control > packets MUST be sent over the default topology." in 5. the fact that default topology is "disabled" on the interface means: 1. OSPF does not advertise the link in the default topology. 2. connected route for the interface exist in the RIB associated with the default topology (2) allows control packets to be sent over the interface. In other words disabling topology on the interface only affects what OSPF advertises. > > >> >>11.5 OSPF LSA Advertisement and SPF Computation for Excluded Links >> >> When MTRoutingExclusionCapability is enabled and the link does >> not participate in the default topology, the MT-ID#0 metric is not >> advertised. The TOS0 metric is set to infinity (0xFFFF) but is >> ignored during the default topology SPF computation. >> >> When MTRoutingExclusionCapability is enabled and a link participates >> in the default topology, MT-ID#0 metric is used to advertise the >> metric associated with the default topology. The TOS0 metric is set >> to the same value as the MT-ID#0 metric but is ignored during the >> default topology SPF computation. > > > Why not simply indicate that the TOS0 metric is not used when > MTRoutingExclusionCapability has value 'enabled', and that the does not the text above says that? "is ignored during the default topology SPF computation" > field is cleared to zero prior to transmission? TOS-0 metric can be set to whatever value, because it's not used in this case. We can remove the part that says what value it should be set to and leave it up to the implementation to fill the value. thanks, Peter > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 22 16:03:20 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04117 for ; Tue, 22 Mar 2005 16:03:18 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00FE7D1C@cherry.ease.lsoft.com>; Tue, 22 Mar 2005 16:03:17 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 62620406 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 22 Mar 2005 16:03:14 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 22 Mar 2005 15:53:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01872; Tue, 22 Mar 2005 15:53:10 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200503222053.PAA01872@ietf.org> Date: Tue, 22 Mar 2005 15:53:09 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-traffic-04.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Traffic Engineering Extensions to OSPF version 3 Author(s) : K. Ishiguro, et al. Filename : draft-ietf-ospf-ospfv3-traffic-04.txt Pages : 17 Date : 2005-3-22 This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to handle IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-traffic-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-traffic-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-ospf-ospfv3-traffic-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: <2005-3-22162553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-traffic-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-traffic-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-22162553.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 22 16:10:15 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05914 for ; Tue, 22 Mar 2005 16:10:15 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00FE7BBA@cherry.ease.lsoft.com>; Tue, 22 Mar 2005 16:09:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 62621862 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 22 Mar 2005 16:09:42 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 22 Mar 2005 16:09:42 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 22 Mar 2005 16:28:22 -0500 X-IronPort-AV: i="3.91,111,1110171600"; d="scan'208"; a="41489348:sNHT27789196" Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2ML9e1j029513 for ; Tue, 22 Mar 2005 16:09:40 -0500 (EST) Received: from [10.82.216.97] (rtp-vpn3-97.cisco.com [10.82.216.97]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BGH03780; Tue, 22 Mar 2005 13:09:38 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200503222053.PAA01872@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <42408992.4080206@cisco.com> Date: Tue, 22 Mar 2005 16:09:38 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-ietf-ospf-ospfv3-traffic-04.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200503222053.PAA01872@ietf.org> Precedence: list Content-Transfer-Encoding: 7bit Please take a look at this version as I think we are close to being ready for a WG last call. Thanks, Acee Internet-Drafts@IETF.ORG wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. > > Title : Traffic Engineering Extensions to OSPF version 3 > Author(s) : K. Ishiguro, et al. > Filename : draft-ietf-ospf-ospfv3-traffic-04.txt > Pages : 17 > Date : 2005-3-22 > >This document describes extensions to OSPFv3 to support intra-area > Traffic Engineering (TE). This document extends OSPFv2 TE to handle > IPv6 networks. A new TLV and several new sub-TLVs are defined to > support IPv6 networks. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-traffic-04.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-ospf-ospfv3-traffic-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-ospf-ospfv3-traffic-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. >------------------------------------------------------------------------- >CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY >------------------------------------------------------------------------- >In order to maintain computing infrastructure integrity, Cisco Systems >Enterprise Messaging Services and InfoSec teams have set a mail policy >disallowing executable attachments in email. > >This message contained an executable attachment type that is prohibited >by this policy. The attachment has been removed from this message and >copied to quarantine by our systems. It will be held in quarantine for >seven days in the event that the content needs to be retrieved. > >Please be aware many viruses attempt to look like legitimate email or >notifications from anti-virus systems. We will clearly mark a seperation >between our notifications and the original email as follows: > > "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" > >For further reference information about viruses and email antivirus >efforts within Cisco, please visit: > >http://wwwin.cisco.com/it/ems/services/antiviral > >If your concern isn't addressed by the information in this notification >or the above web page, you may open a support request: > >http://wwwin.cisco.com/support/ > >Select "Messaging", "Email-Related", "Mail Routing" > >Please include in the text of your case the following information: > >* Full headers of the message. Documentation on displaying the full >headers is available at this URL: > >http://wwwin.cisco.com/support/library/faqs/solution002471.html > >* This unique quarantine identifier: j2ML26gm022836 > >If the matter is urgent, you may follow up by calling one of the below >referenced numbers. Please make every effort to provide the above >requested information via the support web tool prior to calling as it >will greatly aid the resolution of your issue. > >Americas: >1 408 526 8888 > >Asiapac >+61 2 8446 8888 > >EMEA >+31 20 485 4888 > >Japan >+81 3 5549 6888 > >US (Toll Free) >1| 800| 888| 8187| (ext.68888) > >Thank you for your cooperation, > >Enterprise Messaging Services >Cisco Systems, Inc > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 23 15:10:16 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28713 for ; Wed, 23 Mar 2005 15:10:15 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00FE9AEF@cherry.ease.lsoft.com>; Wed, 23 Mar 2005 15:10:12 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 62748196 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 23 Mar 2005 15:10:09 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 23 Mar 2005 15:10:08 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 23 Mar 2005 15:10:09 -0500 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2NKA6jI029869 for ; Wed, 23 Mar 2005 15:10:07 -0500 (EST) Received: from [64.102.48.137] (dhcp-64-102-48-137.cisco.com [64.102.48.137]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BGH82032; Wed, 23 Mar 2005 12:10:04 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 Message-ID: <4241CD1C.4060205@cisco.com> Date: Wed, 23 Mar 2005 15:10:04 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPFv3 Extension Future Direction (this ought to get your attention) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit At the Minneapolis IETF, I presented a comparision of the various options we have for extending OSPFv3. The reaction to the presentation was very positive. However, it was last on the agenda and the OSPF WG coincided with other WGs (most notably L2VPN). At this point, I would like to initiate more discussion. The basic question is whether we go with a TLV based approach or continue to add new LSAs which need to be synchronized with the LSAs advertising topology and prefix information. A TLV based approach is described in: http://www.ietf.org/internet-drafts/draft-mirtorabi-mt-ospfv3-01.txt The crux of my presentation would be that this is gives us the powerful extension capability while still allowing us to advertise information that does not need to be synchronized in separate LSAs. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 23 16:23:04 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08029 for ; Wed, 23 Mar 2005 16:23:04 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00FE9C5A@cherry.ease.lsoft.com>; Wed, 23 Mar 2005 16:23:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 62753570 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 23 Mar 2005 16:23:01 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 23 Mar 2005 16:13:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05450; Wed, 23 Mar 2005 16:13:00 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200503232113.QAA05450@ietf.org> Date: Wed, 23 Mar 2005 16:12:59 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-update-03.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : OSPF for IPv6 Author(s) : D. Ferguson, et al. Filename : draft-ietf-ospf-ospfv3-update-03.txt Pages : 87 Date : 2005-3-23 This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-update-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-update-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-23164424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-update-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-23164424.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 23 17:06:42 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28476 for ; Wed, 23 Mar 2005 17:06:41 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00FE9EF8@cherry.ease.lsoft.com>; Wed, 23 Mar 2005 17:06:37 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 62766374 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 23 Mar 2005 17:06:34 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 23 Mar 2005 17:06:34 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 23 Mar 2005 14:06:35 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2NM6UgE010095 for ; Wed, 23 Mar 2005 14:06:30 -0800 (PST) Received: (from localhost [127.0.0.1]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) id BDF93008; Wed, 23 Mar 2005 14:06:32 -0800 (PST) Auto-Submitted: auto-replied MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Message-ID: <20050323140632.BDF93008@mira-sjc5-b.cisco.com> Date: Wed, 23 Mar 2005 14:06:32 -0800 Reply-To: Mailing List Sender: Mailing List From: akr@CISCO.COM Subject: on PTO till March 25th.. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit If this is urgent, please contact Ahmad Yazdi (ayazdi). From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 24 05:38:03 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24147 for ; Thu, 24 Mar 2005 05:38:03 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00FEAE1D@cherry.ease.lsoft.com>; Thu, 24 Mar 2005 5:37:59 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 62921227 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 24 Mar 2005 05:37:57 -0500 Received: from 202.43.216.207 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 24 Mar 2005 05:37:56 -0500 Received: from [202.96.96.35] by web15404.mail.cnb.yahoo.com via HTTP; Thu, 24 Mar 2005 18:37:54 CST MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Message-ID: <20050324103754.84107.qmail@web15404.mail.cnb.yahoo.com> Date: Thu, 24 Mar 2005 18:37:54 +0800 Reply-To: Mailing List Sender: Mailing List From: Jing Shen Subject: Re: Number of Routes and network stability To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: 6667 Precedence: list Content-Transfer-Encoding: 8bit I think the number parallel adjacent router per interface should be the point that node degree should be limited; but, to current situation, even with L3 switch, each interface does not exceed 10 adjacy in real networks. So, IMHO the total number of routes should not be a hard limit for a OSPF area; but, the covergence time & node degree should be limited. regards Jing --- Brett White wrote: > Hi Mitchell, > > You say that a router shouldn't have an issue with > 3000 links to other routers in an area. What I am > interested in is how you see the breakdown of this > figure on a per interface basis? Do you expect that > the device should be able to support these 3000 > links on a single interface or spread across say 128 > ports? > > Regards, > > Brett White > > -----Original Message----- > From: Mailing List > [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > Erblichs > Sent: Friday, 3 December 2004 13:49 > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Number of Routes and network stability > > Andrew Smith, > > I don't think I agree with 90% of this. > > Available memory has to do with the max size > of > the LSDB, siumultaneous rexmit queues, etc, > THAN > the max number of routers supported in a > area. > > Assuming that enough memory is available, > link-stability > and dead-router interval are more important > than CPU > capability wrt network stability. Next comes > with the > number & sizing of input queues, link-speed, > and network > topology. > > If the number of hellos and OSPF control > pkts > overload a CPU, then I hate to see the SPF > timeframes, > or what would happen if a large number of > pkts > are targeted to the router. > > If one says that they can't handle close to > 3000 > simultaneous links with other routers in a > area, > then IMO, they have a few issues with their > code. > > I am NOT stating that 3000 simultaneous full > adjs can > be formed. But if you are dropping adjs > because their > are too many routers in the area and you > thus are > dropping (or delaing the processing of) > hellos, then > their is something wrong with the code or > hardware. > > Support for a large number of routers within > a area > more has to do with IMO, the ability to > decrease the > hello interval and hello multiplier and > still not drop > adjs. Secondly, each router then COULD > support fewer > links and a failed router would have less of > a topology > effect. > > Mitchell Erblich > ----------------- > > > Andrew Smith wrote: > > > > The recommendation for number of routers per area > is usually derived > > by considering the amount of processor power and > memory available to > > the routers in an area. Usually you consider the > lowest common > > denominator. This means the smallest router (the > router with the > > fewest resources) limits the size of the area. > > > > A good rule of thumb is no more than 100 routers > per area. If you try > > to keep an initial design to 50-70 routers that > usually allows room to > > grow and recover from a network crisis. > > > > The vendors that say they can do 3000 routers per > area are giving a > > scalability number for that box. This particular > router can achieve > > 3000 routers per area "under the proper > circumstances". This is good > > to know for how much the box can take, not how > high to scale your OSPF > > areas. > > > > Regards, > > Andy Smith > > > > -----Original Message----- > > From: Mailing List > [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > > Jing Shen > > Sent: Thursday, December 02, 2004 4:46 AM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Number of Routes and network stability > > > > Hi, > > > > Some vendors recommended that number of routers > within one OSPF area > > should not exceed 50, some others recommended > number of routes within > > one area should not exceed 3000. > > > > To my understanding, OSPF stability is directly > related to link > > stability, radius of an OSPF area and OSPF > implementation( router > > hardware, methodology of link status processing). > But, is there any > > research done on this topic? or how are those > recommendation derived ? > > > > thanks > > > > Jing Shen > > > > > _________________________________________________________ > > Do You Yahoo!? > > ×¢²áÊÀ½çÒ»Á÷Æ·ÖʵÄÑÅ»¢Ãâ·ÑµçÓÊ > > > http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/ > Jing Shen Data Communication Center HangZhou TeleCom HangZhou ZJ 310027 P.R.China ' spamcontrol ' _________________________________________________________ Do You Yahoo!? ×¢²áÊÀ½çÒ»Á÷Æ·ÖʵÄÑÅ»¢Ãâ·ÑµçÓÊ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/ From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 24 22:58:31 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15186 for ; Thu, 24 Mar 2005 22:58:30 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00FEC8DB@cherry.ease.lsoft.com>; Thu, 24 Mar 2005 22:58:30 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 63185951 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 24 Mar 2005 22:58:23 -0500 Received: from 66.218.92.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 24 Mar 2005 22:58:19 -0500 Received: (qmail 9438 invoked by uid 60001); 25 Mar 2005 03:58:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=cLcVax+LMGhxJaIsL55JrK85MLqs0+wnCTfPRtRnSCqkcAU4E25Ec0o/X6BXKsRznDqX5MKBgmFvJ0GGxvLKqnyLGhZkcH1d3AqvF/CCiIXXJ6K9xOvJkoNA01OeWG/oB5Wic6JSfmkxDk6oqj59IRYMMt3GvbOkzInJXwofO38= ; Received: from [64.142.109.122] by web40428.mail.yahoo.com via HTTP; Thu, 24 Mar 2005 19:58:18 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20050325035818.9436.qmail@web40428.mail.yahoo.com> Date: Thu, 24 Mar 2005 19:58:18 -0800 Reply-To: Mailing List Sender: Mailing List Comments: DomainKeys? See http://antispam.yahoo.com/domainkeys From: Pyda Srisuresh Subject: Re: OSPFv3 Extension Future Direction (this ought to get your attention) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: 6667 Precedence: list Acee, I had done some work previously on using new LSAs for advertising topology and prefix info into TE networks (draft-srisuresh-ospf-te-07.txt). This draft can be a good starting point to use for turning into future MT extensions to OSPFv3. I have not been active on this work recently due to my work priorities. However, if there are folks on the list interested in pursuing, I would be happy to work with you on the effort and discussion. Thanks. cheers, suresh --- Acee Lindem wrote: > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > At the Minneapolis IETF, I presented a comparision of the > various options we have for extending OSPFv3. The reaction to the > presentation was very positive. However, it was last on the agenda and > the OSPF WG coincided with other WGs (most notably L2VPN). > > At this point, I would like to initiate more discussion. The basic > question is whether we go with a TLV based approach or continue > to add new LSAs which need to be synchronized with the LSAs > advertising topology and prefix information. A TLV based approach > is described in: > > http://www.ietf.org/internet-drafts/draft-mirtorabi-mt-ospfv3-01.txt > > The crux of my presentation would be that this is gives us the powerful > extension capability while still allowing us to advertise information that > does not need to be synchronized in separate LSAs. > > Thanks, > Acee > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 24 23:05:36 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16129 for ; Thu, 24 Mar 2005 23:05:31 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00FECB53@cherry.ease.lsoft.com>; Thu, 24 Mar 2005 23:05:32 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 63188961 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 24 Mar 2005 23:05:30 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 24 Mar 2005 23:05:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: OSPFv3 Extension Future Direction (this ought to get your attention) Thread-Index: AcUw7ukVtwjH5/SaSV6mPFpmjChiNwAAa6mA Message-ID: Date: Thu, 24 Mar 2005 20:05:29 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: OSPFv3 Extension Future Direction (this ought to get your attention) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Acee, I have not read the draft yet.=20 Having implemented both OSPF and IS-IS from scratch, my view is that the OSPF LSA's have a big advantage of all relevant information being clubbed togather. I think having extensible LSA's with TLV's(hybrid approach) is the best approach (like in Pyda's draft) but I am not sure we want to go to a fully TLV based approach. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Pyda Srisuresh Sent: Friday, March 25, 2005 9:28 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: OSPFv3 Extension Future Direction (this ought to get your attention) Acee, I had done some work previously on using new LSAs for advertising topology and prefix info into TE networks (draft-srisuresh-ospf-te-07.txt). This draft can be a good starting point to use for turning into future MT extensions to OSPFv3.=20 I have not been active on this work recently due to my work priorities. However, if there are folks on the list interested in pursuing, I would be happy to work with you on the effort and discussion.=20 Thanks. cheers, suresh=20 =20 --- Acee Lindem wrote: > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > Content-Transfer-Encoding: 7bit >=20 > At the Minneapolis IETF, I presented a comparision of the > various options we have for extending OSPFv3. The reaction to the > presentation was very positive. However, it was last on the agenda and > the OSPF WG coincided with other WGs (most notably L2VPN). >=20 > At this point, I would like to initiate more discussion. The basic > question is whether we go with a TLV based approach or continue > to add new LSAs which need to be synchronized with the LSAs > advertising topology and prefix information. A TLV based approach > is described in: >=20 > http://www.ietf.org/internet-drafts/draft-mirtorabi-mt-ospfv3-01.txt >=20 > The crux of my presentation would be that this is gives us the powerful > extension capability while still allowing us to advertise information that > does not need to be synchronized in separate LSAs. >=20 > Thanks, > Acee >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 24 23:24:00 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17536 for ; Thu, 24 Mar 2005 23:24:00 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00FECAB4@cherry.ease.lsoft.com>; Thu, 24 Mar 2005 23:24:00 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 63192611 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 24 Mar 2005 23:23:59 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 24 Mar 2005 23:23:59 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 24 Mar 2005 23:23:59 -0500 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2P4Ns1j010575 for ; Thu, 24 Mar 2005 23:23:55 -0500 (EST) Received: from [10.82.226.76] (rtp-vpn1-588.cisco.com [10.82.226.76]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BGJ08896; Thu, 24 Mar 2005 20:23:55 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20050325035818.9436.qmail@web40428.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4243925B.6080706@cisco.com> Date: Thu, 24 Mar 2005 23:23:55 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 Extension Future Direction (this ought to get your attention) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050325035818.9436.qmail@web40428.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit Pyda Srisuresh wrote: >Acee, > >I had done some work previously on using new LSAs for advertising topology and >prefix info into TE networks (draft-srisuresh-ospf-te-07.txt). This draft can >be a good starting point to use for turning into future MT extensions to >OSPFv3. > > Hi Pyda, I don't see a requirement to mix TE data and the unicast/multicast topology information. This has traditionally been separate and processed by different functional components. The new LSAs in our draft correspond directly to the existing base LSA types (only they are in extendible TLV format and support multiple topologies). Thanks, Acee >I have not been active on this work recently due to my work priorities. >However, if there are folks on the list interested in pursuing, I would be >happy to work with you on the effort and discussion. > >Thanks. > >cheers, >suresh > >--- Acee Lindem wrote: > > >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>Content-Transfer-Encoding: 7bit >> >>At the Minneapolis IETF, I presented a comparision of the >>various options we have for extending OSPFv3. The reaction to the >>presentation was very positive. However, it was last on the agenda and >>the OSPF WG coincided with other WGs (most notably L2VPN). >> >>At this point, I would like to initiate more discussion. The basic >>question is whether we go with a TLV based approach or continue >>to add new LSAs which need to be synchronized with the LSAs >>advertising topology and prefix information. A TLV based approach >>is described in: >> >>http://www.ietf.org/internet-drafts/draft-mirtorabi-mt-ospfv3-01.txt >> >>The crux of my presentation would be that this is gives us the powerful >>extension capability while still allowing us to advertise information that >>does not need to be synchronized in separate LSAs. >> >>Thanks, >>Acee >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 24 23:28:20 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17869 for ; Thu, 24 Mar 2005 23:28:20 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00FECB54@cherry.ease.lsoft.com>; Thu, 24 Mar 2005 23:28:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 63193419 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 24 Mar 2005 23:28:19 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 24 Mar 2005 23:28:19 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 24 Mar 2005 23:47:24 -0500 X-IronPort-AV: i="3.91,121,1110171600"; d="scan'208"; a="41878577:sNHT28310054" Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2P4SGjI021981 for ; Thu, 24 Mar 2005 23:28:17 -0500 (EST) Received: from [10.82.226.76] (rtp-vpn1-588.cisco.com [10.82.226.76]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BGJ08988; Thu, 24 Mar 2005 20:28:16 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <42439360.507@cisco.com> Date: Thu, 24 Mar 2005 23:28:16 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 Extension Future Direction (this ought to get your attention) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Vishwas Manral wrote: >Hi Acee, > >I have not read the draft yet. > >Having implemented both OSPF and IS-IS from scratch, my view is that the >OSPF LSA's have a big advantage of all relevant information being >clubbed togather. I think having extensible LSA's with TLV's(hybrid >approach) is the best approach (like in Pyda's draft) but I am not sure >we want to go to a fully TLV based approach. > > This is the approach taken in the draft. I think that if we adopt this approach we should be somewhat conservative about what TLVs we allow to be added. Since we also have the flexibility of adding new LSA types we should use that option when the protocol extensions do not need to be advertised and synchronized with the prefix and topology information. >Thanks, >Vishwas >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Pyda >Srisuresh >Sent: Friday, March 25, 2005 9:28 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: OSPFv3 Extension Future Direction (this ought to get your >attention) > >Acee, > >I had done some work previously on using new LSAs for advertising >topology and >prefix info into TE networks (draft-srisuresh-ospf-te-07.txt). This >draft can >be a good starting point to use for turning into future MT extensions to >OSPFv3. > >I have not been active on this work recently due to my work priorities. >However, if there are folks on the list interested in pursuing, I would >be >happy to work with you on the effort and discussion. > >Thanks. > >cheers, >suresh > >--- Acee Lindem wrote: > > >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>Content-Transfer-Encoding: 7bit >> >>At the Minneapolis IETF, I presented a comparision of the >>various options we have for extending OSPFv3. The reaction to the >>presentation was very positive. However, it was last on the agenda and >>the OSPF WG coincided with other WGs (most notably L2VPN). >> >>At this point, I would like to initiate more discussion. The basic >>question is whether we go with a TLV based approach or continue >>to add new LSAs which need to be synchronized with the LSAs >>advertising topology and prefix information. A TLV based approach >>is described in: >> >>http://www.ietf.org/internet-drafts/draft-mirtorabi-mt-ospfv3-01.txt >> >>The crux of my presentation would be that this is gives us the >> >> >powerful > > >>extension capability while still allowing us to advertise information >> >> >that > > >>does not need to be synchronized in separate LSAs. >> >>Thanks, >>Acee >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 25 03:46:32 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28931 for ; Fri, 25 Mar 2005 03:46:31 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00FECFB9@cherry.ease.lsoft.com>; Fri, 25 Mar 2005 3:46:31 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 63232781 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 25 Mar 2005 03:46:30 -0500 Received: from 144.254.15.118 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 25 Mar 2005 03:46:30 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j2P8kSx15761 for ; Fri, 25 Mar 2005 09:46:28 +0100 (CET) Received: from cisco.com (ppsenak--isdn-home4.cisco.com [10.49.2.221]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j2P8kRK22829 for ; Fri, 25 Mar 2005 09:46:28 +0100 (CET) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <42439360.507@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4243CFE3.1000404@cisco.com> Date: Fri, 25 Mar 2005 09:46:27 +0100 Reply-To: Mailing List Sender: Mailing List From: Peter Psenak Subject: Re: OSPFv3 Extension Future Direction (this ought to get your attention) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee Lindem wrote: > Vishwas Manral wrote: > >> Hi Acee, >> >> I have not read the draft yet. >> Having implemented both OSPF and IS-IS from scratch, my view is that the >> OSPF LSA's have a big advantage of all relevant information being >> clubbed togather. I think having extensible LSA's with TLV's(hybrid >> approach) is the best approach (like in Pyda's draft) but I am not sure >> we want to go to a fully TLV based approach. the question also is how much information do we want to plug in a single LSA. Do we want to keep the current per prefix/router granularity of AS-external-LSA/Inter-Area-Prefix-LSA/Inter-Area-Router-LSA or use these LSAs as a container to advertise many prefixes/routers. Peter >> >> > This is the approach taken in the draft. I think that if we adopt this > approach we should > be somewhat conservative about what TLVs we allow to be added. Since we > also have the > flexibility of adding new LSA types we should use that option when the > protocol extensions > do not need to be advertised and synchronized with the prefix and > topology information. > > >> Thanks, >> Vishwas >> -----Original Message----- >> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Pyda >> Srisuresh >> Sent: Friday, March 25, 2005 9:28 AM >> To: OSPF@PEACH.EASE.LSOFT.COM >> Subject: Re: OSPFv3 Extension Future Direction (this ought to get your >> attention) >> >> Acee, >> >> I had done some work previously on using new LSAs for advertising >> topology and >> prefix info into TE networks (draft-srisuresh-ospf-te-07.txt). This >> draft can >> be a good starting point to use for turning into future MT extensions to >> OSPFv3. >> I have not been active on this work recently due to my work priorities. >> However, if there are folks on the list interested in pursuing, I would >> be >> happy to work with you on the effort and discussion. >> Thanks. >> >> cheers, >> suresh >> --- Acee Lindem wrote: >> >> >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>> Content-Transfer-Encoding: 7bit >>> >>> At the Minneapolis IETF, I presented a comparision of the >>> various options we have for extending OSPFv3. The reaction to the >>> presentation was very positive. However, it was last on the agenda and >>> the OSPF WG coincided with other WGs (most notably L2VPN). >>> >>> At this point, I would like to initiate more discussion. The basic >>> question is whether we go with a TLV based approach or continue >>> to add new LSAs which need to be synchronized with the LSAs >>> advertising topology and prefix information. A TLV based approach >>> is described in: >>> >>> http://www.ietf.org/internet-drafts/draft-mirtorabi-mt-ospfv3-01.txt >>> >>> The crux of my presentation would be that this is gives us the >>> >> >> powerful >> >> >>> extension capability while still allowing us to advertise information >>> >> >> that >> >> >>> does not need to be synchronized in separate LSAs. >>> >>> Thanks, >>> Acee >>> >>> >> >> >> >> > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 25 08:59:45 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28644 for ; Fri, 25 Mar 2005 08:59:44 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00FED7C6@cherry.ease.lsoft.com>; Fri, 25 Mar 2005 8:58:01 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 63327935 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 25 Mar 2005 08:58:00 -0500 Received: from 66.218.92.33 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 25 Mar 2005 08:57:59 -0500 Received: (qmail 72878 invoked by uid 60001); 25 Mar 2005 13:57:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=ZoJjUvhyMPAPA5RLcQbpDh0HhFM0lPXMK5sb1/QXWGuyoiVZZG/ojsEZkWeWw2LJ1QPcU8KkAAzp5BOg69OsI7pVkd11SBsrjrk+U93NWhjtIz9PuZywEBH6GC6O31+IVbvpQnkWNzIDBzoNx3/2tgArQwSHI+iNDhDdrx/nqP8= ; Received: from [67.164.86.136] by web40422.mail.yahoo.com via HTTP; Fri, 25 Mar 2005 05:57:55 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20050325135755.72876.qmail@web40422.mail.yahoo.com> Date: Fri, 25 Mar 2005 05:57:55 -0800 Reply-To: Mailing List Sender: Mailing List Comments: DomainKeys? See http://antispam.yahoo.com/domainkeys From: Pyda Srisuresh Subject: Re: OSPFv3 Extension Future Direction (this ought to get your attention) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: 6667 Precedence: list Right. That is my opinion as well. cheers, suresh --- Vishwas Manral wrote: > Hi Acee, > > I have not read the draft yet. > > Having implemented both OSPF and IS-IS from scratch, my view is that the > OSPF LSA's have a big advantage of all relevant information being > clubbed togather. I think having extensible LSA's with TLV's(hybrid > approach) is the best approach (like in Pyda's draft) but I am not sure > we want to go to a fully TLV based approach. > > Thanks, > Vishwas > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Pyda > Srisuresh > Sent: Friday, March 25, 2005 9:28 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: OSPFv3 Extension Future Direction (this ought to get your > attention) > > Acee, > > I had done some work previously on using new LSAs for advertising > topology and > prefix info into TE networks (draft-srisuresh-ospf-te-07.txt). This > draft can > be a good starting point to use for turning into future MT extensions to > OSPFv3. > > I have not been active on this work recently due to my work priorities. > However, if there are folks on the list interested in pursuing, I would > be > happy to work with you on the effort and discussion. > > Thanks. > > cheers, > suresh > > --- Acee Lindem wrote: > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Content-Transfer-Encoding: 7bit > > > > At the Minneapolis IETF, I presented a comparision of the > > various options we have for extending OSPFv3. The reaction to the > > presentation was very positive. However, it was last on the agenda and > > the OSPF WG coincided with other WGs (most notably L2VPN). > > > > At this point, I would like to initiate more discussion. The basic > > question is whether we go with a TLV based approach or continue > > to add new LSAs which need to be synchronized with the LSAs > > advertising topology and prefix information. A TLV based approach > > is described in: > > > > http://www.ietf.org/internet-drafts/draft-mirtorabi-mt-ospfv3-01.txt > > > > The crux of my presentation would be that this is gives us the > powerful > > extension capability while still allowing us to advertise information > that > > does not need to be synchronized in separate LSAs. > > > > Thanks, > > Acee > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 25 09:15:15 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00596 for ; Fri, 25 Mar 2005 09:15:14 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00FED874@cherry.ease.lsoft.com>; Fri, 25 Mar 2005 9:15:14 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 63333115 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 25 Mar 2005 09:15:12 -0500 Received: from 66.218.92.38 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 25 Mar 2005 09:15:12 -0500 Received: (qmail 67667 invoked by uid 60001); 25 Mar 2005 14:15:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=MxHG7kE6j7CFyoP8nm5O1sXx7mCcjOhbWKVKX3Hy1lNdMS3hIrIEZlMPJLJ8g97nJEdywq89UQ4hgIEeZxP9imxvPegKGT+kLwS8rhjZn2yRqr5J1sl2ZaQ+yWpNsyn+QWt8jQRAijgsVhXuYLUx6KqORbhx7/vAONzU5o3thgA= ; Received: from [67.164.86.136] by web40427.mail.yahoo.com via HTTP; Fri, 25 Mar 2005 06:15:11 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20050325141511.67664.qmail@web40427.mail.yahoo.com> Date: Fri, 25 Mar 2005 06:15:11 -0800 Reply-To: Mailing List Sender: Mailing List Comments: DomainKeys? See http://antispam.yahoo.com/domainkeys From: Pyda Srisuresh Subject: Re: OSPFv3 Extension Future Direction (this ought to get your attention) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: 6667 Precedence: list --- Acee Lindem wrote: > Pyda Srisuresh wrote: > > >Acee, > > > >I had done some work previously on using new LSAs for advertising topology > and > >prefix info into TE networks (draft-srisuresh-ospf-te-07.txt). This draft > can > >be a good starting point to use for turning into future MT extensions to > >OSPFv3. > > > > > Hi Pyda, > I don't see a requirement to mix TE data and the unicast/multicast > topology information. This has traditionally > been separate and processed by different functional components. The new > LSAs in our draft correspond > directly to the existing base LSA types (only they are in extendible TLV > format and support multiple > topologies). > [suresh] Acee - I am referign to usign the srisuresh-ospf-te draft as a basis to make MT extensions. Specifically, the suggestion is to add new LSA types with MT protocol extensions. And, the new LSA types could have topology specific TLVs. The LSAs may be restricted to being advertised within the topology boundary. cheers, suresh > Thanks, > Acee > > >I have not been active on this work recently due to my work priorities. > >However, if there are folks on the list interested in pursuing, I would be > >happy to work with you on the effort and discussion. > > > >Thanks. > > > >cheers, > >suresh > > > >--- Acee Lindem wrote: > > > > > >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >>Content-Transfer-Encoding: 7bit > >> > >>At the Minneapolis IETF, I presented a comparision of the > >>various options we have for extending OSPFv3. The reaction to the > >>presentation was very positive. However, it was last on the agenda and > >>the OSPF WG coincided with other WGs (most notably L2VPN). > >> > >>At this point, I would like to initiate more discussion. The basic > >>question is whether we go with a TLV based approach or continue > >>to add new LSAs which need to be synchronized with the LSAs > >>advertising topology and prefix information. A TLV based approach > >>is described in: > >> > >>http://www.ietf.org/internet-drafts/draft-mirtorabi-mt-ospfv3-01.txt > >> > >>The crux of my presentation would be that this is gives us the powerful > >>extension capability while still allowing us to advertise information that > >>does not need to be synchronized in separate LSAs. > >> > >>Thanks, > >>Acee > >> > >> > >> > > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 25 17:20:44 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22717 for ; Fri, 25 Mar 2005 17:20:44 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00FEE2B6@cherry.ease.lsoft.com>; Fri, 25 Mar 2005 17:20:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 63450681 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 25 Mar 2005 17:20:43 -0500 Received: from 63.150.47.131 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 25 Mar 2005 17:20:43 -0500 Received: from claven.luminous.com ([172.16.0.13]) by norm.luminous.com (SMSSMTP 4.1.0.19) with SMTP id M2005032514204014575 for ; Fri, 25 Mar 2005 14:20:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Question on flushing AS-external LSAs Thread-Index: AcUxiOBQnhpy6VcQRtCo5WJvTXNPeQ== Message-ID: Date: Fri, 25 Mar 2005 14:20:41 -0800 Reply-To: Mailing List Sender: Mailing List From: Mukesh Hira Subject: Question on flushing AS-external LSAs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi, I'm looking for an answer to how OSPF would behave in the following = scenario. Say an ASBR advertised some AS-external LSAs and then crashed. Now, OSPF = (at least v2) only allows a router to flush LSAs that it originated. = Given that the router that originated these AS-external LSAs has = crashed, would these AS-external LSAs stay in the Link State Database of = all routers in the OSPF domain for upto an hour until they get aged out? = Would these not be flushed? Let's assume that the forwarding address in the AS-external LSAs was set = to the IP address of one of the interfaces on the ASBR. When SPF is run = after the Router LSA (or Summary LSA if the ASBR is in another area) to = this IP address gets flushed, would this forwarding address not being = reachable anymore cause all these AS-external routes to be deleted from = the routing table of all nodes? What if this ASBR that crashed was one of two ASBRs advertising the same = AS-external routes, and has the higher router ID, so that the other ASBR = flushed its AS-external LSAs. When this ASBR with higher router ID = crashes, what triggers the other ASBR to re-inject its AS-external LSAs = into the network? Would the event of forwarding address for the LSAs = heard from the other ASBR not being reachable anymore trigger it to = inject its own AS-external LSAs in the network? Thanks in advance - Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Fri Mar 25 17:48:53 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24499 for ; Fri, 25 Mar 2005 17:48:52 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00FEE4C0@cherry.ease.lsoft.com>; Fri, 25 Mar 2005 17:48:54 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 63456086 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 25 Mar 2005 17:48:50 -0500 Received: from 64.47.51.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 25 Mar 2005 17:48:50 -0500 Received: from vpndg ([128.251.10.1] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 25 Mar 2005 14:48:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-OriginalArrivalTime: 25 Mar 2005 22:48:46.0297 (UTC) FILETIME=[CD822C90:01C5318C] Message-ID: Date: Fri, 25 Mar 2005 14:49:50 -0800 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: Question on flushing AS-external LSAs Comments: To: Mukesh Hira To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Mukesh, Comments inline. -don ========== Hi, I'm looking for an answer to how OSPF would behave in the following scenario. Say an ASBR advertised some AS-external LSAs and then crashed. Now, OSPF (at least v2) only allows a router to flush LSAs that it originated. Given that the router that originated these AS-external LSAs has crashed, would these AS-external LSAs stay in the Link State Database of all routers in the OSPF domain for upto an hour until they get aged out? Would these not be flushed? >>> Yes, they would remain in each LSDB until they age to 3600. At that time, >>> they would then be flushed on each of the other routers. Let's assume that the forwarding address in the AS-external LSAs was set to the IP address of one of the interfaces on the ASBR. When SPF is run after the Router LSA (or Summary LSA if the ASBR is in another area) to this IP address gets flushed, would this forwarding address not being reachable anymore cause all these AS-external routes to be deleted from the routing table of all nodes? >>> Not exactly. When the router crashes, presumably the mechanism send out OSPF >>> hello packets stops. After the router dead interval, this crashed ASBRs neighbors >>> will remove the transit links to this ASBR. Since there is no longer reachability >>> to the ASBR, no routes will be formed to any of these AS externals, although they >>> do remain in the LSDB until MaxAge as I already stated. What if this ASBR that crashed was one of two ASBRs advertising the same AS-external routes, and has the higher router ID, so that the other ASBR flushed its AS-external LSAs. When this ASBR with higher router ID crashes, what triggers the other ASBR to re-inject its AS-external LSAs into the network? Would the event of forwarding address for the LSAs heard from the other ASBR not being reachable anymore trigger it to inject its own AS-external LSAs in the network? >>> Once the ASBR is no longer reachable (as I indicated previously), the other >>> ASBR "should" detect this and re-inject any equivalent AS-externals it had >>> previously withdrawn due to having a lower router ID (pg 142 of RFC2328). >>> The only "trigger" is the fact that an ASBR is no longer reachable. How >>> this is implemented varies from vendor to vendor. Thanks in advance - Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Sun Mar 27 22:12:46 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02373 for ; Sun, 27 Mar 2005 22:12:45 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00FF200B@cherry.ease.lsoft.com>; 27 Mar 2005 22:12:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64102682 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 27 Mar 2005 22:12:41 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Sun, 27 Mar 2005 22:12:41 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 27 Mar 2005 22:32:17 -0500 X-IronPort-AV: i="3.91,127,1110171600"; d="scan'208"; a="42100475:sNHT27593228" Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2S3CcjI028288 for ; Sun, 27 Mar 2005 22:12:39 -0500 (EST) Received: from [10.82.218.177] (rtp-vpn3-686.cisco.com [10.82.218.177]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BGK16290; Sun, 27 Mar 2005 19:12:37 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <42477623.20504@cisco.com> Date: Sun, 27 Mar 2005 22:12:35 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Question on flushing AS-external LSAs To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi Mukesh, See inline. Mukesh Hira wrote: >Hi, > >I'm looking for an answer to how OSPF would behave in the following scenario. > >Say an ASBR advertised some AS-external LSAs and then crashed. Now, OSPF (at least v2) only allows a router to flush LSAs that it originated. Given that the router that originated these AS-external LSAs has crashed, would these AS-external LSAs stay in the Link State Database of all routers in the OSPF domain for upto an hour until they get aged out? Would these not be flushed? > > The AS-external LSAs would stay in the database for up to an hour (MAXAGE) and would not be flushed until the aged out. >Let's assume that the forwarding address in the AS-external LSAs was set to the IP address of one of the interfaces on the ASBR. When SPF is run after the Router LSA (or Summary LSA if the ASBR is in another area) to this IP address gets flushed, would this forwarding address not being reachable anymore cause all these AS-external routes to be deleted from the routing table of all nodes? > > Yes. When the LSA is flushed this would happen. However, the crash of the ASBR would not cause the Router-LSA to be flushed. However, it would cause the ASBR to be unreachable and trigger an SPF calculation which would cause the AS external routes to be removed from each router's routing table. >What if this ASBR that crashed was one of two ASBRs advertising the same AS-external routes, and has the higher router ID, so that the other ASBR flushed its AS-external LSAs. When this ASBR with higher router ID crashes, what triggers the other ASBR to re-inject its AS-external LSAs into the network? > This isn't specified in the protocol but I would mark LSAs that suppressed self-originated LSA orginations due to duplication and check for reachability each time the LSA is processed in an AS external SPF calculation. If the LSA's ASBR is unreachable then there is no reason to suppress self-origination. >Would the event of forwarding address for the LSAs heard from the other ASBR not being reachable anymore trigger it to inject its own AS-external LSAs in the network? > > I think there are problems trying to implement it this way since the forwarding address is a /32 and the corresponding intra-area or inter-area OSPF route generally is not. Hope this helps, Acee >Thanks in advance >- Mukesh > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Mar 28 03:48:55 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22777 for ; Mon, 28 Mar 2005 03:48:54 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00FF28E3@cherry.ease.lsoft.com>; Mon, 28 Mar 2005 3:48:54 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64164164 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 28 Mar 2005 03:48:50 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 28 Mar 2005 03:48:50 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 28 Mar 2005 03:48:51 -0500 Received: from smirtorawxp (rtp-vpn3-68.cisco.com [10.82.216.68]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2S8ml1j025749 for ; Mon, 28 Mar 2005 03:48:48 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcUv5GVj8GQPOQwkSLSgtA7PD+5gaACv4MLA Message-ID: <200503280848.j2S8ml1j025749@rtp-core-1.cisco.com> Date: Mon, 28 Mar 2005 00:48:48 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: OSPFv3 Extension Future Direction (this ought to get your attention) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4241CD1C.4060205@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit All, Let me clarify a couple of points: 1) The main purpose of the draft is to support MTR in OSPFv3. As the existing LSA cannot be used for this extension, new LSA with flexible encoding (i.e. TLV) are used for this purpose. 2) The draft also can be used to support an integrated approach to carry address-families in OSPFv3. Other AF would simply be defined in different MT-ID. The next version of the draft would specify that. 3) MT capable router would interact with non-MT routers in default topology using existing LSA. If all routers are MT capable one has the possibility to use new LSAs even for default topology. This is controlled through configuration via rfc2740compatibility. 4) The draft does NOT propose to replace rfc2740 but simply the support of MTR (and AF) 5) The draft _may_ be used to move to a flexible encoding for future development of OSPFv3. 6) Future extensions are in no way tied to these newly proposed LSAs. As appropriate, we would introduce them in yet another LSA (e.g. OSPFv3 TE LSA) or as a TLVs/Sub-TLVs in our newly proposed LSAs. 7) deployment wise, there may be three categories 7-a) if one does not need MTR/ AF, chances are that there is not much motivation to move to this new encoding for them 7-b) if MTR /AF are needed in some part of network, a coexistence of both exiting and new LSA would exist 7-c) if all routers are MTR-capable and MTR/AF are mostly deployed, new LSA would be used The discussion seems to be aimed at 5) however the original purpose of the draft is 1) and 2). Thanks Sina -> -----Original Message----- -> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On -> Behalf Of Acee Lindem -> Sent: Wednesday, March 23, 2005 12:10 PM -> To: OSPF@PEACH.EASE.LSOFT.COM -> Subject: OSPFv3 Extension Future Direction (this ought to -> get your attention) -> -> Content-Type: text/plain; charset=ISO-8859-1; format=flowed -> Content-Transfer-Encoding: 7bit -> -> At the Minneapolis IETF, I presented a comparision of the -> various options we have for extending OSPFv3. The reaction -> to the presentation was very positive. However, it was last -> on the agenda and the OSPF WG coincided with other WGs (most -> notably L2VPN). -> -> At this point, I would like to initiate more discussion. The -> basic question is whether we go with a TLV based approach or -> continue to add new LSAs which need to be synchronized with -> the LSAs advertising topology and prefix information. A TLV -> based approach is described in: -> -> http://www.ietf.org/internet-drafts/draft-mirtorabi-mt-ospfv3-01.txt -> -> The crux of my presentation would be that this is gives us -> the powerful extension capability while still allowing us to -> advertise information that does not need to be synchronized -> in separate LSAs. -> -> Thanks, -> Acee -> From owner-ospf@PEACH.EASE.LSOFT.COM Mon Mar 28 19:19:00 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29510 for ; Mon, 28 Mar 2005 19:19:00 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00FF3F4D@cherry.ease.lsoft.com>; Mon, 28 Mar 2005 19:19:00 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64370842 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 28 Mar 2005 19:18:58 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 28 Mar 2005 19:18:58 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 28 Mar 2005 19:38:43 -0500 X-IronPort-AV: i="3.91,129,1110171600"; d="scan'208"; a="42234812:sNHT27471736" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2T0It1j000369 for ; Mon, 28 Mar 2005 19:18:55 -0500 (EST) Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Mar 2005 19:18:54 -0500 Received: from [10.82.218.177] ([10.82.218.177]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Mar 2005 19:18:53 -0500 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20050325141511.67664.qmail@web40427.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Mar 2005 00:18:53.0179 (UTC) FILETIME=[E38024B0:01C533F4] Message-ID: <42489EEC.8090201@cisco.com> Date: Mon, 28 Mar 2005 19:18:52 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 Extension Future Direction (this ought to get your attention) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050325141511.67664.qmail@web40427.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit Pyda Srisuresh wrote: >--- Acee Lindem wrote: > > >>Pyda Srisuresh wrote: >> >> >> >>>Acee, >>> >>>I had done some work previously on using new LSAs for advertising topology >>> >>> >>and >> >> >>>prefix info into TE networks (draft-srisuresh-ospf-te-07.txt). This draft >>> >>> >>can >> >> >>>be a good starting point to use for turning into future MT extensions to >>>OSPFv3. >>> >>> >>> >>> >>Hi Pyda, >>I don't see a requirement to mix TE data and the unicast/multicast >>topology information. This has traditionally >>been separate and processed by different functional components. The new >>LSAs in our draft correspond >>directly to the existing base LSA types (only they are in extendible TLV >>format and support multiple >>topologies). >> >> >> >[suresh] Acee - I am referign to usign the srisuresh-ospf-te draft as a basis >to make MT extensions. Specifically, the suggestion is to add new LSA types >with MT protocol extensions. And, the new LSA types could have topology >specific TLVs. The LSAs may be restricted to being advertised within the >topology boundary. > > Pyda, I took another look at your draft and don't see a good reason to use it as a starting point for OSPFv3 extension including MTR and AFs: 1. It is targeted at TE extensions 2. It is based on OSPFv2 3. It doesn't specify the changes needed to base OSPFv3 needed to support it. 4. To the best of my knowledge, there is not a large base of deployments or even implementations that would benefit from using it as a base. Thanks, Acee >cheers, >suresh > > > >>Thanks, >>Acee >> >> >> >>>I have not been active on this work recently due to my work priorities. >>>However, if there are folks on the list interested in pursuing, I would be >>>happy to work with you on the effort and discussion. >>> >>>Thanks. >>> >>>cheers, >>>suresh >>> >>>--- Acee Lindem wrote: >>> >>> >>> >>> >>>>Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>>>Content-Transfer-Encoding: 7bit >>>> >>>>At the Minneapolis IETF, I presented a comparision of the >>>>various options we have for extending OSPFv3. The reaction to the >>>>presentation was very positive. However, it was last on the agenda and >>>>the OSPF WG coincided with other WGs (most notably L2VPN). >>>> >>>>At this point, I would like to initiate more discussion. The basic >>>>question is whether we go with a TLV based approach or continue >>>>to add new LSAs which need to be synchronized with the LSAs >>>>advertising topology and prefix information. A TLV based approach >>>>is described in: >>>> >>>>http://www.ietf.org/internet-drafts/draft-mirtorabi-mt-ospfv3-01.txt >>>> >>>>The crux of my presentation would be that this is gives us the powerful >>>>extension capability while still allowing us to advertise information that >>>>does not need to be synchronized in separate LSAs. >>>> >>>>Thanks, >>>>Acee >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 29 09:25:06 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00989 for ; Tue, 29 Mar 2005 09:25:06 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00FF5104@cherry.ease.lsoft.com>; Tue, 29 Mar 2005 9:25:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64487819 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Mar 2005 09:25:02 -0500 Received: from 66.218.92.34 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 29 Mar 2005 09:25:02 -0500 Received: (qmail 77196 invoked by uid 60001); 29 Mar 2005 14:25:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=N5cp/YTc8blyG4Oxo5yYKRHf0OjiIejihkA9HK7h9lYLNJS4iO+1aQlSPNcBE1lq9BVw2pis631RiFWgpOowqjPxILSt7i24usPfP2X/Fb6kows5iQav5UaQP1JhJuI0lH4xPprf1Ay9Ya/jPgHizrL5FSWD7GcQpMQ2n+ziuuM= ; Received: from [67.164.86.136] by web40423.mail.yahoo.com via HTTP; Tue, 29 Mar 2005 06:25:01 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20050329142501.77194.qmail@web40423.mail.yahoo.com> Date: Tue, 29 Mar 2005 06:25:01 -0800 Reply-To: Mailing List Sender: Mailing List Comments: DomainKeys? See http://antispam.yahoo.com/domainkeys From: Pyda Srisuresh Subject: Re: OSPFv3 Extension Future Direction (this ought to get your attention) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: 6667 Precedence: list --- Acee Lindem wrote: > Pyda Srisuresh wrote: > > >--- Acee Lindem wrote: > > > > > >>Pyda Srisuresh wrote: > >> > >> > >> > >>>Acee, > >>> > >>>I had done some work previously on using new LSAs for advertising topology > >>> > >>> > >>and > >> > >> > >>>prefix info into TE networks (draft-srisuresh-ospf-te-07.txt). This draft > >>> > >>> > >>can > >> > >> > >>>be a good starting point to use for turning into future MT extensions to > >>>OSPFv3. > >>> > >>> > >>> > >>> > >>Hi Pyda, > >>I don't see a requirement to mix TE data and the unicast/multicast > >>topology information. This has traditionally > >>been separate and processed by different functional components. The new > >>LSAs in our draft correspond > >>directly to the existing base LSA types (only they are in extendible TLV > >>format and support multiple > >>topologies). > >> > >> > >> > >[suresh] Acee - I am referign to usign the srisuresh-ospf-te draft as a > basis > >to make MT extensions. Specifically, the suggestion is to add new LSA types > >with MT protocol extensions. And, the new LSA types could have topology > >specific TLVs. The LSAs may be restricted to being advertised within the > >topology boundary. > > > > > Pyda, > > I took another look at your draft and don't see a good reason to use it > as a starting point > for OSPFv3 extension including MTR and AFs: > > 1. It is targeted at TE extensions > 2. It is based on OSPFv2 > 3. It doesn't specify the changes needed to base OSPFv3 needed to > support it. > 4. To the best of my knowledge, there is not a large base of > deployments or even > implementations that would benefit from using it as a base. > Acee, Items 1, 2 and 3 are true. However, that is not to say that the concepts in the draft cannot be used as the base to add new LSA types with MT protocol extensions, restrict scope of LSA advertisements etc. The draft will need rework and will look much different from the current draft when done. As for Item 4, you are postulating that if we did have a new draft using the concepts in srisuresh-ospf-te, you dont think it woudl benefit the existing deployments. That seems a bit presumptious. Sound like, you are declaring that adding new LSAs will not benefit existing deployments and hence not beneficial to pursue. If so, it seems you have already made up your mind to go with the TLV based approach. Is that the case? cheers, suresh > Thanks, > Acee > > >cheers, > >suresh > > > > > > > >>Thanks, > >>Acee > >> > >> > >> > >>>I have not been active on this work recently due to my work priorities. > >>>However, if there are folks on the list interested in pursuing, I would > be > >>>happy to work with you on the effort and discussion. > >>> > >>>Thanks. > >>> > >>>cheers, > >>>suresh > >>> > >>>--- Acee Lindem wrote: > >>> > >>> > >>> > >>> > >>>>Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >>>>Content-Transfer-Encoding: 7bit > >>>> > >>>>At the Minneapolis IETF, I presented a comparision of the > >>>>various options we have for extending OSPFv3. The reaction to the > >>>>presentation was very positive. However, it was last on the agenda and > >>>>the OSPF WG coincided with other WGs (most notably L2VPN). > >>>> > >>>>At this point, I would like to initiate more discussion. The basic > >>>>question is whether we go with a TLV based approach or continue > >>>>to add new LSAs which need to be synchronized with the LSAs > >>>>advertising topology and prefix information. A TLV based approach > >>>>is described in: > >>>> > >>>>http://www.ietf.org/internet-drafts/draft-mirtorabi-mt-ospfv3-01.txt > >>>> > >>>>The crux of my presentation would be that this is gives us the powerful > >>>>extension capability while still allowing us to advertise information > that > >>>>does not need to be synchronized in separate LSAs. > >>>> > >>>>Thanks, > >>>>Acee > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 29 09:55:44 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04215 for ; Tue, 29 Mar 2005 09:55:44 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00FF5022@cherry.ease.lsoft.com>; Tue, 29 Mar 2005 9:55:43 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64491406 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Mar 2005 09:55:42 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 29 Mar 2005 09:55:42 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 29 Mar 2005 10:15:35 -0500 X-IronPort-AV: i="3.91,131,1110171600"; d="scan'208"; a="42308477:sNHT28883944" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2TEtdjI005724 for ; Tue, 29 Mar 2005 09:55:40 -0500 (EST) Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Mar 2005 09:55:39 -0500 Received: from [10.82.218.177] ([10.82.218.177]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Mar 2005 09:55:39 -0500 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20050329142501.77194.qmail@web40423.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Mar 2005 14:55:39.0066 (UTC) FILETIME=[5F0D79A0:01C5346F] Message-ID: <42496C6A.2020601@cisco.com> Date: Tue, 29 Mar 2005 09:55:38 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 Extension Future Direction (this ought to get your attention) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20050329142501.77194.qmail@web40423.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit Pyda, See inline. Pyda Srisuresh wrote: >--- Acee Lindem wrote: > > >>Pyda Srisuresh wrote: >> >> >> >>>--- Acee Lindem wrote: >>> >>> >>> >>> >>>>Pyda Srisuresh wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Acee, >>>>> >>>>>I had done some work previously on using new LSAs for advertising topology >>>>> >>>>> >>>>> >>>>> >>>>and >>>> >>>> >>>> >>>> >>>>>prefix info into TE networks (draft-srisuresh-ospf-te-07.txt). This draft >>>>> >>>>> >>>>> >>>>> >>>>can >>>> >>>> >>>> >>>> >>>>>be a good starting point to use for turning into future MT extensions to >>>>>OSPFv3. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Hi Pyda, >>>>I don't see a requirement to mix TE data and the unicast/multicast >>>>topology information. This has traditionally >>>>been separate and processed by different functional components. The new >>>>LSAs in our draft correspond >>>>directly to the existing base LSA types (only they are in extendible TLV >>>>format and support multiple >>>>topologies). >>>> >>>> >>>> >>>> >>>> >>>[suresh] Acee - I am referign to usign the srisuresh-ospf-te draft as a >>> >>> >>basis >> >> >>>to make MT extensions. Specifically, the suggestion is to add new LSA types >>>with MT protocol extensions. And, the new LSA types could have topology >>>specific TLVs. The LSAs may be restricted to being advertised within the >>>topology boundary. >>> >>> >>> >>> >>Pyda, >> >>I took another look at your draft and don't see a good reason to use it >>as a starting point >>for OSPFv3 extension including MTR and AFs: >> >> 1. It is targeted at TE extensions >> 2. It is based on OSPFv2 >> 3. It doesn't specify the changes needed to base OSPFv3 needed to >>support it. >> 4. To the best of my knowledge, there is not a large base of >>deployments or even >> implementations that would benefit from using it as a base. >> >> >> > >Acee, > >Items 1, 2 and 3 are true. However, that is not to say that the concepts in the >draft cannot be used as the base to add new LSA types with MT protocol >extensions, restrict scope of LSA advertisements etc. The draft will need >rework and will look much different from the current draft when done. > > I suspect it would look much like draft-mirtorabi-mt-ospfv3-01.txt. >As for Item 4, you are postulating that if we did have a new draft using the >concepts in srisuresh-ospf-te, you dont think it woudl benefit the existing >deployments. That seems a bit presumptious. Sound like, you are declaring that >adding new LSAs will not benefit existing deployments and hence not beneficial >to pursue. If so, it seems you have already made up your mind to go with the >TLV based approach. Is that the case? > > That is not the case at all. #4 was in direct response to the presumption that there was tremendous advantage to be gained in starting with srisuresh-ospf-te as a base since it already exists. As for the TLV approach, I do think it is the right way to go but it is the OSPF WG and not any single individual that must decide. The OSPF WG is always open to other proposals. Thanks, Acee >cheers, >suresh > > > >>Thanks, >>Acee >> >> >> >>>cheers, >>>suresh >>> >>> >>> >>> >>> >>>>Thanks, >>>>Acee >>>> >>>> >>>> >>>> >>>> >>>>>I have not been active on this work recently due to my work priorities. >>>>>However, if there are folks on the list interested in pursuing, I would >>>>> >>>>> >>be >> >> >>>>>happy to work with you on the effort and discussion. >>>>> >>>>>Thanks. >>>>> >>>>>cheers, >>>>>suresh >>>>> >>>>>--- Acee Lindem wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>>>>>Content-Transfer-Encoding: 7bit >>>>>> >>>>>>At the Minneapolis IETF, I presented a comparision of the >>>>>>various options we have for extending OSPFv3. The reaction to the >>>>>>presentation was very positive. However, it was last on the agenda and >>>>>>the OSPF WG coincided with other WGs (most notably L2VPN). >>>>>> >>>>>>At this point, I would like to initiate more discussion. The basic >>>>>>question is whether we go with a TLV based approach or continue >>>>>>to add new LSAs which need to be synchronized with the LSAs >>>>>>advertising topology and prefix information. A TLV based approach >>>>>>is described in: >>>>>> >>>>>>http://www.ietf.org/internet-drafts/draft-mirtorabi-mt-ospfv3-01.txt >>>>>> >>>>>>The crux of my presentation would be that this is gives us the powerful >>>>>>extension capability while still allowing us to advertise information >>>>>> >>>>>> >>that >> >> >>>>>>does not need to be synchronized in separate LSAs. >>>>>> >>>>>>Thanks, >>>>>>Acee >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 29 18:27:04 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08679 for ; Tue, 29 Mar 2005 18:27:04 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00FF5D6B@cherry.ease.lsoft.com>; Tue, 29 Mar 2005 18:27:02 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64533808 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Mar 2005 18:27:01 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 29 Mar 2005 18:27:01 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGQ6u-00069F-EB; Tue, 29 Mar 2005 23:27:00 +0000 X-Priority: 3 (Normal) References: <111973429.20050317094906@psg.com> <423C343B.60105@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <76052700.20050329152658@psg.com> Date: Tue, 29 Mar 2005 15:26:58 -0800 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Comments: To: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <423C343B.60105@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Acee, et al- After thinking more about this: We all seem to agree new link types explicitly affecting route calculation will need to ensure everyone in the area understands them. The remaining question is whether other things (those that we believe shouldn't affect normal route calculation) will trigger an unwanted reaction or not. The crux of the matter here is two-fold: - redefining the "unknown link-type" situation from an exception with unspecified processing to a normal situation with a well-defined behavior - whether such redefinition will be effective 'ex post facto', given current protocol deployments, and what are the worst-case scenarios One of the questions here is whether we sure there are no networks deployed out there that will react to an unknown link-type (when a newer router gets its SW upgraded) by ignoring the whole router-LSA as John suggested, or screaming loudly. Leaving this in the capable hands of this WG now. -- Alex http://www.psg.com/~zinin Saturday, March 19, 2005, 6:16:27 AM, Acee Lindem wrote: > Hi Alex, > I don't feel that strongly on whether or not we need to document the > behavior when an unknown link type is encountered. However, I was > content to ignore them and leave the backward compatibility issues > to those proposing new link types. If there were compelling reasons to > introduce a new link type we are now relegated to a solution where we > need protocol mechanisms to assure that every router in the area understands > it prior to it's usage and, depending on the link type, this may be more > conservative than what is needed. > Thanks, > Acee > Alex Zinin wrote: >>Vishwas, >> >>I'll try one more time. >> >> >> >>>If someone wants to write an implementation of OSPF, what does he/she do >>>regarding unknown link types? >>> >>> >> >>We discussed this earlier in this thread. >> >> >> >>>We need to define the behavior else we >>>will never get interoperability. I guess we both agree with the above. >>> >>> >> >>We do NOT have an interoperability issue unless we start deliberately >>introducing new link types without making sure everyone understands them. >> >> >> >>>If I understood the discussion in the mailing list right, most >>>implementations ignore the link and that is what we are trying to >>>standardize. >>> >>> >> >>A few years ago we had a discussion that touched on link records. John mentioned >>that there are still implementations out there that will ignore the whole LSA >>when the see an unknown link type. I don't think we can ignore this. >> >> >> >>>The suggestion you make will not interoperate with the >>>installed base at all while a MUST ignore solution will with most of >>>them. >>> >>> >> >>I don't understand what you mean by "will not interoperate". >> >>Alex >> >> >> From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 29 20:08:19 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18032 for ; Tue, 29 Mar 2005 20:08:19 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00FF5CEF@cherry.ease.lsoft.com>; Tue, 29 Mar 2005 20:08:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64540861 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Mar 2005 20:08:18 -0500 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 29 Mar 2005 20:08:18 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j2U18HBm062667 for ; Tue, 29 Mar 2005 17:08:17 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2U18Ge93690 for ; Tue, 29 Mar 2005 17:08:17 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v619.2) References: <111973429.20050317094906@psg.com> <423C343B.60105@cisco.com> <76052700.20050329152658@psg.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.619.2) Message-ID: <46095bc03f9b02a409445eecd5107c59@juniper.net> Date: Tue, 29 Mar 2005 18:08:13 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <76052700.20050329152658@psg.com> Precedence: list Content-Transfer-Encoding: 7bit On Mar 29, 2005, at 4:26 PM, Alex Zinin wrote: > - whether such redefinition will be effective 'ex post facto', > given > current protocol deployments, and what are the worst-case > scenarios Until a new link type is specified, the worst case scenario is that somebody will build a router tester that sends undefined link types and well meaning people will harass zero or more vendors, who will not be able to do anything about their deployed base. If a new link type is defined, the possible scenarios range from no issues at all, to broken routing, to crashes in "show" commands, to wholesale network collapses (unlikely, but fun to watch from a safe distance.) > > One of the questions here is whether we sure there are no networks > deployed > out there that will react to an unknown link-type (when a newer > router gets > its SW upgraded) by ignoring the whole router-LSA as John suggested, > or > screaming loudly. There is no way of knowing this. Judging from the questions on this list over the years, the number of implementations is essentially unbounded. One of the dominant implementations will silently skip the bad link type and go on to the next link. Can't speak for the other one. It's worth defining what to do in this case, but it is essentially academic until a new link type is defined. Unfortunately, it will have little effect on the eventual outcome if that happens, given that it's 15 years too late. --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 29 20:29:07 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19977 for ; Tue, 29 Mar 2005 20:29:07 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00FF5EF3@cherry.ease.lsoft.com>; Tue, 29 Mar 2005 20:29:07 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64541741 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Mar 2005 20:29:06 -0500 Received: from 207.217.121.249 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 29 Mar 2005 20:29:05 -0500 Received: from h-68-164-155-80.snvacaid.dynamic.covad.net ([68.164.155.80] helo=earthlink.net) by pop-a065d05.pas.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DGS12-0004sI-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Mar 2005 17:29:04 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <111973429.20050317094906@psg.com> <423C343B.60105@cisco.com> <76052700.20050329152658@psg.com> <46095bc03f9b02a409445eecd5107c59@juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <4249FF56.BB59A699@earthlink.net> Date: Tue, 29 Mar 2005 17:22:30 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit in the land of the giants... Don't we think that some testers has already generated undefined link types to make sure that their implementation doesn't crash? Thus, my worst fear is that some routers will create different LSDBs from others, these non synch LSDBs will create periodic black holes, etc AND NOBODY is aware that this is happening... Mitchell Erblich ------------------------- Dave Katz wrote: > > On Mar 29, 2005, at 4:26 PM, Alex Zinin wrote: > > > - whether such redefinition will be effective 'ex post facto', > > given > > current protocol deployments, and what are the worst-case > > scenarios > > Until a new link type is specified, the worst case scenario is that > somebody will build a router tester that sends undefined link types and > well meaning people will harass zero or more vendors, who will not be > able to do anything about their deployed base. > > If a new link type is defined, the possible scenarios range from no > issues at all, to broken routing, to crashes in "show" commands, to > wholesale network collapses (unlikely, but fun to watch from a safe > distance.) > > > > One of the questions here is whether we sure there are no networks > > deployed > > out there that will react to an unknown link-type (when a newer > > router gets > > its SW upgraded) by ignoring the whole router-LSA as John suggested, > > or > > screaming loudly. > > There is no way of knowing this. Judging from the questions on this > list over the years, the number of implementations is essentially > unbounded. > > One of the dominant implementations will silently skip the bad link > type and go on to the next link. Can't speak for the other one. > > It's worth defining what to do in this case, but it is essentially > academic until a new link type is defined. Unfortunately, it will have > little effect on the eventual outcome if that happens, given that it's > 15 years too late. > > --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 29 20:58:52 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22152 for ; Tue, 29 Mar 2005 20:58:49 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00FF5EA6@cherry.ease.lsoft.com>; Tue, 29 Mar 2005 20:58:49 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64543294 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Mar 2005 20:58:47 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 29 Mar 2005 20:58:47 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 29 Mar 2005 21:18:43 -0500 X-IronPort-AV: i="3.91,132,1110171600"; d="scan'208"; a="42408359:sNHT4338838558" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2U1wg1j000053; Tue, 29 Mar 2005 20:58:42 -0500 (EST) Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Mar 2005 20:58:41 -0500 Received: from [10.82.242.22] ([10.82.242.22]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Mar 2005 20:58:41 -0500 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <111973429.20050317094906@psg.com> <423C343B.60105@cisco.com> <76052700.20050329152658@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2005 01:58:41.0511 (UTC) FILETIME=[FF3CD770:01C534CB] Message-ID: <424A07D0.4050806@cisco.com> Date: Tue, 29 Mar 2005 20:58:40 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Comments: To: Alex Zinin To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <76052700.20050329152658@psg.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Alex, Alex Zinin wrote: >Acee, et al- > > After thinking more about this: > > We all seem to agree new link types explicitly affecting route calculation > will need to ensure everyone in the area understands them. The remaining > question is whether other things (those that we believe shouldn't affect > normal route calculation) will trigger an unwanted reaction or not. > And I believe we agree that isn't desirable to handle the addition of all possible future link types in this draft since due to simply fact that different link types may require different compatibility considerations. > The crux > of the matter here is two-fold: > > - redefining the "unknown link-type" situation from an exception with > unspecified processing to a normal situation with a well-defined behavior > > - whether such redefinition will be effective 'ex post facto', given current protocol deployments, and what are the worst-case scenarios At least defining the rules would provide a migration path if vendors and open source developers follow the rules. If we can't agree that this is a good thing to do then I guess the default action is to maintain the status quo of leaving it undefined. At least initially, the concensus was to ignore the unknown link types. > One of the questions here is whether we sure there are no networks deployed > out there that will react to an unknown link-type (when a newer router gets > its SW upgraded) by ignoring the whole router-LSA as John suggested, or > screaming loudly. > > Leaving this in the capable hands of this WG now. > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 29 21:07:58 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22936 for ; Tue, 29 Mar 2005 21:07:58 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00FF6139@cherry.ease.lsoft.com>; Tue, 29 Mar 2005 21:07:58 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64544363 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Mar 2005 21:07:57 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 29 Mar 2005 21:07:57 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 29 Mar 2005 21:27:54 -0500 X-IronPort-AV: i="3.91,132,1110171600"; d="scan'208"; a="42409361:sNHT27664788" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2U27k1j001862 for ; Tue, 29 Mar 2005 21:07:46 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Mar 2005 21:07:46 -0500 Received: from [10.82.242.22] ([10.82.242.22]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Mar 2005 21:07:46 -0500 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <111973429.20050317094906@psg.com> <423C343B.60105@cisco.com> <76052700.20050329152658@psg.com> <46095bc03f9b02a409445eecd5107c59@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2005 02:07:46.0058 (UTC) FILETIME=[43D01EA0:01C534CD] Message-ID: <424A09F1.4090109@cisco.com> Date: Tue, 29 Mar 2005 21:07:45 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <46095bc03f9b02a409445eecd5107c59@juniper.net> Precedence: list Content-Transfer-Encoding: 7bit Hi Dave, Dave Katz wrote: > On Mar 29, 2005, at 4:26 PM, Alex Zinin wrote: > >> - whether such redefinition will be effective 'ex post facto', given >> current protocol deployments, and what are the worst-case >> scenarios > > > Until a new link type is specified, the worst case scenario is that > somebody will build a router tester that sends undefined link types > and well meaning people will harass zero or more vendors, who will not > be able to do anything about their deployed base. > > If a new link type is defined, the possible scenarios range from no > issues at all, to broken routing, to crashes in "show" commands, to > wholesale network collapses (unlikely, but fun to watch from a safe > distance.) > >> >> One of the questions here is whether we sure there are no networks >> deployed >> out there that will react to an unknown link-type (when a newer >> router gets >> its SW upgraded) by ignoring the whole router-LSA as John >> suggested, or >> screaming loudly. > > > There is no way of knowing this. Judging from the questions on this > list over the years, the number of implementations is essentially > unbounded. > > One of the dominant implementations will silently skip the bad link > type and go on to the next link. Can't speak for the other one. Since this is what Vishwas' draft recommends, can we take this as a vote for adoption of his draft :^) ? > > > It's worth defining what to do in this case, but it is essentially > academic until a new link type is defined. Unfortunately, it will > have little effect on the eventual outcome if that happens, given that > it's 15 years too late. It is true that this is late but at least it would provide a migration path. In a perfect world, an OSPF routing domain is under a single administrative authority and that authority should have some control over what is deployed. Thanks, Acee > > --Dave > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 29 21:09:34 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23065 for ; Tue, 29 Mar 2005 21:09:32 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00FF5F00@cherry.ease.lsoft.com>; Tue, 29 Mar 2005 21:09:25 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64544574 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Mar 2005 21:09:23 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 29 Mar 2005 21:09:21 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 29 Mar 2005 21:09:22 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2U29DjM011697 for ; Tue, 29 Mar 2005 21:09:19 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Mar 2005 21:09:17 -0500 Received: from [10.82.242.22] ([10.82.242.22]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Mar 2005 21:09:17 -0500 User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <111973429.20050317094906@psg.com> <423C343B.60105@cisco.com> <76052700.20050329152658@psg.com> <46095bc03f9b02a409445eecd5107c59@juniper.net> <4249FF56.BB59A699@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2005 02:09:17.0574 (UTC) FILETIME=[7A5C5A60:01C534CD] Message-ID: <424A0A4D.3050407@cisco.com> Date: Tue, 29 Mar 2005 21:09:17 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4249FF56.BB59A699@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit Hi Mitchell, Erblichs wrote: >in the land of the giants... > > Don't we think that some testers has already > generated undefined link types to make sure > that their implementation doesn't crash? > > Thus, my worst fear is that some routers > will create different LSDBs from others, > these non synch LSDBs will create periodic > black holes, etc AND NOBODY is aware > that this is happening... > > We will not allow any new link types to be standardised without addressing backward compatibility concerns. > Mitchell Erblich > ------------------------- > > >Dave Katz wrote: > > >>On Mar 29, 2005, at 4:26 PM, Alex Zinin wrote: >> >> >> >>> - whether such redefinition will be effective 'ex post facto', >>>given >>> current protocol deployments, and what are the worst-case >>>scenarios >>> >>> >>Until a new link type is specified, the worst case scenario is that >>somebody will build a router tester that sends undefined link types and >>well meaning people will harass zero or more vendors, who will not be >>able to do anything about their deployed base. >> >>If a new link type is defined, the possible scenarios range from no >>issues at all, to broken routing, to crashes in "show" commands, to >>wholesale network collapses (unlikely, but fun to watch from a safe >>distance.) >> >> >>> One of the questions here is whether we sure there are no networks >>>deployed >>> out there that will react to an unknown link-type (when a newer >>>router gets >>> its SW upgraded) by ignoring the whole router-LSA as John suggested, >>>or >>> screaming loudly. >>> >>> >>There is no way of knowing this. Judging from the questions on this >>list over the years, the number of implementations is essentially >>unbounded. >> >>One of the dominant implementations will silently skip the bad link >>type and go on to the next link. Can't speak for the other one. >> >>It's worth defining what to do in this case, but it is essentially >>academic until a new link type is defined. Unfortunately, it will have >>little effect on the eventual outcome if that happens, given that it's >>15 years too late. >> >>--Dave >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 29 22:49:00 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00622 for ; Tue, 29 Mar 2005 22:49:00 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00FF619E@cherry.ease.lsoft.com>; Tue, 29 Mar 2005 22:48:59 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64549441 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Mar 2005 22:48:53 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 29 Mar 2005 22:48:53 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGUCK-000FQ4-MP; Wed, 30 Mar 2005 03:48:52 +0000 X-Priority: 3 (Normal) References: <111973429.20050317094906@psg.com> <423C343B.60105@cisco.com> <76052700.20050329152658@psg.com> <424A07D0.4050806@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: <169978949.20050329194849@psg.com> Date: Tue, 29 Mar 2005 19:48:49 -0800 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Comments: To: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <424A07D0.4050806@cisco.com> Precedence: list Content-Transfer-Encoding: quoted-printable Acee, > And I believe we agree that isn't desirable to handle the addition of all > possible future link types in this draft since due to simply fact that > different link types may require different compatibility considerations. Right. > At least defining the rules would provide a migration path if vendors and= open > source developers follow the rules. Even if everyone on this list jumps on it tomorrow and checks their code to ensure the follow this recommendation, there will still be networks out the= re that happily run old equipment with old SW from vendors that don't even exi= st anymore. The side effect of recommending to ignore unknowns is creation of the impre= ssion that we can rely on this behavior when defining new link types, while in fa= ct we can't. And if we can't rely on it, then why specify? From=20your message to Dave: > In a perfect world, an OSPF routing domain is under a single administrati= ve > authority and that authority should have some control over what is deploy= ed. This is a reasonable assumption. On the other hand, it seems we shouldn't a= ssume that the administrator of a moderate enterprise network knows all details o= f the protocol machinery to the details of how version X of a specific implementa= tions handles this scenario. Since there would be no protocol-level safeguards ag= ainst newer implementations conflicting with legacy ones, it would look very shak= y. > If we can't agree that this is a good thing to do then I guess the default > action is to maintain the status quo of leaving it undefined. At least > initially, the concensus was to ignore the unknown link types. It's a good thing we're having this discussion early in the process. Alex From owner-ospf@PEACH.EASE.LSOFT.COM Tue Mar 29 23:58:15 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08387 for ; Tue, 29 Mar 2005 23:58:14 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00FF632D@cherry.ease.lsoft.com>; Tue, 29 Mar 2005 23:58:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64554265 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Mar 2005 23:58:12 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 29 Mar 2005 23:58:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Thread-Index: AcU022kTxqImXk6tSoy0B5HR9c5OrAAAajvQ Message-ID: Date: Tue, 29 Mar 2005 20:58:10 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Acee, > The side effect of recommending to ignore unknowns is creation of the > impression that we can rely on this behavior when defining new link types,=20 > while in fact we can't. And if we can't rely on it, then why specify? I may be totally off target, however stating that a solution to a problem should not be accepted because it will not be immediately effective may not be right. I think stating it will get the behavior in all major/ new and highly used implementations soon if not immediately. As I pointed out in my previous mail, malicious packets can very well be sent if we know this creates routing problems (and other interesting problems that Dave mentioned) and we will never have a solution to that if we leave things open-ended. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Alex Zinin Sent: Wednesday, March 30, 2005 9:19 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 Acee, > And I believe we agree that isn't desirable to handle the addition of all > possible future link types in this draft since due to simply fact that > different link types may require different compatibility considerations. Right. > At least defining the rules would provide a migration path if vendors and open > source developers follow the rules. Even if everyone on this list jumps on it tomorrow and checks their code to ensure the follow this recommendation, there will still be networks out there that happily run old equipment with old SW from vendors that don't even exist anymore. The side effect of recommending to ignore unknowns is creation of the impression that we can rely on this behavior when defining new link types, while in fact we can't. And if we can't rely on it, then why specify? From your message to Dave: > In a perfect world, an OSPF routing domain is under a single administrative > authority and that authority should have some control over what is deployed. This is a reasonable assumption. On the other hand, it seems we shouldn't assume that the administrator of a moderate enterprise network knows all details of the protocol machinery to the details of how version X of a specific implementations handles this scenario. Since there would be no protocol-level safeguards against newer implementations conflicting with legacy ones, it would look very shaky. > If we can't agree that this is a good thing to do then I guess the default > action is to maintain the status quo of leaving it undefined. At least > initially, the concensus was to ignore the unknown link types. It's a good thing we're having this discussion early in the process. Alex From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 30 04:28:31 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04598 for ; Wed, 30 Mar 2005 04:28:31 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00FF6899@cherry.ease.lsoft.com>; Wed, 30 Mar 2005 4:28:29 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64568476 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Mar 2005 04:28:28 -0500 Received: from 216.37.114.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 30 Mar 2005 04:28:28 -0500 Received: (qmail 17021 invoked from network); 30 Mar 2005 09:28:26 -0000 Received: from unknown (HELO ?192.168.1.28?) (172.16.104.132) by lxmail.nj.us.utstar.com with SMTP; 30 Mar 2005 09:28:26 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20040921 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <111973429.20050317094906@psg.com> <423C343B.60105@cisco.com> <76052700.20050329152658@psg.com> <424A07D0.4050806@cisco.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <424A8D5D.8030806@xebeo.com> Date: Wed, 30 Mar 2005 11:28:29 +0000 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <424A07D0.4050806@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Acee Lindem wrote: > Hi Alex, > > Alex Zinin wrote: > >> Acee, et al- >> >> After thinking more about this: >> >> We all seem to agree new link types explicitly affecting route >> calculation >> will need to ensure everyone in the area understands them. The >> remaining >> question is whether other things (those that we believe shouldn't >> affect >> normal route calculation) will trigger an unwanted reaction or not. >> > And I believe we agree that isn't desirable to handle the addition of > all possible future link types in > this draft since due to simply fact that different link types may > require different compatibility considerations. > the 'new' link types will fall into one of two categories: . they will either affect the shortest-path tree for hop-by-hop . or not (e.g. be only leaves or not do forwarding hop-by-hop traffic along those links [TE]) in case they do you must have a possiblity to understand what each router is doing in terms of topological capabilites and based on that modify your SPF in the newer routers. It's a case of a chain of topologies (means, topologies nested within each other, each additional capability defines a 'higher' level). It has been proven that in such a scenario SPFs can be computed and the network works loop-free, look up *V. Fayet, D. A. Khotimsky, and T. Przygienda, \Hop-by-hop routing with node-dependent topology information," /in IEEE INFOCOM'99, Mar. 1999 The math is not for the faint of heart but you can just plug out the algorithm (which is a nested Dijkstra with 2 or 3 ifs added). If you add 'unknown' links (which means some routers understand them and use them for SPF hop-by-hop and some don't), simple examples exist to prove that the network will loop easily (more rigorously, you partially loose connectivity in the network) thanks -- tony /* From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 30 04:38:30 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05313 for ; Wed, 30 Mar 2005 04:38:30 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00FF66F2@cherry.ease.lsoft.com>; Wed, 30 Mar 2005 4:38:30 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64569000 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Mar 2005 04:38:29 -0500 Received: from 216.37.114.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 30 Mar 2005 04:38:29 -0500 Received: (qmail 17366 invoked from network); 30 Mar 2005 09:38:28 -0000 Received: from unknown (HELO ?192.168.1.28?) (172.16.104.132) by lxmail.nj.us.utstar.com with SMTP; 30 Mar 2005 09:38:28 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20040921 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <111973429.20050317094906@psg.com> <423C343B.60105@cisco.com> <76052700.20050329152658@psg.com> <424A07D0.4050806@cisco.com> <424A8D5D.8030806@xebeo.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <424A8FB7.4080809@xebeo.com> Date: Wed, 30 Mar 2005 11:38:31 +0000 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <424A8D5D.8030806@xebeo.com> Precedence: list Content-Transfer-Encoding: 7bit Tony Przygienda wrote: > Acee Lindem wrote: > >> Hi Alex, >> >> Alex Zinin wrote: >> >>> Acee, et al- >>> >>> After thinking more about this: >>> >>> We all seem to agree new link types explicitly affecting route >>> calculation >>> will need to ensure everyone in the area understands them. The >>> remaining >>> question is whether other things (those that we believe shouldn't >>> affect >>> normal route calculation) will trigger an unwanted reaction or not. >>> >> And I believe we agree that isn't desirable to handle the addition of >> all possible future link types in >> this draft since due to simply fact that different link types may >> require different compatibility considerations. >> > > the 'new' link types will fall into one of two categories: > > . they will either affect the shortest-path tree for hop-by-hop > . or not (e.g. be only leaves or not do forwarding hop-by-hop traffic > along those links [TE]) hastily written, sorry, 'leafs', isn't it ? > > If you add 'unknown' links (which means some routers understand them > and use them for SPF hop-by-hop > and some don't), simple examples exist to prove that the network will > loop easily (more rigorously, you > partially loose connectivity in the network) here I implicitly ment, 'if you don't do anything else except normal Dijkstra', of course. -- tony From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 30 10:18:16 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07917 for ; Wed, 30 Mar 2005 10:18:15 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00FF6ECF@cherry.ease.lsoft.com>; Wed, 30 Mar 2005 10:18:14 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64621743 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Mar 2005 10:18:13 -0500 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 30 Mar 2005 10:18:13 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j2UFIC919555 for ; Wed, 30 Mar 2005 07:18:12 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2UFI7e20079 for ; Wed, 30 Mar 2005 07:18:07 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed X-Mailer: Apple Mail (2.619.2) Message-ID: <74636e771e6bce4a2b6ee22883dd887d@juniper.net> Date: Wed, 30 Mar 2005 08:18:06 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit On Mar 29, 2005, at 7:07 PM, Acee Lindem wrote: >> One of the dominant implementations will silently skip the bad link >> type and go on to the next link. Can't speak for the other one. > > Since this is what Vishwas' draft recommends, can we take this as a > vote for adoption > of his draft :^) ? I abstain based on lack of involvement... > > >> >> >> It's worth defining what to do in this case, but it is essentially >> academic until a new link type is defined. Unfortunately, it will >> have little effect on the eventual outcome if that happens, given >> that it's 15 years too late. > > It is true that this is late but at least it would provide a migration > path. In a perfect > world, an OSPF routing domain is under a single administrative > authority and that > authority should have some control over what is deployed. Just pointing out that it's not a perfect world, and that customers' desire to upgrade software, if necessary, will be based on far more important considerations than whether the software conforms to this draft. --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 30 10:19:50 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08099 for ; Wed, 30 Mar 2005 10:19:50 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00FF6F58@cherry.ease.lsoft.com>; Wed, 30 Mar 2005 10:19:50 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64621871 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Mar 2005 10:19:49 -0500 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 30 Mar 2005 10:19:49 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j2UFJmBm066937 for ; Wed, 30 Mar 2005 07:19:48 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2UFJme20271 for ; Wed, 30 Mar 2005 07:19:48 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed X-Mailer: Apple Mail (2.619.2) Message-ID: <1ef4c3994932e94812fbd0bc12785eef@juniper.net> Date: Wed, 30 Mar 2005 08:19:47 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit On Mar 29, 2005, at 6:22 PM, Erblichs wrote: > Don't we think that some testers has already > generated undefined link types to make sure > that their implementation doesn't crash? This is probably true, though I was referring to 3rd party conformance testers, which by definition cannot officially test this case as there is no conformance to verify. > > Thus, my worst fear is that some routers > will create different LSDBs from others, > these non synch LSDBs will create periodic > black holes, etc AND NOBODY is aware > that this is happening... This is probably the worst case scenario. My points, perhaps steeped in a bit too much sarcasm, are this: If nobody ever actually adds a new link type to OSPF, this draft is entirely harmless. If a new link type is added to OSPF at some point, whatever is said in this draft will have no effect on the vast majority of deployed systems, and they will *never* all be upgraded. Further, as others have pointed out, the implications of a new link type cannot be addressed by this draft, as such a new link type is likely to impact the route calculation and could easily lead to a broken network unless all systems support it. The only safe way to add such a thing would be to change something guaranteed to be noticed by older implementations, and the only thing guaranteed would be to bump the version number. I don't buy the argument that adding a phrase to the spec would somehow make people think that new link types could be added willy-nilly without breaking things. Hopefully the OSPFWG of the future will not be that stupid, and if they are, well, this is the least of their problems. The Founding Fathers that spec'ed OSPF back in the olden days did not expend a lot of effort to try to make OSPF extensible, and this particular nit is only a small part of that problem. I have no particular objection to adding this language to the spec, but the idea that it will have any meaningful effect is unrealistic. The number of electrons killed to discuss it have already been excessive relative to its merits. Harmless, but a solution chasing a nonexistent problem. IMHO. --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 30 10:23:51 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08511 for ; Wed, 30 Mar 2005 10:23:49 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00FF6E76@cherry.ease.lsoft.com>; Wed, 30 Mar 2005 10:23:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64622141 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Mar 2005 10:23:47 -0500 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 30 Mar 2005 10:23:47 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j2UFNkBm066958 for ; Wed, 30 Mar 2005 07:23:46 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2UFNke20900 for ; Wed, 30 Mar 2005 07:23:46 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v619.2) References: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.619.2) Message-ID: <0c4ae137a8c302dfd322a0759d9e4dba@juniper.net> Date: Wed, 30 Mar 2005 08:23:45 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit On Mar 29, 2005, at 9:58 PM, Vishwas Manral wrote: > As I pointed out in my previous mail, malicious packets can very well > be > sent if we know this creates routing problems (and other interesting > problems that Dave mentioned) and we will never have a solution to that > if we leave things open-ended. Sorry, you're way off base here. If somebody wants to send malicious packets into an OSPF network, there are an infinite number of ways of breaking things, and this change leaves (infinity - 1) of them. The *only* way to protect against this is cryptographic authentication. Similarly, there are an infinite number of ways for a benign but broken implementation to break things, and this doesn't fix those either. The only argument for this is as a way to possibly avoid future extension problems, but I don't think it helps there either. --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 30 12:13:33 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19912 for ; Wed, 30 Mar 2005 12:13:33 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00FF70F6@cherry.ease.lsoft.com>; Wed, 30 Mar 2005 12:13:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64633825 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Mar 2005 12:13:32 -0500 Received: from 66.218.92.33 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 30 Mar 2005 12:13:32 -0500 Received: (qmail 54260 invoked by uid 60001); 30 Mar 2005 17:13:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=CYAS2hbL4svl1wJghGsedXLgaQd1+9PrfoQk1ZUK8qeJmdhDEryatYR37SoJrf4D3ZIphYeAt/8sFiAV8kDqUbCWWD3s5GTqjZSY2BHbIpQ2XMCXYsrBBDLcnyQqFLD9a7NRouBL25dKpLVkO4c/WfzQId+VDz7QI5uJ9X4oiKk= ; Received: from [64.142.109.122] by web40422.mail.yahoo.com via HTTP; Wed, 30 Mar 2005 09:13:30 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20050330171331.54258.qmail@web40422.mail.yahoo.com> Date: Wed, 30 Mar 2005 09:13:30 -0800 Reply-To: Mailing List Sender: Mailing List Comments: DomainKeys? See http://antispam.yahoo.com/domainkeys From: Pyda Srisuresh Subject: Re: OSPFv3 Extension Future Direction (this ought to get your attention) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <42496C6A.2020601@cisco.com> Precedence: list Acee, Pease see my response below inline. Thanks. regards, suresh <... stuff deleted> > >>>[suresh] Acee - I am referign to usign the srisuresh-ospf-te draft as a > >>> > >>> > >>basis > >> > >> > >>>to make MT extensions. Specifically, the suggestion is to add new LSA > types > >>>with MT protocol extensions. And, the new LSA types could have topology > >>>specific TLVs. The LSAs may be restricted to being advertised within the > >>>topology boundary. > >>> > >>> > >>> > >>> > >>Pyda, > >> > >>I took another look at your draft and don't see a good reason to use it > >>as a starting point > >>for OSPFv3 extension including MTR and AFs: > >> > >> 1. It is targeted at TE extensions > >> 2. It is based on OSPFv2 > >> 3. It doesn't specify the changes needed to base OSPFv3 needed to > >>support it. > >> 4. To the best of my knowledge, there is not a large base of > >>deployments or even > >> implementations that would benefit from using it as a base. > >> > >> > >> > > > >Acee, > > > >Items 1, 2 and 3 are true. However, that is not to say that the concepts in > the > >draft cannot be used as the base to add new LSA types with MT protocol > >extensions, restrict scope of LSA advertisements etc. The draft will need > >rework and will look much different from the current draft when done. > > > > > I suspect it would look much like draft-mirtorabi-mt-ospfv3-01.txt. > [suresh] I will give the mirtorabi-mt-ospfv3 draft a read. > >As for Item 4, you are postulating that if we did have a new draft using the > >concepts in srisuresh-ospf-te, you dont think it woudl benefit the existing > >deployments. That seems a bit presumptious. Sound like, you are declaring > that > >adding new LSAs will not benefit existing deployments and hence not > beneficial > >to pursue. If so, it seems you have already made up your mind to go with the > >TLV based approach. Is that the case? > > > > > That is not the case at all. #4 was in direct response to the > presumption that there was tremendous > advantage to be gained in starting with srisuresh-ospf-te as a base > since it already exists. > [suresh] Acee - This seems to be a semantics issue. I was refering to using the concepts in the draft as a base, not the draft as is. The srisuresh-ospf-te draft was conceived with the notion of making OSPF extendible for different topologies and distribution needs. Yet, the scope of the draft was OSPF-xTE. You may have misunderstood what I said. I certainly did not mean for anyone to taking the draft as is and turn it into a mt-ospfv3 draft. However, I would have little problem taking the current draft as is and turning it around to come up with a a mt-ospfv3 version of it. But, the mt-ospfv3 version of the draft would look different from the ospf-te draft. Hope you get the drift of what I mean. As I said earlier, I will give the mirtorabi draft a read to see If the draft already incorporates concepts from my draft. > As for the TLV approach, I do think it is the right way to go but it is > the OSPF WG and not any > single individual that must decide. The OSPF WG is always open to other > proposals. [suresh] Thanks. regards, suresh > > Thanks, > Acee > > > >cheers, > >suresh > > > > > > > >>Thanks, > >>Acee > >> > >> > >> > >>>cheers, > >>>suresh > >>> > >>> > >>> > >>> > >>> > >>>>Thanks, > >>>>Acee > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>I have not been active on this work recently due to my work priorities. > >>>>>However, if there are folks on the list interested in pursuing, I would > >>>>> > >>>>> > >>be > >> > >> > >>>>>happy to work with you on the effort and discussion. > >>>>> > >>>>>Thanks. > >>>>> > >>>>>cheers, > >>>>>suresh > >>>>> > >>>>>--- Acee Lindem wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >>>>>>Content-Transfer-Encoding: 7bit > >>>>>> > >>>>>>At the Minneapolis IETF, I presented a comparision of the > >>>>>>various options we have for extending OSPFv3. The reaction to the > >>>>>>presentation was very positive. However, it was last on the agenda and > >>>>>>the OSPF WG coincided with other WGs (most notably L2VPN). > >>>>>> > >>>>>>At this point, I would like to initiate more discussion. The basic > >>>>>>question is whether we go with a TLV based approach or continue > >>>>>>to add new LSAs which need to be synchronized with the LSAs > >>>>>>advertising topology and prefix information. A TLV based approach > >>>>>>is described in: > >>>>>> > >>>>>>http://www.ietf.org/internet-drafts/draft-mirtorabi-mt-ospfv3-01.txt > >>>>>> > >>>>>>The crux of my presentation would be that this is gives us the powerful > >>>>>>extension capability while still allowing us to advertise information > >>>>>> > >>>>>> > >>that > >> > >> > >>>>>>does not need to be synchronized in separate LSAs. > >>>>>> > >>>>>>Thanks, > >>>>>>Acee > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > >>> > >>> > > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 30 15:04:17 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04371 for ; Wed, 30 Mar 2005 15:04:17 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00FF75C0@cherry.ease.lsoft.com>; Wed, 30 Mar 2005 15:04:16 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64646248 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Mar 2005 15:04:15 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 30 Mar 2005 15:04:12 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 30 Mar 2005 12:04:01 -0800 X-IronPort-AV: i="3.91,135,1110182400"; d="scan'208"; a="243105013:sNHT824936260" Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2UK3xDr017498 for ; Wed, 30 Mar 2005 12:03:59 -0800 (PST) Received: from cisco.com (sjc-vpn4-175.cisco.com [10.21.80.175]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id BDT41407; Wed, 30 Mar 2005 12:03:58 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <4241CD1C.4060205@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <424B0612.8050308@cisco.com> Date: Wed, 30 Mar 2005 12:03:30 -0800 Reply-To: Mailing List Sender: Mailing List From: Michael J Barnes Subject: Re: OSPFv3 Extension Future Direction (this ought to get your attention) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4241CD1C.4060205@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Hey Acee, I want to pass this thought by you personally before sending it to the whole list, to see what you think. It seems to me that we should be talking about OSPFv4. Radical? Perhaps, but here's why I think this: OSPFv3, while it has many improvements over OPSFv2, was still not really designed to be extended. I really agree with you in general about the future direction for OSPF, by including TLVs in certain data structures, etc., are great ideas, but the solutions are nasty hacks. But the point I really want to make is not that we shouldn't be extending v3, it's that IMHO the future direction of OSPF should first, be a version of the protocol that has been designed from the base to be extendable. OSPFv3 is part way there, and I agree with the ideas you presented for the future direction, but I just think it would be better in the long run to have a new version of OSPF for this. If you're interested, I do have some specific ideas for functionality. Is that too radical of an idea, or something that would be worth more thought? Thanks, Michael From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 30 15:12:59 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05666 for ; Wed, 30 Mar 2005 15:12:59 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00FF7521@cherry.ease.lsoft.com>; Wed, 30 Mar 2005 15:12:57 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64646625 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Mar 2005 15:12:55 -0500 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 30 Mar 2005 15:12:54 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j2UKCr923254 for ; Wed, 30 Mar 2005 12:12:53 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2UKCle75171 for ; Wed, 30 Mar 2005 12:12:48 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v619.2) References: <4241CD1C.4060205@cisco.com> <424B0612.8050308@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.619.2) Message-ID: Date: Wed, 30 Mar 2005 13:12:47 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: OSPFv3 Extension Future Direction (this ought to get your attention) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <424B0612.8050308@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Guess you sent it to the whole list anyhow. ;-) Bumping the version number is the only safe way to make significant changes for which backward compatibility may be problematic. It doesn't even have to be a significant syntactic or semantic change to a protocol, though it tends to invite a whole bunch of meddling when you do so... On Mar 30, 2005, at 1:03 PM, Michael J Barnes wrote: > Hey Acee, > > I want to pass this thought by you personally before sending it to the > whole list, to see what you think. > > It seems to me that we should be talking about OSPFv4. Radical? > Perhaps, but here's why I think this: > > OSPFv3, while it has many improvements over OPSFv2, was still not > really designed to be extended. I really agree with you in general > about the future direction for OSPF, by including TLVs in certain data > structures, etc., are great ideas, but the solutions are nasty hacks. > But the point I really want to make is not that we shouldn't be > extending v3, it's that IMHO the future direction of OSPF should > first, be a version of the protocol that has been designed from the > base to be extendable. OSPFv3 is part way there, and I agree with the > ideas you presented for the future direction, but I just think it > would be better in the long run to have a new version of OSPF for > this. > > If you're interested, I do have some specific ideas for functionality. > > Is that too radical of an idea, or something that would be worth more > thought? > > Thanks, > Michael > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 30 15:52:23 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11645 for ; Wed, 30 Mar 2005 15:52:23 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00FF73AB@cherry.ease.lsoft.com>; Wed, 30 Mar 2005 15:52:23 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64649369 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Mar 2005 15:52:21 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 30 Mar 2005 15:42:21 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08552; Wed, 30 Mar 2005 15:42:19 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200503302042.PAA08552@ietf.org> Date: Wed, 30 Mar 2005 15:42:19 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-mt-03.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Multi-Topology (MT) Routing in OSPF Author(s) : P. Psenak, et al. Filename : draft-ietf-ospf-mt-03.txt Pages : 22 Date : 2005-3-30 This draft describes an extension to OSPF in order to define independent IP topologies called Multi-Topologies (MTs). The MT extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service, or in-band network management. [M-ISIS] describes a similar mechanism for ISIS. An optional extension to exclude selected links from the default topology is also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-mt-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-mt-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-mt-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-30151154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-mt-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-mt-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-30151154.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Mar 30 17:58:53 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06200 for ; Wed, 30 Mar 2005 17:58:52 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00FF79D8@cherry.ease.lsoft.com>; Wed, 30 Mar 2005 17:58:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64657569 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Mar 2005 17:58:50 -0500 Received: from 207.217.121.247 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 30 Mar 2005 17:58:50 -0500 Received: from h-68-164-155-80.snvacaid.dynamic.covad.net ([68.164.155.80] helo=earthlink.net) by pop-a065c32.pas.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1DGm9B-0001op-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Mar 2005 14:58:49 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <4241CD1C.4060205@cisco.com> <424B0612.8050308@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <424B2F64.87EFB1AA@earthlink.net> Date: Wed, 30 Mar 2005 14:59:48 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: OSPFv3 Extension Future Direction (this ought to get your attention) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Oooooh, Why? Would v4 and v2 interoperate? If they did wouldn't we run into the same problems? Would v4 and v3 interoperate? IM limited opinion, the idea of extensibility is very difficult to achive. Would we support subsec hellos? Do we add two levels of IP support? Would we add nack support? Would we support overload notification? Would we support notification of router capibility like a Enterprise level router, that would over-ride DR election? Where do you stop? Just food for thought.. Mitchell Erblich ------------------------ Dave Katz wrote: > > Guess you sent it to the whole list anyhow. ;-) > > Bumping the version number is the only safe way to make significant > changes for which backward compatibility may be problematic. It > doesn't even have to be a significant syntactic or semantic change to a > protocol, though it tends to invite a whole bunch of meddling when you > do so... > > On Mar 30, 2005, at 1:03 PM, Michael J Barnes wrote: > > > Hey Acee, > > > > I want to pass this thought by you personally before sending it to the > > whole list, to see what you think. > > > > It seems to me that we should be talking about OSPFv4. Radical? > > Perhaps, but here's why I think this: > > > > OSPFv3, while it has many improvements over OPSFv2, was still not > > really designed to be extended. I really agree with you in general > > about the future direction for OSPF, by including TLVs in certain data > > structures, etc., are great ideas, but the solutions are nasty hacks. > > But the point I really want to make is not that we shouldn't be > > extending v3, it's that IMHO the future direction of OSPF should > > first, be a version of the protocol that has been designed from the > > base to be extendable. OSPFv3 is part way there, and I agree with the > > ideas you presented for the future direction, but I just think it > > would be better in the long run to have a new version of OSPF for > > this. > > > > If you're interested, I do have some specific ideas for functionality. > > > > Is that too radical of an idea, or something that would be worth more > > thought? > > > > Thanks, > > Michael > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Mar 31 14:48:16 2005 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27633 for ; Thu, 31 Mar 2005 14:48:15 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00FF8FB4@cherry.ease.lsoft.com>; Thu, 31 Mar 2005 14:48:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 64783890 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 31 Mar 2005 14:48:12 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 31 Mar 2005 14:48:12 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 31 Mar 2005 14:48:12 -0500 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2VJm9jI026622 for ; Thu, 31 Mar 2005 14:48:10 -0500 (EST) Received: from cisco.com (sjc-vpn6-71.cisco.com [10.21.120.71]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id BDU54798; Thu, 31 Mar 2005 11:48:07 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <4241CD1C.4060205@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <424C50B9.7040203@cisco.com> Date: Thu, 31 Mar 2005 11:34:17 -0800 Reply-To: Mailing List Sender: Mailing List From: Michael J Barnes Subject: Re: OSPFv3 Extension Future Direction (this ought to get your attention) To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4241CD1C.4060205@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Acee, Acee Lindem wrote: > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > At the Minneapolis IETF, I presented a comparision of the > various options we have for extending OSPFv3. The reaction to the > presentation was very positive. However, it was last on the agenda and > the OSPF WG coincided with other WGs (most notably L2VPN). > > At this point, I would like to initiate more discussion. The basic > question is whether we go with a TLV based approach or continue > to add new LSAs which need to be synchronized with the LSAs > advertising topology and prefix information. A TLV based approach > is described in: > > http://www.ietf.org/internet-drafts/draft-mirtorabi-mt-ospfv3-01.txt > > The crux of my presentation would be that this is gives us the powerful > extension capability while still allowing us to advertise information that > does not need to be synchronized in separate LSAs. If we want to stick to enhancing v3 rather than moving forward to v4, then I would like to suggest that there be a separate draft for new LSAs (and perhaps other enhancements), similar to what is done in the MTR draft, but not specifically for MTR. The reason for a separate draft is so that we can design the new LSAs such that they more generally accomplish the goal of making OSPFv3 extendable, rather than just the more specific goal of supporting MTR. Then the MTR draft, and other drafts, can be written to take advantage of the new LSAs. It is also my opinion that not too much be stuffed into the router LSA, because if the LSA becomes large enough that it must be fragmented, and when any small part of the LSA is updated a lot of unchanged information will be reflooded. There are ways that the synchronization can be addressed without putting many different pieces of data into the Router LSA. Regards, Michael > Thanks, > Acee >