From ospf-bounces@ietf.org Thu May 1 10:51:05 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037F028C1A8; Thu, 1 May 2008 10:51:05 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DD883A6B70 for ; Thu, 1 May 2008 10:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSNR7eszSAjn for ; Thu, 1 May 2008 10:50:59 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 5C1E828C42C for ; Thu, 1 May 2008 10:49:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id EFDFD323D62; Thu, 1 May 2008 10:49:51 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31141-02; Thu, 1 May 2008 10:49:51 -0700 (PDT) Received: from [?*???n?IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 7943C323D5F; Thu, 1 May 2008 10:49:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753) To: OSPF List , mpls@lists.ietf.org Message-Id: <630B2D95-54D8-431A-925A-2D9623067F85@redback.com> From: Acee Lindem Date: Thu, 1 May 2008 13:48:11 -0400 X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Subject: [OSPF] Last Chance on draft-ietf-mpls-number-0-bw-te-lsps-09.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1034569278==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============1034569278== Content-Type: multipart/alternative; boundary=Apple-Mail-272--571342850 --Apple-Mail-272--571342850 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed We have decided to allow for a 1 week last call on the subject MPLS WG document in both the OSPF and ISIS WGs. It was previously last called but this was some time ago (1-2 years back). If you have any comments (other than no draft should be allowed to have a title spanning 2 full lines), please send them to this list and the MPLS list (mpls@lists.ietf.org) by 12:00 AM EST on Friday, May 9th. For your convenience: http://www.ietf.org/internet-drafts/draft-ietf-mpls-number-0-bw-te- lsps-09.txt Thanks, Acee --Apple-Mail-272--571342850 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 We have decided to allow for a = 1 week last call on the subject MPLS WG document in both the OSPF and = ISIS WGs. It was previously last called but this was some time ago (1-2 = years back). If you have any comments (other than no draft should be = allowed to have a title spanning 2 full lines), please send them to this = list and the MPLS list (mpls@lists.ietf.org) by 12:00 AM = EST on Friday, May 9th.=A0

For your = convenience:=A0


Thanks,
X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B53D628C41F; Thu, 1 May 2008 10:51:05 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E0E3A68F2 for ; Thu, 1 May 2008 10:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9A6c9xCNBss for ; Thu, 1 May 2008 10:51:00 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 2BCBB28C42F for ; Thu, 1 May 2008 10:49:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id C3425323D62; Thu, 1 May 2008 10:49:52 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30886-09; Thu, 1 May 2008 10:49:52 -0700 (PDT) Received: from [?*???n?IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 25F20323D5F; Thu, 1 May 2008 10:49:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753) To: OSPF List , mpls@lists.ietf.org Message-Id: From: Acee Lindem Date: Thu, 1 May 2008 13:48:28 -0400 X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Subject: [OSPF] Last Chance on draft-ietf-mpls-number-0-bw-te-lsps-09.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1727637818==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============1727637818== Content-Type: multipart/alternative; boundary=Apple-Mail-273--571325679 --Apple-Mail-273--571325679 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed We have decided to allow for a 1 week last call on the subject MPLS WG document in both the OSPF and ISIS WGs. It was previously last called but this was some time ago (1-2 years back). If you have any comments (other than no draft should be allowed to have a title spanning 2 full lines), please send them to this list and the MPLS list (mpls@lists.ietf.org) by 12:00 AM EST on Friday, May 9th. For your convenience: http://www.ietf.org/internet-drafts/draft-ietf-mpls-number-0-bw-te- lsps-09.txt Thanks, Acee --Apple-Mail-273--571325679 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 We have decided to allow for a 1 week last call on the subject MPLS WG = document in both the OSPF and ISIS WGs. It was previously last called = but this was some time ago (1-2 years back). If you have any comments = (other than no draft should be allowed to have a title spanning 2 full = lines), please send them to this list and the MPLS list (mpls@lists.ietf.org) by 12:00 AM = EST on Friday, May 9th.=A0

For your = convenience:=A0


Thanks,
X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA2763A6A1C for ; Sat, 3 May 2008 04:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.247 X-Spam-Level: *** X-Spam-Status: No, score=3.247 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_50=0.001, RAZOR2_CHECK=0.5, TVD_PH_SUBJ_ACCOUNTS_POST=2.996] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BZoCZm7H-D5 for ; Sat, 3 May 2008 04:07:21 -0700 (PDT) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by core3.amsl.com (Postfix) with ESMTP id 19F7B3A67F5 for ; Sat, 3 May 2008 04:07:21 -0700 (PDT) Received: from sccqwbc01 (scommcenter01.asp.att.net[204.127.203.161]) by sccmmhc91.asp.att.net (sccmmhc91) with SMTP id <20080503110710m91003go7ne>; Sat, 3 May 2008 11:07:22 +0000 Received: from [128.241.105.0] by sccqwbc01; Sat, 03 May 2008 11:07:09 +0000 From: teamwebmail@mchsi.com (Webmail Support Team) Subject: Confirm Your Email Account Date: Sat, 03 May 2008 11:07:09 +0000 Message-Id: <050320081107.9769.481C475D000A2FC100002629219792474103010CD2079C080C03BF04070E030D0A99030E0A9B@mchsi.com> X-Mailer: AT&T Message Center Version 1 (Oct 30 2007) X-Authenticated-Sender: dGVhbXdlYm1haWxAbWNoc2kuY29t To: undisclosed-recipients:; Dear Webmail Subscriber, To complete your webmail account, you must reply to this email immediately and enter your password here (*********)And user name here (__________) Failure to do this will immediately render your email address deactivated from our database. You can also confirm your email address by logging into your webmail account. Thank you for using! THE SUPPORT TEAM WEBMAIL SUPPORT. From ospf-bounces@ietf.org Tue May 6 06:42:28 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89BBB3A6FFD; Tue, 6 May 2008 06:42:28 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AEB43A6963 for ; Tue, 6 May 2008 06:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOWkZowZxdsd for ; Tue, 6 May 2008 06:42:25 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 55D533A6E4B for ; Tue, 6 May 2008 06:42:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 024D92B3E35 for ; Tue, 6 May 2008 06:42:24 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13551-06 for ; Tue, 6 May 2008 06:42:23 -0700 (PDT) Received: from [?????n?IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id D5EE92B3E34 for ; Tue, 6 May 2008 06:42:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: <23A7A4B5-F58E-4467-9520-BC6B263D1C73@redback.com> References: <23A7A4B5-F58E-4467-9520-BC6B263D1C73@redback.com> Message-Id: <38ECD9C4-1DEA-480C-ADEE-A5DDF3729CA8@redback.com> Cc: OSPF List From: Acee Lindem Date: Tue, 6 May 2008 09:42:18 -0400 X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Subject: Re: [OSPF] OSPF Link-local Signaling - draft-ietf-ospf-lls-05.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0657559091==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============0657559091== Content-Type: multipart/alternative; boundary=Apple-Mail-7--154095269 --Apple-Mail-7--154095269 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed The WG last call on the revised document has completed. I will prepare the protocol write-up for the AD review. Thanks, Acee On Apr 24, 2008, at 5:33 PM, Acee Lindem wrote: > This version includes Vishwas Manral's and Jonathan Sadler's > comments from the WG last call. Please take a look at the updated > version. Unless there are any objections, I plan to send it to the > ADs on April 30th, 2008. > > For you convenience, here is a link: > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-lls-05.txt > > Thanks, > Acee > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-7--154095269 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 The WG last call on the revised document has completed. I will prepare = the protocol write-up for the AD = review.=A0
Thanks,
Acee=A0
On Apr 24, 2008, = at 5:33 PM, Acee Lindem wrote:

This = version includes Vishwas Manral's and Jonathan Sadler's comments from = the WG last call. Please take a look at the updated version. Unless = there are any objections, I plan to send it to the ADs on April 30th, = 2008.

= --Apple-Mail-7--154095269-- --===============0657559091== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --===============0657559091==-- From ospf-bounces@ietf.org Thu May 8 16:15:12 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC2628C582; Thu, 8 May 2008 16:15:12 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5786D28C516; Thu, 8 May 2008 16:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.299 X-Spam-Level: X-Spam-Status: No, score=-17.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPIQN8XEUAP4; Thu, 8 May 2008 16:15:05 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id C466C28C543; Thu, 8 May 2008 16:15:05 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 5EF2D12973C; Thu, 8 May 2008 16:15:04 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20080508231504.5EF2D12973C@bosco.isi.edu> Date: Thu, 8 May 2008 16:15:04 -0700 (PDT) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] RFC 5185 on OSPF Multi-Area Adjacency X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5185 Title: OSPF Multi-Area Adjacency Author: S. Mirtorabi, P. Psenak, A. Lindem, Ed., A. Oswal Status: Standards Track Date: May 2008 Mailbox: sina@nuovasystems.com, ppsenak@cisco.com, acee@redback.com, aoswal@redback.com Pages: 11 Characters: 18698 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ospf-multi-area-adj-09.txt URL: http://www.rfc-editor.org/rfc/rfc5185.txt This document describes an extension to the Open Shortest Path First (OSPF) protocol to allow a single physical link to be shared by multiple areas. This is necessary to allow the link to be considered an intra-area link in multiple areas. This would create an intra- area path in each of the corresponding areas sharing the same link. [STANDARDS TRACK] This document is a product of the Open Shortest Path First IGP Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From c.lenaerts@waypoint-design.com Sun May 18 13:27:09 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473113A6800; Sun, 18 May 2008 13:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.263 X-Spam-Level: X-Spam-Status: No, score=-76.263 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, RCVD_IN_BL_SPAMCOP_NET=2.188, RCVD_IN_DSBL=0.753, RCVD_IN_PBL=0.509, RCVD_IN_SORBS_DUL=1.615, RCVD_IN_XBL=2.896, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7a9SvQ+EATC; Sun, 18 May 2008 13:27:08 -0700 (PDT) Received: from cliente-10702.iberbanda.es (unknown [82.198.105.204]) by core3.amsl.com (Postfix) with SMTP id 38BFA3A690F; Sun, 18 May 2008 13:26:43 -0700 (PDT) X-Originating-IP: 168.170.57.130 by smtp.82.198.105.204; Sun, 18 May 2008 16:26:44 -0500 Message-ID: From: "Nona Black" Reply-To: "Nona Black" To: atompub-archive@megatron.ietf.org Subject: Replica watches made easy Date: Sun, 18 May 2008 16:26:44 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new Porsche Design watches originated from the novel Titanium Chronograph from the 1970's, an absolutely unique creation due to the perfection of its workmanship. Based on its design, the Porsche Design Company developed an appealing, stylish, sporty and highly accurate watch. Unfortunately, these timepieces come with a high price tag. http://rywafyko20118.blogspot.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://rywafyko20118.blogspot.com/ From c.vanherp@rotim.com Mon May 19 17:42:28 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758813A6B39; Mon, 19 May 2008 17:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -79.766 X-Spam-Level: X-Spam-Status: No, score=-79.766 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_DSBL=0.961, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUCbDO7VdGIh; Mon, 19 May 2008 17:42:27 -0700 (PDT) Received: from 201-255-10-157.mrse.com.ar (unknown [201.255.10.157]) by core3.amsl.com (Postfix) with SMTP id 4C16F3A6B26; Mon, 19 May 2008 17:42:13 -0700 (PDT) X-Originating-IP: 17.37.196.162 by smtp.201.255.10.157; Mon, 19 May 2008 20:42:14 -0500 Message-ID: From: "Galen Rainey" Reply-To: "Galen Rainey" To: atompub-archive@megatron.ietf.org Subject: Save thousands... no one will know Date: Mon, 19 May 2008 20:42:14 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new Porsche Design watches originated from the novel Titanium Chronograph from the 1970's, an absolutely unique creation due to the perfection of its workmanship. Based on its design, the Porsche Design Company developed an appealing, stylish, sporty and highly accurate watch. Unfortunately, these timepieces come with a high price tag. http://nuvohehenyd04.blogspot.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://nuvohehenyd04.blogspot.com/ From ediuf11@yahoo.com.ph Tue May 20 05:56:53 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFFA13A6B87 for ; Tue, 20 May 2008 05:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.745 X-Spam-Level: **** X-Spam-Status: No, score=4.745 tagged_above=-999 required=5 tests=[ADVANCE_FEE_2=1.234, ADVANCE_FEE_3=1.432, BAYES_50=0.001, HTML_MESSAGE=0.001, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHADmE8DKopE for ; Tue, 20 May 2008 05:56:52 -0700 (PDT) Received: from n9a.bullet.mail.mud.yahoo.com (n9a.bullet.mail.mud.yahoo.com [209.191.87.108]) by core3.amsl.com (Postfix) with SMTP id 42FAA3A6B97 for ; Tue, 20 May 2008 05:56:51 -0700 (PDT) Received: from [68.142.194.243] by n9.bullet.mail.mud.yahoo.com with NNFMP; 20 May 2008 12:56:49 -0000 Received: from [209.191.90.56] by t1.bullet.mud.yahoo.com with NNFMP; 20 May 2008 12:56:49 -0000 Received: from [127.0.0.1] by omp109.mail.mud.yahoo.com with NNFMP; 20 May 2008 12:56:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 308085.60569.bm@omp109.mail.mud.yahoo.com Received: (qmail 70073 invoked by uid 60001); 20 May 2008 12:56:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ph; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=tZ78GvF+jSmElzswagG6ELmGMRglya1VCelZtzWDWBWJh2dt96pRmU4d7mdiPHKWBM2zlceLrxuyMDjnZa85La9rPpO4JaoAUS9irzV/3r5L9nb+IGz4zQ2LpUUUCQK3i5R4Dp9u/HGxU9NOHtPuoo4i1ewyA5KnekEwnTn3uo0=; X-YMail-OSG: JHU90zkVM1nd8ZXgGt_6VHtMG9iFImMRE.C7dmnq Received: from [41.208.167.126] by web76005.mail.sg1.yahoo.com via HTTP; Tue, 20 May 2008 05:56:47 PDT Date: Tue, 20 May 2008 05:56:47 -0700 (PDT) From: "Eng.Assans Eng.Assans" Reply-To: a_diuf@excite.com Subject: ARE YOU TRUST WHORTHY To: ediuf11@yahoo.com.ph MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1946813581-1211288207=:67988" Content-Transfer-Encoding: 8bit Message-ID: <222648.67988.qm@web76005.mail.sg1.yahoo.com> --0-1946813581-1211288207=:67988 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Compliment of day, I am Eng.Assane Diuf from SENEGAL and i want to do business with you and will like let you know that this project is planned to be quickened and will be conducted with precise actions according to the program i want you to understand that this is not fake as you think but i want you to know that you will not pay anything till the money gets to you care. First it may be of interest to know that I am the incumbent Technical director in the Federal Ministry of Works and Housing and I have the privilege of office to facilitate the claim of an over-invoice amount still pending in the suspense account of the Ministry of Finance awaiting recommendation for payment from my office. I have prepared the grounds to present you as a sub-contractor and provide necessary papers in the contract file to back the claim application in your favour according to the legal requirements of my ministry. The ministry of finance has established two options for all categories of capital contract payment to beneficiaries and you will choose which process we will take to receive the money as soon as the payment is approved in your name. The amount that will be claimed in this project is $7.5m . Given your unalloyed support I am confident that we can effect this claim in a matter of a week and some days. I must assure you that no risk is attached because all the legal steps will be strictly followed and we will hire a lawyer who will stand as your legal representative and sign the fund release order bond on your behalf as soon as the payment is approved in your favour. It will be a pleasure to talk with you on the telephone for acquaintance and rapport and I will not hesitate to give you a call upon receipt of your positive response for the way forward. Do indicate your mobile phone number for my call in your next mail. Eng.Assane Diuf. --------------------------------- Support Victims of the Cyclone in Myanmar (Burma). Donate Now. --0-1946813581-1211288207=:67988 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Compliment of day,
 
I am Eng.Assane Diuf from SENEGAL and i want to do business with you and will like let you know that this project is planned to be quickened and will be conducted with precise actions according to the program i want you to understand that this is not fake as you think but i want you to know that you will not pay anything till the money gets to you care.
 
 
First it may be of interest to know that I am the incumbent Technical director in the Federal Ministry of Works and Housing and I have the privilege of office to facilitate the claim of an over-invoice amount still pending in the suspense account of the Ministry of Finance awaiting recommendation for payment from my office.
 
I have prepared the grounds to present you as a sub-contractor and provide necessary papers in the contract file to back the claim application in your favour according to the legal requirements of my ministry.
 
The ministry of finance has established two options for all categories of capital contract payment to beneficiaries and you will choose which process we will take to receive the money as soon as the payment is approved in your name. The amount that will be claimed in this project is $7.5m .
 
Given your unalloyed support I am confident that we can effect this claim in a matter of a week and some days.

I must assure you that no risk is attached because all the legal steps will be strictly followed and we will hire a lawyer who will stand as your legal representative and sign the fund release order bond on your behalf as soon as the payment is approved in your favour.
 
It will be a pleasure to talk with you on the telephone for acquaintance and rapport and I will not hesitate to give you a call upon receipt of your positive response for the way forward. Do indicate your mobile phone number for my call in your next mail.
 
Eng.Assane Diuf.

Support Victims of the Cyclone in Myanmar (Burma).
Donate Now. --0-1946813581-1211288207=:67988-- From ediuf11@yahoo.com.ph Tue May 20 05:56:56 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B063A6B7F for ; Tue, 20 May 2008 05:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.745 X-Spam-Level: **** X-Spam-Status: No, score=4.745 tagged_above=-999 required=5 tests=[ADVANCE_FEE_2=1.234, ADVANCE_FEE_3=1.432, BAYES_50=0.001, HTML_MESSAGE=0.001, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRTxiEEFvSAy for ; Tue, 20 May 2008 05:56:52 -0700 (PDT) Received: from n18.bullet.mail.mud.yahoo.com (n18.bullet.mail.mud.yahoo.com [68.142.206.145]) by core3.amsl.com (Postfix) with SMTP id 3E8063A6B8F for ; Tue, 20 May 2008 05:56:51 -0700 (PDT) Received: from [68.142.194.243] by n18.bullet.mail.mud.yahoo.com with NNFMP; 20 May 2008 12:56:48 -0000 Received: from [209.191.86.73] by t1.bullet.mud.yahoo.com with NNFMP; 20 May 2008 12:56:49 -0000 Received: from [127.0.0.1] by omp308.mail.mud.yahoo.com with NNFMP; 20 May 2008 12:56:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 303307.31161.bm@omp308.mail.mud.yahoo.com Received: (qmail 70073 invoked by uid 60001); 20 May 2008 12:56:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ph; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=tZ78GvF+jSmElzswagG6ELmGMRglya1VCelZtzWDWBWJh2dt96pRmU4d7mdiPHKWBM2zlceLrxuyMDjnZa85La9rPpO4JaoAUS9irzV/3r5L9nb+IGz4zQ2LpUUUCQK3i5R4Dp9u/HGxU9NOHtPuoo4i1ewyA5KnekEwnTn3uo0=; X-YMail-OSG: JHU90zkVM1nd8ZXgGt_6VHtMG9iFImMRE.C7dmnq Received: from [41.208.167.126] by web76005.mail.sg1.yahoo.com via HTTP; Tue, 20 May 2008 05:56:47 PDT Date: Tue, 20 May 2008 05:56:47 -0700 (PDT) From: "Eng.Assans Eng.Assans" Reply-To: a_diuf@excite.com Subject: ARE YOU TRUST WHORTHY To: ediuf11@yahoo.com.ph MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1946813581-1211288207=:67988" Content-Transfer-Encoding: 8bit Message-ID: <222648.67988.qm@web76005.mail.sg1.yahoo.com> --0-1946813581-1211288207=:67988 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Compliment of day, I am Eng.Assane Diuf from SENEGAL and i want to do business with you and will like let you know that this project is planned to be quickened and will be conducted with precise actions according to the program i want you to understand that this is not fake as you think but i want you to know that you will not pay anything till the money gets to you care. First it may be of interest to know that I am the incumbent Technical director in the Federal Ministry of Works and Housing and I have the privilege of office to facilitate the claim of an over-invoice amount still pending in the suspense account of the Ministry of Finance awaiting recommendation for payment from my office. I have prepared the grounds to present you as a sub-contractor and provide necessary papers in the contract file to back the claim application in your favour according to the legal requirements of my ministry. The ministry of finance has established two options for all categories of capital contract payment to beneficiaries and you will choose which process we will take to receive the money as soon as the payment is approved in your name. The amount that will be claimed in this project is $7.5m . Given your unalloyed support I am confident that we can effect this claim in a matter of a week and some days. I must assure you that no risk is attached because all the legal steps will be strictly followed and we will hire a lawyer who will stand as your legal representative and sign the fund release order bond on your behalf as soon as the payment is approved in your favour. It will be a pleasure to talk with you on the telephone for acquaintance and rapport and I will not hesitate to give you a call upon receipt of your positive response for the way forward. Do indicate your mobile phone number for my call in your next mail. Eng.Assane Diuf. --------------------------------- Support Victims of the Cyclone in Myanmar (Burma). Donate Now. --0-1946813581-1211288207=:67988 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Compliment of day,
 
I am Eng.Assane Diuf from SENEGAL and i want to do business with you and will like let you know that this project is planned to be quickened and will be conducted with precise actions according to the program i want you to understand that this is not fake as you think but i want you to know that you will not pay anything till the money gets to you care.
 
 
First it may be of interest to know that I am the incumbent Technical director in the Federal Ministry of Works and Housing and I have the privilege of office to facilitate the claim of an over-invoice amount still pending in the suspense account of the Ministry of Finance awaiting recommendation for payment from my office.
 
I have prepared the grounds to present you as a sub-contractor and provide necessary papers in the contract file to back the claim application in your favour according to the legal requirements of my ministry.
 
The ministry of finance has established two options for all categories of capital contract payment to beneficiaries and you will choose which process we will take to receive the money as soon as the payment is approved in your name. The amount that will be claimed in this project is $7.5m .
 
Given your unalloyed support I am confident that we can effect this claim in a matter of a week and some days.

I must assure you that no risk is attached because all the legal steps will be strictly followed and we will hire a lawyer who will stand as your legal representative and sign the fund release order bond on your behalf as soon as the payment is approved in your favour.
 
It will be a pleasure to talk with you on the telephone for acquaintance and rapport and I will not hesitate to give you a call upon receipt of your positive response for the way forward. Do indicate your mobile phone number for my call in your next mail.
 
Eng.Assane Diuf.

Support Victims of the Cyclone in Myanmar (Burma).
Donate Now. --0-1946813581-1211288207=:67988-- From c.nipkow@quartierkultur-kreis6.ch Wed May 21 11:00:27 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F327928C210; Wed, 21 May 2008 11:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.683 X-Spam-Level: **** X-Spam-Status: No, score=4.683 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SUB_PERFECT=0.725, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yljgolX7-X5T; Wed, 21 May 2008 11:00:25 -0700 (PDT) Received: from cable201-233-159-41.epm.net.co (cable201-233-159-41.epm.net.co [201.233.159.41]) by core3.amsl.com (Postfix) with SMTP id C35893A69B0; Wed, 21 May 2008 11:00:04 -0700 (PDT) X-Originating-IP: 178.30.116.46 by smtp.201.233.159.41; Wed, 21 May 2008 14:00:09 -0500 Message-ID: From: "Pat Gilmore" Reply-To: "Pat Gilmore" To: atompub-archive@megatron.ietf.org Subject: Replica watch is a perfect gift Date: Wed, 21 May 2008 14:00:09 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Since 1884 Bvlgari watches have drawn inspiration from the timeless beauty of Greek and Roman art. The time pieces that they produce are as much works of art, as a way to tell time, and now you can possess one of these splendid time pieces for a very affordable price, at Prestige Replicas. http://www.adieks.com/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://www.adieks.com/ From c.unfried@secure.medicalnet.at Thu May 22 12:05:26 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D033A6B2F; Thu, 22 May 2008 12:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -72.626 X-Spam-Level: X-Spam-Status: No, score=-72.626 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxwIODdaMrWo; Thu, 22 May 2008 12:05:24 -0700 (PDT) Received: from 39-141-223-201.adsl.terra.cl (39-141-223-201.adsl.terra.cl [201.223.141.39]) by core3.amsl.com (Postfix) with SMTP id 4ADEF28C161; Thu, 22 May 2008 12:02:21 -0700 (PDT) X-Originating-IP: 144.223.155.180 by smtp.201.223.141.39; Thu, 22 May 2008 15:02:21 -0500 Message-ID: From: "Morton Quintero" Reply-To: "Morton Quintero" To: atompub-archive@megatron.ietf.org Subject: Beautiful Rado watches for less Date: Thu, 22 May 2008 15:02:21 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit What comes to mind when you hear the words Louis Vuitton? Of course, the classic style, the superior quality of their bags, their unique look, and their inflated price tag. But, how about being able to afford a beautiful Louis Vuitton handbag without having to dent your budget? It is now possible. Thanks to Prestige Replicas, that Louis Vuitton bag or wallet is closer to you than ever before! Come visit our new designer bag section and pick that special Louis Vuitton handbag that you've always wanted. http://wuhyluhakyr77.blogspot.com/ Remember, Prestige Replicas offers award winning customer service and an absolute guarantee of its products and your privacy! http://wuhyluhakyr77.blogspot.com/ From northdeluxe@bellnet.ca Sat May 24 06:34:52 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99EA43A69D9 for ; Sat, 24 May 2008 06:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.312 X-Spam-Level: ** X-Spam-Status: No, score=2.312 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_50=0.001, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyaYosjiwn8r for ; Sat, 24 May 2008 06:34:52 -0700 (PDT) Received: from tomts37-srv.bellnexxia.net (tomts37.bellnexxia.net [209.226.175.94]) by core3.amsl.com (Postfix) with ESMTP id D4EB63A687C for ; Sat, 24 May 2008 06:34:51 -0700 (PDT) Received: from toip39-bus.srvr.bell.ca ([67.69.240.40]) by tomts37-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20080524133449.OUQP1740.tomts37-srv.bellnexxia.net@toip39-bus.srvr.bell.ca> for ; Sat, 24 May 2008 09:34:49 -0400 Message-Id: <6tghee$1agt99@toip39-bus.srvr.bell.ca> X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtNJAGK2N0jR4q/5/2dsb2JhbACJbB99IYYSmAQ Received: from tofep1.bellnexxia.net (HELO smtp.bellnexxia.net) ([209.226.175.249]) by toip39-bus.srvr.bell.ca with SMTP; 24 May 2008 09:34:52 -0400 X-Mailer: Openwave WebEngine, version 2.8.11 (webedge20-101-194-20030622) X-Originating-IP: [200.157.216.167] From: Reply-To: mrjohn_williams439@yahoo.co.uk To: Subject: You Won =?ISO-8859-1?B?ozEsMDAwLDAwMC4wMA==?= GBP Date: Sat, 24 May 2008 9:34:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You won the sum of =A31,000,000.00 GBP from our monthlyPromotion,to claim= your prize get back to us with your Names,Address,Occupation,Age. Send t= o = :mrjohn_williams772@yahoo.co.uk From cabmail@woodenradiatorcabinet.com Mon May 26 00:52:39 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80C143A6B48; Mon, 26 May 2008 00:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.222 X-Spam-Level: X-Spam-Status: No, score=-26.222 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTTP_ESCAPED_HOST=0.134, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXMCZfPjKamY; Mon, 26 May 2008 00:52:33 -0700 (PDT) Received: from cm-85-152-146-209.telecable.es (cm-85-152-146-209.telecable.es [85.152.146.209]) by core3.amsl.com (Postfix) with SMTP id 3F7023A6997; Mon, 26 May 2008 00:52:13 -0700 (PDT) X-Originating-IP: 194.81.121.210 by smtp.85.152.146.209; Mon, 26 May 2008 03:52:27 -0500 Message-ID: From: "Pablo Hammer" Reply-To: "Pablo Hammer" To: atompub-archive@megatron.ietf.org Subject: Watches made to impress Date: Mon, 26 May 2008 03:52:27 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Since 1884 Bvlgari watches have drawn inspiration from the timeless beauty of Greek and Roman art. The time pieces that they produce are as much works of art, as a way to tell time, and now you can possess one of these splendid time pieces for a very affordable price, at Prestige Replicas. http://www%2Ejusiile%2Ecom/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://www%2Ejusiile%2Ecom/ From trevor4@bellnet.ca Mon May 26 06:14:10 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0A03A6A47 for ; Mon, 26 May 2008 06:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.804 X-Spam-Level: X-Spam-Status: No, score=0.804 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvVldP050qvv for ; Mon, 26 May 2008 06:14:09 -0700 (PDT) Received: from tomts27-srv.bellnexxia.net (tomts27.bellnexxia.net [209.226.175.101]) by core3.amsl.com (Postfix) with ESMTP id 9D5813A6A0C for ; Mon, 26 May 2008 06:14:09 -0700 (PDT) Received: from toip39-bus.srvr.bell.ca ([67.69.240.40]) by tomts27-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20080526131411.XSTG1705.tomts27-srv.bellnexxia.net@toip39-bus.srvr.bell.ca> for ; Mon, 26 May 2008 09:14:11 -0400 Message-Id: <6tghee$1aqac8@toip39-bus.srvr.bell.ca> X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcsAIxUOkjR4q+H/2dsb2JhbACLKIgZ Received: from tofep3.bellnexxia.net (HELO smtp.bellnexxia.net) ([209.226.175.135]) by toip39-bus.srvr.bell.ca with SMTP; 26 May 2008 09:14:11 -0400 X-Mailer: Openwave WebEngine, version 2.8.11 (webedge20-101-194-20030622) X-Originating-IP: [201.75.239.212] From: Irish Lottery Promo Reply-To: dr.williams_spencer02@yahoo.co.uk Organization: Irish Lottery Promo To: Subject: 2008 **winner** Date: Mon, 26 May 2008 9:14:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit contactr. Dr. Williams Spencer,Email: dr.williams_spencer02@yahoo.co.uk for a lump sum pay out of 1,350 000 pounds. Provide him with the information below: 1.Full Name: 2.Full Address, Occupation, sex and age From c.porot@mutualitefrancaiserhone.fr Mon May 26 12:24:19 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DEF53A6BDF; Mon, 26 May 2008 12:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.648 X-Spam-Level: X-Spam-Status: No, score=-15.648 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTTP_ESCAPED_HOST=0.134, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIeu7EVVkrdm; Mon, 26 May 2008 12:24:13 -0700 (PDT) Received: from host51-133-dynamic.7-87-r.retail.telecomitalia.it (host51-133-dynamic.7-87-r.retail.telecomitalia.it [87.7.133.51]) by core3.amsl.com (Postfix) with SMTP id CF31E3A69FC; Mon, 26 May 2008 12:24:02 -0700 (PDT) X-Originating-IP: 194.32.17.48 by smtp.87.7.133.51; Mon, 26 May 2008 15:24:17 -0500 Message-ID: From: "Ronnie Grimm" Reply-To: "Ronnie Grimm" To: atompub-archive@megatron.ietf.org Subject: The affordable watch alternative Date: Mon, 26 May 2008 15:24:17 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit X-Antivirus: avast! (VPS 080526-0, 26/05/2008), Outbound message X-Antivirus-Status: Clean Everybody knows that a Cartier watch is a silent statement of wealth and luxury. But we all know as well that the price of putting one of them on your wrist is for the most unaffordable by the average Joe. That's why replica Cartier watches are becoming more and more popular by the day. They're actually the affordable solution to this dilemma. And thanks to the internet, there is now a place where the highest quality Cartier replicas are available: Prestige Replicas. So, why not take a look at the extensive inventory that this site has to offer? After all, browsing through their hundreds of Cartier watches is absolutely free, and buying the one of your dreams is simply inexpensive. http://www%2Eadieks%2Ecom/ From caciara@caciara.it Tue May 27 01:47:57 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C773A6784; Tue, 27 May 2008 01:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.857 X-Spam-Level: X-Spam-Status: No, score=-6.857 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_FR=0.35, HTTP_ESCAPED_HOST=0.134, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_BAYES_5x7=0.6, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2dQy8kDPbVD; Tue, 27 May 2008 01:47:50 -0700 (PDT) Received: from LPuteaux-151-42-40-146.w193-251.abo.wanadoo.fr (LPuteaux-151-42-40-146.w193-251.abo.wanadoo.fr [193.251.191.146]) by core3.amsl.com (Postfix) with SMTP id 6F14728C218; Tue, 27 May 2008 01:46:35 -0700 (PDT) X-Originating-IP: 112.96.12.238 by smtp.193.251.191.146; Tue, 27 May 2008 04:46:50 -0500 Message-ID: From: "Jonah Mcgee" Reply-To: "Jonah Mcgee" To: atompub-archive@megatron.ietf.org Subject: Why get an original watch? Date: Tue, 27 May 2008 04:46:50 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is a one of a kind store: the online place where you can find the highest quality replica watches at the best prices in the world! Forget about flying to China to get a mockup Cartier watch... You can now get European quality Cartier replicas at deeply discounted prices at Prestige Replicas! The best part is that our watches are so finely crafted that even the most experienced connoisseur would have a hard time telling our watches from the real deal. http://www%2Ebybyusse%2Ecom/ Visit Prestige Replicas today and discover a wide range of top quality Cartier replica watches offered at unbelievable prices, with a 15% discount when you buy two! http://www%2Ebybyusse%2Ecom/ From ospf-bounces@ietf.org Wed May 28 05:18:57 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9D93A6863; Wed, 28 May 2008 05:18:57 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7E263A6863 for ; Wed, 28 May 2008 05:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VG5vdf60TkRc for ; Wed, 28 May 2008 05:18:54 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 655923A681C for ; Wed, 28 May 2008 05:18:54 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Wed, 28 May 2008 05:14:30 PDT Received: from gaugeboson.jnpr.net ([10.209.194.17]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 May 2008 05:18:20 -0700 Received: from emailbng2.jnpr.net ([10.209.194.16]) by gaugeboson.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 May 2008 17:48:15 +0530 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 17:48:15 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What is the use of MTU field in DD packet Thread-Index: AciWYqp9wv/wSnfFSEKR4douJXLx0gqWFvIg References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> From: "Prasanna Kumar A.S" To: "OSPF List" X-OriginalArrivalTime: 28 May 2008 12:18:15.0554 (UTC) FILETIME=[E7CEE620:01C8C0BC] Subject: [OSPF] What is the use of MTU field in DD packet X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi I just wanted to understand what the primary use of exchanging MTU in DD packets and doing MTU-check is? Is it only for the control plane or is it for the DATA-plane? Why I am getting this doubt is, in draft-ietf-ospf-af-alt-06.txt doesn't specify which MTU we should use while exchanging the DD packet for the ipv4-unicast or ipv4-mutlticast Address-family, is it ipv6-mtu or ipv4-mtu? Regards Prasanna _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed May 28 05:24:22 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D9063A6929; Wed, 28 May 2008 05:24:22 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D490B3A6929 for ; Wed, 28 May 2008 05:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgLxay6dHNhP for ; Wed, 28 May 2008 05:24:18 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id F16143A67C0 for ; Wed, 28 May 2008 05:24:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id AA2AF6014D1; Wed, 28 May 2008 05:24:22 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13281-02; Wed, 28 May 2008 05:24:22 -0700 (PDT) Received: from [JC???n?IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id DC62941F65F; Wed, 28 May 2008 05:24:08 -0700 (PDT) In-Reply-To: References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Acee Lindem Date: Wed, 28 May 2008 08:24:07 -0400 To: "Prasanna Kumar A.S" X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List Subject: Re: [OSPF] What is the use of MTU field in DD packet X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Prasanna, On May 28, 2008, at 8:18 AM, Prasanna Kumar A.S wrote: > Hi > I just wanted to understand what the primary use of exchanging > MTU in > DD packets and doing MTU-check is? Is it only for the control plane or > is it for the DATA-plane? Control-plane - when sending DD, LSR, and LSU packets, OSPF will attempt to send as many LSA headers or complete LSAs as will fit in a maximum sized packet. > > Why I am getting this doubt is, in draft-ietf-ospf-af-alt-06.txt > doesn't > specify which MTU we should use while exchanging the DD packet for the > ipv4-unicast or ipv4-mutlticast Address-family, is it ipv6-mtu or > ipv4-mtu? We have this clarified in the an update which we post soon. Since this is OSPFv3 which using IPv6 for transport, you always use the IPv6 MTU. Thanks, Acee > > > Regards > Prasanna > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From steckelberg@gallatinriver.net Wed May 28 06:33:46 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 753C93A6AD6 for ; Wed, 28 May 2008 06:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.43 X-Spam-Level: ** X-Spam-Status: No, score=2.43 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_93=0.6, LOTTERY_PH_004470=2.015] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9B4KQbYok0Sr for ; Wed, 28 May 2008 06:33:45 -0700 (PDT) Received: from thorin.grics.net (thorin.grics.net [64.40.95.86]) by core3.amsl.com (Postfix) with ESMTP id A29383A6AD5 for ; Wed, 28 May 2008 06:33:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thorin.grics.net (Postfix) with ESMTP id A2AD727AFD; Wed, 28 May 2008 08:33:11 -0500 (CDT) X-Virus-Scanned: amavisd-new at grics.net Received: from thorin.grics.net ([127.0.0.1]) by localhost (mail1.grics.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGNN-2SrNq9v; Wed, 28 May 2008 08:33:05 -0500 (CDT) Received: from localhost (bofur.grics.net [64.40.95.91]) by thorin.grics.net (Postfix) with ESMTP id 9A62827A98; Wed, 28 May 2008 08:32:51 -0500 (CDT) Received: from 10.0.0.63 (10.0.0.63 [10.0.0.63]) by webmail.grics.net (Horde MIME library) with HTTP; Wed, 28 May 2008 08:32:18 -0500 Message-ID: <20080528083218.kghran5340w4oo8o@webmail.grics.net> Date: Wed, 28 May 2008 08:32:18 -0500 From: steckelberg@gallatinriver.net To: undisclosed-recipients:; Subject: REF:UKL/74A0802742006 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) Ticket N=BA: 22-1356-4096-988 Serial N=BA: A069-07 Lucky N=BA: 12-13-21-26-32-39 Bonus-17 File REF N=BA.: UKL/74-A0802742006 BATCH N=BA.: 2006UKL-01 You won the sum of =A3891,934.00 GBP & Car, from our monthly UKNational Lottery Promotion,you are hereby adviced to get back to us, to claim your prize. Contact MR.Brain Johnson Email: mrbrawnjohnson@live.com Claims Requirements: 1.full name: 2.Home Address: 3.Age: 4.Occupation: 5.Sex: 6.Phone Number: 7.Nationality 8.Country Of Residence. MR.Brain Johnson. Tell:+44-70457-13755 Tell:+44-70240-94597 Tell::+44-70240-94349 Claim Manager From steckelberg@gallatinriver.net Wed May 28 06:39:30 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACD723A6AD6 for ; Wed, 28 May 2008 06:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.43 X-Spam-Level: ** X-Spam-Status: No, score=2.43 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_93=0.6, LOTTERY_PH_004470=2.015] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7i-cGBjPFWY for ; Wed, 28 May 2008 06:39:30 -0700 (PDT) Received: from mail3.grics.net (mail3.grics.net [64.40.95.92]) by core3.amsl.com (Postfix) with ESMTP id 1C7133A686A for ; Wed, 28 May 2008 06:39:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail3.grics.net (Postfix) with ESMTP id 19B8811E620; Wed, 28 May 2008 08:39:21 -0500 (CDT) X-Virus-Scanned: amavisd-new at grics.net Received: from mail3.grics.net ([127.0.0.1]) by localhost (mail1.grics.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UY0l7OrrD3bo; Wed, 28 May 2008 08:39:15 -0500 (CDT) Received: from localhost (bofur.grics.net [64.40.95.91]) by mail3.grics.net (Postfix) with ESMTP id 12A8F11E5FA; Wed, 28 May 2008 08:37:50 -0500 (CDT) Received: from 10.0.0.63 (10.0.0.63 [10.0.0.63]) by webmail.grics.net (Horde MIME library) with HTTP; Wed, 28 May 2008 08:36:45 -0500 Message-ID: <20080528083645.0o1o8dijacg80o0c@webmail.grics.net> Date: Wed, 28 May 2008 08:36:45 -0500 From: steckelberg@gallatinriver.net To: undisclosed-recipients:; Subject: REF:UKL/74A0802742006 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) Ticket N=BA: 22-1356-4096-988 Serial N=BA: A069-07 Lucky N=BA: 12-13-21-26-32-39 Bonus-17 File REF N=BA.: UKL/74-A0802742006 BATCH N=BA.: 2006UKL-01 You won the sum of =A3891,934.00 GBP & Car, from our monthly UKNational Lottery Promotion,you are hereby adviced to get back to us, to claim your prize. Contact MR.Brain Johnson Email: mrbrawnjohnson@live.com Claims Requirements: 1.full name: 2.Home Address: 3.Age: 4.Occupation: 5.Sex: 6.Phone Number: 7.Nationality 8.Country Of Residence. MR.Brain Johnson. Tell:+44-70457-13755 Tell:+44-70240-94597 Tell::+44-70240-94349 Claim Manager From steckelberg@gallatinriver.net Wed May 28 06:43:41 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE67E28C11C for ; Wed, 28 May 2008 06:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.43 X-Spam-Level: ** X-Spam-Status: No, score=2.43 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_93=0.6, LOTTERY_PH_004470=2.015] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyJPBFEPrC5c for ; Wed, 28 May 2008 06:43:41 -0700 (PDT) Received: from mail3.grics.net (mail3.grics.net [64.40.95.92]) by core3.amsl.com (Postfix) with ESMTP id 8AB6928C113 for ; Wed, 28 May 2008 06:43:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail3.grics.net (Postfix) with ESMTP id 7961711E571; Wed, 28 May 2008 08:43:49 -0500 (CDT) X-Virus-Scanned: amavisd-new at grics.net Received: from mail3.grics.net ([127.0.0.1]) by localhost (mail1.grics.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANrb4wP93kcM; Wed, 28 May 2008 08:43:46 -0500 (CDT) Received: from localhost (bofur.grics.net [64.40.95.91]) by mail3.grics.net (Postfix) with ESMTP id C060A11D412; Wed, 28 May 2008 08:43:20 -0500 (CDT) Received: from 10.0.0.63 (10.0.0.63 [10.0.0.63]) by webmail.grics.net (Horde MIME library) with HTTP; Wed, 28 May 2008 08:41:52 -0500 Message-ID: <20080528084152.h6alzolce84ccw0o@webmail.grics.net> Date: Wed, 28 May 2008 08:41:52 -0500 From: steckelberg@gallatinriver.net To: undisclosed-recipients:; Subject: REF:UKL/74A0802742006 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) Ticket N=BA: 22-1356-4096-988 Serial N=BA: A069-07 Lucky N=BA: 12-13-21-26-32-39 Bonus-17 File REF N=BA.: UKL/74-A0802742006 BATCH N=BA.: 2006UKL-01 You won the sum of =A3891,934.00 GBP & Car, from our monthly UKNational Lottery Promotion,you are hereby adviced to get back to us, to claim your prize. Contact MR.Brain Johnson Email: mrbrawnjohnson@live.com Claims Requirements: 1.full name: 2.Home Address: 3.Age: 4.Occupation: 5.Sex: 6.Phone Number: 7.Nationality 8.Country Of Residence. MR.Brain Johnson. Tell:+44-70457-13755 Tell:+44-70240-94597 Tell::+44-70240-94349 Claim Manager From ospf-bounces@ietf.org Wed May 28 11:04:59 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E3D33A6B88; Wed, 28 May 2008 11:04:59 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D51C028C0DE for ; Wed, 28 May 2008 11:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqT1BZ4jM7Qj for ; Wed, 28 May 2008 11:04:55 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B87833A6A6D for ; Wed, 28 May 2008 11:04:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,556,1204531200"; d="scan'208";a="36687752" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 28 May 2008 11:05:04 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4SI54q9031255; Wed, 28 May 2008 11:05:04 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4SI54SG004490; Wed, 28 May 2008 18:05:04 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 May 2008 11:05:04 -0700 Received: from pauwells-linux.cisco.com ([10.19.20.100]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 May 2008 11:05:03 -0700 Message-ID: <483D9ECE.5080300@cisco.com> Date: Wed, 28 May 2008 13:05:02 -0500 From: Paul Wells User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Acee Lindem References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> In-Reply-To: X-OriginalArrivalTime: 28 May 2008 18:05:03.0873 (UTC) FILETIME=[5A886710:01C8C0ED] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1909; t=1211997904; x=1212861904; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pauwells@cisco.com; z=From:=20Paul=20Wells=20 |Subject:=20Re=3A=20[OSPF]=20What=20is=20the=20use=20of=20M TU=20field=20in=20DD=20packet |Sender:=20; bh=fQjY8gJP/Q0CWJww7ur62a8dqmntLx+vIdA4LVP6SiI=; b=zXjLv3M/DgqSLQisKSyjWdIozjODAuBY9EoINZfSqk8OSVmCK1bsdze2jU jEMmj/s+XI1fBfglI79ZF8WSwC6zSuRbli8nsVED/VM5k2jRIzcyyPjyUszd UnzmEMUT5u; Authentication-Results: sj-dkim-2; header.From=pauwells@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: OSPF List Subject: Re: [OSPF] What is the use of MTU field in DD packet X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Acee, I disagree about the "original intent" of the MTU field. As I see it, it's function is to prevent an OSPF adjacency from forming over a link where the endpoints disagree about the link MTU. We do this primarily to prevent the data plane from using a link that will drop packets sent to a system with an MTU smaller than ours. While OSPFv3 certainly needs to know the IPv6 link MTU when building it's packets, this information should be available locally without reference to the MTU field in the DBD packet. So, I would argue that in af-alt the MTU in the DBD packet should be for the address family we are routing, not IPv6 in all cases. Regards, Paul Acee Lindem wrote: > Hi Prasanna, > > On May 28, 2008, at 8:18 AM, Prasanna Kumar A.S wrote: > >> Hi >> I just wanted to understand what the primary use of exchanging >> MTU in >> DD packets and doing MTU-check is? Is it only for the control plane or >> is it for the DATA-plane? > > Control-plane - when sending DD, LSR, and LSU packets, OSPF will > attempt to send as many LSA headers or complete LSAs as will fit in a > maximum sized packet. > > >> Why I am getting this doubt is, in draft-ietf-ospf-af-alt-06.txt >> doesn't >> specify which MTU we should use while exchanging the DD packet for the >> ipv4-unicast or ipv4-mutlticast Address-family, is it ipv6-mtu or >> ipv4-mtu? > > We have this clarified in the an update which we post soon. Since > this is OSPFv3 which using IPv6 for transport, you always use the > IPv6 MTU. > > Thanks, > Acee > > >> >> Regards >> Prasanna >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed May 28 11:51:59 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB0723A6AEA; Wed, 28 May 2008 11:51:58 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4533A6A38 for ; Wed, 28 May 2008 11:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyEYWSMkss5L for ; Wed, 28 May 2008 11:51:56 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 5F5B528C180 for ; Wed, 28 May 2008 11:51:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 6671E16AB4D; Wed, 28 May 2008 11:51:47 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19661-10; Wed, 28 May 2008 11:51:47 -0700 (PDT) Received: from [JC???n?IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 4B0BD16AB4F; Wed, 28 May 2008 11:51:45 -0700 (PDT) In-Reply-To: <483D9ECE.5080300@cisco.com> References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> <483D9ECE.5080300@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Acee Lindem Date: Wed, 28 May 2008 14:51:43 -0400 To: Paul Wells X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List Subject: Re: [OSPF] What is the use of MTU field in DD packet X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1539194423==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============1539194423== Content-Type: multipart/alternative; boundary=Apple-Mail-32--382213557 --Apple-Mail-32--382213557 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Paul, On May 28, 2008, at 2:05 PM, Paul Wells wrote: > Hi Acee, > > I disagree about the "original intent" of the MTU field. As I see > it, it's function is to prevent an OSPF adjacency from forming over > a link where the endpoints disagree about the link MTU. We do this > primarily to prevent the data plane from using a link that will > drop packets sent to a system with an MTU smaller than ours. I happen to remember the discussion of this problem on the OSPF list and this was not the primary motivation. There were lots of problems with bridged heterogeneous LANs with mismatched MTUs (ethernet, FDDI, token ring, and the worst of all technologies - ATM emulated LANs :^). Adjacencies would come up fine initially but the exchange process would hang indefinitely when they were restarted due to the router with the larger MTU having a larger database and trying to use full DD packets. Unfortunately, the OSPF list was hosted on a server at Microsoft Corporation in those days and I don't have access to archives. Here is some text from RFC 2178, appendix G: G.9 Detecting interface MTU mismatches When two neighboring routers have a different interface MTU for their common network segment, serious problems can ensue: large packets are prevented from being successfully transferred from one router to the other, impairing OSPF's flooding algorithm and possibly creating "black holes" for user data traffic. This memo provides a fix for the interface MTU mismatch problem by advertising the interface MTU in Database Description packets. When a router receives a Database description packet advertising an MTU larger than the router can receive, the router drops the Database Description packet. This prevents an adjacency from forming, telling OSPF flooding and user data traffic to avoid the connection between the two routers. For more information, see Sections 10.6, 10.8, and A.3.3. On the other hand, once the MTU checking was implemented, I believe data plane MTU consistency has been purported as a benefit. If we used the IPv4 MTU in the IPv4 address database exchanges, we could still have an IPv6 MTU mismatch. One could depend on the unicast IPv6 address family for this checking but, heretofore, we've kept the instances independent. Thanks, Acee > > While OSPFv3 certainly needs to know the IPv6 link MTU when > building it's packets, this information should be available locally > without reference to the MTU field in the DBD packet. > > So, I would argue that in af-alt the MTU in the DBD packet should > be for the address family we are routing, not IPv6 in all cases. > > Regards, > Paul > > Acee Lindem wrote: >> Hi Prasanna, >> On May 28, 2008, at 8:18 AM, Prasanna Kumar A.S wrote: >>> Hi >>> I just wanted to understand what the primary use of exchanging >>> MTU in >>> DD packets and doing MTU-check is? Is it only for the control >>> plane or >>> is it for the DATA-plane? >> Control-plane - when sending DD, LSR, and LSU packets, OSPF will >> attempt to send as many LSA headers or complete LSAs as will fit >> in a maximum sized packet. >>> Why I am getting this doubt is, in draft-ietf-ospf-af-alt-06.txt >>> doesn't >>> specify which MTU we should use while exchanging the DD packet >>> for the >>> ipv4-unicast or ipv4-mutlticast Address-family, is it ipv6-mtu or >>> ipv4-mtu? >> We have this clarified in the an update which we post soon. Since >> this is OSPFv3 which using IPv6 for transport, you always use the >> IPv6 MTU. >> Thanks, >> Acee >>> >>> Regards >>> Prasanna >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-32--382213557 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Paul,

On May 28, 2008, at 2:05 PM, = Paul Wells wrote:

Hi Acee,

I = disagree about the "original intent" of the MTU field. As I see it, it's = function is to prevent an OSPF adjacency from forming over a link where = the endpoints disagree about the link MTU. We do this primarily to = prevent the data plane from using a link that will drop packets sent to = a system with an MTU smaller than = ours.

I happen to remember the = discussion of this problem on the OSPF list and this was not the primary = motivation. There were lots of problems with bridged heterogeneous LANs = with mismatched MTUs (ethernet, FDDI, token ring, and the worst of all = technologies - ATM emulated LANs :^). =A0Adjacencies would come up fine = initially but the exchange process would hang indefinitely when they = were restarted due to the router with the larger MTU having a larger = database and trying to use full DD packets. Unfortunately, the OSPF list = was hosted on a server at Microsoft Corporation in those days and I = don't have access to archives. Here is some text from RFC 2178, appendix = G:=A0

G.9 = Detecting interface MTU mismatches
=A0=A0 When two neighboring = routers have a different interface MTU for their
=A0=A0 common network segment, serious problems can = ensue: large packets are
=A0=A0 = prevented from being successfully transferred from one router to = the
=A0=A0 other, impairing = OSPF's flooding algorithm and possibly creating
=A0=A0 "black holes" for user data = traffic.

=A0=A0 This memo provides a fix for the interface MTU = mismatch problem by
=A0=A0 = advertising the interface MTU in Database Description packets. When = a
=A0=A0 router receives a = Database description packet advertising an MTU
=A0=A0 larger than the router can receive, the router = drops the Database
=A0=A0 = Description packet. This prevents an adjacency from forming, = telling
=A0=A0 OSPF flooding and = user data traffic to avoid the connection between
=A0=A0 the two routers. For more information, see = Sections 10.6, 10.8, and
=A0=A0 = A.3.3.

On the other hand, once = the MTU checking was implemented, I believe data plane MTU consistency = has been purported as a benefit. If we used the IPv4 MTU in the IPv4 = address database exchanges, we could still have an IPv6 MTU mismatch. = One could depend on the unicast IPv6 address family for this checking = but, heretofore, we've kept the instances = independent.=A0

Thanks,
Acee
=


While OSPFv3 certainly needs to = know the IPv6 link MTU when building it's packets, this information = should be available locally without reference to the MTU field in the = DBD packet.

So, I would argue that in af-alt the MTU in the DBD = packet should be for the address family we are routing, not IPv6 in all = cases.

Regards,

Acee Lindem wrote:
Hi Prasanna,
On May 28, 2008, at 8:18 AM, Prasanna Kumar A.S = wrote:
Hi
=A0 I = just wanted to understand what the primary use of exchanging=A0 MTU in
DD packets and doing MTU-check is? Is it only for = the control plane or
is it for the = DATA-plane?
Control-plane = - when sending DD, LSR, and LSU packets, OSPF will=A0 attempt to send as many LSA = headers or complete LSAs as will fit in a=A0 maximum sized packet.
=
Why I am getting this doubt = is, in draft-ietf-ospf-af-alt-06.txt=A0 doesn't
specify which MTU we should use while exchanging the = DD packet for the
ipv4-unicast or ipv4-mutlticast = Address-family, is it ipv6-mtu or
We have this = clarified in the an update which we post soon. Since=A0 this is OSPFv3 which using = IPv6 for transport, you always use the=A0 IPv6 MTU.
Thanks,
Acee
=
Regards
Prasanna
OSPF mailing list
OSPF mailing list
=

= --Apple-Mail-32--382213557-- --===============1539194423== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --===============1539194423==-- From ospf-bounces@ietf.org Wed May 28 14:31:23 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49BDF3A6A92; Wed, 28 May 2008 14:31:23 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19D383A6A92 for ; Wed, 28 May 2008 14:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQMKwG73y3+Y for ; Wed, 28 May 2008 14:31:20 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E108E3A6835 for ; Wed, 28 May 2008 14:31:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,557,1204531200"; d="scan'208";a="36778484" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 28 May 2008 14:31:30 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4SLVUPA013640; Wed, 28 May 2008 14:31:30 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m4SLVUqK029842; Wed, 28 May 2008 21:31:30 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 May 2008 14:31:28 -0700 Received: from pauwells-linux.cisco.com ([10.19.20.100]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 May 2008 14:31:28 -0700 Message-ID: <483DCF2F.2040801@cisco.com> Date: Wed, 28 May 2008 16:31:27 -0500 From: Paul Wells User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Acee Lindem References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> <483D9ECE.5080300@cisco.com> In-Reply-To: X-OriginalArrivalTime: 28 May 2008 21:31:28.0567 (UTC) FILETIME=[3062BC70:01C8C10A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5365; t=1212010290; x=1212874290; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pauwells@cisco.com; z=From:=20Paul=20Wells=20 |Subject:=20Re=3A=20[OSPF]=20What=20is=20the=20use=20of=20M TU=20field=20in=20DD=20packet |Sender:=20; bh=XWgDhgWmH5m/TnmXOeqSLYB+phioMyA2sbtBT1SdA9w=; b=fb7rv63pEnEqS7ei9n0M8LLbPOnLzTHy31ZsIj5fq67Csnmi1Kj8/Eh89j jDeSYr47BDdZei97yIK8R/yn9awnKM15W614qbZWPfSvx9qF1MyIlasv2mQx IZv1xFFnsx; Authentication-Results: sj-dkim-2; header.From=pauwells@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: OSPF List Subject: Re: [OSPF] What is the use of MTU field in DD packet X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Acee, That was before my time, so I'll defer to your recollection about how OSPF MTU checking came to be. The section of 2178 below does seem to give equal weight to both the control and data plane benefits of MTU verification however. This still leaves the question of what to do for af-alt when routing address families other than IPv6. It seems that there are two cases of interest in deciding which MTU to advertise in the DBD packets: 1. IPv6 MTUs match, but IPv4 MTUs differ. 2. IPv6 MTUs differ, but IPv4 MTUs match. In the first case I don't think we're doing anyone a favor by installing routes in the IPv4 RIB that will be unreliable due to a MTU mismatch. In the second case OSPFv3 flooding and synchronization may be compromised. A side effect of this may be that the adjacency never forms, or having formed may later fail. Short of resorting to LLS or some other way of communicating both MTUs it seems we have to pick one or the other. I'd like to propose that we use the DBD packet to communicate the IPv4 MTU when routing that address family, and use the IPv6 minimum MTU of 1280 bytes for OSPFv3 protocol packets. Thanks, Paul Acee Lindem wrote: > Hi Paul, > > On May 28, 2008, at 2:05 PM, Paul Wells wrote: > >> Hi Acee, >> >> I disagree about the "original intent" of the MTU field. As I see it, >> it's function is to prevent an OSPF adjacency from forming over a link >> where the endpoints disagree about the link MTU. We do this primarily >> to prevent the data plane from using a link that will drop packets >> sent to a system with an MTU smaller than ours. > > I happen to remember the discussion of this problem on the OSPF list and > this was not the primary motivation. There were lots of problems with > bridged heterogeneous LANs with mismatched MTUs (ethernet, FDDI, token > ring, and the worst of all technologies - ATM emulated LANs :^). > Adjacencies would come up fine initially but the exchange process would > hang indefinitely when they were restarted due to the router with the > larger MTU having a larger database and trying to use full DD packets. > Unfortunately, the OSPF list was hosted on a server at Microsoft > Corporation in those days and I don't have access to archives. Here is > some text from RFC 2178, appendix G: > > G.9 Detecting interface MTU mismatches > > When two neighboring routers have a different interface MTU for their > common network segment, serious problems can ensue: large packets are > prevented from being successfully transferred from one router to the > other, impairing OSPF's flooding algorithm and possibly creating > "black holes" for user data traffic. > > This memo provides a fix for the interface MTU mismatch problem by > advertising the interface MTU in Database Description packets. When a > router receives a Database description packet advertising an MTU > larger than the router can receive, the router drops the Database > Description packet. This prevents an adjacency from forming, telling > OSPF flooding and user data traffic to avoid the connection between > the two routers. For more information, see Sections 10.6, 10.8, and > A.3.3. > > On the other hand, once the MTU checking was implemented, I believe data > plane MTU consistency has been purported as a benefit. If we used the > IPv4 MTU in the IPv4 address database exchanges, we could still have an > IPv6 MTU mismatch. One could depend on the unicast IPv6 address family > for this checking but, heretofore, we've kept the instances independent. > > Thanks, > Acee > > >> >> While OSPFv3 certainly needs to know the IPv6 link MTU when building >> it's packets, this information should be available locally without >> reference to the MTU field in the DBD packet. >> >> So, I would argue that in af-alt the MTU in the DBD packet should be >> for the address family we are routing, not IPv6 in all cases. >> >> Regards, >> Paul >> >> Acee Lindem wrote: >>> Hi Prasanna, >>> On May 28, 2008, at 8:18 AM, Prasanna Kumar A.S wrote: >>>> Hi >>>> I just wanted to understand what the primary use of exchanging MTU in >>>> DD packets and doing MTU-check is? Is it only for the control plane or >>>> is it for the DATA-plane? >>> Control-plane - when sending DD, LSR, and LSU packets, OSPF will >>> attempt to send as many LSA headers or complete LSAs as will fit in >>> a maximum sized packet. >>>> Why I am getting this doubt is, in draft-ietf-ospf-af-alt-06.txt >>>> doesn't >>>> specify which MTU we should use while exchanging the DD packet for the >>>> ipv4-unicast or ipv4-mutlticast Address-family, is it ipv6-mtu or >>>> ipv4-mtu? >>> We have this clarified in the an update which we post soon. Since >>> this is OSPFv3 which using IPv6 for transport, you always use the >>> IPv6 MTU. >>> Thanks, >>> Acee >>>> >>>> Regards >>>> Prasanna >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed May 28 15:22:26 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8343A3A6B15; Wed, 28 May 2008 15:22:26 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95E803A6B15 for ; Wed, 28 May 2008 15:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ineZkZJfheWG for ; Wed, 28 May 2008 15:22:19 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id D69743A6A63 for ; Wed, 28 May 2008 15:22:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 5D8DC15ED2B; Wed, 28 May 2008 15:22:29 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28791-05; Wed, 28 May 2008 15:22:29 -0700 (PDT) Received: from [JC???n?IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id B942C15ED27; Wed, 28 May 2008 15:22:28 -0700 (PDT) In-Reply-To: <483DCF2F.2040801@cisco.com> References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> <483D9ECE.5080300@cisco.com> <483DCF2F.2040801@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Acee Lindem Date: Wed, 28 May 2008 18:22:28 -0400 To: Paul Wells X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List Subject: Re: [OSPF] What is the use of MTU field in DD packet X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Paul, On May 28, 2008, at 5:31 PM, Paul Wells wrote: > Hi Acee, > > That was before my time, so I'll defer to your recollection about > how OSPF MTU checking came to be. The section of 2178 below does > seem to give equal weight to both the control and data plane > benefits of MTU verification however. Hey - wouldn't you take credit? It beats the hell out of padding your hello packets to the maximum transmission unit (MTU) :^) > > This still leaves the question of what to do for af-alt when > routing address families other than IPv6. It seems that there are > two cases of interest in deciding which MTU to advertise in the DBD > packets: > > 1. IPv6 MTUs match, but IPv4 MTUs differ. > 2. IPv6 MTUs differ, but IPv4 MTUs match. > > In the first case I don't think we're doing anyone a favor by > installing routes in the IPv4 RIB that will be unreliable due to a > MTU mismatch. > > In the second case OSPFv3 flooding and synchronization may be > compromised. A side effect of this may be that the adjacency never > forms, or having formed may later fail. > > Short of resorting to LLS or some other way of communicating both > MTUs it seems we have to pick one or the other. > > I'd like to propose that we use the DBD packet to communicate the > IPv4 MTU when routing that address family, and use the IPv6 minimum > MTU of 1280 bytes for OSPFv3 protocol packets. This is a coherent proposal. I'd like to bounce this off the other authors and would solicit general comments. The question is whether the OSPFv3 protocol checking for MTU mismatches is worth relegated OSPFv3 exchange and flooding to the the IPv6 minimum MTU. I'm not sure it does but I'd like to open it up to a brief discussion. Thanks, Acee > > Thanks, > Paul > > Acee Lindem wrote: >> Hi Paul, >> On May 28, 2008, at 2:05 PM, Paul Wells wrote: >>> Hi Acee, >>> >>> I disagree about the "original intent" of the MTU field. As I see >>> it, it's function is to prevent an OSPF adjacency from forming >>> over a link where the endpoints disagree about the link MTU. We >>> do this primarily to prevent the data plane from using a link >>> that will drop packets sent to a system with an MTU smaller than >>> ours. >> I happen to remember the discussion of this problem on the OSPF >> list and this was not the primary motivation. There were lots of >> problems with bridged heterogeneous LANs with mismatched MTUs >> (ethernet, FDDI, token ring, and the worst of all technologies - >> ATM emulated LANs :^). Adjacencies would come up fine initially >> but the exchange process would hang indefinitely when they were >> restarted due to the router with the larger MTU having a larger >> database and trying to use full DD packets. Unfortunately, the >> OSPF list was hosted on a server at Microsoft Corporation in those >> days and I don't have access to archives. Here is some text from >> RFC 2178, appendix G: G.9 Detecting interface MTU mismatches >> When two neighboring routers have a different interface MTU for >> their >> common network segment, serious problems can ensue: large >> packets are >> prevented from being successfully transferred from one router >> to the >> other, impairing OSPF's flooding algorithm and possibly creating >> "black holes" for user data traffic. >> This memo provides a fix for the interface MTU mismatch problem by >> advertising the interface MTU in Database Description packets. >> When a >> router receives a Database description packet advertising an MTU >> larger than the router can receive, the router drops the Database >> Description packet. This prevents an adjacency from forming, >> telling >> OSPF flooding and user data traffic to avoid the connection >> between >> the two routers. For more information, see Sections 10.6, 10.8, >> and >> A.3.3. >> On the other hand, once the MTU checking was implemented, I >> believe data plane MTU consistency has been purported as a >> benefit. If we used the IPv4 MTU in the IPv4 address database >> exchanges, we could still have an IPv6 MTU mismatch. One could >> depend on the unicast IPv6 address family for this checking but, >> heretofore, we've kept the instances independent. Thanks, >> Acee >>> >>> While OSPFv3 certainly needs to know the IPv6 link MTU when >>> building it's packets, this information should be available >>> locally without reference to the MTU field in the DBD packet. >>> >>> So, I would argue that in af-alt the MTU in the DBD packet should >>> be for the address family we are routing, not IPv6 in all cases. >>> >>> Regards, >>> Paul >>> >>> Acee Lindem wrote: >>>> Hi Prasanna, >>>> On May 28, 2008, at 8:18 AM, Prasanna Kumar A.S wrote: >>>>> Hi >>>>> I just wanted to understand what the primary use of >>>>> exchanging MTU in >>>>> DD packets and doing MTU-check is? Is it only for the control >>>>> plane or >>>>> is it for the DATA-plane? >>>> Control-plane - when sending DD, LSR, and LSU packets, OSPF >>>> will attempt to send as many LSA headers or complete LSAs as >>>> will fit in a maximum sized packet. >>>>> Why I am getting this doubt is, in draft-ietf-ospf-af- >>>>> alt-06.txt doesn't >>>>> specify which MTU we should use while exchanging the DD packet >>>>> for the >>>>> ipv4-unicast or ipv4-mutlticast Address-family, is it ipv6-mtu or >>>>> ipv4-mtu? >>>> We have this clarified in the an update which we post soon. >>>> Since this is OSPFv3 which using IPv6 for transport, you always >>>> use the IPv6 MTU. >>>> Thanks, >>>> Acee >>>>> >>>>> Regards >>>>> Prasanna >>>>> _______________________________________________ >>>>> OSPF mailing list >>>>> OSPF@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ospf >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed May 28 16:17:12 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D802C28C19F; Wed, 28 May 2008 16:17:12 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CDDD28C1A8 for ; Wed, 28 May 2008 16:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQjZvQb+KJSw for ; Wed, 28 May 2008 16:17:10 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id E795C28C19F for ; Wed, 28 May 2008 16:17:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 89E36D6636B; Wed, 28 May 2008 16:17:19 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08122-09; Wed, 28 May 2008 16:17:19 -0700 (PDT) Received: from [?????n?IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id E5C04D6636C; Wed, 28 May 2008 16:17:18 -0700 (PDT) In-Reply-To: <20080528222059.GB2925@lxb401.van.redback.com> References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> <483D9ECE.5080300@cisco.com> <20080528222059.GB2925@lxb401.van.redback.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Acee Lindem Date: Wed, 28 May 2008 19:17:18 -0400 To: Michael Rozhavsky X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List Subject: Re: [OSPF] What is the use of MTU field in DD packet X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Michael, Nope - it was a pre-RFC 2178 thread involving Derek Yeung, John Moy, and others. Thanks, Acee On May 28, 2008, at 6:20 PM, Michael Rozhavsky wrote: > Hi Acee, > >> >> I happen to remember the discussion of this problem on the OSPF >> list and >> this was not the primary motivation. > > I believe this is the discussion you are referring to: > > http://marc.info/?l=ms-ospf&m=103430314528492&w=4 > >> There were lots of problems with >> bridged heterogeneous LANs with mismatched MTUs (ethernet, FDDI, >> token >> ring, and the worst of all technologies - ATM emulated LANs :^). >> Adjacencies would come up fine initially but the exchange process >> would >> hang indefinitely when they were restarted due to the router with the >> larger MTU having a larger database and trying to use full DD >> packets. >> Unfortunately, the OSPF list was hosted on a server at Microsoft >> Corporation in those days and I don't have access to archives. >> Here is some >> text from RFC 2178, appendix G: >> > > -- > Michael Rozhavsky _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed May 28 19:11:48 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAFE53A6CE5; Wed, 28 May 2008 19:11:48 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06C6A3A680B for ; Wed, 28 May 2008 19:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id At4YlOpeC4nQ for ; Wed, 28 May 2008 19:11:46 -0700 (PDT) Received: from nuova-ex1.nuovasystems.com (nuova-ex1.nuovasystems.com [67.91.200.196]) by core3.amsl.com (Postfix) with ESMTP id 5B31A3A6841 for ; Wed, 28 May 2008 19:11:46 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 19:11:55 -0700 Message-ID: <34BDD2A93E5FD84594BB230DD6C18EA2046DBEC5@nuova-ex1.hq.nuovaimpresa.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] What is the use of MTU field in DD packet Thread-Index: AcjBEVwy5Vdj3oeGRb2araOqzd9u0AAE5qjg References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> <483D9ECE.5080300@cisco.com><483DCF2F.2040801@cisco.com> From: "Sina Mirtorabi" To: "Acee Lindem" , "Paul Wells" Cc: OSPF List Subject: Re: [OSPF] What is the use of MTU field in DD packet X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Acee, > > This still leaves the question of what to do for af-alt when > > routing address families other than IPv6. It seems that there are > > two cases of interest in deciding which MTU to advertise in > the DBD > > packets: > > > > 1. IPv6 MTUs match, but IPv4 MTUs differ. > > 2. IPv6 MTUs differ, but IPv4 MTUs match. > > > > In the first case I don't think we're doing anyone a favor by > > installing routes in the IPv4 RIB that will be unreliable due to a > > MTU mismatch. > > > > In the second case OSPFv3 flooding and synchronization may be > > compromised. A side effect of this may be that the adjacency never > > forms, or having formed may later fail. > > > > Short of resorting to LLS or some other way of communicating both > > MTUs it seems we have to pick one or the other. > > > > I'd like to propose that we use the DBD packet to communicate the > > IPv4 MTU when routing that address family, and use the IPv6 > minimum > > MTU of 1280 bytes for OSPFv3 protocol packets. > > This is a coherent proposal. I'd like to bounce this off the other > authors and would solicit general comments. The question is whether > the OSPFv3 protocol checking for MTU mismatches is worth relegated > OSPFv3 exchange and flooding to the the IPv6 minimum MTU. I'm not > sure it does but I'd like to open it up to a brief discussion. One issue is backward compatibility, if there is any implementation of alt draft, then we cannot just change the MTU in the DD packet from IPv6 to IPv4 MTU. If we don't worry about backward compatibility (no deployed implementation) then we have a shot to define as appropriate. There are couple of options 1) Paul's proposal however I would add that IPv6 Path MTU discovery should be used. 2) We can set a bit in the DD packet to indicate that the MTU value is for both v4 and v6, if this bit is clear (i.e. MTU mismatch between v4 and v6) then the MTU field in DD packet is for corresponding AF, e.g. IPv4 and for IPv6 mtu we have to use 1) (minimum MTU), the advantage of this is that unless MTU is really different between v4 and v6 you don't blindly reduce the IPv6 mtu 3) carry the MTU value for both IPv6 and IPv4 either in DD packet (there are unused octet although not contiguous block) or through LLS. 4) any other options The advantage of 2) a part from simplicity is that by not knowing the IPv6 MTU we fall back to minimum MTU and adj will be formed, for 3) if there is a MTU mismatch then unless you change the rule and state that in case of mismatch, default minimum MTU should be used, the adj will not be established if we follow the MTU mismatch rule. The only advantage of the 3) compared to 2) is that in case IPv4 and IPv6 does not match AND IPv6 are the same between the system, the actual IPv6 MTU (which is carried) is used instead of Minimum MTU. thanks Sina > > Thanks, > Acee > > > > > > > Thanks, > > Paul > > > > Acee Lindem wrote: > >> Hi Paul, > >> On May 28, 2008, at 2:05 PM, Paul Wells wrote: > >>> Hi Acee, > >>> > >>> I disagree about the "original intent" of the MTU field. > As I see > >>> it, it's function is to prevent an OSPF adjacency from forming > >>> over a link where the endpoints disagree about the link MTU. We > >>> do this primarily to prevent the data plane from using a link > >>> that will drop packets sent to a system with an MTU smaller than > >>> ours. > >> I happen to remember the discussion of this problem on the OSPF > >> list and this was not the primary motivation. There were lots of > >> problems with bridged heterogeneous LANs with mismatched MTUs > >> (ethernet, FDDI, token ring, and the worst of all technologies - > >> ATM emulated LANs :^). Adjacencies would come up fine initially > >> but the exchange process would hang indefinitely when they were > >> restarted due to the router with the larger MTU having a larger > >> database and trying to use full DD packets. Unfortunately, the > >> OSPF list was hosted on a server at Microsoft Corporation > in those > >> days and I don't have access to archives. Here is some text from > >> RFC 2178, appendix G: G.9 Detecting interface MTU mismatches > >> When two neighboring routers have a different interface > MTU for > >> their > >> common network segment, serious problems can ensue: large > >> packets are > >> prevented from being successfully transferred from one router > >> to the > >> other, impairing OSPF's flooding algorithm and possibly creating > >> "black holes" for user data traffic. > >> This memo provides a fix for the interface MTU mismatch > problem by > >> advertising the interface MTU in Database Description packets. > >> When a > >> router receives a Database description packet advertising an MTU > >> larger than the router can receive, the router drops > the Database > >> Description packet. This prevents an adjacency from forming, > >> telling > >> OSPF flooding and user data traffic to avoid the connection > >> between > >> the two routers. For more information, see Sections > 10.6, 10.8, > >> and > >> A.3.3. > >> On the other hand, once the MTU checking was implemented, I > >> believe data plane MTU consistency has been purported as a > >> benefit. If we used the IPv4 MTU in the IPv4 address database > >> exchanges, we could still have an IPv6 MTU mismatch. One could > >> depend on the unicast IPv6 address family for this checking but, > >> heretofore, we've kept the instances independent. Thanks, > >> Acee > >>> > >>> While OSPFv3 certainly needs to know the IPv6 link MTU when > >>> building it's packets, this information should be available > >>> locally without reference to the MTU field in the DBD packet. > >>> > >>> So, I would argue that in af-alt the MTU in the DBD > packet should > >>> be for the address family we are routing, not IPv6 in all cases. > >>> > >>> Regards, > >>> Paul > >>> > >>> Acee Lindem wrote: > >>>> Hi Prasanna, > >>>> On May 28, 2008, at 8:18 AM, Prasanna Kumar A.S wrote: > >>>>> Hi > >>>>> I just wanted to understand what the primary use of > >>>>> exchanging MTU in > >>>>> DD packets and doing MTU-check is? Is it only for the control > >>>>> plane or > >>>>> is it for the DATA-plane? > >>>> Control-plane - when sending DD, LSR, and LSU packets, OSPF > >>>> will attempt to send as many LSA headers or complete LSAs as > >>>> will fit in a maximum sized packet. > >>>>> Why I am getting this doubt is, in draft-ietf-ospf-af- > >>>>> alt-06.txt doesn't > >>>>> specify which MTU we should use while exchanging the DD packet > >>>>> for the > >>>>> ipv4-unicast or ipv4-mutlticast Address-family, is it > ipv6-mtu or > >>>>> ipv4-mtu? > >>>> We have this clarified in the an update which we post soon. > >>>> Since this is OSPFv3 which using IPv6 for transport, > you always > >>>> use the IPv6 MTU. > >>>> Thanks, > >>>> Acee > >>>>> > >>>>> Regards > >>>>> Prasanna > >>>>> _______________________________________________ > >>>>> OSPF mailing list > >>>>> OSPF@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ospf > >>>> _______________________________________________ > >>>> OSPF mailing list > >>>> OSPF@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu May 29 00:04:27 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6CBE3A68A6; Thu, 29 May 2008 00:04:27 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD773A67E3 for ; Thu, 29 May 2008 00:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ds7teL-h1XgN for ; Thu, 29 May 2008 00:04:25 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id E56FD3A68A6 for ; Thu, 29 May 2008 00:04:24 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Thu, 29 May 2008 00:03:22 PDT Received: from gaugeboson.jnpr.net ([10.209.194.17]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 00:03:55 -0700 Received: from emailbng2.jnpr.net ([10.209.194.16]) by gaugeboson.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 12:33:50 +0530 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 May 2008 12:33:50 +0530 Message-ID: In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2046DBEC5@nuova-ex1.hq.nuovaimpresa.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] What is the use of MTU field in DD packet Thread-Index: AcjBEVwy5Vdj3oeGRb2araOqzd9u0AAE5qjgAAziCTA= References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> <483D9ECE.5080300@cisco.com><483DCF2F.2040801@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2046DBEC5@nuova-ex1.hq.nuovaimpresa.com> From: "Prasanna Kumar A.S" To: "Sina Mirtorabi" , "Acee Lindem" , "Paul Wells" X-OriginalArrivalTime: 29 May 2008 07:03:50.0859 (UTC) FILETIME=[25FCA1B0:01C8C15A] Cc: OSPF List Subject: Re: [OSPF] What is the use of MTU field in DD packet X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi I suggest following mechanism to communicate both the MTUs Initial DD packet should carry the MTU of Address-family which should match with the mtu of that address-family otherwise mtu check should fail, (I.e. if initial DD packet with AF bit set and matching MTU then MTU check should pass) and subsequent DD packets should carry the ipv6-MTU (ignore MTU check for non initial DD packet with Af bit set), And the ipv6 MTU of each neighbor should be saved in the neighbor data-structure, then smallest MTU of all the neighbors on the link is used for constructing the ospf-packets to be transmitted on that link Regards Prasanna -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Sina Mirtorabi Sent: Thursday, May 29, 2008 7:42 AM To: Acee Lindem; Paul Wells Cc: OSPF List Subject: Re: [OSPF] What is the use of MTU field in DD packet Hi Acee, > > This still leaves the question of what to do for af-alt when > > routing address families other than IPv6. It seems that there are > > two cases of interest in deciding which MTU to advertise in > the DBD > > packets: > > > > 1. IPv6 MTUs match, but IPv4 MTUs differ. > > 2. IPv6 MTUs differ, but IPv4 MTUs match. > > > > In the first case I don't think we're doing anyone a favor by > > installing routes in the IPv4 RIB that will be unreliable due to a > > MTU mismatch. > > > > In the second case OSPFv3 flooding and synchronization may be > > compromised. A side effect of this may be that the adjacency never > > forms, or having formed may later fail. > > > > Short of resorting to LLS or some other way of communicating both > > MTUs it seems we have to pick one or the other. > > > > I'd like to propose that we use the DBD packet to communicate the > > IPv4 MTU when routing that address family, and use the IPv6 > minimum > > MTU of 1280 bytes for OSPFv3 protocol packets. > > This is a coherent proposal. I'd like to bounce this off the other > authors and would solicit general comments. The question is whether > the OSPFv3 protocol checking for MTU mismatches is worth relegated > OSPFv3 exchange and flooding to the the IPv6 minimum MTU. I'm not > sure it does but I'd like to open it up to a brief discussion. One issue is backward compatibility, if there is any implementation of alt draft, then we cannot just change the MTU in the DD packet from IPv6 to IPv4 MTU. If we don't worry about backward compatibility (no deployed implementation) then we have a shot to define as appropriate. There are couple of options 1) Paul's proposal however I would add that IPv6 Path MTU discovery should be used. 2) We can set a bit in the DD packet to indicate that the MTU value is for both v4 and v6, if this bit is clear (i.e. MTU mismatch between v4 and v6) then the MTU field in DD packet is for corresponding AF, e.g. IPv4 and for IPv6 mtu we have to use 1) (minimum MTU), the advantage of this is that unless MTU is really different between v4 and v6 you don't blindly reduce the IPv6 mtu 3) carry the MTU value for both IPv6 and IPv4 either in DD packet (there are unused octet although not contiguous block) or through LLS. 4) any other options The advantage of 2) a part from simplicity is that by not knowing the IPv6 MTU we fall back to minimum MTU and adj will be formed, for 3) if there is a MTU mismatch then unless you change the rule and state that in case of mismatch, default minimum MTU should be used, the adj will not be established if we follow the MTU mismatch rule. The only advantage of the 3) compared to 2) is that in case IPv4 and IPv6 does not match AND IPv6 are the same between the system, the actual IPv6 MTU (which is carried) is used instead of Minimum MTU. thanks Sina > > Thanks, > Acee > > > > > > > Thanks, > > Paul > > > > Acee Lindem wrote: > >> Hi Paul, > >> On May 28, 2008, at 2:05 PM, Paul Wells wrote: > >>> Hi Acee, > >>> > >>> I disagree about the "original intent" of the MTU field. > As I see > >>> it, it's function is to prevent an OSPF adjacency from forming > >>> over a link where the endpoints disagree about the link MTU. We > >>> do this primarily to prevent the data plane from using a link > >>> that will drop packets sent to a system with an MTU smaller than > >>> ours. > >> I happen to remember the discussion of this problem on the OSPF > >> list and this was not the primary motivation. There were lots of > >> problems with bridged heterogeneous LANs with mismatched MTUs > >> (ethernet, FDDI, token ring, and the worst of all technologies - > >> ATM emulated LANs :^). Adjacencies would come up fine initially > >> but the exchange process would hang indefinitely when they were > >> restarted due to the router with the larger MTU having a larger > >> database and trying to use full DD packets. Unfortunately, the > >> OSPF list was hosted on a server at Microsoft Corporation > in those > >> days and I don't have access to archives. Here is some text from > >> RFC 2178, appendix G: G.9 Detecting interface MTU mismatches > >> When two neighboring routers have a different interface > MTU for > >> their > >> common network segment, serious problems can ensue: large > >> packets are > >> prevented from being successfully transferred from one router > >> to the > >> other, impairing OSPF's flooding algorithm and possibly creating > >> "black holes" for user data traffic. > >> This memo provides a fix for the interface MTU mismatch > problem by > >> advertising the interface MTU in Database Description packets. > >> When a > >> router receives a Database description packet advertising an MTU > >> larger than the router can receive, the router drops > the Database > >> Description packet. This prevents an adjacency from forming, > >> telling > >> OSPF flooding and user data traffic to avoid the connection > >> between > >> the two routers. For more information, see Sections > 10.6, 10.8, > >> and > >> A.3.3. > >> On the other hand, once the MTU checking was implemented, I > >> believe data plane MTU consistency has been purported as a > >> benefit. If we used the IPv4 MTU in the IPv4 address database > >> exchanges, we could still have an IPv6 MTU mismatch. One could > >> depend on the unicast IPv6 address family for this checking but, > >> heretofore, we've kept the instances independent. Thanks, > >> Acee > >>> > >>> While OSPFv3 certainly needs to know the IPv6 link MTU when > >>> building it's packets, this information should be available > >>> locally without reference to the MTU field in the DBD packet. > >>> > >>> So, I would argue that in af-alt the MTU in the DBD > packet should > >>> be for the address family we are routing, not IPv6 in all cases. > >>> > >>> Regards, > >>> Paul > >>> > >>> Acee Lindem wrote: > >>>> Hi Prasanna, > >>>> On May 28, 2008, at 8:18 AM, Prasanna Kumar A.S wrote: > >>>>> Hi > >>>>> I just wanted to understand what the primary use of > >>>>> exchanging MTU in > >>>>> DD packets and doing MTU-check is? Is it only for the control > >>>>> plane or > >>>>> is it for the DATA-plane? > >>>> Control-plane - when sending DD, LSR, and LSU packets, OSPF > >>>> will attempt to send as many LSA headers or complete LSAs as > >>>> will fit in a maximum sized packet. > >>>>> Why I am getting this doubt is, in draft-ietf-ospf-af- > >>>>> alt-06.txt doesn't > >>>>> specify which MTU we should use while exchanging the DD packet > >>>>> for the > >>>>> ipv4-unicast or ipv4-mutlticast Address-family, is it > ipv6-mtu or > >>>>> ipv4-mtu? > >>>> We have this clarified in the an update which we post soon. > >>>> Since this is OSPFv3 which using IPv6 for transport, > you always > >>>> use the IPv6 MTU. > >>>> Thanks, > >>>> Acee > >>>>> > >>>>> Regards > >>>>> Prasanna > >>>>> _______________________________________________ > >>>>> OSPF mailing list > >>>>> OSPF@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ospf > >>>> _______________________________________________ > >>>> OSPF mailing list > >>>> OSPF@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu May 29 01:44:16 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90AC13A696F; Thu, 29 May 2008 01:44:16 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307603A6963 for ; Thu, 29 May 2008 01:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSy5gAW5rkId for ; Thu, 29 May 2008 01:44:14 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id DC3A93A699B for ; Thu, 29 May 2008 01:44:13 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Thu, 29 May 2008 01:42:15 PDT Received: from gaugeboson.jnpr.net ([10.209.194.17]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 01:43:54 -0700 Received: from emailbng2.jnpr.net ([10.209.194.16]) by gaugeboson.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 14:13:13 +0530 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 May 2008 14:13:12 +0530 Message-ID: In-Reply-To: <483DCF2F.2040801@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] What is the use of MTU field in DD packet Thread-Index: AcjBCjsEgpw5pdijSwKx6B5zBg8RwgAXUE5Q References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> <483D9ECE.5080300@cisco.com> <483DCF2F.2040801@cisco.com> From: "Prasanna Kumar A.S" To: "Paul Wells" , "Acee Lindem" X-OriginalArrivalTime: 29 May 2008 08:43:13.0150 (UTC) FILETIME=[07CA09E0:01C8C168] Cc: OSPF List Subject: Re: [OSPF] What is the use of MTU field in DD packet X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org I second paul, What is the use of the routes learnt when we know forwarding is going to fail, And secondly the forwarding will fail selectively only for the large data-packets that makes the troubleshooting more difficult Regards Prasanna -----Original Message----- From: Paul Wells [mailto:pauwells@cisco.com] Sent: Thursday, May 29, 2008 3:01 AM To: Acee Lindem Cc: Prasanna Kumar A.S; OSPF List Subject: Re: [OSPF] What is the use of MTU field in DD packet Hi Acee, That was before my time, so I'll defer to your recollection about how OSPF MTU checking came to be. The section of 2178 below does seem to give equal weight to both the control and data plane benefits of MTU verification however. This still leaves the question of what to do for af-alt when routing address families other than IPv6. It seems that there are two cases of interest in deciding which MTU to advertise in the DBD packets: 1. IPv6 MTUs match, but IPv4 MTUs differ. 2. IPv6 MTUs differ, but IPv4 MTUs match. In the first case I don't think we're doing anyone a favor by installing routes in the IPv4 RIB that will be unreliable due to a MTU mismatch. In the second case OSPFv3 flooding and synchronization may be compromised. A side effect of this may be that the adjacency never forms, or having formed may later fail. Short of resorting to LLS or some other way of communicating both MTUs it seems we have to pick one or the other. I'd like to propose that we use the DBD packet to communicate the IPv4 MTU when routing that address family, and use the IPv6 minimum MTU of 1280 bytes for OSPFv3 protocol packets. Thanks, Paul Acee Lindem wrote: > Hi Paul, > > On May 28, 2008, at 2:05 PM, Paul Wells wrote: > >> Hi Acee, >> >> I disagree about the "original intent" of the MTU field. As I see it, >> it's function is to prevent an OSPF adjacency from forming over a link >> where the endpoints disagree about the link MTU. We do this primarily >> to prevent the data plane from using a link that will drop packets >> sent to a system with an MTU smaller than ours. > > I happen to remember the discussion of this problem on the OSPF list and > this was not the primary motivation. There were lots of problems with > bridged heterogeneous LANs with mismatched MTUs (ethernet, FDDI, token > ring, and the worst of all technologies - ATM emulated LANs :^). > Adjacencies would come up fine initially but the exchange process would > hang indefinitely when they were restarted due to the router with the > larger MTU having a larger database and trying to use full DD packets. > Unfortunately, the OSPF list was hosted on a server at Microsoft > Corporation in those days and I don't have access to archives. Here is > some text from RFC 2178, appendix G: > > G.9 Detecting interface MTU mismatches > > When two neighboring routers have a different interface MTU for their > common network segment, serious problems can ensue: large packets are > prevented from being successfully transferred from one router to the > other, impairing OSPF's flooding algorithm and possibly creating > "black holes" for user data traffic. > > This memo provides a fix for the interface MTU mismatch problem by > advertising the interface MTU in Database Description packets. When a > router receives a Database description packet advertising an MTU > larger than the router can receive, the router drops the Database > Description packet. This prevents an adjacency from forming, telling > OSPF flooding and user data traffic to avoid the connection between > the two routers. For more information, see Sections 10.6, 10.8, and > A.3.3. > > On the other hand, once the MTU checking was implemented, I believe data > plane MTU consistency has been purported as a benefit. If we used the > IPv4 MTU in the IPv4 address database exchanges, we could still have an > IPv6 MTU mismatch. One could depend on the unicast IPv6 address family > for this checking but, heretofore, we've kept the instances independent. > > Thanks, > Acee > > >> >> While OSPFv3 certainly needs to know the IPv6 link MTU when building >> it's packets, this information should be available locally without >> reference to the MTU field in the DBD packet. >> >> So, I would argue that in af-alt the MTU in the DBD packet should be >> for the address family we are routing, not IPv6 in all cases. >> >> Regards, >> Paul >> >> Acee Lindem wrote: >>> Hi Prasanna, >>> On May 28, 2008, at 8:18 AM, Prasanna Kumar A.S wrote: >>>> Hi >>>> I just wanted to understand what the primary use of exchanging MTU in >>>> DD packets and doing MTU-check is? Is it only for the control plane or >>>> is it for the DATA-plane? >>> Control-plane - when sending DD, LSR, and LSU packets, OSPF will >>> attempt to send as many LSA headers or complete LSAs as will fit in >>> a maximum sized packet. >>>> Why I am getting this doubt is, in draft-ietf-ospf-af-alt-06.txt >>>> doesn't >>>> specify which MTU we should use while exchanging the DD packet for the >>>> ipv4-unicast or ipv4-mutlticast Address-family, is it ipv6-mtu or >>>> ipv4-mtu? >>> We have this clarified in the an update which we post soon. Since >>> this is OSPFv3 which using IPv6 for transport, you always use the >>> IPv6 MTU. >>> Thanks, >>> Acee >>>> >>>> Regards >>>> Prasanna >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu May 29 07:05:07 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1BCA3A6B98; Thu, 29 May 2008 07:05:07 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F4128C26C for ; Thu, 29 May 2008 07:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHPVnZz1CHAR for ; Thu, 29 May 2008 07:04:59 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 1F4883A6B9F for ; Thu, 29 May 2008 07:04:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id F1B3FD44B1D; Thu, 29 May 2008 07:04:51 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03580-03; Thu, 29 May 2008 07:04:51 -0700 (PDT) Received: from [JC???n?IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 17D9CD44B20; Thu, 29 May 2008 07:04:50 -0700 (PDT) In-Reply-To: <34BDD2A93E5FD84594BB230DD6C18EA2046DBEC5@nuova-ex1.hq.nuovaimpresa.com> References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> <483D9ECE.5080300@cisco.com><483DCF2F.2040801@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2046DBEC5@nuova-ex1.hq.nuovaimpresa.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Acee Lindem Date: Thu, 29 May 2008 10:04:50 -0400 To: Sina Mirtorabi X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List Subject: Re: [OSPF] What is the use of MTU field in DD packet X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Sina, Other than it will be a pain to specify, I like #2 with one variation. I say that if the new bit is clear, the 2 MTUs are equal and the specified MTU is simply checked against both MTUs. If it is set, it means the MTUs differ and we need to use the IPv6 minimum for OSPFv3 packet computation. As someone may point out, it's actually more complex - I'll post proposed text (hopefully, later today). Thanks, Acee On May 28, 2008, at 10:11 PM, Sina Mirtorabi wrote: > Hi Acee, > >>> This still leaves the question of what to do for af-alt when >>> routing address families other than IPv6. It seems that there are >>> two cases of interest in deciding which MTU to advertise in >> the DBD >>> packets: >>> >>> 1. IPv6 MTUs match, but IPv4 MTUs differ. >>> 2. IPv6 MTUs differ, but IPv4 MTUs match. >>> >>> In the first case I don't think we're doing anyone a favor by >>> installing routes in the IPv4 RIB that will be unreliable due to a >>> MTU mismatch. >>> >>> In the second case OSPFv3 flooding and synchronization may be >>> compromised. A side effect of this may be that the adjacency never >>> forms, or having formed may later fail. >>> >>> Short of resorting to LLS or some other way of communicating both >>> MTUs it seems we have to pick one or the other. >>> >>> I'd like to propose that we use the DBD packet to communicate the >>> IPv4 MTU when routing that address family, and use the IPv6 >> minimum >>> MTU of 1280 bytes for OSPFv3 protocol packets. >> >> This is a coherent proposal. I'd like to bounce this off the other >> authors and would solicit general comments. The question is whether >> the OSPFv3 protocol checking for MTU mismatches is worth relegated >> OSPFv3 exchange and flooding to the the IPv6 minimum MTU. I'm not >> sure it does but I'd like to open it up to a brief discussion. > > One issue is backward compatibility, if there is any implementation of > alt draft, then we cannot just change the MTU in the DD packet from > IPv6 > to IPv4 MTU. If we don't worry about backward compatibility (no > deployed > implementation) then we have a shot to define as appropriate. There > are > couple of options > > 1) Paul's proposal however I would add that IPv6 Path MTU discovery > should be used. > > 2) We can set a bit in the DD packet to indicate that the MTU value is > for both v4 and v6, if this bit is clear (i.e. MTU mismatch between v4 > and v6) then the MTU field in DD packet is for corresponding AF, e.g. > IPv4 and for IPv6 mtu we have to use 1) (minimum MTU), the > advantage of > this is that unless MTU is really different between v4 and v6 you > don't > blindly reduce the IPv6 mtu > > 3) carry the MTU value for both IPv6 and IPv4 either in DD packet > (there > are unused octet although not contiguous block) or through LLS. > > 4) any other options > > > The advantage of 2) a part from simplicity is that by not knowing the > IPv6 MTU we fall back to minimum MTU and adj will be formed, for 3) if > there is a MTU mismatch then unless you change the rule and state that > in case of mismatch, default minimum MTU should be used, the adj will > not be established if we follow the MTU mismatch rule. The only > advantage of the 3) compared to 2) is that in case IPv4 and IPv6 does > not match AND IPv6 are the same between the system, the actual IPv6 > MTU > (which is carried) is used instead of Minimum MTU. > > thanks > Sina > >> >> Thanks, >> Acee >> >> >> >>> >>> Thanks, >>> Paul >>> >>> Acee Lindem wrote: >>>> Hi Paul, >>>> On May 28, 2008, at 2:05 PM, Paul Wells wrote: >>>>> Hi Acee, >>>>> >>>>> I disagree about the "original intent" of the MTU field. >> As I see >>>>> it, it's function is to prevent an OSPF adjacency from forming >>>>> over a link where the endpoints disagree about the link MTU. We >>>>> do this primarily to prevent the data plane from using a link >>>>> that will drop packets sent to a system with an MTU smaller than >>>>> ours. >>>> I happen to remember the discussion of this problem on the OSPF >>>> list and this was not the primary motivation. There were lots of >>>> problems with bridged heterogeneous LANs with mismatched MTUs >>>> (ethernet, FDDI, token ring, and the worst of all technologies - >>>> ATM emulated LANs :^). Adjacencies would come up fine initially >>>> but the exchange process would hang indefinitely when they were >>>> restarted due to the router with the larger MTU having a larger >>>> database and trying to use full DD packets. Unfortunately, the >>>> OSPF list was hosted on a server at Microsoft Corporation >> in those >>>> days and I don't have access to archives. Here is some text from >>>> RFC 2178, appendix G: G.9 Detecting interface MTU mismatches >>>> When two neighboring routers have a different interface >> MTU for >>>> their >>>> common network segment, serious problems can ensue: large >>>> packets are >>>> prevented from being successfully transferred from one router >>>> to the >>>> other, impairing OSPF's flooding algorithm and possibly creating >>>> "black holes" for user data traffic. >>>> This memo provides a fix for the interface MTU mismatch >> problem by >>>> advertising the interface MTU in Database Description packets. >>>> When a >>>> router receives a Database description packet advertising an MTU >>>> larger than the router can receive, the router drops >> the Database >>>> Description packet. This prevents an adjacency from forming, >>>> telling >>>> OSPF flooding and user data traffic to avoid the connection >>>> between >>>> the two routers. For more information, see Sections >> 10.6, 10.8, >>>> and >>>> A.3.3. >>>> On the other hand, once the MTU checking was implemented, I >>>> believe data plane MTU consistency has been purported as a >>>> benefit. If we used the IPv4 MTU in the IPv4 address database >>>> exchanges, we could still have an IPv6 MTU mismatch. One could >>>> depend on the unicast IPv6 address family for this checking but, >>>> heretofore, we've kept the instances independent. Thanks, >>>> Acee >>>>> >>>>> While OSPFv3 certainly needs to know the IPv6 link MTU when >>>>> building it's packets, this information should be available >>>>> locally without reference to the MTU field in the DBD packet. >>>>> >>>>> So, I would argue that in af-alt the MTU in the DBD >> packet should >>>>> be for the address family we are routing, not IPv6 in all cases. >>>>> >>>>> Regards, >>>>> Paul >>>>> >>>>> Acee Lindem wrote: >>>>>> Hi Prasanna, >>>>>> On May 28, 2008, at 8:18 AM, Prasanna Kumar A.S wrote: >>>>>>> Hi >>>>>>> I just wanted to understand what the primary use of >>>>>>> exchanging MTU in >>>>>>> DD packets and doing MTU-check is? Is it only for the control >>>>>>> plane or >>>>>>> is it for the DATA-plane? >>>>>> Control-plane - when sending DD, LSR, and LSU packets, OSPF >>>>>> will attempt to send as many LSA headers or complete LSAs as >>>>>> will fit in a maximum sized packet. >>>>>>> Why I am getting this doubt is, in draft-ietf-ospf-af- >>>>>>> alt-06.txt doesn't >>>>>>> specify which MTU we should use while exchanging the DD packet >>>>>>> for the >>>>>>> ipv4-unicast or ipv4-mutlticast Address-family, is it >> ipv6-mtu or >>>>>>> ipv4-mtu? >>>>>> We have this clarified in the an update which we post soon. >>>>>> Since this is OSPFv3 which using IPv6 for transport, >> you always >>>>>> use the IPv6 MTU. >>>>>> Thanks, >>>>>> Acee >>>>>>> >>>>>>> Regards >>>>>>> Prasanna >>>>>>> _______________________________________________ >>>>>>> OSPF mailing list >>>>>>> OSPF@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>>> _______________________________________________ >>>>>> OSPF mailing list >>>>>> OSPF@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ospf >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu May 29 07:13:33 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DE223A6B9F; Thu, 29 May 2008 07:13:33 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D41003A6B98 for ; Thu, 29 May 2008 07:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7BGJDXKvtvK for ; Thu, 29 May 2008 07:13:26 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 3A5713A6B9F for ; Thu, 29 May 2008 07:13:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 1AB24912F8B; Thu, 29 May 2008 07:13:24 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05372-06; Thu, 29 May 2008 07:13:23 -0700 (PDT) Received: from [?????n?IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 5020E912F8E; Thu, 29 May 2008 07:13:23 -0700 (PDT) In-Reply-To: References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> <483D9ECE.5080300@cisco.com><483DCF2F.2040801@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2046DBEC5@nuova-ex1.hq.nuovaimpresa.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: From: Acee Lindem Date: Thu, 29 May 2008 10:13:21 -0400 To: Prasanna Kumar A.S X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List Subject: Re: [OSPF] What is the use of MTU field in DD packet X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Prasanna, I'm not that keen on using the same field for different purposes. I would hope that in most cases the MTUs would be the same anyway. Thanks, Acee On May 29, 2008, at 3:03 AM, Prasanna Kumar A.S wrote: > Hi > I suggest following mechanism to communicate both the MTUs > Initial DD packet should carry the MTU of Address-family which > should > match with the mtu of that address-family otherwise mtu check should > fail, (I.e. if initial DD packet with AF bit set and matching MTU then > MTU check should pass) > > and subsequent DD packets should carry the ipv6-MTU (ignore MTU check > for non initial DD packet with Af bit set), And the ipv6 MTU of each > neighbor should be saved in the neighbor data-structure, then smallest > MTU of all the neighbors on the link is used for constructing the > ospf-packets to be transmitted on that link > > Regards > Prasanna > > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On > Behalf Of > Sina Mirtorabi > Sent: Thursday, May 29, 2008 7:42 AM > To: Acee Lindem; Paul Wells > Cc: OSPF List > Subject: Re: [OSPF] What is the use of MTU field in DD packet > > Hi Acee, > >>> This still leaves the question of what to do for af-alt when >>> routing address families other than IPv6. It seems that there are >>> two cases of interest in deciding which MTU to advertise in >> the DBD >>> packets: >>> >>> 1. IPv6 MTUs match, but IPv4 MTUs differ. >>> 2. IPv6 MTUs differ, but IPv4 MTUs match. >>> >>> In the first case I don't think we're doing anyone a favor by >>> installing routes in the IPv4 RIB that will be unreliable due to a >>> MTU mismatch. >>> >>> In the second case OSPFv3 flooding and synchronization may be >>> compromised. A side effect of this may be that the adjacency never >>> forms, or having formed may later fail. >>> >>> Short of resorting to LLS or some other way of communicating both >>> MTUs it seems we have to pick one or the other. >>> >>> I'd like to propose that we use the DBD packet to communicate the >>> IPv4 MTU when routing that address family, and use the IPv6 >> minimum >>> MTU of 1280 bytes for OSPFv3 protocol packets. >> >> This is a coherent proposal. I'd like to bounce this off the other >> authors and would solicit general comments. The question is whether >> the OSPFv3 protocol checking for MTU mismatches is worth relegated >> OSPFv3 exchange and flooding to the the IPv6 minimum MTU. I'm not >> sure it does but I'd like to open it up to a brief discussion. > > One issue is backward compatibility, if there is any implementation of > alt draft, then we cannot just change the MTU in the DD packet from > IPv6 > to IPv4 MTU. If we don't worry about backward compatibility (no > deployed > implementation) then we have a shot to define as appropriate. There > are > couple of options > > 1) Paul's proposal however I would add that IPv6 Path MTU discovery > should be used. > > 2) We can set a bit in the DD packet to indicate that the MTU value is > for both v4 and v6, if this bit is clear (i.e. MTU mismatch between v4 > and v6) then the MTU field in DD packet is for corresponding AF, e.g. > IPv4 and for IPv6 mtu we have to use 1) (minimum MTU), the > advantage of > this is that unless MTU is really different between v4 and v6 you > don't > blindly reduce the IPv6 mtu > > 3) carry the MTU value for both IPv6 and IPv4 either in DD packet > (there > are unused octet although not contiguous block) or through LLS. > > 4) any other options > > > The advantage of 2) a part from simplicity is that by not knowing the > IPv6 MTU we fall back to minimum MTU and adj will be formed, for 3) if > there is a MTU mismatch then unless you change the rule and state that > in case of mismatch, default minimum MTU should be used, the adj will > not be established if we follow the MTU mismatch rule. The only > advantage of the 3) compared to 2) is that in case IPv4 and IPv6 does > not match AND IPv6 are the same between the system, the actual IPv6 > MTU > (which is carried) is used instead of Minimum MTU. > > thanks > Sina > >> >> Thanks, >> Acee >> >> >> >>> >>> Thanks, >>> Paul >>> >>> Acee Lindem wrote: >>>> Hi Paul, >>>> On May 28, 2008, at 2:05 PM, Paul Wells wrote: >>>>> Hi Acee, >>>>> >>>>> I disagree about the "original intent" of the MTU field. >> As I see >>>>> it, it's function is to prevent an OSPF adjacency from forming >>>>> over a link where the endpoints disagree about the link MTU. We >>>>> do this primarily to prevent the data plane from using a link >>>>> that will drop packets sent to a system with an MTU smaller than >>>>> ours. >>>> I happen to remember the discussion of this problem on the OSPF >>>> list and this was not the primary motivation. There were lots of >>>> problems with bridged heterogeneous LANs with mismatched MTUs >>>> (ethernet, FDDI, token ring, and the worst of all technologies - >>>> ATM emulated LANs :^). Adjacencies would come up fine initially >>>> but the exchange process would hang indefinitely when they were >>>> restarted due to the router with the larger MTU having a larger >>>> database and trying to use full DD packets. Unfortunately, the >>>> OSPF list was hosted on a server at Microsoft Corporation >> in those >>>> days and I don't have access to archives. Here is some text from >>>> RFC 2178, appendix G: G.9 Detecting interface MTU mismatches >>>> When two neighboring routers have a different interface >> MTU for >>>> their >>>> common network segment, serious problems can ensue: large >>>> packets are >>>> prevented from being successfully transferred from one router >>>> to the >>>> other, impairing OSPF's flooding algorithm and possibly creating >>>> "black holes" for user data traffic. >>>> This memo provides a fix for the interface MTU mismatch >> problem by >>>> advertising the interface MTU in Database Description packets. >>>> When a >>>> router receives a Database description packet advertising an MTU >>>> larger than the router can receive, the router drops >> the Database >>>> Description packet. This prevents an adjacency from forming, >>>> telling >>>> OSPF flooding and user data traffic to avoid the connection >>>> between >>>> the two routers. For more information, see Sections >> 10.6, 10.8, >>>> and >>>> A.3.3. >>>> On the other hand, once the MTU checking was implemented, I >>>> believe data plane MTU consistency has been purported as a >>>> benefit. If we used the IPv4 MTU in the IPv4 address database >>>> exchanges, we could still have an IPv6 MTU mismatch. One could >>>> depend on the unicast IPv6 address family for this checking but, >>>> heretofore, we've kept the instances independent. Thanks, >>>> Acee >>>>> >>>>> While OSPFv3 certainly needs to know the IPv6 link MTU when >>>>> building it's packets, this information should be available >>>>> locally without reference to the MTU field in the DBD packet. >>>>> >>>>> So, I would argue that in af-alt the MTU in the DBD >> packet should >>>>> be for the address family we are routing, not IPv6 in all cases. >>>>> >>>>> Regards, >>>>> Paul >>>>> >>>>> Acee Lindem wrote: >>>>>> Hi Prasanna, >>>>>> On May 28, 2008, at 8:18 AM, Prasanna Kumar A.S wrote: >>>>>>> Hi >>>>>>> I just wanted to understand what the primary use of >>>>>>> exchanging MTU in >>>>>>> DD packets and doing MTU-check is? Is it only for the control >>>>>>> plane or >>>>>>> is it for the DATA-plane? >>>>>> Control-plane - when sending DD, LSR, and LSU packets, OSPF >>>>>> will attempt to send as many LSA headers or complete LSAs as >>>>>> will fit in a maximum sized packet. >>>>>>> Why I am getting this doubt is, in draft-ietf-ospf-af- >>>>>>> alt-06.txt doesn't >>>>>>> specify which MTU we should use while exchanging the DD packet >>>>>>> for the >>>>>>> ipv4-unicast or ipv4-mutlticast Address-family, is it >> ipv6-mtu or >>>>>>> ipv4-mtu? >>>>>> We have this clarified in the an update which we post soon. >>>>>> Since this is OSPFv3 which using IPv6 for transport, >> you always >>>>>> use the IPv6 MTU. >>>>>> Thanks, >>>>>> Acee >>>>>>> >>>>>>> Regards >>>>>>> Prasanna >>>>>>> _______________________________________________ >>>>>>> OSPF mailing list >>>>>>> OSPF@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>>> _______________________________________________ >>>>>> OSPF mailing list >>>>>> OSPF@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ospf >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu May 29 11:31:37 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E848728C0FD; Thu, 29 May 2008 11:31:37 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5ED3A6B38 for ; Thu, 29 May 2008 11:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOj8VdwA6ak3 for ; Thu, 29 May 2008 11:31:34 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 8543628C16E for ; Thu, 29 May 2008 11:24:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 1836684B543 for ; Thu, 29 May 2008 11:24:26 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23170-01 for ; Thu, 29 May 2008 11:24:25 -0700 (PDT) Received: from [?????n?IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 2E41284B53F for ; Thu, 29 May 2008 11:24:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753) In-Reply-To: References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> <483D9ECE.5080300@cisco.com><483DCF2F.2040801@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2046DBEC5@nuova-ex1.hq.nuovaimpresa.com> Message-Id: <1C8A838F-FFFF-414D-AF88-A3CF2A9B88C9@redback.com> Cc: OSPF List From: Acee Lindem Date: Thu, 29 May 2008 14:24:24 -0400 X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Subject: Re: [OSPF] What is the use of MTU field in DD packet X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0132085738==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============0132085738== Content-Type: multipart/alternative; boundary=Apple-Mail-48--297453083 --Apple-Mail-48--297453083 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Those of you who have worked with me in the past will not be surprised that I have come up with a slightly different solution. However, I think this is a simpler approach allows an OSPFv3 router to disable IPv6 MTU checking for non-IPv6 address families even if their IPv6 MTU matches their IPv4 MTU. 2.7. Database Description Maximum Transmissoin Unit (MTU) Specification for Non-IPv6 AFs For address families other than IPv6, both the MTU for the address family of the instance and IPv6 MTU used for OSPFv3 maximum packet determination must be considered. The MTU in the Database Description packet MUST always contain the MTU corresponding to the advertised address family. For example, if the instance corresponds to an IPv4 address family, the IPv4 MTU for the interface MUST be specified in the interface MTU field. As specified section 10.6 of [OSPFV2], the Database Description packet will be rejected if the MTU is greater than the receiving interface's MTU for the address family corresponding to the instance. This behavior will assure an adjacency is not formed and address family specific routes are not installed over a path with conflicting MTUs. The value used for OSPFv3 maximum packet size determination must also be compatible an adjacency to be established. Since only a single MTU field is specified, the M6-bit is defined by this specification. If the M6-bit is set, the OSPFv3 router will send OSPFv3 packets no larger than 1280 octets, the minimum IPv6 MTU (refer to [IPV6]). If the M6-bit is clear, the specified MTU should also be checked against the IPv6 MTU and the Database Description packet should be rejected if the MTU is larger than the receiving interface's IPv6 MTU. If the IPv6 and IPv4 MTUs differ, the M6-bit MUST be set for non-IPv6 address families. If the M6-bit is set in a received Database Description packet for a non-IPv6 address family, the receiving router MUST NOT check the Interface MTU in the Database Exchange packet against the receiving interface's IPv6 MTU. The figure below graphically depicts the OSPFv3 Database Packet: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+- +--+ | 3 | 2 | Packet Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+- +--+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+- +--+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+- +--+ | Checksum | Instance ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+- +--+ | 0 | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+- +--+ | Interface MTU | 0 |0|0|0|M6|0|I|M| MS| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+- +--+ | DD sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+- +--+ | | +- -+ | | +- An LSA Header -+ | | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+- +--+ | ... | The OSPFv3 Database Description Packet The changed fields in the Database Description packet are described below. The remaining fields are unchanged from [OSPFV3]. Interface MTU The size in octets of the largest address-family specific datagram that can be sent out the associated interface without fragmentation. The MTUs of common Internet link types can be found in Table 7-1 of [MTUDISC]. Interface MTU should be set to 0 in Database Description packets sent over virtual links. M6-bit The Minimum IPv6 MTU bit - this bit indicates the sender wishes that the minumum IPv6 MTU be used for OSPFv3 maximum packet size determination. Thanks, Acee On May 29, 2008, at 10:04 AM, Acee Lindem wrote: > Hi Sina, > Other than it will be a pain to specify, I like #2 with one > variation. I say that if the new bit is clear, the 2 MTUs are equal > and the specified MTU is simply checked against both MTUs. If it is > set, it means the MTUs differ and we need to use the IPv6 minimum for > OSPFv3 packet computation. As someone may point out, it's actually > more complex - I'll post proposed text (hopefully, later today). > Thanks, > Acee > On May 28, 2008, at 10:11 PM, Sina Mirtorabi wrote: > >> Hi Acee, >> >>>> This still leaves the question of what to do for af-alt when >>>> routing address families other than IPv6. It seems that there are >>>> two cases of interest in deciding which MTU to advertise in >>> the DBD >>>> packets: >>>> >>>> 1. IPv6 MTUs match, but IPv4 MTUs differ. >>>> 2. IPv6 MTUs differ, but IPv4 MTUs match. >>>> >>>> In the first case I don't think we're doing anyone a favor by >>>> installing routes in the IPv4 RIB that will be unreliable due to a >>>> MTU mismatch. >>>> >>>> In the second case OSPFv3 flooding and synchronization may be >>>> compromised. A side effect of this may be that the adjacency never >>>> forms, or having formed may later fail. >>>> >>>> Short of resorting to LLS or some other way of communicating both >>>> MTUs it seems we have to pick one or the other. >>>> >>>> I'd like to propose that we use the DBD packet to communicate the >>>> IPv4 MTU when routing that address family, and use the IPv6 >>> minimum >>>> MTU of 1280 bytes for OSPFv3 protocol packets. >>> >>> This is a coherent proposal. I'd like to bounce this off the other >>> authors and would solicit general comments. The question is whether >>> the OSPFv3 protocol checking for MTU mismatches is worth relegated >>> OSPFv3 exchange and flooding to the the IPv6 minimum MTU. I'm not >>> sure it does but I'd like to open it up to a brief discussion. >> >> One issue is backward compatibility, if there is any >> implementation of >> alt draft, then we cannot just change the MTU in the DD packet from >> IPv6 >> to IPv4 MTU. If we don't worry about backward compatibility (no >> deployed >> implementation) then we have a shot to define as appropriate. There >> are >> couple of options >> >> 1) Paul's proposal however I would add that IPv6 Path MTU discovery >> should be used. >> >> 2) We can set a bit in the DD packet to indicate that the MTU >> value is >> for both v4 and v6, if this bit is clear (i.e. MTU mismatch >> between v4 >> and v6) then the MTU field in DD packet is for corresponding AF, e.g. >> IPv4 and for IPv6 mtu we have to use 1) (minimum MTU), the >> advantage of >> this is that unless MTU is really different between v4 and v6 you >> don't >> blindly reduce the IPv6 mtu >> >> 3) carry the MTU value for both IPv6 and IPv4 either in DD packet >> (there >> are unused octet although not contiguous block) or through LLS. >> >> 4) any other options >> >> >> The advantage of 2) a part from simplicity is that by not knowing the >> IPv6 MTU we fall back to minimum MTU and adj will be formed, for >> 3) if >> there is a MTU mismatch then unless you change the rule and state >> that >> in case of mismatch, default minimum MTU should be used, the adj will >> not be established if we follow the MTU mismatch rule. The only >> advantage of the 3) compared to 2) is that in case IPv4 and IPv6 does >> not match AND IPv6 are the same between the system, the actual IPv6 >> MTU >> (which is carried) is used instead of Minimum MTU. >> >> thanks >> Sina >> >>> >>> Thanks, >>> Acee >>> >>> >>> >>>> >>>> Thanks, >>>> Paul >>>> >>>> Acee Lindem wrote: >>>>> Hi Paul, >>>>> On May 28, 2008, at 2:05 PM, Paul Wells wrote: >>>>>> Hi Acee, >>>>>> >>>>>> I disagree about the "original intent" of the MTU field. >>> As I see >>>>>> it, it's function is to prevent an OSPF adjacency from forming >>>>>> over a link where the endpoints disagree about the link MTU. We >>>>>> do this primarily to prevent the data plane from using a link >>>>>> that will drop packets sent to a system with an MTU smaller than >>>>>> ours. >>>>> I happen to remember the discussion of this problem on the OSPF >>>>> list and this was not the primary motivation. There were lots of >>>>> problems with bridged heterogeneous LANs with mismatched MTUs >>>>> (ethernet, FDDI, token ring, and the worst of all technologies - >>>>> ATM emulated LANs :^). Adjacencies would come up fine initially >>>>> but the exchange process would hang indefinitely when they were >>>>> restarted due to the router with the larger MTU having a larger >>>>> database and trying to use full DD packets. Unfortunately, the >>>>> OSPF list was hosted on a server at Microsoft Corporation >>> in those >>>>> days and I don't have access to archives. Here is some text from >>>>> RFC 2178, appendix G: G.9 Detecting interface MTU mismatches >>>>> When two neighboring routers have a different interface >>> MTU for >>>>> their >>>>> common network segment, serious problems can ensue: large >>>>> packets are >>>>> prevented from being successfully transferred from one router >>>>> to the >>>>> other, impairing OSPF's flooding algorithm and possibly >>>>> creating >>>>> "black holes" for user data traffic. >>>>> This memo provides a fix for the interface MTU mismatch >>> problem by >>>>> advertising the interface MTU in Database Description packets. >>>>> When a >>>>> router receives a Database description packet advertising an >>>>> MTU >>>>> larger than the router can receive, the router drops >>> the Database >>>>> Description packet. This prevents an adjacency from forming, >>>>> telling >>>>> OSPF flooding and user data traffic to avoid the connection >>>>> between >>>>> the two routers. For more information, see Sections >>> 10.6, 10.8, >>>>> and >>>>> A.3.3. >>>>> On the other hand, once the MTU checking was implemented, I >>>>> believe data plane MTU consistency has been purported as a >>>>> benefit. If we used the IPv4 MTU in the IPv4 address database >>>>> exchanges, we could still have an IPv6 MTU mismatch. One could >>>>> depend on the unicast IPv6 address family for this checking but, >>>>> heretofore, we've kept the instances independent. Thanks, >>>>> Acee >>>>>> >>>>>> While OSPFv3 certainly needs to know the IPv6 link MTU when >>>>>> building it's packets, this information should be available >>>>>> locally without reference to the MTU field in the DBD packet. >>>>>> >>>>>> So, I would argue that in af-alt the MTU in the DBD >>> packet should >>>>>> be for the address family we are routing, not IPv6 in all cases. >>>>>> >>>>>> Regards, >>>>>> Paul >>>>>> >>>>>> Acee Lindem wrote: >>>>>>> Hi Prasanna, >>>>>>> On May 28, 2008, at 8:18 AM, Prasanna Kumar A.S wrote: >>>>>>>> Hi >>>>>>>> I just wanted to understand what the primary use of >>>>>>>> exchanging MTU in >>>>>>>> DD packets and doing MTU-check is? Is it only for the control >>>>>>>> plane or >>>>>>>> is it for the DATA-plane? >>>>>>> Control-plane - when sending DD, LSR, and LSU packets, OSPF >>>>>>> will attempt to send as many LSA headers or complete LSAs as >>>>>>> will fit in a maximum sized packet. >>>>>>>> Why I am getting this doubt is, in draft-ietf-ospf-af- >>>>>>>> alt-06.txt doesn't >>>>>>>> specify which MTU we should use while exchanging the DD packet >>>>>>>> for the >>>>>>>> ipv4-unicast or ipv4-mutlticast Address-family, is it >>> ipv6-mtu or >>>>>>>> ipv4-mtu? >>>>>>> We have this clarified in the an update which we post soon. >>>>>>> Since this is OSPFv3 which using IPv6 for transport, >>> you always >>>>>>> use the IPv6 MTU. >>>>>>> Thanks, >>>>>>> Acee >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanna >>>>>>>> _______________________________________________ >>>>>>>> OSPF mailing list >>>>>>>> OSPF@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>>>> _______________________________________________ >>>>>>> OSPF mailing list >>>>>>> OSPF@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ospf >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >>> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-48--297453083 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Those of you who have worked with me in the past = will not be surprised that I have come up with a slightly different = solution. However, I think this is a simpler approach allows an OSPFv3 = router to disable IPv6 MTU checking for non-IPv6 address families even = if their IPv6 MTU matches their IPv4 MTU.=A0


2.7. =A0Database Description Maximum Transmissoin Unit = (MTU)
=A0=A0 =A0 =A0Specification for Non-IPv6 = AFs

=A0=A0 For address families other than IPv6, both the = MTU for the address
=A0=A0 family = of the instance and IPv6 MTU used for OSPFv3 maximum = packet
=A0=A0 determination must be considered. = =A0The MTU in the Database
=A0=A0 = Description packet MUST always contain the MTU corresponding to = the
=A0=A0 advertised address family. =A0For = example, if the instance corresponds
=A0=A0 to an = IPv4 address family, the IPv4 MTU for the interface MUST = be
=A0=A0 specified in the interface MTU = field. =A0As specified section 10.6 of
=A0=A0 [OSPFV2], the Database Description packet will be = rejected if the MTU
=A0=A0 is = greater than the receiving interface's MTU for the address = family
=A0=A0 corresponding to the instance. = =A0This behavior will assure an
=A0=A0 = adjacency is not formed and address family specific routes are = not
=A0=A0 installed over a path with = conflicting MTUs.

=A0=A0 The value used for OSPFv3 maximum packet size = determination must also
=A0=A0 be = compatible an adjacency to be established. =A0Since only a = single
=A0=A0 MTU field is specified, the M6-bit = is defined by this specification.
=A0=A0 If the = M6-bit is set, the OSPFv3 router will send OSPFv3 packets = no
=A0=A0 larger than 1280 octets, the = minimum IPv6 MTU (refer to [IPV6]). =A0If
=A0=A0 the M6-bit is clear, the specified MTU should = also be checked against
=A0=A0 the = IPv6 MTU and the Database Description packet should be = rejected
=A0=A0 if the MTU is larger than the = receiving interface's IPv6 MTU. =A0If the
=A0=A0 IPv6 and IPv4 MTUs differ, the M6-bit MUST be set = for non-IPv6
=A0=A0 address = families.

=A0=A0 If the M6-bit is set in a received Database = Description packet for a
=A0=A0 = non-IPv6 address family, the receiving router MUST NOT check = the
=A0=A0 Interface MTU in the Database = Exchange packet against the receiving
=A0=A0 interface's IPv6 MTU.

=A0=A0 The = figure below graphically depicts the OSPFv3 Database = Packet:

=A0=A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A03
=A0=A0 =A0 =A00 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 =A08 9 0 1
=A0=A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+=
=A0=A0 =A0 | =A0 =A0 =A03 =A0 =A0 =A0 =A0| =A0 =A0 =A0 2 = =A0 =A0 =A0 | =A0 =A0 =A0 =A0Packet Length =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 Router ID =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 Area ID =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 Checksum =A0 =A0 =A0 =A0 = =A0 =A0| =A0Instance ID =A0| =A0 =A0 =A00 =A0 =A0 =A0 =A0 = =A0|
=A0=A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+=
=A0=A0 =A0 | =A0 =A0 =A0 0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 = =A0 =A0 =A0 Options =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = |
=A0=A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+=
=A0=A0 =A0 | =A0 =A0 =A0 =A0Interface MTU =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A00 =A0 =A0 =A0 =A0|0|0|0|M6|0|I|M|MS|
=A0=A0 =A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+=
=A0=A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DD = sequence number =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 =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 An LSA Header =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 = =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 =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 =A0 The OSPFv3 Database = Description Packet

=A0=A0 The changed fields in the Database Description = packet are described
=A0=A0 below. = =A0The remaining fields are unchanged from [OSPFV3].


=A0=A0 Interface MTU
=A0=A0 =A0 = =A0The size in octets of the largest address-family specific = datagram
=A0=A0 =A0 =A0that can be sent out the = associated interface without
=A0=A0 =A0 = =A0fragmentation. =A0The MTUs of common Internet link types can = be
=A0=A0 =A0 =A0found in Table 7-1 of = [MTUDISC]. =A0Interface MTU should be set to 0
=A0=A0 =A0 =A0in Database Description packets sent over = virtual links.

=A0=A0 M6-bit
=A0=A0 =A0 = =A0The Minimum IPv6 MTU bit - this bit indicates the sender = wishes
=A0=A0 =A0 =A0that the minumum IPv6 MTU = be used for OSPFv3 maximum packet size
=A0=A0 =A0 =A0determination.
Hi Sina,
Other than it = will be a pain to specify, I like #2 with one =A0
=A0
and the specified MTU is simply checked against both = MTUs. If it is =A0
set, it means the MTUs differ and we need to use the = IPv6 minimum for =A0
OSPFv3 packet computation. As someone may point out, = it's actually =A0
more complex - I'll post proposed text (hopefully, = later today).
Thanks,
Acee
On May 28, = 2008, at 10:11 PM, Sina Mirtorabi wrote:

Hi Acee,

This still leaves the question = of what to do for af-alt when
routing = address families other than IPv6. It seems that there are
two cases of interest in deciding which MTU to = advertise in
the DBD
=
packets:

1. IPv6 = MTUs match, but IPv4 MTUs differ.
2. IPv6 MTUs = differ, but IPv4 MTUs match.

In the first case I don't think = we're doing anyone a favor by
installing = routes in the IPv4 RIB that will be unreliable due to a
MTU mismatch.

In the second case OSPFv3 = flooding and synchronization may be
compromised. = A side effect of this may be that the adjacency never
forms, or having formed may later fail.

Short of = resorting to LLS or some other way of communicating both
MTUs it seems we have to pick one or the = other.

I'd like to propose that we use the DBD packet to = communicate the
IPv4 MTU when routing that = address family, and use the IPv6
minimum
MTU of 1280 bytes for OSPFv3 protocol packets.
=

This is a coherent proposal. I'd like to bounce this = off the other
authors and would solicit = general comments. The question is whether
the = OSPFv3 protocol checking for MTU mismatches is worth relegated
OSPFv3 exchange and flooding to the the IPv6 minimum = MTU. I'm not
sure it does but I'd like to = open it up to a brief discussion.

One = issue is backward compatibility, if there is any implementation = of
alt draft, then we cannot just change the MTU = in the DD packet from =A0
to IPv4 MTU. If we don't worry = about backward compatibility (no =A0
implementation) then we have a = shot to define as appropriate. There =A0
couple of options

1) = Paul's proposal however I would add that IPv6 Path MTU = discovery
should be used.

2) We = can set a bit in the DD packet to indicate that the MTU value = is
for both v4 and v6, if this bit is clear (i.e. = MTU mismatch between v4
and v6) then = the MTU field in DD packet is for corresponding AF, e.g.
IPv4 and for IPv6 mtu we have to use 1) (minimum = MTU), the =A0
advantage of
this is that = unless MTU is really different between v4 and v6 you =A0
blindly reduce the IPv6 = mtu

3) carry the MTU value for both IPv6 and IPv4 either = in DD packet =A0
(there
are unused = octet although not contiguous block) or through LLS.

4) any = other options


The = advantage of 2) a part from simplicity is that by not knowing = the
IPv6 MTU we fall back to minimum = MTU and adj will be formed, for 3) if
there is = a MTU mismatch then unless you change the rule and state that
in case of mismatch, default minimum MTU should be = used, the adj will
not be established if we = follow the MTU mismatch rule. The only
not match AND IPv6 are the same = between the system, the actual IPv6 =A0
(which is carried) is used = instead of Minimum MTU.

thanks
Sina


Acee




Paul

Acee = Lindem wrote:
Hi = Paul,
On May 28, 2008, at 2:05 PM, = Paul Wells wrote:
Hi Acee,

I disagree about the "original = intent" of the MTU field.
=
As I = see
it, it's function is to prevent = an OSPF adjacency from forming
over a link = where the endpoints disagree about the link MTU. We
do this primarily to prevent the data plane from = using a link
that will drop packets sent to a = system with an MTU smaller than
ours.
=
I happen to remember the = discussion of this problem on the OSPF
list and = this was not the primary motivation. There were lots of
problems with bridged heterogeneous LANs with = mismatched MTUs
(ethernet, FDDI, token ring, and = the worst of all technologies -
ATM emulated = LANs :^).=A0 Adjacencies = would come up fine initially
but the = exchange process would hang indefinitely when they were
restarted due to the router with the larger MTU = having a larger
database and trying to use full = DD packets. Unfortunately, the
OSPF list was = hosted on a server at Microsoft Corporation
=
in those
days and I = don't have access to archives. Here is some text from
RFC 2178, appendix G: G.9 Detecting interface MTU = mismatches
=A0=A0 When two neighboring = routers have a different interface
MTU for
their
=A0=A0 = common network segment, serious problems can ensue: = large
packets are
=A0=A0 = prevented from being successfully transferred from one = router
to the
=A0=A0 = other, impairing OSPF's flooding algorithm and possibly = creating
=A0=A0 "black holes" for user = data traffic.
=A0=A0 This memo provides a fix = for the interface MTU mismatch
problem by
=A0=A0 advertising the interface = MTU in Database Description packets.
When = a
=A0=A0 = router receives a Database description packet advertising an = MTU
=A0=A0 larger than the router can = receive, the router drops
the Database
=A0=A0 Description packet. This = prevents an adjacency from forming,
=A0=A0 OSPF flooding and user = data traffic to avoid the connection
=A0=A0 the two routers. For more = information, see Sections
10.6, 10.8,
and
=A0=A0 = A.3.3.
On the other hand, once the MTU = checking was implemented, I
believe data = plane MTU consistency has been purported as a
benefit. If we used the IPv4 MTU in the IPv4 address = database
exchanges, we could still have = an IPv6 MTU mismatch. One could
depend on the = unicast IPv6 address family for this checking but,
heretofore, we've kept the instances independent. = Thanks,
Acee

While OSPFv3 certainly needs to know the IPv6 link = MTU when
building it's packets, this = information should be available
locally = without reference to the MTU field in the DBD packet.

So, I = would argue that in af-alt the MTU in the DBD
=
packet = should
be for the = address family we are routing, not IPv6 in all cases.

Paul

Acee = Lindem wrote:
Hi = Prasanna,
On May 28, 2008, at 8:18 AM, = Prasanna Kumar A.S wrote:
Hi
=A0 I just wanted to understand = what the primary use of
=A0 MTU = in
DD packets and doing MTU-check is? Is it only = for the control
plane or
is it for the DATA-plane?
Control-plane - when sending DD, LSR, and LSU = packets, OSPF
will=A0 attempt to send as many LSA = headers or complete LSAs as
will fit in = a=A0 maximum sized = packet.
Why I am = getting this doubt is, in draft-ietf-ospf-af-
alt-06.txt=A0 = doesn't
specify which MTU we should use = while exchanging the DD packet
for = the
ipv4-unicast or ipv4-mutlticast = Address-family, is it
=
ipv6-mtu or
ipv4-mtu?
We have = this clarified in the an update which we post soon.
Since=A0 = this is OSPFv3 which using IPv6 for transport,
=
you always
use the=A0 = IPv6 MTU.
Thanks,
Acee

Prasanna
OSPF mailing list
mailto:OSPF@ietf.org>
OSPF mailing list
mailto:OSPF@ietf.org>
=

OSPF mailing list


OSPF mailing list

= --Apple-Mail-48--297453083-- --===============0132085738== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --===============0132085738==-- From ospf-bounces@ietf.org Thu May 29 13:01:46 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 323723A6BC9; Thu, 29 May 2008 13:01:46 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7DA03A6B27 for ; Thu, 29 May 2008 13:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQDYcOKTlFFK for ; Thu, 29 May 2008 13:01:35 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 3F4933A6BAE for ; Thu, 29 May 2008 12:59:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,562,1204531200"; d="scan'208";a="51519033" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 29 May 2008 12:59:47 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m4TJxljj004933; Thu, 29 May 2008 12:59:47 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4TJxlRZ017816; Thu, 29 May 2008 19:59:47 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 12:59:47 -0700 Received: from pauwells-linux.cisco.com ([10.19.20.100]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 12:59:46 -0700 Message-ID: <483F0B31.40103@cisco.com> Date: Thu, 29 May 2008 14:59:45 -0500 From: Paul Wells User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Acee Lindem References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> <483D9ECE.5080300@cisco.com><483DCF2F.2040801@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2046DBEC5@nuova-ex1.hq.nuovaimpresa.com> <1C8A838F-FFFF-414D-AF88-A3CF2A9B88C9@redback.com> In-Reply-To: <1C8A838F-FFFF-414D-AF88-A3CF2A9B88C9@redback.com> X-OriginalArrivalTime: 29 May 2008 19:59:46.0522 (UTC) FILETIME=[8B530BA0:01C8C1C6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15422; t=1212091187; x=1212955187; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pauwells@cisco.com; z=From:=20Paul=20Wells=20 |Subject:=20Re=3A=20[OSPF]=20What=20is=20the=20use=20of=20M TU=20field=20in=20DD=20packet |Sender:=20; bh=bPDVxNfxuLDFO9oMVhpW6NWN+kTYcw2yoIXzXfGGmw4=; b=n11Cl2i9aQ1wynrdt8V4vV5tStsgZT5hSYngEetAvatxWeUvjUu63gbbk8 12SX/IxQU1s+GGv95MATuZ0cejChBV3myAoZwJDUYmJoQ1N8No27GmbNSD1Z X1jmniS3bN; Authentication-Results: sj-dkim-3; header.From=pauwells@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: OSPF List Subject: Re: [OSPF] What is the use of MTU field in DD packet X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Acee, This scheme looks okay to me. I have a couple of questions/suggestions, though. You say: "If the IPv6 and IPv4 MTUs differ, the M6-bit MUST be set for non-IPv6 address families." Do we also need to add a sentence like: If the IPv6 and IPv4 MTUs are the same, the M6-bit MUST NOT be set for non-IPv6 address families. in order to preclude an implementation setting the M6-bit in all cases? Also, what happens when the M6-bits of routers on the link don't match? The text specifies that the router which has differing IPv4/IPv6 MTUs will send 1280 byte OSPFv3 packets, but it's really the other router(s) on the link that need to do this because they don't know what that router's IPv6 MTU is. I'd suggest changing the third paragraph to something like: If the M6-bit is set in a received Database Description packet for a non-IPv6 address family, the receiving router MUST NOT check the Interface MTU in the Database Exchange packet against the receiving interface's IPv6 MTU and it MUST send OSPFv3 packets no larger than 1280 octets. Thanks, Paul Acee Lindem wrote: > Those of you who have worked with me in the past will not be surprised > that I have come up with a slightly different solution. However, I think > this is a simpler approach allows an OSPFv3 router to disable IPv6 MTU > checking for non-IPv6 address families even if their IPv6 MTU matches > their IPv4 MTU. > > > 2.7. Database Description Maximum Transmissoin Unit (MTU) > Specification for Non-IPv6 AFs > > For address families other than IPv6, both the MTU for the address > family of the instance and IPv6 MTU used for OSPFv3 maximum packet > determination must be considered. The MTU in the Database > Description packet MUST always contain the MTU corresponding to the > advertised address family. For example, if the instance corresponds > to an IPv4 address family, the IPv4 MTU for the interface MUST be > specified in the interface MTU field. As specified section 10.6 of > [OSPFV2], the Database Description packet will be rejected if the MTU > is greater than the receiving interface's MTU for the address family > corresponding to the instance. This behavior will assure an > adjacency is not formed and address family specific routes are not > installed over a path with conflicting MTUs. > > The value used for OSPFv3 maximum packet size determination must also > be compatible an adjacency to be established. Since only a single > MTU field is specified, the M6-bit is defined by this specification. > If the M6-bit is set, the OSPFv3 router will send OSPFv3 packets no > larger than 1280 octets, the minimum IPv6 MTU (refer to [IPV6]). If > the M6-bit is clear, the specified MTU should also be checked against > the IPv6 MTU and the Database Description packet should be rejected > if the MTU is larger than the receiving interface's IPv6 MTU. If the > IPv6 and IPv4 MTUs differ, the M6-bit MUST be set for non-IPv6 > address families. > > If the M6-bit is set in a received Database Description packet for a > non-IPv6 address family, the receiving router MUST NOT check the > Interface MTU in the Database Exchange packet against the receiving > interface's IPv6 MTU. > > The figure below graphically depicts the OSPFv3 Database Packet: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ > | 3 | 2 | Packet Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ > | Router ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ > | Area ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ > | Checksum | Instance ID | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ > | 0 | Options | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ > | Interface MTU | 0 |0|0|0|M6|0|I|M|MS| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ > | DD sequence number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ > | | > +- -+ > | | > +- An LSA Header -+ > | | > +- -+ > | | > +- -+ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ > | ... | > > The OSPFv3 Database Description Packet > > The changed fields in the Database Description packet are described > below. The remaining fields are unchanged from [OSPFV3]. > > > Interface MTU > The size in octets of the largest address-family specific datagram > that can be sent out the associated interface without > fragmentation. The MTUs of common Internet link types can be > found in Table 7-1 of [MTUDISC]. Interface MTU should be set to 0 > in Database Description packets sent over virtual links. > > M6-bit > The Minimum IPv6 MTU bit - this bit indicates the sender wishes > that the minumum IPv6 MTU be used for OSPFv3 maximum packet size > determination. > > Thanks, > Acee > > On May 29, 2008, at 10:04 AM, Acee Lindem wrote: > >> Hi Sina, >> Other than it will be a pain to specify, I like #2 with one >> variation. I say that if the new bit is clear, the 2 MTUs are equal >> and the specified MTU is simply checked against both MTUs. If it is >> set, it means the MTUs differ and we need to use the IPv6 minimum for >> OSPFv3 packet computation. As someone may point out, it's actually >> more complex - I'll post proposed text (hopefully, later today). >> Thanks, >> Acee >> On May 28, 2008, at 10:11 PM, Sina Mirtorabi wrote: >> >>> Hi Acee, >>> >>>>> This still leaves the question of what to do for af-alt when >>>>> routing address families other than IPv6. It seems that there are >>>>> two cases of interest in deciding which MTU to advertise in >>>> the DBD >>>>> packets: >>>>> >>>>> 1. IPv6 MTUs match, but IPv4 MTUs differ. >>>>> 2. IPv6 MTUs differ, but IPv4 MTUs match. >>>>> >>>>> In the first case I don't think we're doing anyone a favor by >>>>> installing routes in the IPv4 RIB that will be unreliable due to a >>>>> MTU mismatch. >>>>> >>>>> In the second case OSPFv3 flooding and synchronization may be >>>>> compromised. A side effect of this may be that the adjacency never >>>>> forms, or having formed may later fail. >>>>> >>>>> Short of resorting to LLS or some other way of communicating both >>>>> MTUs it seems we have to pick one or the other. >>>>> >>>>> I'd like to propose that we use the DBD packet to communicate the >>>>> IPv4 MTU when routing that address family, and use the IPv6 >>>> minimum >>>>> MTU of 1280 bytes for OSPFv3 protocol packets. >>>> >>>> This is a coherent proposal. I'd like to bounce this off the other >>>> authors and would solicit general comments. The question is whether >>>> the OSPFv3 protocol checking for MTU mismatches is worth relegated >>>> OSPFv3 exchange and flooding to the the IPv6 minimum MTU. I'm not >>>> sure it does but I'd like to open it up to a brief discussion. >>> >>> One issue is backward compatibility, if there is any implementation of >>> alt draft, then we cannot just change the MTU in the DD packet from >>> IPv6 >>> to IPv4 MTU. If we don't worry about backward compatibility (no >>> deployed >>> implementation) then we have a shot to define as appropriate. There >>> are >>> couple of options >>> >>> 1) Paul's proposal however I would add that IPv6 Path MTU discovery >>> should be used. >>> >>> 2) We can set a bit in the DD packet to indicate that the MTU value is >>> for both v4 and v6, if this bit is clear (i.e. MTU mismatch between v4 >>> and v6) then the MTU field in DD packet is for corresponding AF, e.g. >>> IPv4 and for IPv6 mtu we have to use 1) (minimum MTU), the >>> advantage of >>> this is that unless MTU is really different between v4 and v6 you >>> don't >>> blindly reduce the IPv6 mtu >>> >>> 3) carry the MTU value for both IPv6 and IPv4 either in DD packet >>> (there >>> are unused octet although not contiguous block) or through LLS. >>> >>> 4) any other options >>> >>> >>> The advantage of 2) a part from simplicity is that by not knowing the >>> IPv6 MTU we fall back to minimum MTU and adj will be formed, for 3) if >>> there is a MTU mismatch then unless you change the rule and state that >>> in case of mismatch, default minimum MTU should be used, the adj will >>> not be established if we follow the MTU mismatch rule. The only >>> advantage of the 3) compared to 2) is that in case IPv4 and IPv6 does >>> not match AND IPv6 are the same between the system, the actual IPv6 >>> MTU >>> (which is carried) is used instead of Minimum MTU. >>> >>> thanks >>> Sina >>> >>>> >>>> Thanks, >>>> Acee >>>> >>>> >>>> >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> Acee Lindem wrote: >>>>>> Hi Paul, >>>>>> On May 28, 2008, at 2:05 PM, Paul Wells wrote: >>>>>>> Hi Acee, >>>>>>> >>>>>>> I disagree about the "original intent" of the MTU field. >>>> As I see >>>>>>> it, it's function is to prevent an OSPF adjacency from forming >>>>>>> over a link where the endpoints disagree about the link MTU. We >>>>>>> do this primarily to prevent the data plane from using a link >>>>>>> that will drop packets sent to a system with an MTU smaller than >>>>>>> ours. >>>>>> I happen to remember the discussion of this problem on the OSPF >>>>>> list and this was not the primary motivation. There were lots of >>>>>> problems with bridged heterogeneous LANs with mismatched MTUs >>>>>> (ethernet, FDDI, token ring, and the worst of all technologies - >>>>>> ATM emulated LANs :^). Adjacencies would come up fine initially >>>>>> but the exchange process would hang indefinitely when they were >>>>>> restarted due to the router with the larger MTU having a larger >>>>>> database and trying to use full DD packets. Unfortunately, the >>>>>> OSPF list was hosted on a server at Microsoft Corporation >>>> in those >>>>>> days and I don't have access to archives. Here is some text from >>>>>> RFC 2178, appendix G: G.9 Detecting interface MTU mismatches >>>>>> When two neighboring routers have a different interface >>>> MTU for >>>>>> their >>>>>> common network segment, serious problems can ensue: large >>>>>> packets are >>>>>> prevented from being successfully transferred from one router >>>>>> to the >>>>>> other, impairing OSPF's flooding algorithm and possibly creating >>>>>> "black holes" for user data traffic. >>>>>> This memo provides a fix for the interface MTU mismatch >>>> problem by >>>>>> advertising the interface MTU in Database Description packets. >>>>>> When a >>>>>> router receives a Database description packet advertising an MTU >>>>>> larger than the router can receive, the router drops >>>> the Database >>>>>> Description packet. This prevents an adjacency from forming, >>>>>> telling >>>>>> OSPF flooding and user data traffic to avoid the connection >>>>>> between >>>>>> the two routers. For more information, see Sections >>>> 10.6, 10.8, >>>>>> and >>>>>> A.3.3. >>>>>> On the other hand, once the MTU checking was implemented, I >>>>>> believe data plane MTU consistency has been purported as a >>>>>> benefit. If we used the IPv4 MTU in the IPv4 address database >>>>>> exchanges, we could still have an IPv6 MTU mismatch. One could >>>>>> depend on the unicast IPv6 address family for this checking but, >>>>>> heretofore, we've kept the instances independent. Thanks, >>>>>> Acee >>>>>>> >>>>>>> While OSPFv3 certainly needs to know the IPv6 link MTU when >>>>>>> building it's packets, this information should be available >>>>>>> locally without reference to the MTU field in the DBD packet. >>>>>>> >>>>>>> So, I would argue that in af-alt the MTU in the DBD >>>> packet should >>>>>>> be for the address family we are routing, not IPv6 in all cases. >>>>>>> >>>>>>> Regards, >>>>>>> Paul >>>>>>> >>>>>>> Acee Lindem wrote: >>>>>>>> Hi Prasanna, >>>>>>>> On May 28, 2008, at 8:18 AM, Prasanna Kumar A.S wrote: >>>>>>>>> Hi >>>>>>>>> I just wanted to understand what the primary use of >>>>>>>>> exchanging MTU in >>>>>>>>> DD packets and doing MTU-check is? Is it only for the control >>>>>>>>> plane or >>>>>>>>> is it for the DATA-plane? >>>>>>>> Control-plane - when sending DD, LSR, and LSU packets, OSPF >>>>>>>> will attempt to send as many LSA headers or complete LSAs as >>>>>>>> will fit in a maximum sized packet. >>>>>>>>> Why I am getting this doubt is, in draft-ietf-ospf-af- >>>>>>>>> alt-06.txt doesn't >>>>>>>>> specify which MTU we should use while exchanging the DD packet >>>>>>>>> for the >>>>>>>>> ipv4-unicast or ipv4-mutlticast Address-family, is it >>>> ipv6-mtu or >>>>>>>>> ipv4-mtu? >>>>>>>> We have this clarified in the an update which we post soon. >>>>>>>> Since this is OSPFv3 which using IPv6 for transport, >>>> you always >>>>>>>> use the IPv6 MTU. >>>>>>>> Thanks, >>>>>>>> Acee >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanna >>>>>>>>> _______________________________________________ >>>>>>>>> OSPF mailing list >>>>>>>>> OSPF@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>>>>> _______________________________________________ >>>>>>>> OSPF mailing list >>>>>>>> OSPF@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ospf >>>> >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>>> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > > ------------------------------------------------------------------------ > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu May 29 13:20:21 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AA2B28C0E4; Thu, 29 May 2008 13:20:21 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B243F28C0DB for ; Thu, 29 May 2008 13:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V638mea+Z6WF for ; Thu, 29 May 2008 13:20:18 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id B0F853A6B6C for ; Thu, 29 May 2008 13:20:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 6DAF3DAD23F; Thu, 29 May 2008 13:20:16 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16702-09; Thu, 29 May 2008 13:20:16 -0700 (PDT) Received: from [?????n?IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id B6072DAD243; Thu, 29 May 2008 13:20:15 -0700 (PDT) In-Reply-To: <483F0B31.40103@cisco.com> References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> <483D9ECE.5080300@cisco.com><483DCF2F.2040801@cisco.com> <34BDD2A93E5FD84594BB230DD6C18EA2046DBEC5@nuova-ex1.hq.nuovaimpresa.com> <1C8A838F-FFFF-414D-AF88-A3CF2A9B88C9@redback.com> <483F0B31.40103@cisco.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <8D9BA19E-F5C1-4C9A-B813-B191EF4BD1EB@redback.com> From: Acee Lindem Date: Thu, 29 May 2008 16:20:14 -0400 To: Paul Wells X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Cc: OSPF List Subject: Re: [OSPF] What is the use of MTU field in DD packet X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org Hi Paul, On May 29, 2008, at 3:59 PM, Paul Wells wrote: > Hi Acee, > > This scheme looks okay to me. I have a couple of questions/ > suggestions, though. You say: > > "If the IPv6 and IPv4 MTUs differ, the M6-bit MUST be set for non- > IPv6 address families." > > Do we also need to add a sentence like: > > If the IPv6 and IPv4 MTUs are the same, the M6-bit MUST NOT be set > for non-IPv6 address families. > > in order to preclude an implementation setting the M6-bit in all > cases? No - I'd let an implementation set the bit and use the minimum IPv6 MTU if they wanted to avoid a mismatch with their neighbors. In other words, this would handle the case where the routers IPv4 and IPv6 MTUs were the same but their neighbor's were not. > > Also, what happens when the M6-bits of routers on the link don't > match? The text specifies that the router which has differing IPv4/ > IPv6 MTUs will send 1280 byte OSPFv3 packets, but it's really the > other router(s) on the link that need to do this because they don't > know what that router's IPv6 MTU is. I'd suggest changing the third > paragraph to something like: > > If the M6-bit is set in a received Database Description packet for > a non-IPv6 address family, the receiving router MUST NOT check the > Interface MTU in the Database Exchange packet against the receiving > interface's IPv6 MTU and it MUST send OSPFv3 packets no larger than > 1280 octets. I don't think this is necessary - 10.6 of [OSPFv2] says the receiver should check that the received MTU is not greater than the receiving interface MTU. So, in short, the sender indicates what it will send (either explicitly or the minimum) and the receiver verifies that it can receive this MTU. Perhaps, I didn't articulate this well but I gotta get on another conference call in a couple minutes. Thanks, Acee > > Thanks, > Paul > > Acee Lindem wrote: >> Those of you who have worked with me in the past will not be >> surprised that I have come up with a slightly different solution. >> However, I think this is a simpler approach allows an OSPFv3 >> router to disable IPv6 MTU checking for non-IPv6 address families >> even if their IPv6 MTU matches their IPv4 MTU. 2.7. Database >> Description Maximum Transmissoin Unit (MTU) >> Specification for Non-IPv6 AFs >> For address families other than IPv6, both the MTU for the address >> family of the instance and IPv6 MTU used for OSPFv3 maximum packet >> determination must be considered. The MTU in the Database >> Description packet MUST always contain the MTU corresponding to >> the >> advertised address family. For example, if the instance >> corresponds >> to an IPv4 address family, the IPv4 MTU for the interface MUST be >> specified in the interface MTU field. As specified section >> 10.6 of >> [OSPFV2], the Database Description packet will be rejected if >> the MTU >> is greater than the receiving interface's MTU for the address >> family >> corresponding to the instance. This behavior will assure an >> adjacency is not formed and address family specific routes are not >> installed over a path with conflicting MTUs. >> The value used for OSPFv3 maximum packet size determination >> must also >> be compatible an adjacency to be established. Since only a single >> MTU field is specified, the M6-bit is defined by this >> specification. >> If the M6-bit is set, the OSPFv3 router will send OSPFv3 >> packets no >> larger than 1280 octets, the minimum IPv6 MTU (refer to >> [IPV6]). If >> the M6-bit is clear, the specified MTU should also be checked >> against >> the IPv6 MTU and the Database Description packet should be >> rejected >> if the MTU is larger than the receiving interface's IPv6 MTU. >> If the >> IPv6 and IPv4 MTUs differ, the M6-bit MUST be set for non-IPv6 >> address families. >> If the M6-bit is set in a received Database Description packet >> for a >> non-IPv6 address family, the receiving router MUST NOT check the >> Interface MTU in the Database Exchange packet against the >> receiving >> interface's IPv6 MTU. >> The figure below graphically depicts the OSPFv3 Database Packet: >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+- >> +-+--+ >> | 3 | 2 | Packet >> Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+- >> +-+--+ >> | Router >> ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+- >> +-+--+ >> | Area >> ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+- >> +-+--+ >> | Checksum | Instance ID | >> 0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+- >> +-+--+ >> | 0 | >> Options | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+- >> +-+--+ >> | Interface MTU | 0 |0|0|0|M6|0|I| >> M|MS| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+- >> +-+--+ >> | DD sequence >> number | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+- >> +-+--+ >> >> | | >> >> +- -+ >> >> | | >> +- An LSA >> Header -+ >> >> | | >> >> +- -+ >> >> | | >> >> +- -+ >> >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+- >> +-+--+ >> >> | ... | >> The OSPFv3 Database Description Packet >> The changed fields in the Database Description packet are >> described >> below. The remaining fields are unchanged from [OSPFV3]. >> Interface MTU >> The size in octets of the largest address-family specific >> datagram >> that can be sent out the associated interface without >> fragmentation. The MTUs of common Internet link types can be >> found in Table 7-1 of [MTUDISC]. Interface MTU should be >> set to 0 >> in Database Description packets sent over virtual links. >> M6-bit >> The Minimum IPv6 MTU bit - this bit indicates the sender wishes >> that the minumum IPv6 MTU be used for OSPFv3 maximum packet >> size >> determination. >> Thanks, >> Acee >> On May 29, 2008, at 10:04 AM, Acee Lindem wrote: >>> Hi Sina, >>> Other than it will be a pain to specify, I like #2 with one >>> variation. I say that if the new bit is clear, the 2 MTUs are >>> equal and the specified MTU is simply checked against both MTUs. >>> If it is set, it means the MTUs differ and we need to use the >>> IPv6 minimum for OSPFv3 packet computation. As someone may point >>> out, it's actually more complex - I'll post proposed text >>> (hopefully, later today). >>> Thanks, >>> Acee >>> On May 28, 2008, at 10:11 PM, Sina Mirtorabi wrote: >>> >>>> Hi Acee, >>>> >>>>>> This still leaves the question of what to do for af-alt when >>>>>> routing address families other than IPv6. It seems that there are >>>>>> two cases of interest in deciding which MTU to advertise in >>>>> the DBD >>>>>> packets: >>>>>> >>>>>> 1. IPv6 MTUs match, but IPv4 MTUs differ. >>>>>> 2. IPv6 MTUs differ, but IPv4 MTUs match. >>>>>> >>>>>> In the first case I don't think we're doing anyone a favor by >>>>>> installing routes in the IPv4 RIB that will be unreliable due >>>>>> to a >>>>>> MTU mismatch. >>>>>> >>>>>> In the second case OSPFv3 flooding and synchronization may be >>>>>> compromised. A side effect of this may be that the adjacency >>>>>> never >>>>>> forms, or having formed may later fail. >>>>>> >>>>>> Short of resorting to LLS or some other way of communicating both >>>>>> MTUs it seems we have to pick one or the other. >>>>>> >>>>>> I'd like to propose that we use the DBD packet to communicate the >>>>>> IPv4 MTU when routing that address family, and use the IPv6 >>>>> minimum >>>>>> MTU of 1280 bytes for OSPFv3 protocol packets. >>>>> >>>>> This is a coherent proposal. I'd like to bounce this off the other >>>>> authors and would solicit general comments. The question is >>>>> whether >>>>> the OSPFv3 protocol checking for MTU mismatches is worth relegated >>>>> OSPFv3 exchange and flooding to the the IPv6 minimum MTU. I'm not >>>>> sure it does but I'd like to open it up to a brief discussion. >>>> >>>> One issue is backward compatibility, if there is any >>>> implementation of >>>> alt draft, then we cannot just change the MTU in the DD packet >>>> from IPv6 >>>> to IPv4 MTU. If we don't worry about backward compatibility (no >>>> deployed >>>> implementation) then we have a shot to define as appropriate. >>>> There are >>>> couple of options >>>> >>>> 1) Paul's proposal however I would add that IPv6 Path MTU discovery >>>> should be used. >>>> >>>> 2) We can set a bit in the DD packet to indicate that the MTU >>>> value is >>>> for both v4 and v6, if this bit is clear (i.e. MTU mismatch >>>> between v4 >>>> and v6) then the MTU field in DD packet is for corresponding AF, >>>> e.g. >>>> IPv4 and for IPv6 mtu we have to use 1) (minimum MTU), the >>>> advantage of >>>> this is that unless MTU is really different between v4 and v6 >>>> you don't >>>> blindly reduce the IPv6 mtu >>>> >>>> 3) carry the MTU value for both IPv6 and IPv4 either in DD >>>> packet (there >>>> are unused octet although not contiguous block) or through LLS. >>>> >>>> 4) any other options >>>> >>>> >>>> The advantage of 2) a part from simplicity is that by not >>>> knowing the >>>> IPv6 MTU we fall back to minimum MTU and adj will be formed, for >>>> 3) if >>>> there is a MTU mismatch then unless you change the rule and >>>> state that >>>> in case of mismatch, default minimum MTU should be used, the adj >>>> will >>>> not be established if we follow the MTU mismatch rule. The only >>>> advantage of the 3) compared to 2) is that in case IPv4 and IPv6 >>>> does >>>> not match AND IPv6 are the same between the system, the actual >>>> IPv6 MTU >>>> (which is carried) is used instead of Minimum MTU. >>>> >>>> thanks >>>> Sina >>>> >>>>> >>>>> Thanks, >>>>> Acee >>>>> >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> Acee Lindem wrote: >>>>>>> Hi Paul, >>>>>>> On May 28, 2008, at 2:05 PM, Paul Wells wrote: >>>>>>>> Hi Acee, >>>>>>>> >>>>>>>> I disagree about the "original intent" of the MTU field. >>>>> As I see >>>>>>>> it, it's function is to prevent an OSPF adjacency from forming >>>>>>>> over a link where the endpoints disagree about the link MTU. We >>>>>>>> do this primarily to prevent the data plane from using a link >>>>>>>> that will drop packets sent to a system with an MTU smaller >>>>>>>> than >>>>>>>> ours. >>>>>>> I happen to remember the discussion of this problem on the OSPF >>>>>>> list and this was not the primary motivation. There were lots of >>>>>>> problems with bridged heterogeneous LANs with mismatched MTUs >>>>>>> (ethernet, FDDI, token ring, and the worst of all technologies - >>>>>>> ATM emulated LANs :^). Adjacencies would come up fine initially >>>>>>> but the exchange process would hang indefinitely when they were >>>>>>> restarted due to the router with the larger MTU having a larger >>>>>>> database and trying to use full DD packets. Unfortunately, the >>>>>>> OSPF list was hosted on a server at Microsoft Corporation >>>>> in those >>>>>>> days and I don't have access to archives. Here is some text from >>>>>>> RFC 2178, appendix G: G.9 Detecting interface MTU mismatches >>>>>>> When two neighboring routers have a different interface >>>>> MTU for >>>>>>> their >>>>>>> common network segment, serious problems can ensue: large >>>>>>> packets are >>>>>>> prevented from being successfully transferred from one router >>>>>>> to the >>>>>>> other, impairing OSPF's flooding algorithm and possibly >>>>>>> creating >>>>>>> "black holes" for user data traffic. >>>>>>> This memo provides a fix for the interface MTU mismatch >>>>> problem by >>>>>>> advertising the interface MTU in Database Description >>>>>>> packets. >>>>>>> When a >>>>>>> router receives a Database description packet advertising >>>>>>> an MTU >>>>>>> larger than the router can receive, the router drops >>>>> the Database >>>>>>> Description packet. This prevents an adjacency from forming, >>>>>>> telling >>>>>>> OSPF flooding and user data traffic to avoid the connection >>>>>>> between >>>>>>> the two routers. For more information, see Sections >>>>> 10.6, 10.8, >>>>>>> and >>>>>>> A.3.3. >>>>>>> On the other hand, once the MTU checking was implemented, I >>>>>>> believe data plane MTU consistency has been purported as a >>>>>>> benefit. If we used the IPv4 MTU in the IPv4 address database >>>>>>> exchanges, we could still have an IPv6 MTU mismatch. One could >>>>>>> depend on the unicast IPv6 address family for this checking but, >>>>>>> heretofore, we've kept the instances independent. Thanks, >>>>>>> Acee >>>>>>>> >>>>>>>> While OSPFv3 certainly needs to know the IPv6 link MTU when >>>>>>>> building it's packets, this information should be available >>>>>>>> locally without reference to the MTU field in the DBD packet. >>>>>>>> >>>>>>>> So, I would argue that in af-alt the MTU in the DBD >>>>> packet should >>>>>>>> be for the address family we are routing, not IPv6 in all >>>>>>>> cases. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Paul >>>>>>>> >>>>>>>> Acee Lindem wrote: >>>>>>>>> Hi Prasanna, >>>>>>>>> On May 28, 2008, at 8:18 AM, Prasanna Kumar A.S wrote: >>>>>>>>>> Hi >>>>>>>>>> I just wanted to understand what the primary use of >>>>>>>>>> exchanging MTU in >>>>>>>>>> DD packets and doing MTU-check is? Is it only for the control >>>>>>>>>> plane or >>>>>>>>>> is it for the DATA-plane? >>>>>>>>> Control-plane - when sending DD, LSR, and LSU packets, OSPF >>>>>>>>> will attempt to send as many LSA headers or complete LSAs as >>>>>>>>> will fit in a maximum sized packet. >>>>>>>>>> Why I am getting this doubt is, in draft-ietf-ospf-af- >>>>>>>>>> alt-06.txt doesn't >>>>>>>>>> specify which MTU we should use while exchanging the DD >>>>>>>>>> packet >>>>>>>>>> for the >>>>>>>>>> ipv4-unicast or ipv4-mutlticast Address-family, is it >>>>> ipv6-mtu or >>>>>>>>>> ipv4-mtu? >>>>>>>>> We have this clarified in the an update which we post soon. >>>>>>>>> Since this is OSPFv3 which using IPv6 for transport, >>>>> you always >>>>>>>>> use the IPv6 MTU. >>>>>>>>> Thanks, >>>>>>>>> Acee >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanna >>>>>>>>>> _______________________________________________ >>>>>>>>>> OSPF mailing list >>>>>>>>>> OSPF@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>>>>>> _______________________________________________ >>>>>>>>> OSPF mailing list >>>>>>>>> OSPF@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>> >>>>> _______________________________________________ >>>>> OSPF mailing list >>>>> OSPF@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ospf >>>>> >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >> --------------------------------------------------------------------- >> --- >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From info@uklottery.org Thu May 29 17:46:28 2008 Return-Path: X-Original-To: ietfarch-ospf-archive@core3.amsl.com Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDF2F3A63C9 for ; Thu, 29 May 2008 17:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.745 X-Spam-Level: **** X-Spam-Status: No, score=4.745 tagged_above=-999 required=5 tests=[BAYES_60=1, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_93=0.6, LOTTERY_PH_004470=2.015] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbsHN6AEf51q for ; Thu, 29 May 2008 17:46:26 -0700 (PDT) Received: from pop1.oxfordnetworks.net (pop1.oxfordnetworks.net [66.231.220.66]) by core3.amsl.com (Postfix) with ESMTP id D36533A6BD5 for ; Thu, 29 May 2008 17:44:06 -0700 (PDT) Received: from webmail.megalink.net (localhost.localdomain [127.0.0.1]) by pop1.oxfordnetworks.net (Postfix) with ESMTP id 39375C0C7EF; Thu, 29 May 2008 10:29:36 -0400 (EDT) Received: from 83.138.136.91 (proxying for 81.199.180.76, 127.0.0.1) (SquirrelMail authenticated user klm) by webmail.megalink.net with HTTP; Thu, 29 May 2008 10:29:40 -0400 (EDT) Message-ID: <45930.83.138.136.91.1212071380.squirrel@webmail.megalink.net> Date: Thu, 29 May 2008 10:29:40 -0400 (EDT) Subject: Lucky Winner Confirm Reciept !!! From: "UNITED KINGDOM LOTTERY BOARD" Reply-To: aandrew6@btinternet.com User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; You won the sum of £1.000,000.00 GBP from our monthly UkLottery Promotion,you are hereby adviced to get back to us, to claim your prize. Contact Mr.Abel Andrew Email:aandrew6@btinternet.com Phone: +447024068762 Claims Requirements: 1.full name: 2.Home Address: 3.Age: 4.Sex: 5.Phone Number: 6.Country Of Residence. Mrs. Rose Wood. From ospf-bounces@ietf.org Thu May 29 23:28:51 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CC2628C0F9; Thu, 29 May 2008 23:28:51 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DB1E3A6B73 for ; Thu, 29 May 2008 23:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[AWL=1.019, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uAy1R6nH2rK for ; Thu, 29 May 2008 23:28:49 -0700 (PDT) Received: from n71.bullet.mail.sp1.yahoo.com (n71.bullet.mail.sp1.yahoo.com [98.136.44.36]) by core3.amsl.com (Postfix) with SMTP id 4A2063A6C13 for ; Thu, 29 May 2008 23:28:49 -0700 (PDT) Received: from [216.252.122.219] by n71.bullet.mail.sp1.yahoo.com with NNFMP; 30 May 2008 06:28:48 -0000 Received: from [69.147.84.116] by t4.bullet.sp1.yahoo.com with NNFMP; 30 May 2008 06:28:48 -0000 Received: from [127.0.0.1] by omp208.mail.sp1.yahoo.com with NNFMP; 30 May 2008 06:28:48 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 416639.44388.bm@omp208.mail.sp1.yahoo.com Received: (qmail 91304 invoked by uid 60001); 30 May 2008 06:28:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=cN9vT5K4jsaqTbVaX26S7vvXZKW5d+LmYUPVloPgiaeDwb7lBEXJmLyslh6n3am27DSCd7TSkVS4sMaBDqV66YZBfxF9Pi9nUMGyXnv7QNBgSsWqaJ9/HneTMFH779ikbdDXeDPd7XxvflkDtTomC5LdNHdWt6Sb2Z6mjW7sTk4=; X-YMail-OSG: OUwYtukVM1kyqNFip2UDDzWBBe8gP1HMG7.zO9WUS2bdYgsUahLZgfa8oOXRd1i8Rw-- Received: from [203.129.222.168] by web46314.mail.sp1.yahoo.com via HTTP; Thu, 29 May 2008 23:28:48 PDT X-Mailer: YahooMailRC/975.41 YahooMailWebService/0.7.185 Date: Thu, 29 May 2008 23:28:48 -0700 (PDT) From: Jennifer Christy To: ospf@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-427061362-1212128928=:89284" Message-ID: <152196.89284.qm@web46314.mail.sp1.yahoo.com> Subject: [OSPF] Fw: Tye - 5 and Type -3 LSA issues X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --0-427061362-1212128928=:89284 Content-Type: multipart/alternative; boundary="0-974380720-1212128928=:89284" --0-974380720-1212128928=:89284 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi ,=0A=0AWe are using zebra-0.93b in all the routers , installed it in thr= ee linux boxes.=0A=0AAs per the topology ( PPT attached ) , we have three r= outers A , B , C in our setup.=0ASteps to reproduce the issue :=0A1. Router= A is sending a Type 5 LSA route 172.25.25.0/24 ( External Route ) via 11.1= 1.11.11 to Router C.=0A2. Router B is sending a Type 3 LSA route 172.25.25.= 0/24 via 12.12.12.12 to Router C.=0A=0ALet me explain the issue.=0A=0ACase = 1 :=0A=0A1. Enable OSPF in Router C on interface ( 12.12.12.10 ) =0A2. Then= Type - 3 LSA Route 172.25.25.0/24 via 12.12.12.12 from Router B will be ad= ded to Router C.=0A3. Now Router C will have the route 172.25.25.0/24 via 1= 2.12.12.12. ( Added by Type -3 LSA )=0A4. Enable OSPF in Router C opn inter= face ( 11.11.11.10 )=0A5. Then Type - 5 LSA Route 172.25.25.0/24 from Route= r A is not added to Router C , because while comparing the Type - 5 and Typ= e - 3 , its adding the best route as Type - 3 Route.=0A6. So the Router wil= l have the Type - 3 route in routing table=0A=0ACase 2 : =0A=0A1. Enable OS= PF in Router C on interface ( 11.11.11.10 ).=0A2. Then Type - 5 LSA Route 1= 72.25.25.0/24 via 11.11.11.11 from Router A will be added to Router C.=0A3.= Now Router C will have the route 172.25.25.0/24 via 11.11.11.11 ( Added by= Type -5 LSA )=0A4. Enable OSPF in Router C on interface ( 12.12.12.10 ) = =0A5. Now Type - 3 ( 172.25.25.0/24 via 12.12.12.12 ) is the best route whe= n compared to Type -5 route =0A( 172.25.25.0/24 via 11.11.11.11 ) , so zebr= a is sending a message to delete the Type -5 route.=0A6. And its sending a = message to add the Type -3 route.So Type - 3 route is added into the Router= C.=0A7. Here the issue starts , again zebra is sending a message to delete= the existing the Type - 3 route from the Router C.=0A8. So the Type - 3 ro= ute is deleted from the routing table , now there is no routes for 172.25.2= 5.0/24 in the routing table.=0A=0AThis is the real issue , not happening wh= en u enable type -3 first.=0A=0AWe dont know this is an usual behaviour or = its really an issue=0APlease let us know the this is an already existing is= sue or if any patch is there for this issue that would be fine.=0A=0AWe wan= t to know the root cause analysis of this issue .=0AIts a long mail but hop= e you understand it.=0APlease reply as soon as possible.=0A=0ANote :=0AThe = issue is reproducible in latest version also ( zebra-0.95a )=A0=0AIf you ne= ed any help in reproducing / understanding the issue , please let us know.= =0A=0AThanks in Advance ,=0AJenny=0A=0A=0A --0-974380720-1212128928=:89284 Content-Type: text/html; charset=us-ascii
Hi ,

We are using zebra-0.93b in all the routers , installed it in three linux boxes.

As per the topology ( PPT attached ) , we have three routers A , B , C in our setup.
Steps to reproduce the issue :
1. Router A is sending a Type 5 LSA route 172.25.25.0/24 ( External Route ) via 11.11.11.11 to Router C.
2. Router B is sending a Type 3 LSA route 172.25.25.0/24 via 12.12.12.12 to Router C.

Let me explain the issue.

Case 1 :

1. Enable OSPF in Router C on interface ( 12.12.12.10 )
2. Then Type - 3 LSA Route 172.25.25.0/24 via 12.12.12.12 from Router B will be added to Router C.
3. Now Router C will have the route 172.25.25.0/24 via 12.12.12.12. ( Added by Type -3 LSA )
4. Enable OSPF in Router C opn interface ( 11.11.11.10 )
5. Then Type - 5 LSA Route 172.25.25.0/24 from Router A is not added to Router C , because while comparing the Type - 5 and Type - 3 , its adding the best route as Type - 3 Route.
6. So the Router will have the Type - 3 route in routing table

Case 2 :

1. Enable OSPF in Router C on interface ( 11.11.11.10 ).
2. Then Type - 5 LSA Route 172.25.25.0/24 via 11.11.11.11 from Router A will be added to Router C.
3. Now Router C will have the route 172.25.25.0/24 via 11.11.11.11 ( Added by Type -5 LSA )
4. Enable OSPF in Router C on interface ( 12.12.12.10 )
5. Now Type - 3 ( 172.25.25.0/24 via 12.12.12.12 ) is the best route when compared to Type -5 route
( 172.25.25.0/24 via 11.11.11.11 ) , so zebra is sending a message to delete the Type -5 route.
6. And its sending a message to add the Type -3 route.So Type - 3 route is added into the Router C.
7. Here the issue starts , again zebra is sending a message to delete the existing the Type - 3 route from the Router C.
8. So the Type - 3 route is deleted from the routing table , now there is no routes for 172.25.25.0/24 in the routing table.

This is the real issue , not happening when u enable type -3 first.

We dont know this is an usual behaviour or its really an issue
Please let us know the this is an already existing issue or if any patch is there for this issue that would be fine.

We want to know the root cause analysis of this issue .
Its a long mail but hope you understand it.
Please reply as soon as possible.

Note :
The issue is reproducible in latest version also ( zebra-0.95a ) 
If you need any help in reproducing / understanding the issue , please let us know.

Thanks in Advance ,
Jenny
   



--0-974380720-1212128928=:89284-- --0-427061362-1212128928=:89284 Content-Type: application/octet-stream; name="issue.ppt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="issue.ppt" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwADAP7/CQAGAAAAAAAAAAAAAAAC AAAAmQAAAAAAAAAAEAAAAgAAAAEAAAD+////AAAAAAAAAACAAAAA//////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ///////////////////////9//////////7////+////BQAAAAYAAAAHAAAA CAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAAT AAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4A AAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAA ACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAA NQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABA AAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsA AABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAA AFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAA YgAAAGMAAABkAAAAZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABt AAAAbgAAAG8AAABwAAAAcQAAAHIAAABzAAAAdAAAAP7///92AAAAdwAAAHgA AAB5AAAAegAAAHsAAAB8AAAAfQAAAH4AAAB/AAAAgQAAAFIAbwBvAHQAIABF AG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAWAAUA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA/v///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD+////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP// /////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AP7///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v///wAA AAAAAAAA/v////7////+////BAAAAAUAAAAGAAAA/v////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////8BAP7/AwoAAP////8QjYFkm0/PEYbq AKoAuSnoEQAAAE1TIFBvd2VyUG9pbnQgOTcAAAAAAAAAAAAAAAAAAAAAAQAA AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA9g8kAAAAFAAAAF/AkeN2RQAADAD0AwMAAABD dXJyZW50IFVzZXIIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAA AAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4b EJOXCAArLPmuTAAAAAgAAAAAAAAAmAAAAAMAAAAAAAAAIAAAAAEAAAA4AAAA AgAAAEAAAAABAAAAAgAAAAoAAABfUElEX0dVSUQAAAACAAAA5AQAAEEAAABO AAAAewBEAEIAMQBBAEMAOQA2ADQALQBFADMAOQBDAC0AMQAxAEQAMgAtAEEA MQBFAEYALQAwADAANgAwADkANwBEAEEANQA2ADgAOQB9AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAE AAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAGjh AAACAAAAAgAAABgAAAARAAAAMAAAAB8AAAAIAAAAUwBsAGkAZABlACAAMQAA AEcAAAAw4QAA/////wgAAAAoAAAAoAAAAHgAAAABABgAAAAAAADhAAAAAAAA AAAAAAAAAAAAAAAA//////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////AAAAAAAA //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////AAAAAAAA//////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////AAAAAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////AAAA////AAAAAAAA////AAAAAAAA AAAA////AAAA////AAAAAAAAAAAAAAAA//////////////////////////// AAAA/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZAAAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////AAAA//// ////AAAA////////AAAA////////AAAAAAAAAAAA////////////AAAAAAAA AAAA////////AAAA////////////////////////AAAA/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZAAAA//////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////AAAAAAAAAAAAAAAA ////AAAAAAAAAAAAAAAA////////AAAAAAAAAAAAAAAA////AAAAAAAA//// ////////////////////AAAA/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZAAAA//////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// AAAA/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZAAAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////AAAA/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZAAAA//////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////AAAA/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZAAAA//////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////AAAA/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZAAAA//////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////AAAA/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZAAAA/8yZAAAAAAAAAAAA/8yZAAAAAAAA/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZAAAA//////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////AAAA/8yZ /8yZ/8yZAAAA/8yZAAAAAAAA/8yZAAAAAAAA/8yZAAAA/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZAAAA//////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// AAAA/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZAAAAAAAAAAAA/8yZ AAAA/8yZ/8yZAAAAAAAA/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZAAAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////AAAA/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ AAAAAAAA/8yZAAAAAAAA/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZAAAA/8yZAAAAAAAAAAAA/8yZAAAAAAAAAAAA /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZAAAA//////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////AAAA/8yZ/8yZ/8yZ/8yZAAAA/8yZAAAAAAAA/8yZAAAAAAAA AAAA/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZAAAAAAAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////AAAA/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZAAAA//////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////AAAA/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZAAAA////AAAA//// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// AAAA/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZAAAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////AAAA/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZAAAA////////AAAA//////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////AAAA/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZAAAA//////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////AAAA/8yZ/8yZ/8yZAAAA/8yZAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA/8yZAAAA/8yZ/8yZ/8yZ/8yZAAAAAAAA/8yZ/8yZ/8yZ/8yZ/8yZ /8yZAAAA////////////AAAA//////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////AAAA/8yZ /8yZ/8yZAAAAAAAA/8yZAAAAAAAAAAAA/8yZAAAAAAAAAAAA/8yZAAAA/8yZ AAAAAAAA/8yZAAAAAAAA/8yZ/8yZ/8yZ/8yZ/8yZ/8yZAAAA//////////// ////AAAA////////////////AAAA////AAAAAAAA////AAAAAAAAAAAA//// AAAA////AAAAAAAAAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////AAAA/8yZ/8yZ/8yZAAAAAAAA/8yZ /8yZ/8yZ/8yZ/8yZAAAA/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZAAAAAAAA /8yZ/8yZ/8yZ/8yZ/8yZ/8yZAAAA////////////////AAAAAAAA////AAAA ////////AAAA////////AAAAAAAAAAAA////////////AAAAAAAAAAAA//// AAAA////AAAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////AAAA/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ/8yZ /8yZAAAA////////////////////////AAAAAAAAAAAAAAAAAAAA////AAAA AAAAAAAAAAAA////////AAAAAAAAAAAAAAAA//////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////// ////////////////AAAA//////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AAAA ////AAAA////////AAAA////AAAA////AAAA////AAAA////////AAAA//// ////////////////////////////////////AAAAAAAA//////////////// //////////////////////////////////////////////////////////// AAAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////AAAA////AAAA////////AAAA////AAAA ////////AAAAAAAA////////AAAA////AAAA//////////////////////// ////////////////AAAAAAAA//////////////////////////////////// ////////////////////////////////////////////AAAA//////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AAAA ////AAAA//////////////////////////////////////////////////// ////////////////////////////AAAA//////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////AAAA////AAAA//////////// //////////////////////////////////////////////////////////// ////////////AAAA//////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////AAAA////////AAAA//////////////////////////// ////////////////////////////////////////////////////////AAAA //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AAAA ////////AAAA//////////////////////////////////////////////// ////////////////////////////////////////AAAA//////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////AAAA////////////AAAA//// //////////////////////////////////////////////////////////// ////////////////////////AAAA//////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////AAAA////////////AAAA//////////////////////// //////////////////////////////////////////////////////////// ////////AAAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AAAA ////////////////AAAA//////////////////////////////////////// ////////////////////////////////////////////////////AAAA//// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////AAAA////////////////AAAA //////////////////////////////////////////////////////////// ////////////////////////////////////AAAA//////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////AAAA////////////////////AAAA//////////////// //////////////////////////////////////////////////////////// ////////////////////AAAA//////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AAAA ////////////////////AAAA//////////////////////////////////// //////////////////////////////////////////////////////////// ////AAAA//////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////AAAA//////////////////// ////AAAA//////////////////////////////////////////////////// ////////////////////////////////////////////////AAAA//////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////AAAA////////////////////////AAAA//////////// //////////////////////////////////////////////////////////// ////////////////////////////////AAAA//////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AAAA //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////AAAA//////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AAAA //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////AAAA//////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AAAA //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////AAAA//////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////AAAA////AAAA////AAAA////////////AAAAAAAA////AAAA//// ////AAAAAAAAAAAAAAAA////////////////////////////////////AAAA ////////////////AAAAAAAA////AAAA////AAAAAAAA////AAAAAAAA//// ////////////AAAA////////////AAAA////////AAAA//////////////// ////////////////////////AAAAAAAA////AAAA////AAAAAAAA////AAAA AAAA////////AAAA////AAAAAAAA////////AAAAAAAA////AAAAAAAA//// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////AAAA////////////AAAA////AAAA AAAAAAAAAAAA////////////AAAA////AAAA////////////AAAAAAAAAAAA ////////////////////////////////////AAAA////////////////AAAA AAAA////AAAAAAAA////AAAAAAAAAAAAAAAA////////AAAA////////AAAA ////////////AAAA////////AAAA//////////////////////////////// ////AAAAAAAA////AAAAAAAA////AAAAAAAAAAAAAAAA////////////AAAA ////////AAAA////////////AAAA////////AAAA//////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////AAAA////////AAAAAAAA////AAAAAAAAAAAA//////////// AAAAAAAA////AAAA////////AAAAAAAA////AAAA//////////////////// ////////////////AAAA////////////////////AAAA////AAAAAAAA//// AAAA////////AAAA//////////////////////////////////////////// ////////////////////////////////////////////////AAAA////AAAA AAAA////AAAA////////AAAA////////AAAAAAAA////AAAAAAAA//////// AAAAAAAA////AAAAAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AAAA //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////AAAA//////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////AAAA//////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AAAA //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////AAAA//////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////AAAA////AAAA////////AAAA ////AAAA////AAAA////AAAA////////AAAA//////////////////////// ////////////////AAAA//////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////AAAA////AAAA////////AAAA////AAAA////////AAAAAAAA//// ////AAAA////AAAA////////////////////////////////////////AAAA //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////AAAA//////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////AAAA4+C74+C7 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7AAAA//////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////AAAA4+C74+C74+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C7AAAA//////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////AAAA4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 AAAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////AAAA4+C74+C7 4+C7AAAA4+C7AAAAAAAAAAAAAAAAAAAAAAAA4+C74+C74+C7AAAA4+C74+C7 AAAA4+C7AAAA4+C7AAAAAAAAAAAA4+C74+C74+C7AAAA//////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////AAAA4+C74+C74+C7AAAAAAAA4+C7AAAA 4+C7AAAAAAAA4+C7AAAAAAAA4+C7AAAAAAAA4+C7AAAAAAAA4+C74+C7AAAA 4+C74+C74+C74+C74+C7AAAA//////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////AAAA4+C74+C74+C7AAAAAAAA4+C7AAAAAAAAAAAAAAAA4+C7AAAA AAAA4+C7AAAA4+C74+C7AAAAAAAA4+C74+C7AAAAAAAA4+C74+C74+C74+C7 AAAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////AAAA4+C74+C7 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7AAAA//////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////AAAA4+C74+C74+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C7AAAA//////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////AAAA//////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////AAAA//////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////AAAAAAAAAAAAAAAA//////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////AAAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// AAAAAAAA4+C74+C74+C74+C7AAAAAAAA//////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////AAAA//////// ////AAAA////////////////AAAA////////AAAA////////AAAA//////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////AAAA4+C74+C74+C74+C74+C7 4+C74+C74+C7AAAA//////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////AAAA////AAAA////////AAAA////AAAA////AAAA////AAAA ////////AAAA////AAAA////////AAAA//////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////AAAA4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7AAAA //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////AAAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////AAAA4+C74+C7 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7AAAA//////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////AAAA//////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////AAAA4+C74+C74+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C7AAAA//////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////AAAA//////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////AAAA4+C7AAAAAAAAAAAAAAAA4+C7AAAAAAAA4+C74+C74+C74+C7 AAAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////AAAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////AAAA4+C7AAAA 4+C7AAAAAAAA4+C7AAAA4+C7AAAA4+C74+C74+C7AAAA//////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////AAAA//////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////AAAA4+C74+C74+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C7AAAA//////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////AAAA//////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////AAAA4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 AAAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////AAAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////AAAAAAAA4+C7 4+C74+C74+C74+C74+C74+C74+C74+C74+C7AAAAAAAA//////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////AAAA//////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////AAAAAAAA4+C74+C74+C74+C74+C7 4+C74+C74+C7AAAAAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////AAAA//////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////AAAAAAAAAAAA4+C74+C74+C74+C7AAAAAAAAAAAA//// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////AAAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////AAAAAAAAAAAAAAAAAAAAAAAA//////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////AAAA//////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////AAAA//////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////AAAAAAAA////AAAAAAAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA//////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////AAAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////AAAA////AAAAAAAA//////// AAAA////AAAA////////AAAAAAAA////////AAAA////AAAA//////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////mTMz//////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////AAAA//////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////mTMz//////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////AAAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////mTMz//////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////AAAA//////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////mTMz//////////////////////////////////////////////////// ////////////////////////////////AAAA//////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////AAAA////////AAAAAAAAAAAAAAAA//////////////// //////////////////////////////////////////////////////////// ////////////////////////////AAAA//////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////mTMz//////////// //////////////////////////////////////////////////////////// AAAAAAAA////AAAA////AAAAAAAAAAAAAAAAAAAA////AAAAAAAA//////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AAAA ////////////AAAAAAAAAAAA//////////////////////////////////// //////////////////////////////////////////////////////////// ////////AAAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////mTMz//////////////////////////////// ////////////////////////////////////////////AAAA////AAAAAAAA AAAA////AAAAAAAAAAAA////AAAAAAAAAAAA//////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////AAAA////////AAAAAAAA//// AAAA//////////////////////////////////////////////////////// ////////////////////////////////////////////////AAAA//////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////mTMz//////////////////////////////////////////////////// ////////////////////AAAAAAAA////////////////////AAAA//////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////AAAA//////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////mTMz//////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////AAAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////mTMz//////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////AAAA//// AAAA////AAAA////////////AAAAAAAA//////////////////////////// ////////////////////////////////////////////////AAAA//////// ////////////////////////////////////////AAAAAAAA////AAAAAAAA ////AAAA////AAAAAAAAAAAA////AAAA////////AAAA//////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////mTMz//////////////////////////////////////////////////// ////////////////////AAAAAAAA////AAAAAAAAAAAA////AAAAAAAAAAAA ////AAAAAAAAAAAAAAAA////AAAAAAAA////AAAAAAAAAAAAAAAA//////// //////////////////////////////////////////////////////////// ////////////////AAAA////////////AAAA////AAAAAAAAAAAAAAAA//// ////AAAAAAAA//////////////////////////////////////////////// ////////////////////////////AAAA//////////////////////////// ////////////////////AAAAAAAA////////AAAA////AAAA////////AAAA AAAA////////AAAA////AAAA//////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// AAAAAAAA////AAAA////AAAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA////AAAA////AAAA//////////////////////////////// ////////////////////////////////////////////////////////AAAA ////////AAAAAAAA////AAAAAAAAAAAA////////////AAAAAAAA//////// ////////////////////////AAAA////////////AAAA//////////////// AAAA////AAAA//////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AAAA AAAA////AAAAAAAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////// ////////////////////////////////////////////AAAA//////////// AAAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////AAAA////AAAA ////AAAA////AAAA////////AAAA////AAAA////AAAA////AAAA//////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////AAAA////AAAAAAAA////////AAAA//// AAAA////////AAAA////AAAA////AAAA//////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////AAAA//////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA//////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AAAA 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7AAAA//////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////AAAA4+C7 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7AAAA//////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////AAAA4+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C74+C7AAAA//////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////AAAA4+C74+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C7AAAA//////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////AAAA4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 4+C7AAAA//////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////AAAA4+C74+C74+C74+C74+C74+C74+C7AAAA4+C7AAAAAAAA AAAAAAAAAAAAAAAA4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 AAAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AAAA 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7AAAA//////////// ////////////////////////////////////////////////////AAAA//// AAAA////AAAA////AAAA////AAAAAAAA////AAAA////AAAA////AAAA4+C7 4+C74+C74+C74+C74+C74+C7AAAAAAAAAAAAAAAA4+C7AAAA4+C7AAAA4+C7 AAAA4+C74+C74+C74+C74+C74+C74+C74+C74+C7AAAA//////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////AAAA4+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C74+C7AAAA//////////////////////////////// ////////////////////////////////AAAA////AAAA////AAAA////AAAA ////////AAAA////AAAA////////AAAAAAAA4+C74+C74+C74+C74+C74+C7 4+C7AAAA4+C7AAAAAAAAAAAAAAAAAAAAAAAA4+C7AAAA4+C74+C74+C74+C7 4+C74+C74+C74+C74+C7AAAA//////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////AAAA4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 4+C7AAAA//////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////AAAA4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 4+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C74+C7 AAAA//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AAAA 4+C7AAAA4+C7AAAAAAAAAAAA4+C7AAAAAAAA4+C74+C74+C7AAAA4+C7AAAA 4+C7AAAA4+C74+C74+C74+C74+C7AAAAAAAA4+C74+C7AAAA//////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////AAAA4+C7AAAAAAAAAAAA4+C7 AAAA4+C7AAAA4+C7AAAA4+C74+C7AAAAAAAAAAAAAAAA4+C74+C7AAAAAAAA 4+C74+C7AAAAAAAA4+C74+C7AAAA//////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////AAAA4+C7AAAAAAAAAAAAAAAAAAAA4+C7AAAA4+C7AAAA 4+C74+C7AAAA4+C7AAAAAAAA4+C74+C74+C74+C74+C74+C74+C7AAAA4+C7 4+C7AAAA//////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAOgD+gQAAAEA6QMoAAAAgBYA AOAQAADgEAAAgBYAAAEAAAACAAAAAwAAAAAAAAABAAAAAAAAAQ8A8gP0AQAA LwDIDwwAAAAwANIPBAAAAAAAAAAPANUHmAAAAAAAtw9EAAAAVABpAG0AZQBz ACAATgBlAHcAIABSAG8AbQBhAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABhAQALcPRAAAAEEAcgBpAGEAbAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYg AACkDxAAAACAAGYAAAD/////EgAAAAAAAACpDwoAAAAHAAAAAgAJCAAAQACj Dw4BAAAFAP/9PwAOACIgAQBkAAAAAP4AAFcAAAAAAAAAAAAgAQAAAAAHAAAA ///vAAAAAQABAP////8SAAAAAP4AAP99IAAOACIgAQBkAAAAAP4AAFcAAAAA ACABIAEAAP//7wAAAAEAAQD/////EgAAAAD+AAD/fSAADgAiIAEAZAAAAAD+ AABXAAAAAABAAkACAAD//+8AAAABAAEA/////xIAAAAA/gAA/30gAA4AIiAB AGQAAAAA/gAAVwAAAAAAYANgAwAA///vAAAAAQABAP////8SAAAAAP4AAP99 IAAOACIgAQBkAAAAAP4AAFcAAAAAAIAEgAQAAP//7wAAAAEAAQD/////EgAA AAD+AAAPAAsEjAAAAA8AAPCEAAAAAAAG8DAAAAAEEAAABQAAADoAAAAEAAAA AQAAAAcAAAACAAAABQAAAAMAAAAuAAAABAAAAAQAAAAfAAHwAAAAAGMAC/Ak AAAAgQEAuP8AgwEAAAAAvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIQAAe8RAA AAAEAAAIAQAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAIAAAAAAAAAAAAA AAAAAIAAAAAADwDQBz4BAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAABAAAA DwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAAVQAAAGQAAABVAAAAZAAAAFUA AABkAAAAVQAAAGQAAACsFwAA2g0AAPT8//+s////AQAAAHAA+wMIAAAAAAAA AHAIAABwAPsDCAAAAAEAAABACwAADwAHBDwAAAAAAP0DNAAAAKoAAADIAAAA qgAAAMgAAACqAAAAyAAAAKoAAADIAAAArBcAANoNAAD0/P//rP///wEAAAAf APoDZwAAAAAA/gMDAAAAAQEAAAD9AzQAAAA7AAAAZAAAADsAAABkAAAAOwAA AGQAAAA7AAAAZAAAAKwXAAAMDwAAKPn//7j///8BAAAAcAD7AwgAAAAAAAAA QAsAAHAA+wMIAAAAAQAAAHAIAAA/ANkPDAAAAAAA2g8EAAAADQAlAE8A2Q8M AAAAAADaDwQAAAANAD0ADwDwDxwAAAAAAPMDFAAAAAQAAAAAAAAAAAAAAAAB AAAAAAAALwDwDxwAAAAAAPMDFAAAAAUAAAAEAAAAAAAAAAABAAAAAAAAAQAB BFAAAAAAAAAB////fwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAA6gMA AAAADwD4AwwSAAACAO8DGAAAAAEAAAABAgAAAAAAAAAAAAAAAAAAAAAAAGAA 8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgBgAPAHIAAA AAAA/wD///8AAAAAAP//AAD/mQAAAP//AP8AAACWlpYAYADwByAAAAD//8wA AAAAAGZmMwCAgAAAM5kzAIAAAAAAM8wA/8xmAGAA8AcgAAAA////AAAAAAAz MzMAAAAAAN3d3QCAgIAATU1NAOrq6gBgAPAHIAAAAP///wAAAAAAgICAAAAA AAD/zGYAAAD/AMwAzADAwMAAYADwByAAAAD///8AAAAAAICAgAAAAAAAwMDA AABm/wD/AAAAAJkAAGAA8AcgAAAA////AAAAAACAgIAAAAAAADOZ/wCZ/8wA zADMALKysgAAAKMPDgEAAAUA//0/AA4AIiABAGQAAAAA/gEAVwAAAAAAAAAA ACABAAAAAAcAAAD//+8AAAABAAEA/////ywAAAAA/gAA/30gAA4AIiABAGQA AAAA/gEAVwAAAAAAAAAAAAAA///vAAAAAQABAP////8sAAAAAP4AAP99IAAO ACIgAQBkAAAAAP4BAFcAAAAAAAAAAAAAAP//7wAAAAEAAQD/////LAAAAAD+ AAD/fSAADgAiIAEAZAAAAAD+AQBXAAAAAAAAAAAAAAD//+8AAAABAAEA//// /ywAAAAA/gAA/30gAA4AIiABAGQAAAAA/gEAVwAAAAAAAAAAAAAA///vAAAA AQABAP////8sAAAAAP4AABAAow8OAQAABQD//T8ADwAiIAEAZAAAAAD+AABX AMD/AADWAAAAIAEAAAAABwAAAP//7wAAAAEAAQD/////IAAAAAD+AAD/fSAA DwATIAEAZAAAAAD+AABXAMj/AADSASABAAD//+8AAAABAAEA/////xwAAAAA /gAA/30gAA8AIiABAGQAAAAA/gAAVwDQ/wAA0AJAAgAA///vAAAAAQABAP// //8YAAAAAP4AAP99IAAPABMgAQBkAAAAAP4AAFcA2P8AAPADYAMAAP//7wAA AAEAAQD/////FAAAAAD+AAD/fSAADwC7AAEAZAAAAAD+AABXANj/AAAQBYAE AAD//+8AAAABAAEA/////xQAAAAA/gAAIACjDw4BAAAFAP/9PwAOACIgAABk AAAAAP4AAGQAHgAAAAAAAAAgAQAAAAACAAAA///vAAAAAAD///////8MAAAA AP4AAP99IAAOABMgAABkAAAAAP4AAGQAHgAAANQBIAEAAP//7wAAAAAA//// ////DAAAAAD+AAD/fSAADgAiIAAAZAAAAAD+AABkAB4AAADQAkACAAD//+8A AAAAAP///////wwAAAAA/gAA/30gAA4AEyAAAGQAAAAA/gAAZAAeAAAA8ANg AwAA///vAAAAAAD///////8MAAAAAP4AAP99IAAOALsAAABkAAAAAP4AAGQA HgAAABAFgAQAAP//7wAAAAAA////////DAAAAAD+AABAAKMPDgEAAAUA//0/ AA4AIiABAGQAAAAA/gAAVwAAAAAAAAAAACABAAAAAAcAAAD//+8AAAABAAEA /////xIAAAAA/gAA/30gAA4AIiABAGQAAAAA/gAAVwAAAAAAIAEgAQAA///v AAAAAQABAP////8SAAAAAP4AAP99IAAOACIgAQBkAAAAAP4AAFcAAAAAAEAC QAIAAP//7wAAAAEAAQD/////EgAAAAD+AAD/fSAADgAiIAEAZAAAAAD+AABX AAAAAABgA2ADAAD//+8AAAABAAEA/////xIAAAAA/gAA/30gAA4AIiABAGQA AAAA/gAAVwAAAAAAgASABAAA///vAAAAAQABAP////8SAAAAAP4AAFAAow/e AAAABQAAAP99AAAOACIgAQBkAAAAAP4BAFcAwP8AAAAAAAD//wcAAAABACAA AAAA/gEA/30AAA4AEyABAGQAAAAA/gEAVwDA/wAAIAEgAf//BwAAAAEAIAAA AAD+AgD/fQAADgAiIAEAZAAAAAD+AQBXAMD/AABAAkAC//8HAAAAAQAgAAAA AP4DAP99AAAOABMgAQBkAAAAAP4BAFcAwP8AAGADYAP//wcAAAABACAAAAAA /gQA/30AAA4AuwABAGQAAAAA/gEAVwDA/wAAgASABP//BwAAAAEAIAAAAAD+ YACjD94AAAAFAAAA/30AAA4AIiABAGQAAAAA/gEAVwAAAAAAAAAAAP//BwAA AAEALAAAAAD+AQD/fQAADgAiIAEAZAAAAAD+AQBXAAAAAAAAAAAA//8HAAAA AQAsAAAAAP4CAP99AAAOACIgAQBkAAAAAP4BAFcAAAAAAAAAAAD//wcAAAAB ACwAAAAA/gMA/30AAA4AIiABAGQAAAAA/gEAVwAAAAAAAAAAAP//BwAAAAEA LAAAAAD+BAD/fQAADgAiIAEAZAAAAAD+AQBXAAAAAAAAAAAA//8HAAAAAQAs AAAAAP5wAKMP3gAAAAUAAAD/fQAADwAiIAAAZAAAAAD+AABkABQAAADYAAAA //8HAAAAAAAgAAAAAP4BAP99AAAPABMgAABkAAAAAP4AAGQAFAAAANQBIAH/ /wcAAAAAABwAAAAA/gIA/30AAA8AIiAAAGQAAAAA/gAAZAAUAAAA0AJAAv// BwAAAAAAGAAAAAD+AwD/fQAADwATIAAAZAAAAAD+AABkABQAAADwA2AD//8H AAAAAAAUAAAAAP4EAP99AAAPALsAAABkAAAAAP4AAGQAFAAAABAFgAT//wcA AAAAABQAAAAA/oAAow/eAAAABQAAAP99AAAPACIgAABkAAAAAP4AAGQAFAAA ANgAAAD//wcAAAAAACAAAAAA/gEA/30AAA8AEyAAAGQAAAAA/gAAZAAUAAAA 1AEgAf//BwAAAAAAHAAAAAD+AgD/fQAADwAiIAAAZAAAAAD+AABkABQAAADQ AkAC//8HAAAAAAAYAAAAAP4DAP99AAAPABMgAABkAAAAAP4AAGQAFAAAAPAD YAP//wcAAAAAABQAAAAA/gQA/30AAA8AuwAAAGQAAAAA/gAAZAAUAAAAEAWA BP//BwAAAAAAFAAAAAD+DwAMBLQIAAAPAALwrAgAABAACPAIAAAABgAAAAYE AAAPAAPwPggAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAGA//8BgP//AgAK 8AgAAAAABAAABQAAAA8ABPAcAQAAEgAK8AgAAAABBAAAAAoAAPMAC/BaAAAA fwABAAUAgAAkMHoAgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQAAAAAAhwAB AAAAvwAEAAQAvwEAABAAwAEAAAAAwgH///8A1gECAAAA/wEBAAkAAQICAAAI AAAQ8AgAAACtACABXhV7Aw8AEfAQAAAAAADDCwgAAAAAAAAAAQAAAA8ADfB6 AAAAAACfDwQAAAAAAAAAAACgD0YAAABDAGwAaQBjAGsAIAB0AG8AIABlAGQA aQB0ACAAdABoAGUAIAB0AGkAdABsAGUAIAB0AGUAeAB0ACAAZgBvAHIAbQBh AHQAAACiDwYAAAAkAAAAAAAAAKoPCgAAACQAAAABAAAAAAAPAATwmgIAABIA CvAIAAAAAgQAAAAKAADzAAvwWgAAAH8AAQAFAIAA5DB6AIEAkF8BAIIA0LYA AIMAkF8BAIQA0LYAAIUAAAAAAIcAAAAAAL8ABAAEAL8BAAAQAMABAAAAAMIB ////ANYBAgAAAP8BAQAJAAECAgAACAAAEPAIAAAA8AMgAV4VEg8PABHwEAAA AAAAwwsIAAAAAQAAAAIAAAAPAA3w+AEAAAAAnw8EAAAAAQAAAAAAoA+UAQAA QwBsAGkAYwBrACAAdABvACAAZQBkAGkAdAAgAHQAaABlACAAbwB1AHQAbABp AG4AZQAgAHQAZQB4AHQAIABmAG8AcgBtAGEAdAANAFMAZQBjAG8AbgBkACAA TwB1AHQAbABpAG4AZQAgAEwAZQB2AGUAbAANAFQAaABpAHIAZAAgAE8AdQB0 AGwAaQBuAGUAIABMAGUAdgBlAGwADQBGAG8AdQByAHQAaAAgAE8AdQB0AGwA aQBuAGUAIABMAGUAdgBlAGwADQBGAGkAZgB0AGgAIABPAHUAdABsAGkAbgBl ACAATABlAHYAZQBsAA0AUwBpAHgAdABoACAATwB1AHQAbABpAG4AZQAgAEwA ZQB2AGUAbAANAFMAZQB2AGUAbgB0AGgAIABPAHUAdABsAGkAbgBlACAATABl AHYAZQBsAA0ARQBpAGcAaAB0AGgAIABPAHUAdABsAGkAbgBlACAATABlAHYA ZQBsAA0ATgBpAG4AdABoACAATwB1AHQAbABpAG4AZQAgAEwAZQB2AGUAbAAA AKIPNgAAACYAAAAAABUAAAABABQAAAACABUAAAADABQAAAAEABQAAAAEABYA AAAEABUAAAAEABQAAAAEAAAAqg8KAAAAywAAAAEAAAAAAA8ABPBkAQAAEgAK 8AgAAAADBAAAAAoAAPMAC/BaAAAAfwABAAUAgACkMXoAgQCQXwEAggDQtgAA gwCQXwEAhADQtgAAhQAAAAAAhwAAAAAAvwAEAAQAvwEAABAAwAEAAAAAwgH/ //8A1gECAAAA/wEBAAkAAQICAAAIAAAQ8AgAAABeDyABXgaIEA8AEfAQAAAA AADDCwgAAAAAAAAABwAAAA8ADfDCAAAAAACfDwQAAAAEAAAAAACgDwIAAAAq AAAAoQ8kAAAAAgAAAAAA/xAKAA4AIiABAGQAAAAA/mQABQACAAAAAAACAA4A AAD4DwQAAAAAAAAAAACqDwoAAAACAAAAAgAAAAkIAACmD1oAAAAEAAAAFQAA AAAAIAEAAEACAABgAwAAgAQAAKAFAADABgAA4AcAAAAJAAAgCgAAQAsAAGAM AACADQAAoA4AAMAPAADgEAAAABIAACATAABAFAAAYBUAAIAWAAAPAATwZgEA ABIACvAIAAAABAQAAAAKAADzAAvwWgAAAH8AAQAFAIAAZDJ6AIEAkF8BAIIA 0LYAAIMAkF8BAIQA0LYAAIUAAAAAAIcAAAAAAL8ABAAEAL8BAAAQAMABAAAA AMIB////ANYBAgAAAP8BAQAJAAECAgAACAAAEPAIAAAAXg+wB84OiBAPABHw EAAAAAAAwwsIAAAAAAAAAAkAAAAPAA3wxAAAAAAAnw8EAAAABAAAAAAAoA8C AAAAKgAAAKEPJgAAAAIAAAAAAP8YCgAOACIgAQBkAAAAAP4BAGQABQACAAAA AAACAA4AAAD6DwQAAAAAAAAAAACqDwoAAAACAAAAAgAAAAkIAACmD1oAAAAE AAAAFQAAAAAAIAEAAEACAABgAwAAgAQAAKAFAADABgAA4AcAAAAJAAAgCgAA QAsAAGAMAACADQAAoA4AAMAPAADgEAAAABIAACATAABAFAAAYBUAAIAWAAAP AATwZgEAABIACvAIAAAABQQAAAAKAADzAAvwWgAAAH8AAQAFAIAAJDN6AIEA kF8BAIIA0LYAAIMAkF8BAIQA0LYAAIUAAAAAAIcAAAAAAL8ABAAEAL8BAAAQ AMABAAAAAMIB////ANYBAgAAAP8BAQAJAAECAgAACAAAEPAIAAAAXg8gEF4V iBAPABHwEAAAAAAAwwsIAAAAAAAAAAgAAAAPAA3wxAAAAAAAnw8EAAAABAAA AAAAoA8CAAAAKgAAAKEPJgAAAAIAAAAAAP8YCgAOACIg/f///4IAAACDAAAA hAAAAIUAAACGAAAAhwAAAIgAAACJAAAAigAAAIsAAACMAAAAjQAAAI4AAACP AAAAkAAAAJEAAACSAAAAkwAAAJQAAACVAAAAlgAAAJcAAACYAAAA/v///5oA AAD+//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////8BAGQAAAAA/gIAZAAFAAIAAAAAAAIADgAAANgPBAAAAAAAAAAAAKoP CgAAAAIAAAACAAAACQgAAKYPWgAAAAQAAAAVAAAAAAAgAQAAQAIAAGADAACA BAAAoAUAAMAGAADgBwAAAAkAACAKAABACwAAYAwAAIANAACgDgAAwA8AAOAQ AAAAEgAAIBMAAEAUAABgFQAAgBYAAA8ABPBOAAAAEgAK8AgAAAAGBAAAAAwA AJMAC/A2AAAAgAEAAAAAgQH///8AgwEAAAAAkwHAhosAlAEQpWgAvwESABIA /wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZ ADMzzADMzP8AsrKyAA8A8APKAgAAAQDxAwgAAAABAACAAAAAAA8ADASKAgAA DwAC8IICAAAgAAjwCAAAAAQAAAAECAAADwAD8BoCAAAPAATwKAAAAAEACfAQ AAAAAAAAAAAAAAABgP//AYD//wIACvAIAAAAAAgAAAUAAAAPAATwdgAAACIA CvAIAAAAAQgAAAAKAADTAAvwTgAAAIUAAgAAAIcAAQAAAEcBBQAAAIABAAAA AIEB////AIMBAAAAAL8BEAAQAMABAAAAAMIB////AMsBkCQAANYBAQAAAP8B AAAJAD8CAAACAAAAEPAIAAAAAAAAAOAQgBYPAATwrgAAABIACvAIAAAAAggA AAAKAADzAAvwWgAAAH8AAQAFAIAA5DN6AIEAAAAAAIIAAAAAAIMAAAAAAIQA AAAAAIUAAAAAAIcAAQAAAL8ABAAEAL8BAAAQAMABAAAAAMIB////ANYBAgAA AP8BAQAJAAECAgAACAAAEPAIAAAAFPAAAAAAWBMPABHwEAAAAAAAwwsIAAAA AAAAAAUAAAAPAA3wDAAAAAAAnw8EAAAAAgAAAA8ABPCuAAAAEgAK8AgAAAAD CAAAAAoAAPMAC/BaAAAAfwABAAUAgACkNHoAgQAAAAAAggAAAAAAgwAAAAAA hAAAAAAAhQAAAAAAhwAAAAAAvwAEAAQAvwEAABAAwAEAAAAAwgH///8A1gEC AAAA/wEBAAkAAQICAAAIAAAQ8AgAAACwCrABLg/PFA8AEfAQAAAAAADDCwgA AAAAAAAABgAAAA8ADfAMAAAAAACfDwQAAAACAAAADwAE8EgAAAASAArwCAAA AAQIAAAADAAAgwAL8DAAAACBAf///wCDAQAAAACTAd69aACUAY6fiwC/ARIA EgD/AQAAAAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAA zJkAMzPMAMzM/wCysrIADwDuA5YpAAACAO8DGAAAABAAAAAAAAAAAAAAAAAA AIAAAQAABwAAAAAA+QMQAAAAAAQAAAAAAAACABEAAQAAAA8A2Q8MAAAAAADa DwQAAAAAAAQADwAMBLgnAAAPAALwsCcAADAACPAIAAAALQAAAC0MAAAPAAPw VCcAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAGA//8BgP//AgAK8AgAAAAA DAAABQAAAA8ABPBwAAAAQgEK8AgAAAABDAAAAAoAAMMAC/BIAAAARAEEAAAA fwEBEAAAvwEAABAAwAEzM5kAwgHMzGYAywEYbwAA0QEBAAAA1AEBAAAA1QEB AAAA1gEBAAAA/wEYABgAPwIAAAIAAAAQ8AgAAABNA3AOcQ63BA8ABPBYAAAA ogwK8AgAAAACDAAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAvwEAABAAwAEA AAAAwgH///8A1gECAAAA/wEAAAkAPwIAAAIAAAAQ8AgAAADVAx0GqAmQBQ8A BPBgAQAAEgAK8AgAAAADDAAAAAoAACMBC/BsAAAAgAAENXoAgQCQXwEAggDQ tgAAgwCQXwEAhADQtgAAhQACAAAAhwABAAAAvwAEAAQAgAEAAAAAgQG74OMA gwFEHxwAvwEQABAAwAEAAAAAwgH///8AywGQJAAA1gEBAAAA/wEIAAgAPwIA AAIAAAAQ8AgAAAAyB0cDLQdwCA8ADfDEAAAAAACfDwQAAAAEAAAAAACgDxAA AABSAE8AVQBUAEUAUgAgAEMAAAChDyQAAAAJAAAAAAD/GAoADgAiIAEAZAAA AAD+AQBkAAUACQAAAAAAAAAAAKoPCgAAAAkAAAACAAAACQgAAKYPWgAAAAQA AAAVAAAAAAAgAQAAQAIAAGADAACABAAAoAUAAMAGAADgBwAAAAkAACAKAABA CwAAYAwAAIANAACgDgAAwA8AAOAQAAAAEgAAIBMAAEAUAABgFQAAgBYAAA8A BPBYAAAAogwK8AgAAAAEDAAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAvwEA ABAAwAEAAAAAwgH///8A1gECAAAA/wEAAAkAPwIAAAIAAAAQ8AgAAAAcDj0Q KxaxDw8ABPBQAQAAogwK8AgAAAAFDAAAAAoAAOMAC/BUAAAAgABkNXoAgQCQ XwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAAhwAAAAAAvwAGAAYAvwEAABAA wAEAAAAAwgH///8A1gECAAAA/wEAAAkAPwIAAAIAAAAQ8AgAAABdBH0OchEf BQ8ADfDMAAAAAACfDwQAAAAEAAAAAACgDxgAAAAxADcAMgAuADIANQAuADIA NQAuADUAMAAAAKEPJAAAAA0AAAAAAP8QCgAOACIgAQBkAAAAAP5kAAUADQAA AAAAAgAOAAAAqg8KAAAADQAAAAIAAAAJCAAApg9aAAAABAAAABUAAAAAACAB AABAAgAAYAMAAIAEAACgBQAAwAYAAOAHAAAACQAAIAoAAEALAABgDAAAgA0A AKAOAADADwAA4BAAAAASAAAgEwAAQBQAAGAVAACAFgAADwAE8IoBAAASAArw CAAAAAYMAAAACgAAIwEL8GwAAACAAMQ1egCBAJBfAQCCANC2AACDAJBfAQCE ANC2AACFAAIAAACHAAEAAAC/AAQABACAAQAAAACBAbvg4wCDAUQfHAC/ARAA EADAAQAAAADCAf///wDLAZAkAADWAQEAAAD/AQgACAA/AgAAAgAAABDwCAAA ACABdANaB5cCDwAN8O4AAAAAAJ8PBAAAAAQAAAAAAKAPFgAAAFIATwBVAFQA RQBSACAAEyAgAEEADQAAAKEPSAAAAAsAAAAAAP8YCgAOACIgAQBkAAAAAP4B AGQABQABAAAAAAD/GAoADgAiIAEAZAAAAAD+AQBkAAUACwAAAAAAAAABAAAA AAAAAAAAqg8KAAAADAAAAAIAAAAJCAAApg9aAAAABAAAABUAAAAAACABAABA AgAAYAMAAIAEAACgBQAAwAYAAOAHAAAACQAAIAoAAEALAABgDAAAgA0AAKAO AADADwAA4BAAAAASAAAgEwAAQBQAAGAVAACAFgAADwAE8F4AAABCAQrwCAAA AAcMAAAACgAAkwAL8DYAAABEAQQAAAB/AQEQAAC/AQAAEADAAQAAAADCAf// /wDLARhvAADWAQEAAAD/AQgACAA/AgAAAgAAABDwCAAAAJcC6A0QDhAFDwAE 8FgAAACiDArwCAAAAAgMAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAAC/AQAA EADAAQAAAADCAf///wDWAQIAAAD/AQAACQA/AgAAAgAAABDwCAAAAAIEmwM5 BJ0EDwAE8FgAAACiDArwCAAAAAkMAAAACgAAgwAL8DAAAACFAAIAAACHAAEA AAC/AQAAEADAAQAAAADCAf///wDWAQIAAAD/AQAACQA/AgAAAgAAABDwCAAA AKcDkA8uEEIEDwAE8F4AAABCAQrwCAAAAAoMAACACgAAkwAL8DYAAABEAQQA AAB/AQEQAAC/AQAAEADAAQAAAADCAf///wDLARhvAADWAQEAAAD/AQgACAA/ AgAAAgAAABDwCAAAAJUCZwVoBTQHDwAE8DwBAACiDArwCAAAAAsMAAAACgAA 4wAL8FQAAACAACQ2egCBAJBfAQCCANC2AACDAJBfAQCEANC2AACFAAIAAACH AAAAAAC/AAYABgC/AQAAEADAAQAAAADCAf///wDWAQIAAAD/AQAACQA/AgAA AgAAABDwCAAAAIoEvA1wDiUFDwAN8LgAAAAAAJ8PBAAAAAQAAAAAAKAPBAAA AC4AMQAAAKEPJAAAAAMAAAAAAP8QCgAOACIgAQBkAAAAAP5kAAUAAwAAAAAA AgAKAAAAqg8KAAAAAwAAAAIAAAAJCAAApg9aAAAABAAAABUAAAAAACABAABA AgAAYAMAAIAEAACgBQAAwAYAAOAHAAAACQAAIAoAAEALAABgDAAAgA0AAKAO AADADwAA4BAAAAASAAAgEwAAQBQAAGAVAACAFgAADwAE8E4BAACiDArwCAAA AAwMAAAACgAA4wAL8FQAAACAAIQ2egCBAJBfAQCCANC2AACDAJBfAQCEANC2 AACFAAIAAACHAAAAAAC/AAYABgC/AQAAEADAAQAAAADCAf///wDWAQIAAAD/ AQAACQA/AgAAAgAAABDwCAAAAJcC1gyyD1kDDwAN8MoAAAAAAJ8PBAAAAAQA AAAAAKAPFgAAADEANwAyAC4AMgA1AC4AMgAuADUAMQAAAKEPJAAAAAwAAAAA AP8QCgAOACIgAQBkAAAAAP5kAAUADAAAAAAAAgAOAAAAqg8KAAAADAAAAAIA AAAJCAAApg9aAAAABAAAABUAAAAAACABAABAAgAAYAMAAIAEAACgBQAAwAYA AOAHAAAACQAAIAoAAEALAABgDAAAgA0AAKAOAADADwAA4BAAAAASAAAgEwAA QBQAAGAVAACAFgAADwAE8E4BAACiDArwCAAAAA0MAAAACgAA4wAL8FQAAACA AOQ2egCBAJBfAQCCANC2AACDAJBfAQCEANC2AACFAAIAAACHAAAAAAC/AAYA BgC/AQAAEADAAQAAAADCAf///wDWAQIAAAD/AQAACQA/AgAAAgAAABDwCAAA AJcCAwPfBVkDDwAN8MoAAAAAAJ8PBAAAAAQAAAAAAKAPFgAAADEAMQAuADEA MQAuADEAMQAuADEAMQAAAKEPJAAAAAwAAAAAAP8QCgAOACIgAQBkAAAAAP5k AAUADAAAAAAAAgAOAAAAqg8KAAAADAAAAAIAAAAJCAAApg9aAAAABAAAABUA AAAAACABAABAAgAAYAMAAIAEAACgBQAAwAYAAOAHAAAACQAAIAoAAEALAABg DAAAgA0AAKAOAADADwAA4BAAAAASAAAgEwAAQBQAAGAVAACAFgAADwAE8E4B AACiDArwCAAAAA4MAAAACgAA4wAL8FQAAACAAEQ3egCBAJBfAQCCANC2AACD AJBfAQCEANC2AACFAAIAAACHAAAAAAC/AAYABgC/AQAAEADAAQAAAADCAf// /wDWAQIAAAD/AQAACQA/AgAAAgAAABDwCAAAADAGggJeBfIGDwAN8MoAAAAA AJ8PBAAAAAQAAAAAAKAPFgAAADEAMQAuADEAMQAuADEAMQAuADEAMAAAAKEP JAAAAAwAAAAAAP8QCgAOACIgAQBkAAAAAP5kAAUADAAAAAAAAgAOAAAAqg8K AAAADAAAAAIAAAAJCAAApg9aAAAABAAAABUAAAAAACABAABAAgAAYAMAAIAE AACgBQAAwAYAAOAHAAAACQAAIAoAAEALAABgDAAAgA0AAKAOAADADwAA4BAA AAASAAAgEwAAQBQAAGAVAACAFgAADwAE8FoBAAAyAArwCAAAAA8MAAAACgAA IwEL8GwAAACAAKQ3egCBAJBfAQCCANC2AACDAJBfAQCEANC2AACFAAIAAACH AAEAAAC/AAQABACAAQAAAACBAbvg4wCDAUQfHAC/ARAAEADAAQAAAADCAf// /wDLAZAkAADWAQEAAAD/AQgACAA/AgAAAgAAABDwCAAAABIFBg35DtgGDwAN 8L4AAAAAAJ8PBAAAAAQAAAAAAKAPCAAAAEgATwBTAFQAAAChDyYAAAAFAAAA AAD/GAoADgAiIAEAZAAAAAD+AQBkAAUABQAAAAAAAgAOAAAAqg8KAAAABQAA AAIAAAAJCAAApg9aAAAABAAAABUAAAAAACABAABAAgAAYAMAAIAEAACgBQAA wAYAAOAHAAAACQAAIAoAAEALAABgDAAAgA0AAKAOAADADwAA4BAAAAASAAAg EwAAQBQAAGAVAACAFgAADwAE8FgAAACiDArwCAAAABAMAAAACgAAgwAL8DAA AACFAAIAAACHAAEAAAC/AQAAEADAAQAAAADCAf///wDWAQIAAAD/AQAACQA/ AgAAAgAAABDwCAAAABIFMwKuBA0GDwAE8FgBAAASAArwCAAAABEMAAAACgAA IwEL8GwAAACAAAQ4egCBAJBfAQCCANC2AACDAJBfAQCEANC2AACFAAIAAACH AAEAAAC/AAQABACAAQAAAACBAbvg4wCDAUQfHAC/ARAAEADAAQAAAADCAf// /wDLAZAkAADWAQEAAAD/AQgACAA/AgAAAgAAABDwCAAAAIcByAuuD5cCDwAN 8LwAAAAAAJ8PBAAAAAQAAAAAAKAPCAAAAEgATwBTAFQAAAChDyQAAAAFAAAA AAD/GAoADgAiIAEAZAAAAAD+AQBkAAUABQAAAAAAAAAAAKoPCgAAAAUAAAAC AAAACQgAAKYPWgAAAAQAAAAVAAAAAAAgAQAAQAIAAGADAACABAAAoAUAAMAG AADgBwAAAAkAACAKAABACwAAYAwAAIANAACgDgAAwA8AAOAQAAAAEgAAIBMA AEAUAABgFQAAgBYAAA8ABPBeAAAAQgEK8AgAAAASDAAAAAoAAJMAC/A2AAAA RAEEAAAAfwEBEAAAvwEAABAAwAEAAAAAwgH///8AywEYbwAA1gEBAAAA/wEI AAgAPwIAAAIAAAAQ8AgAAABAAlAHvgtBAg8ABPBYAAAAogwK8AgAAAATDAAA AAoAAIMAC/AwAAAAhQACAAAAhwABAAAAvwEAABAAwAEAAAAAwgH///8A1gEC AAAA/wEAAAkAPwIAAAIAAAAQ8AgAAAD/AOwIigmaAQ8ABPBOAQAAogwK8AgA AAAUDAAAAAoAAOMAC/BUAAAAgABkOHoAgQCQXwEAggDQtgAAgwCQXwEAhADQ tgAAhQACAAAAhwAAAAAAvwAGAAYAvwEAABAAwAEAAAAAwgH///8A1gECAAAA /wEAAAkAPwIAAAIAAAAQ8AgAAADFAucGwwmHAw8ADfDKAAAAAACfDwQAAAAE AAAAAACgDxYAAAAyADAALgAyADAALgAyADAALgAxADAAAAChDyQAAAAMAAAA AAD/EAoADgAiIAEAZAAAAAD+ZAAFAAwAAAAAAAIADgAAAKoPCgAAAAwAAAAC AAAACQgAAKYPWgAAAAQAAAAVAAAAAAAgAQAAQAIAAGADAACABAAAoAUAAMAG AADgBwAAAAkAACAKAABACwAAYAwAAIANAACgDgAAwA8AAOAQAAAAEgAAIBMA AEAUAABgFQAAgBYAAA8ABPBOAQAAogwK8AgAAAAVDAAAAAoAAOMAC/BUAAAA gADEOHoAgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAAhwAAAAAAvwAG AAYAvwEAABAAwAEAAAAAwgH///8A1gECAAAA/wEAAAkAPwIAAAIAAAAQ8AgA AACHAX4JWgxJAg8ADfDKAAAAAACfDwQAAAAEAAAAAACgDxYAAAAyADAALgAy ADAALgAyADAALgAxADEAAAChDyQAAAAMAAAAAAD/EAoADgAiIAEAZAAAAAD+ ZAAFAAwAAAAAAAIADgAAAKoPCgAAAAwAAAACAAAACQgAAKYPWgAAAAQAAAAV AAAAAAAgAQAAQAIAAGADAACABAAAoAUAAMAGAADgBwAAAAkAACAKAABACwAA YAwAAIANAACgDgAAwA8AAOAQAAAAEgAAIBMAAEAUAABgFQAAgBYAAA8ABPBY AAAAogwK8AgAAAAWDAAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAvwEAABAA wAEAAAAAwgH///8A1gECAAAA/wEAAAkAPwIAAAIAAAAQ8AgAAACHAYsRNxIi Ag8ABPBeAAAAQgEK8AgAAAAXDAAAgAoAAJMAC/A2AAAARAEEAAAAfwEBEAAA vwEAABAAwAEAAAAAwgH///8AywEYbwAA1gEBAAAA/wEIAAgAPwIAAAIAAAAQ 8AgAAACVAmcFaAU0Bw8ABPBeAAAAQgEK8AgAAAAYDAAAgAoAAJMAC/A2AAAA RAEEAAAAfwEBEAAAvwEAABAAwAEAAAAAwgH///8AywEYbwAA1gEBAAAA/wEI AAgAPwIAAAIAAAAQ8AgAAACVAmcFaAU0Bw8ABPBeAAAAQgEK8AgAAAAZDAAA gAoAAJMAC/A2AAAARAEEAAAAfwEBEAAAvwEAABAAwAEAAAAAwgH///8AywEY bwAA1gEBAAAA/wEIAAgAPwIAAAIAAAAQ8AgAAACVAmcFaAU0Bw8ABPBeAAAA QgEK8AgAAAAaDAAAgAoAAJMAC/A2AAAARAEEAAAAfwEBEAAAvwEAABAAwAEA AAAAwgH///8AywEYbwAA1gEBAAAA/wEIAAgAPwIAAAIAAAAQ8AgAAACVAmcF aAU0Bw8ABPBeAAAAQgEK8AgAAAAbDAAAAAoAAJMAC/A2AAAARAEEAAAAfwEB EAAAvwEAABAAwAEAAAAAwgH///8AywGQJAAA1gECAAAA/wEIAAgAPwIAAAIA AAAQ8AgAAABwCKAFoQXwDA8ABPCYAQAAIgAK8AgAAAAcDAAAAAoAADMBC/By AAAAgAAkOXoAgQCQXwEAggDIrwAAgwCQXwEAhADIrwAAhQAAAAAAhwAEAAAA vwAEAAQARwEyAAAAgAEAAAAAgQGZzP8AgwFmMwAAvwEQABAAwAEAAAAAwgH/ //8AywGQJAAA1gECAAAA/wEIAAgAPwIAAAIAAAAQ8AgAAADwDGADUAegDg8A DfD2AAAAAACfDwQAAAAEAAAAAACgDyAAAABSAG8AdQB0AGUAcgAgABMgIABC ACAADQBBAEIAUgAgAAAAoQ9GAAAADAAAAAAA/xAKAA4AIiABAGQAAAAA/l0A BQAFAAAAAAD/EAoADgAiIAEAZAAAAAD+XQAFAAwAAAAAAAAABQAAAAEAAAAB AAAAqg8KAAAAEQAAAAIAAAAJCAAApg9aAAAABAAAABUAAAAAACABAABAAgAA YAMAAIAEAACgBQAAwAYAAOAHAAAACQAAIAoAAEALAABgDAAAgA0AAKAOAADA DwAA4BAAAAASAAAgEwAAQBQAAGAVAACAFgAADwAE8E4BAACiDArwCAAAAB0M AAAACgAA4wAL8FQAAACAAIQ5egCBAJBfAQCCAMivAACDAJBfAQCEAMivAACF AAAAAACHAAAAAAC/AAQABAC/AQAAEADAAQAAAADCAf///wDWAQIAAAD/AQAA CQA/AgAAAgAAABDwCAAAAHAIsAEQBZAJDwAN8MoAAAAAAJ8PBAAAAAQAAAAA AKAPFgAAADEAMgAuADEAMgAuADEAMgAuADEAMAAAAKEPJAAAAAwAAAAAAP8Q CgAOACIgAQBkAAAAAP5dAAUADAAAAAAAAgAOAAAAqg8KAAAADAAAAAIAAAAJ CAAApg9aAAAABAAAABUAAAAAACABAABAAgAAYAMAAIAEAACgBQAAwAYAAOAH AAAACQAAIAoAAEALAABgDAAAgA0AAKAOAADADwAA4BAAAAASAAAgEwAAQBQA AGAVAACAFgAADwAE8E4BAACiDArwCAAAAB4MAAAACgAA4wAL8FQAAACAAOQ5 egCBAJBfAQCCAMivAACDAJBfAQCEAMivAACFAAAAAACHAAAAAAC/AAQABAC/ AQAAEADAAQAAAADCAf///wDWAQIAAAD/AQAACQA/AgAAAgAAABDwCAAAAGAM sAEQBR0NDwAN8MoAAAAAAJ8PBAAAAAQAAAAAAKAPFgAAADEAMgAuADEAMgAu ADEAMgAuADEAMgAAAKEPJAAAAAwAAAAAAP8QCgAOACIgAQBkAAAAAP5dAAUA DAAAAAAAAgAOAAAAqg8KAAAADAAAAAIAAAAJCAAApg9aAAAABAAAABUAAAAA ACABAABAAgAAYAMAAIAEAACgBQAAwAYAAOAHAAAACQAAIAoAAEALAABgDAAA gA0AAKAOAADADwAA4BAAAAASAAAgEwAAQBQAAGAVAACAFgAADwAE8FgAAACi DArwCAAAAB8MAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAAC/AQAAEADAAQAA AADCAf///wDWAQIAAAD/AQAACQA/AgAAAgAAABDwCAAAAIANUAcACVsODwAE 8F4AAABCAQrwCAAAACAMAAAACgAAkwAL8DYAAABEAQQAAAB/AQEQAAC/AQAA EADAAQAAAADCAf///wDLAZAkAADWAQIAAAD/AQgACAA/AgAAAgAAABDwCAAA ABAOUAdQEBEODwAE8FwBAAAiAArwCAAAACEMAAAACgAAMwEL8HIAAACAAEQ6 egCBAJBfAQCCAMivAACDAJBfAQCEAMivAACFAAAAAACHAAQAAAC/AAQABABH ATIAAACAAQAAAACBAZnM/wCDAWYzAAC/ARAAEADAAQAAAADCAf///wDLAZAk AADWAQIAAAD/AQgACAA/AgAAAgAAABDwCAAAAIANUBDQFDAPDwAN8LoAAAAA AJ8PBAAAAAQAAAAAAKAPCAAAAEgATwBTAFQAAAChDyIAAAAFAAAAAAD/EAoA DgAiIAEAZAAAAAD+XQAFAAUAAAAAAAAAAACqDwoAAAAFAAAAAgAAAAkIAACm D1oAAAAEAAAAFQAAAAAAIAEAAEACAABgAwAAgAQAAKAFAADABgAA4AcAAAAJ AAAgCgAAQAsAAGAMAACADQAAoA4AAMAPAADgEAAAABIAACATAABAFAAAYBUA AIAWAAAPAATwTgEAAKIMCvAIAAAAIgwAAAAKAADjAAvwVAAAAIAApDp6AIEA kF8BAIIAyK8AAIMAkF8BAIQAyK8AAIUAAAAAAIcAAAAAAL8ABAAEAL8BAAAQ AMABAAAAAMIB////ANYBAgAAAP8BAAAJAD8CAAACAAAAEPAIAAAA8AzgB9AL yQ0PAA3wygAAAAAAnw8EAAAABAAAAAAAoA8YAAAAMQA3ADIALgAyADUALgAy ADUALgAxADEAAAChDyIAAAANAAAAAAD/EAoADgAiIAEAZAAAAAD+XQAFAA0A AAAAAAAAAACqDwoAAAANAAAAAgAAAAkIAACmD1oAAAAEAAAAFQAAAAAAIAEA AEACAABgAwAAgAQAAKAFAADABgAA4AcAAAAJAAAgCgAAQAsAAGAMAACADQAA oA4AAMAPAADgEAAAABIAACATAABAFAAAYBUAAIAWAAAPAATwTgEAAKIMCvAI AAAAIwwAAAAKAADjAAvwVAAAAIAABDt6AIEAkF8BAIIAyK8AAIMAkF8BAIQA yK8AAIUAAAAAAIcAAAAAAL8ABAAEAL8BAAAQAMABAAAAAMIB////ANYBAgAA AP8BAAAJAD8CAAACAAAAEPAIAAAAoA5gDMAPGRAPAA3wygAAAAAAnw8EAAAA BAAAAAAAoA8YAAAAMQA3ADIALgAyADUALgAyADUALgAyADUAAAChDyIAAAAN AAAAAAD/EAoADgAiIAEAZAAAAAD+XQAFAA0AAAAAAAAAAACqDwoAAAANAAAA AgAAAAkIAACmD1oAAAAEAAAAFQAAAAAAIAEAAEACAABgAwAAgAQAAKAFAADA BgAA4AcAAAAJAAAgCgAAQAsAAGAMAACADQAAoA4AAMAPAADgEAAAABIAACAT AABAFAAAYBUAAIAWAAAPAATwcAAAAEIBCvAIAAAAJAwAAIAKAADDAAvwSAAA AEQBBAAAAH8BARAAAL8BAAAQAMABAAAAAMIB////AMsBkCQAANEBAQAAANQB AQAAANUBAQAAANYBAgAAAP8BGAAYAD8CAAACAAAAEPAIAAAArgpQB7AKEg4P AATwTgEAAKIMCvAIAAAAJQwAAAAKAADjAAvwVAAAAIAAZDt6AIEAkF8BAIIA yK8AAIMAkF8BAIQAyK8AAIUAAAAAAIcAAAAAAL8ABAAEAL8BAAAQAMABAAAA AMIB////ANYBAgAAAP8BAAAJAD8CAAACAAAAEPAIAAAAkAmwClAQaQoPAA3w ygAAAAAAnw8EAAAABAAAAAAAoA8YAAAAQQBSAEUAQQAgADIALgAyAC4AMgAu ADIAAAChDyIAAAANAAAAAAD/EAoADgAiIAEAZAAAAAD+XQAFAA0AAAAAAAAA AACqDwoAAAANAAAAAgAAAAkIAACmD1oAAAAEAAAAFQAAAAAAIAEAAEACAABg AwAAgAQAAKAFAADABgAA4AcAAAAJAAAgCgAAQAsAAGAMAACADQAAoA4AAMAP AADgEAAAABIAACATAABAFAAAYBUAAIAWAAAPAATwcAAAAEIBCvAIAAAAJgwA AIAKAADDAAvwSAAAAEQBBAAAAH8BARAAAL8BAAAQAMABAAAAAMIB////AMsB kCQAANEBAQAAANQBAQAAANUBAQAAANYBAgAAAP8BGAAYAD8CAAACAAAAEPAI AAAArgqgBcAG8gwPAATwTgEAAKIMCvAIAAAAJwwAAAAKAADjAAvwVAAAAIAA xDt6AIEAkF8BAIIAyK8AAIMAkF8BAIQAyK8AAIUAAAAAAIcAAAAAAL8ABAAE AL8BAAAQAMABAAAAAMIB////ANYBAgAAAP8BAAAJAD8CAAACAAAAEPAIAAAA kAkwBiAKawoPAA3wygAAAAAAnw8EAAAABAAAAAAAoA8YAAAAQQBSAEUAQQAg ADEALgAxAC4AMQAuADEAAAChDyIAAAANAAAAAAD/EAoADgAiIAEAZAAAAAD+ XQAFAA0AAAAAAAAAAACqDwoAAAANAAAAAgAAAAkIAACmD1oAAAAEAAAAFQAA AAAAIAEAAEACAABgAwAAgAQAAKAFAADABgAA4AcAAAAJAAAgCgAAQAsAAGAM AACADQAAoA4AAMAPAADgEAAAABIAACATAABAFAAAYBUAAIAWAAAPAATwWAEA AKIMCvAIAAAAKAwAAAAKAADjAAvwVAAAAIAAJDx6AIEAkF8BAIIAyK8AAIMA kF8BAIQAyK8AAIUAAAAAAIcAAAAAAL8ABAAEAL8BAAAQAMABAAAAAMIB//// ANYBAgAAAP8BAAAJAD8CAAACAAAAEPAIAAAA0ALgEGAVSQQPAA3w1AAAAAAA nw8EAAAABAAAAAAAoA8iAAAAQQB1AHQAbwBuAG8AbQBvAHUAcwAgAFMAeQBz AHQAZQBtAAAAoQ8iAAAAEgAAAAAA/xAKAA4AIiABAGQAAAAA/l0ABQASAAAA AAAAAAAAqg8KAAAAEgAAAAIAAAAJCAAApg9aAAAABAAAABUAAAAAACABAABA AgAAYAMAAIAEAACgBQAAwAYAAOAHAAAACQAAIAoAAEALAABgDAAAgA0AAKAO AADADwAA4BAAAAASAAAgEwAAQBQAAGAVAACAFgAADwAE8G4BAACiDArwCAAA ACkMAAAACgAA4wAL8FQAAACAAIQ8egCBAJBfAQCCAMivAACDAJBfAQCEAMiv AACFAAAAAACHAAAAAAC/AAQABAC/AQAAEADAAQAAAADCAf///wDWAQIAAAD/ AQAACQA/AgAAAgAAABDwCAAAANACkABgA0kEDwAN8OoAAAAAAJ8PBAAAAAQA AAAAAKAPFgAAAFQAWQBQAEUAIAA1ACAADQBMAFMAQQAAAKEPRAAAAAgAAAAA AP8QCgAOACIgAQBkAAAAAP5dAAUABAAAAAAA/xAKAA4AIiABAGQAAAAA/l0A BQAIAAAAAAAAAAQAAAAAAAAAAACqDwoAAAAMAAAAAgAAAAkIAACmD1oAAAAE AAAAFQAAAAAAIAEAAEACAABgAwAAgAQAAKAFAADABgAA4AcAAAAJAAAgCgAA QAsAAGAMAACADQAAoA4AAMAPAADgEAAAABIAACATAABAFAAAYBUAAIAWAAAP AATwSgEAAKIMCvAIAAAAKgwAAAAKAADjAAvwVAAAAIAA5Dx6AIEAkF8BAIIA yK8AAIMAkF8BAIQAyK8AAIUAAAAAAIcAAAAAAL8ABAAEAL8BAAAQAMABAAAA AMIB////ANYBAgAAAP8BAAAJAD8CAAACAAAAEPAIAAAAkAkgARAFaQoPAA3w xgAAAAAAnw8EAAAABAAAAAAAoA8UAAAAVABZAFAARQAgADMAIABMAFMAQQAA AKEPIgAAAAsAAAAAAP8QCgAOACIgAQBkAAAAAP5dAAUACwAAAAAAAAAAAKoP CgAAAAsAAAACAAAACQgAAKYPWgAAAAQAAAAVAAAAAAAgAQAAQAIAAGADAACA BAAAoAUAAMAGAADgBwAAAAkAACAKAABACwAAYAwAAIANAACgDgAAwA8AAOAQ AAAAEgAAIBMAAEAUAABgFQAAgBYAAA8ABPBwAAAAQgEK8AgAAAArDAAAAAoA AMMAC/BIAAAARAEEAAAAfwEBEAAAvwEAABAAwAEAAAAAwgH///8AywGQJAAA 0QEBAAAA1AEBAAAA1QEBAAAA1gECAAAA/wEYABgAPwIAAAIAAAAQ8AgAAAAg CoAEoAUhCg8ABPBwAAAAQgEK8AgAAAAsDAAAAAoAAMMAC/BIAAAARAEEAAAA fwEBEAAAvwEAABAAwAEAAAAAwgH///8AywGQJAAA0QEBAAAA1AEBAAAA1QEB AAAA1gECAAAA/wEYABgAPwIAAAIAAAAQ8AgAAACABLABoAWBBA8ABPA8AAAA EgAK8AgAAAAtDAAAAAwAAGMAC/AkAAAAkwHAhosAlAHAhosAvwESABIA/wEA AAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMz zADMzP8AsrKyAA8AiBNaAQAADwCKE1IBAAAAALoPEAAAAF8AXwBfAFAAUABU ADEAMAAAAIsTMgEAAAAA6y4IAAAA+V3EATAbR+EAAAArBAAAAAAAAAAfAETx BgEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAA/////xIAAAAP AD3xDQAAAEABQvEFAAAAAQkAAAAfAETxwQAAAAAAJ/EgAAAAAAAAAAAAAAAB AAAAAwAAAAAAAAAAAAAA/////xgAAAAPAD3xDQAAAEABQvEFAAAAAQQAAAAA AEHxFAAAAAEAAAABAAAAAAAAAAAAAAADAAAAPwAl8SwAAAAAACjxEAAAAAEA AAAJAAAAAAAAAAAAAAAPADzxDAAAAAAAASsEAAAAAQAAAE8AJfEsAAAAAAAo 8RAAAAABAAAACgAAAAAAAAAAAAAADwA88QwAAAAAAAErBAAAAAEAAAAPAAIr AAAAAA8A8APIAQAAAQDxAwgAAAAAAQAAAwAAAA8A2Q8MAAAAAADaDwQAAAAA ADUADwAMBHQBAAAPAALwbAEAAEAACPAIAAAAAwAAAAMQAAAPAAPwBAEAAA8A BPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAGA//8BgP//AgAK8AgAAAAAEAAABQAA AA8ABPBAAAAAogwK8AgAAAABEAAAAAoAAEMAC/AYAAAAhQACAAAAhwABAAAA 1gEBAAAAPwIAAAIAAAAQ8AgAAAC2AdACEA4mCg8ABPCEAAAAogwK8AgAAAAC EAAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAvwEAABAAwAEAAAAAwgH///8A 1gECAAAA/wEAAAkAPwIAAAIAAAAQ8AgAAACwCrABLw/QFA8AEfAQAAAAAADD CwgAAAAAAAAADAAAAA8ADfAMAAAAAACfDwQAAAACAAAADwAE8EgAAAASAArw CAAAAAMQAAAADAAAgwAL8DAAAACBAf///wCDAQAAAACTAY6fiwCUAd69aAC/ ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAA AAAAzJkAMzPMAMzM/wCysrIAAAByFxgAAAABAFAAAAAAAAIFAAAWFwAA6BkA AIZDAAAAAPUPHAAAAAABAAC8DQADAAAAAFZFAAABAAAABQAAAAEAEgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABSAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAP//////////AQAAABCN gWSbT88RhuoAqgC5KegAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAADAAQAAAAAA AAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAASAAIAAgAAAAMAAAD/////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADkAAAAAAAAAAQBPAGwA ZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAoAAgD///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAFAAAAAAAAABDAHUAcgByAGUAbgB0 ACAAVQBzAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAGgACAAQAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAIAAAAsAAAAAAAAAFAAaQBjAHQAdQByAGUAcwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAS AAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA/v///wAAAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBt AGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgD///// BgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE AAAAmOEAAAAAAABQAG8AdwBlAHIAUABvAGkAbgB0ACAARABvAGMAdQBtAGUA bgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAP////8HAAAA//// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHUAAACaRQAA AAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwBy AG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIA////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAOQAAAAAAAAA --0-427061362-1212128928=:89284 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --0-427061362-1212128928=:89284-- From ospf-bounces@ietf.org Fri May 30 05:08:10 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 766303A67DD; Fri, 30 May 2008 05:08:10 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D5893A67DD for ; Fri, 30 May 2008 05:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOcBUvUruM94 for ; Fri, 30 May 2008 05:08:07 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id CAA053A67A5 for ; Fri, 30 May 2008 05:08:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id B1A28B7BD25; Fri, 30 May 2008 05:08:07 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06736-09; Fri, 30 May 2008 05:08:07 -0700 (PDT) Received: from [*2???n?IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 2C0C4B7BD21; Fri, 30 May 2008 05:08:07 -0700 (PDT) In-Reply-To: <152196.89284.qm@web46314.mail.sp1.yahoo.com> References: <152196.89284.qm@web46314.mail.sp1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <89118FE2-973B-4D40-98A9-50F1B9255CFB@redback.com> From: Acee Lindem Date: Fri, 30 May 2008 08:08:06 -0400 To: Jennifer Christy X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Cc: ospf@ietf.org Subject: Re: [OSPF] Fw: Tye - 5 and Type -3 LSA issues X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0284148064==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============0284148064== Content-Type: multipart/alternative; boundary=Apple-Mail-1--233631252 --Apple-Mail-1--233631252 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Jennifer, This is the wrong list for this question. I suggest you use the Zebra List: http://www.zebra.org/mailing.html www.zebra.org contains other useful resources as well. Having said that, you've definitely found an issue. The zebra daemon should not delete the route it just installed. Good Luck, Acee On May 30, 2008, at 2:28 AM, Jennifer Christy wrote: > Hi , > > We are using zebra-0.93b in all the routers , installed it in three > linux boxes. > > As per the topology ( PPT attached ) , we have three routers A , > B , C in our setup. > Steps to reproduce the issue : > 1. Router A is sending a Type 5 LSA route 172.25.25.0/24 ( External > Route ) via 11.11.11.11 to Router C. > 2. Router B is sending a Type 3 LSA route 172.25.25.0/24 via > 12.12.12.12 to Router C. > > Let me explain the issue. > > Case 1 : > > 1. Enable OSPF in Router C on interface ( 12.12.12.10 ) > 2. Then Type - 3 LSA Route 172.25.25.0/24 via 12.12.12.12 from > Router B will be added to Router C. > 3. Now Router C will have the route 172.25.25.0/24 via 12.12.12.12. > ( Added by Type -3 LSA ) > 4. Enable OSPF in Router C opn interface ( 11.11.11.10 ) > 5. Then Type - 5 LSA Route 172.25.25.0/24 from Router A is not > added to Router C , because while comparing the Type - 5 and Type - > 3 , its adding the best route as Type - 3 Route. > 6. So the Router will have the Type - 3 route in routing table > > Case 2 : > > 1. Enable OSPF in Router C on interface ( 11.11.11.10 ). > 2. Then Type - 5 LSA Route 172.25.25.0/24 via 11.11.11.11 from > Router A will be added to Router C. > 3. Now Router C will have the route 172.25.25.0/24 via 11.11.11.11 > ( Added by Type -5 LSA ) > 4. Enable OSPF in Router C on interface ( 12.12.12.10 ) > 5. Now Type - 3 ( 172.25.25.0/24 via 12.12.12.12 ) is the best > route when compared to Type -5 route > ( 172.25.25.0/24 via 11.11.11.11 ) , so zebra is sending a message > to delete the Type -5 route. > 6. And its sending a message to add the Type -3 route.So Type - 3 > route is added into the Router C. > 7. Here the issue starts , again zebra is sending a message to > delete the existing the Type - 3 route from the Router C. > 8. So the Type - 3 route is deleted from the routing table , now > there is no routes for 172.25.25.0/24 in the routing table. > > This is the real issue , not happening when u enable type -3 first. > > We dont know this is an usual behaviour or its really an issue > Please let us know the this is an already existing issue or if any > patch is there for this issue that would be fine. > > We want to know the root cause analysis of this issue . > Its a long mail but hope you understand it. > Please reply as soon as possible. > > Note : > The issue is reproducible in latest version also ( zebra-0.95a ) > If you need any help in reproducing / understanding the issue , > please let us know. > > Thanks in Advance , > Jenny > > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-1--233631252 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Jennifer,
This is the wrong list for this question. I suggest you = use the Zebra List:=A0


www.zebra.org contains other = useful resources as well.=A0

Having said that, = you've definitely found an issue. The zebra daemon should not delete the = route it just installed.=A0

Good = Luck,
Acee=A0

On May 30, = 2008, at 2:28 AM, Jennifer Christy wrote:

=
Hi ,

We are using = zebra-0.93b in all the routers , installed it in three linux = boxes.

As per the topology ( PPT attached ) , we have three = routers A , B , C in our setup.
Steps to reproduce the issue :
1. = Router A is sending a Type 5 LSA route 172.25.25.0/24 ( External Route ) = via 11.11.11.11 to Router C.
2. Router B is sending a Type 3 LSA = route 172.25.25.0/24 via 12.12.12.12 to Router C.

Let me explain = the issue.

Case 1 :

1. Enable OSPF in Router C on = interface ( 12.12.12.10 )
2. Then Type - 3 LSA Route 172.25.25.0/24 = via 12.12.12.12 from Router B will be added to Router C.
3. Now = Router C will have the route 172.25.25.0/24 via 12.12.12.12. ( Added by = Type -3 LSA )
4. Enable OSPF in Router C opn interface ( 11.11.11.10 = )
5. Then Type - 5 LSA Route 172.25.25.0/24 from Router A is not = added to Router C , because while comparing the Type - 5 and Type - 3 , = its adding the best route as Type - 3 Route.
6. So the Router will = have the Type - 3 route in routing table

Case 2 :

1. = Enable OSPF in Router C on interface ( 11.11.11.10 ).
2. Then Type - = 5 LSA Route 172.25.25.0/24 via 11.11.11.11 from Router A will be added = to Router C.
3. Now Router C will have the route 172.25.25.0/24 via = 11.11.11.11 ( Added by Type -5 LSA )
4. Enable OSPF in Router C on = interface ( 12.12.12.10 )
5. Now Type - 3 ( 172.25.25.0/24 via = 12.12.12.12 ) is the best route when compared to Type -5 route
( = 172.25.25.0/24 via 11.11.11.11 ) , so zebra is sending a message to = delete the Type -5 route.
6. And its sending a message to add the = Type -3 route.So Type - 3 route is added into the Router C.
7. Here = the issue starts , again zebra is sending a message to delete the = existing the Type - 3 route from the Router C.
8. So the Type - 3 = route is deleted from the routing table , now there is no routes for = 172.25.25.0/24 in the routing table.

This is the real issue , not = happening when u enable type -3 first.

We dont know this is an = usual behaviour or its really an issue
Please let us know the this is = an already existing issue or if any patch is there for this issue that = would be fine.

We want to know the root cause analysis of this = issue .
Its a long mail but hope you understand it.
Please reply = as soon as possible.

Note :
The issue is reproducible in = latest version also ( zebra-0.95a )=A0
If = you need any help in reproducing / understanding the issue , please let = us know.

Thanks in Advance ,
Jenny
=A0=A0=A0 =



= <issue.ppt>
OSPF mailing list
=

= --Apple-Mail-1--233631252-- --===============0284148064== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --===============0284148064==-- From ospf-bounces@ietf.org Fri May 30 09:48:05 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196373A6C0E; Fri, 30 May 2008 09:48:05 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C1E53A6BF8 for ; Fri, 30 May 2008 09:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IvvJuY8UyCo for ; Fri, 30 May 2008 09:48:01 -0700 (PDT) Received: from n74a.bullet.mail.sp1.yahoo.com (n74a.bullet.mail.sp1.yahoo.com [98.136.45.21]) by core3.amsl.com (Postfix) with SMTP id 740D928C1E7 for ; Fri, 30 May 2008 09:45:50 -0700 (PDT) Received: from [216.252.122.216] by n74.bullet.mail.sp1.yahoo.com with NNFMP; 30 May 2008 16:45:50 -0000 Received: from [69.147.84.88] by t1.bullet.sp1.yahoo.com with NNFMP; 30 May 2008 16:45:50 -0000 Received: from [127.0.0.1] by omp204.mail.sp1.yahoo.com with NNFMP; 30 May 2008 16:45:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 197655.77403.bm@omp204.mail.sp1.yahoo.com Received: (qmail 67698 invoked by uid 60001); 30 May 2008 16:45:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=jE6qnLVc9CbQL9U5PQpU0gOR4DwyN0sIc193YYY6GT963Udz2Iij+QT/Wyf7hzIGt8LAIGqfz5O7CPSXrC5yeav2OGrsVJMHR01iS4qZ+c3n7kZArZlv+01MlEEj/DA27rpO3m1zqRbmTGlJKq5XSiYkfIEXz8HZlwUf9jJPJZM=; X-YMail-OSG: HsQ58isVM1kLZQ5j8naZlxfxV_KOHJXtvqyeYFIq318obwjQVMokrdC29gH9MctJlEKq6CucoNF2AnldoxtfiCdzjIQtepN3z5uhmbR2TC5oGRr2a6wezHlNG0qyDDKSNYnuNhrjLyyD1MM- Received: from [203.129.222.168] by web46313.mail.sp1.yahoo.com via HTTP; Fri, 30 May 2008 09:45:49 PDT X-Mailer: YahooMailRC/975.41 YahooMailWebService/0.7.185 Date: Fri, 30 May 2008 09:45:49 -0700 (PDT) From: Jennifer Christy To: Acee Lindem MIME-Version: 1.0 Message-ID: <9675.66529.qm@web46313.mail.sp1.yahoo.com> Cc: ospf@ietf.org Subject: Re: [OSPF] Fw: Tye - 5 and Type -3 LSA issues X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0219973537==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============0219973537== Content-Type: multipart/alternative; boundary="0-2071191011-1212165949=:66529" --0-2071191011-1212165949=:66529 Content-Type: text/plain; charset=us-ascii Thanks for the reply Acee , and i have already sent mails to zebra from zebra mailing lists but i didnt get any reply , Please send me any active mailing lists for ospf issues Sorry to disturb again ----- Original Message ---- From: Acee Lindem To: Jennifer Christy Cc: ospf@ietf.org Sent: Friday, May 30, 2008 5:38:06 PM Subject: Re: [OSPF] Fw: Tye - 5 and Type -3 LSA issues Jennifer, This is the wrong list for this question. I suggest you use the Zebra List: http://www.zebra.org/mailing.html www.zebra.org contains other useful resources as well. Having said that, you've definitely found an issue. The zebra daemon should not delete the route it just installed. Good Luck, Acee On May 30, 2008, at 2:28 AM, Jennifer Christy wrote: Hi , We are using zebra-0.93b in all the routers , installed it in three linux boxes. As per the topology ( PPT attached ) , we have three routers A , B , C in our setup. Steps to reproduce the issue : 1. Router A is sending a Type 5 LSA route 172.25.25.0/24 ( External Route ) via 11.11.11.11 to Router C. 2. Router B is sending a Type 3 LSA route 172.25.25.0/24 via 12.12.12.12 to Router C. Let me explain the issue. Case 1 : 1. Enable OSPF in Router C on interface ( 12.12.12.10 ) 2. Then Type - 3 LSA Route 172.25.25.0/24 via 12.12.12.12 from Router B will be added to Router C. 3. Now Router C will have the route 172.25.25.0/24 via 12.12.12.12. ( Added by Type -3 LSA ) 4. Enable OSPF in Router C opn interface ( 11.11.11.10 ) 5. Then Type - 5 LSA Route 172.25.25.0/24 from Router A is not added to Router C , because while comparing the Type - 5 and Type - 3 , its adding the best route as Type - 3 Route. 6. So the Router will have the Type - 3 route in routing table Case 2 : 1. Enable OSPF in Router C on interface ( 11.11.11.10 ). 2. Then Type - 5 LSA Route 172.25.25.0/24 via 11.11.11.11 from Router A will be added to Router C. 3. Now Router C will have the route 172.25.25.0/24 via 11.11.11.11 ( Added by Type -5 LSA ) 4. Enable OSPF in Router C on interface ( 12.12.12.10 ) 5. Now Type - 3 ( 172.25.25.0/24 via 12.12.12.12 ) is the best route when compared to Type -5 route ( 172.25.25.0/24 via 11.11.11.11 ) , so zebra is sending a message to delete the Type -5 route. 6. And its sending a message to add the Type -3 route.So Type - 3 route is added into the Router C. 7. Here the issue starts , again zebra is sending a message to delete the existing the Type - 3 route from the Router C. 8. So the Type - 3 route is deleted from the routing table , now there is no routes for 172.25.25.0/24 in the routing table. This is the real issue , not happening when u enable type -3 first. We dont know this is an usual behaviour or its really an issue Please let us know the this is an already existing issue or if any patch is there for this issue that would be fine. We want to know the root cause analysis of this issue . Its a long mail but hope you understand it. Please reply as soon as possible. Note : The issue is reproducible in latest version also ( zebra-0.95a ) If you need any help in reproducing / understanding the issue , please let us know. Thanks in Advance , Jenny _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --0-2071191011-1212165949=:66529 Content-Type: text/html; charset=us-ascii
Thanks for the reply Acee , and i have already sent mails to zebra from zebra mailing lists
but i didnt get any reply ,

Please send me any active mailing lists for ospf issues

Sorry to disturb again

----- Original Message ----
From: Acee Lindem <acee@redback.com>
To: Jennifer Christy <jenniferchristy56@yahoo.com>
Cc: ospf@ietf.org
Sent: Friday, May 30, 2008 5:38:06 PM
Subject: Re: [OSPF] Fw: Tye - 5 and Type -3 LSA issues

Jennifer,
This is the wrong list for this question. I suggest you use the Zebra List: 


www.zebra.org contains other useful resources as well. 

Having said that, you've definitely found an issue. The zebra daemon should not delete the route it just installed. 

Good Luck,
Acee 

On May 30, 2008, at 2:28 AM, Jennifer Christy wrote:

Hi ,

We are using zebra-0.93b in all the routers , installed it in three linux boxes.

As per the topology ( PPT attached ) , we have three routers A , B , C in our setup.
Steps to reproduce the issue :
1. Router A is sending a Type 5 LSA route 172.25.25.0/24 ( External Route ) via 11.11.11.11 to Router C.
2. Router B is sending a Type 3 LSA route 172.25.25.0/24 via 12.12.12.12 to Router C.

Let me explain the issue.

Case 1 :

1. Enable OSPF in Router C on interface ( 12.12.12.10 )
2. Then Type - 3 LSA Route 172.25.25.0/24 via 12.12.12.12 from Router B will be added to Router C.
3. Now Router C will have the route 172.25.25.0/24 via 12.12.12.12. ( Added by Type -3 LSA )
4. Enable OSPF in Router C opn interface ( 11.11.11.10 )
5. Then Type - 5 LSA Route 172.25.25.0/24 from Router A is not added to Router C , because while comparing the Type - 5 and Type - 3 , its adding the best route as Type - 3 Route.
6. So the Router will have the Type - 3 route in routing table

Case 2 :

1. Enable OSPF in Router C on interface ( 11.11.11.10 ).
2. Then Type - 5 LSA Route 172.25.25.0/24 via 11.11.11.11 from Router A will be added to Router C.
3. Now Router C will have the route 172.25.25.0/24 via 11.11.11.11 ( Added by Type -5 LSA )
4. Enable OSPF in Router C on interface ( 12.12.12.10 )
5. Now Type - 3 ( 172.25.25.0/24 via 12.12.12.12 ) is the best route when compared to Type -5 route
( 172.25.25.0/24 via 11.11.11.11 ) , so zebra is sending a message to delete the Type -5 route.
6. And its sending a message to add the Type -3 route.So Type - 3 route is added into the Router C.
7. Here the issue starts , again zebra is sending a message to delete the existing the Type - 3 route from the Router C.
8. So the Type - 3 route is deleted from the routing table , now there is no routes for 172.25.25.0/24 in the routing table.

This is the real issue , not happening when u enable type -3 first.

We dont know this is an usual behaviour or its really an issue
Please let us know the this is an already existing issue or if any patch is there for this issue that would be fine.

We want to know the root cause analysis of this issue .
Its a long mail but hope you understand it.
Please reply as soon as possible.

Note :
The issue is reproducible in latest version also ( zebra-0.95a ) 
If you need any help in reproducing / understanding the issue , please let us know.

Thanks in Advance ,
Jenny
   



<issue.ppt>
_______________________________________________
OSPF mailing list


--0-2071191011-1212165949=:66529-- --===============0219973537== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --===============0219973537==-- From ospf-bounces@ietf.org Fri May 30 20:50:55 2008 Return-Path: X-Original-To: ospf-archive@optimus.ietf.org Delivered-To: ietfarch-ospf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F18B3A69B4; Fri, 30 May 2008 20:50:55 -0700 (PDT) X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 728EE3A69B4 for ; Fri, 30 May 2008 20:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.92 X-Spam-Level: * X-Spam-Status: No, score=1.92 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iwdlkqkGpRA for ; Fri, 30 May 2008 20:50:51 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [61.144.161.53]) by core3.amsl.com (Postfix) with ESMTP id 097193A68B3 for ; Fri, 30 May 2008 20:50:51 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K1P003XQS0GEK@szxga01-in.huawei.com> for ospf@ietf.org; Sat, 31 May 2008 11:50:40 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K1P00KPSS0G08@szxga01-in.huawei.com> for ospf@ietf.org; Sat, 31 May 2008 11:50:40 +0800 (CST) Received: from z44434bja ([10.111.20.111]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K1P001C3S0FEF@szxml04-in.huawei.com> for ospf@ietf.org; Sat, 31 May 2008 11:50:39 +0800 (CST) Date: Sat, 31 May 2008 11:50:38 +0800 From: Zhang Kui To: 'OSPF List' Message-id: <000001c8c2d1$7dd3b900$0101a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcjC0X074ODtkqOdT+CA1LHnm+3wRQ== Cc: Chen Jie Subject: [OSPF] About identifying the neighbor? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0585427053==" Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============0585427053== Content-type: multipart/alternative; boundary="Boundary_(ID_ka5AqBtnCB9Iqdt+jM0PJg)" This is a multi-part message in MIME format. --Boundary_(ID_ka5AqBtnCB9Iqdt+jM0PJg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, In RFC2328, "If the receiving interface connects to a broadcast network, Point-to-MultiPoint network or NBMA network the sender is identified by the IP source address found in the packet's IP header. If the receiving interface connects to a point-to-point network or a virtual link, the sender is identified by the Router ID (source router) found in the packet's OSPF header." Why do we do this? Is it ok to identify the neighbor by the router id regardless of network types? --Boundary_(ID_ka5AqBtnCB9Iqdt+jM0PJg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi all,

In RFC2328,

“If the receiving interface connects to a broadcast

        network, Point-to-MultiPoint network or NBMA network the sender

        is identified by the IP source address found in the packet's IP

        header.  If the receiving interface connects to a point-to-point

        network or a virtual link, the sender is identified by the

        Router ID (source router) found in the packet's OSPF header.”

Why do we do this? Is it ok to identify the neighbor by the router id regardless of network types?

 

 

--Boundary_(ID_ka5AqBtnCB9Iqdt+jM0PJg)-- --===============0585427053== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --===============0585427053==--