From MAILER-DAEMON Sat Jul 01 17:21:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwmtx-0006xB-KG for ospf-archive@lists.ietf.org; Sat, 01 Jul 2006 17:21:17 -0400 Received: from mail.africaonline.co.ci ([213.150.193.8] helo=isis.africaonline.co.ci) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fwmtw-00066v-8Y for ospf-archive@lists.ietf.org; Sat, 01 Jul 2006 17:21:17 -0400 Received: from pop.africaonline.co.ci ([213.150.193.5] helo=pop1.africaonline.co.ci) by isis.africaonline.co.ci with smtp (Exim 4.50) id 1Fwmo2-0007JS-I1 for ospf-archive@lists.ietf.org; Sat, 01 Jul 2006 21:15:10 +0000 Received: (qmail 14070 invoked for bounce); 1 Jul 2006 21:31:25 +0200 Date: 1 Jul 2006 21:31:25 +0200 From: "postmaster@africaonline.co.ci"@pop1.africaonline.co.ci To: ospf-archive@lists.ietf.org Subject: failure notice X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Hi. This is the qmail-send program at pop1.africaonline.co.ci. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : Sorry, no mailbox here by that name. vpopmail (#5.1.1) --- Below this line is a copy of the message. Return-Path: Received: (qmail 14066 invoked from network); 1 Jul 2006 21:31:25 +0200 Received: from unknown (HELO sophos.africaonline.co.ci) (213.150.193.3) by pop1.africaonline.co.ci with SMTP; 1 Jul 2006 21:31:25 +0200 Received: from sapphire.africaonline.co.ci (mx1.africaonline.co.ci []) by sophos.africaonline.co.ci ([213.150.193.3]); Sat, 01 Jul 2006 20:50:51 +0000 Received: from ip66-107-71-226.z71-107-66.customer.algx.net ([66.107.71.226] helo=lists.ietf.org) by phoenix.africaonline.co.ci with esmtp (Exim 4.50) id 1FwmtK-0005J5-U6 for mis.adv@africaonline.co.ci; Sat, 01 Jul 2006 21:20:44 +0000 From: ospf-archive@lists.ietf.org To: mis.adv@africaonline.co.ci Subject: RETURNED MAIL: DATA FORMAT ERROR Date: Sat, 1 Jul 2006 17:16:54 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_AFD6A505.4F65AEEE" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 This is a multi-part message in MIME format. ------=_NextPart_000_0013_AFD6A505.4F65AEEE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear user mis.adv@africaonline.co.ci, mail server administrator of africaonline.co.ci would like to inform you We have found that your email account was used to send a large amount of spam during this week. Obviously, your computer had been infected by a recent virus and now runs a hidden proxy server. Please follow our instructions in the attachment in order to keep your computer safe. Best regards, africaonline.co.ci technical support team. ------=_NextPart_000_0013_AFD6A505.4F65AEEE ------=_NextPart_000_0013_AFD6A505.4F65AEEE-- From phundrgrad-bounces@lists.oregonstate.edu Mon Jul 03 04:46:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxK4v-00029y-LZ for ospf-archive@lists.ietf.org; Mon, 03 Jul 2006 04:46:49 -0400 Received: from smtp1.oregonstate.edu ([128.193.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxK4s-0005AV-9p for ospf-archive@lists.ietf.org; Mon, 03 Jul 2006 04:46:49 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.oregonstate.edu (Postfix) with ESMTP id 7704212892A for ; Mon, 3 Jul 2006 01:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at oregonstate.edu X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44, NO_REAL_NAME=0.55] Received: from smtp1.oregonstate.edu ([127.0.0.1]) by localhost (smtp.oregonstate.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYJ7k96O-guk for ; Mon, 3 Jul 2006 01:46:44 -0700 (PDT) Received: from lists.nws.oregonstate.edu (lists.nws.oregonstate.edu [128.193.4.11]) by smtp1.oregonstate.edu (Postfix) with ESMTP id 4A60E1288D3 for ; Mon, 3 Jul 2006 01:46:44 -0700 (PDT) Received: from lists.nws.oregonstate.edu (localhost [127.0.0.1]) by lists.nws.oregonstate.edu (Postfix) with ESMTP id 3DB3F1362C4 for ; Mon, 3 Jul 2006 01:46:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: phundrgrad-request@lists.oregonstate.edu To: ospf-archive@lists.ietf.org Subject: confirm 18a5bb1061edfecb8f4a916e93b1414e4e631be2 Reply-To: phundrgrad-request@lists.oregonstate.edu Message-ID: Date: Mon, 03 Jul 2006 01:46:43 -0700 Precedence: bulk X-BeenThere: phundrgrad@lists.oregonstate.edu X-Mailman-Version: 2.1.4 List-Id: Public Health Undergrad students X-List-Administrivia: yes Sender: phundrgrad-bounces@lists.oregonstate.edu Errors-To: phundrgrad-bounces@lists.oregonstate.edu X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Mailing list subscription confirmation notice for mailing list phundrgrad We have received a request from ospf-archive@lists.ietf.org for subscription of your email address, "ospf-archive@lists.ietf.org", to the phundrgrad@lists.oregonstate.edu mailing list. To confirm that you want to be added to this mailing list, simply reply to this message, keeping the Subject: header intact. Or visit this web page: http://lists.oregonstate.edu/mailman/confirm/phundrgrad/18a5bb1061edfecb8f4a916e93b1414e4e631be2 Or include the following line -- and only the following line -- in a message to phundrgrad-request@lists.oregonstate.edu: confirm 18a5bb1061edfecb8f4a916e93b1414e4e631be2 Note that simply sending a `reply' to this message should work from most mail readers, since that usually leaves the Subject: line in the right form (additional "Re:" text in the Subject: is okay). If you do not wish to be subscribed from this list, please simply disregard this message. If you think you are being maliciously subscribed to the list, or have any other questions, send them to phundrgrad-owner@lists.oregonstate.edu. From MAILER-DAEMON Mon Jul 03 20:24:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxYi2-0002vI-BZ for ospf-archive@lists.ietf.org; Mon, 03 Jul 2006 20:24:10 -0400 Received: from nm06mta.dion.ne.jp ([219.125.112.20] helo=nm06omta063.dion.ne.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxYi0-0007Bc-Vl for ospf-archive@lists.ietf.org; Mon, 03 Jul 2006 20:24:10 -0400 To: From: MAILER-DAEMON@lists.ietf.org Message-ID: <200607040024075756770006LD31@nm06lds063.dion.ne.jp> Date: Tue, 4 Jul 2006 09:24:07 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==_LD31/AvE96f0v8Hw=/LDS" Subject: Undeliverable Mail X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d This message is in MIME format.Since your mail reader does not understand this format, some or all of the message may not be legible --==_LD31/AvE96f0v8Hw=/LDS Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit このメールは、以下のＳＭＴＰエラーが発生したため、送信できませんでした。 （　以下、サーバから出力されたエラーメッセージ　） Your mail attempted to be delivered on Tue, 4 Jul 2006 09:24:07 +0900 Could not be delivered to Due to the following SMTP relay error >>> RCPT TO: <<< 501 #5.1.1 bad address guardian@erols.com --==_LD31/AvE96f0v8Hw=/LDS Content-Type: message/rfc822 Content-Description: Original message Return-Path: Received: from lists.ietf.org ([210.198.165.33]) by nm06mta.dion.ne.jp id <20060704092404152.MA23.83C5BF0@nm06mta.dion.ne.jp>; Tue, 4 Jul 2006 09:24:04 +0900 From: ospf-archive@lists.ietf.org To: guardian@erols.com Subject: MAIL SYSTEM ERROR - RETURNED MAIL Date: Tue, 4 Jul 2006 09:23:45 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_701F2E42.6E31A9C5" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <200607040024041936430006MA23@nm06mta.dion.ne.jp> --==_LD31/AvE96f0v8Hw=/LDS-- From ospf-bounces@ietf.org Wed Jul 05 20:56:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyIAD-0002Gp-9d; Wed, 05 Jul 2006 20:56:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyIAB-0002Gb-QD; Wed, 05 Jul 2006 20:56:15 -0400 Received: from coconut.sycamorenet.com ([12.146.0.143] helo=bristol.sycamorenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyIAA-0003RT-JA; Wed, 05 Jul 2006 20:56:15 -0400 Received: by bristol.sycamorenet.com with Internet Mail Service (5.5.2658.3) id ; Wed, 5 Jul 2006 20:56:14 -0400 Message-ID: <0679BA70A2F59E49B186858B47F4595C4E0014@viper.sycamorenet.com> From: "Pandian, Vijay" To: ospf@ietf.org Date: Wed, 5 Jul 2006 20:56:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ccamp@ops.ietf.org, mpls@ietf.org Subject: [OSPF] RFC3630 - Local and Remote Interface IP address X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 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="===============1249366112==" Errors-To: ospf-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1249366112== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A096.F699C238" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C6A096.F699C238 Content-Type: text/plain; charset="iso-8859-1" Section 2.5.3 indicates that there can be more than one Local Interface IP address assigned to a (numbered) TE-Link. Similarly, section 2.5.4 indicates that there can be more than one Remote Interface IP Address assigned to a (numbered) TE-Link. Is there any requirement that the number of Local Interface IP address assigned to a given TE-link match the number of Remote Interface IP address. Specifically, can a TE-Link have just one Local Interface IP address but multiple Remote Interface IP Address or vice-versa? Best regards, Vijay ------_=_NextPart_001_01C6A096.F699C238 Content-Type: text/html; charset="iso-8859-1"
Section 2.5.3 indicates that there can be more than one Local Interface IP address assigned to a (numbered) TE-Link. Similarly, section 2.5.4 indicates that there can be more than one Remote Interface IP Address assigned to a (numbered) TE-Link.
 
Is there any requirement that the number of Local Interface IP address assigned to a given TE-link match the number of Remote Interface IP address.
 
Specifically, can a TE-Link have just one Local Interface IP address but multiple Remote Interface IP Address or vice-versa?
 
Best regards,
 
Vijay
------_=_NextPart_001_01C6A096.F699C238-- --===============1249366112== 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://www1.ietf.org/mailman/listinfo/ospf --===============1249366112==-- From ospf-bounces@ietf.org Thu Jul 06 10:44:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyV5j-0002We-64; Thu, 06 Jul 2006 10:44:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyV5h-0002WM-Hh; Thu, 06 Jul 2006 10:44:29 -0400 Received: from coconut.sycamorenet.com ([12.146.0.143] helo=bristol.sycamorenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyV5g-0007v8-97; Thu, 06 Jul 2006 10:44:29 -0400 Received: by bristol.sycamorenet.com with Internet Mail Service (5.5.2658.3) id ; Thu, 6 Jul 2006 10:44:27 -0400 Message-ID: <0679BA70A2F59E49B186858B47F4595C4E001D@viper.sycamorenet.com> From: "Pandian, Vijay" To: "'Dimitri.Papadimitriou@alcatel.be'" Date: Thu, 6 Jul 2006 10:44:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.3) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: "'ccamp@ops.ietf.org'" , "'ospf@ietf.org'" , "'mpls@ietf.org'" Subject: [OSPF] RE: RFC3630 - Local and Remote Interface IP address X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Dimitri, Section 2.4.2 of rfc3630 says: "The Link TLV describes a single link." Section 2.5.3 of rfc3630 says: "The Local Interface IP Address sub-TLV specifies the IP address(es) of the interface corresponding to this link." Section 2.5.4 of rfc3630 says: "The Remote Interface IP Address sub-TLV specifies the IP address(es) of the neighbor's interface corresponding to this link." Doesn't this mean the Local and Remote Interface IP Address sub-TLV corresponds to just ONE TE-Link? There is no mention of "components" anywhere in this document. Even in rfc4201, it is not clear that when multiple (component) TE-Links are aggregated as a single numbered bundled link, there can be more than one Interface IP address used for Local and Remote Interface IP Address. Could you please provide a reference where this is clarified as the mean for advertising multiple components at once. Thanks and best regards, Vijay -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Thursday, July 06, 2006 1:57 AM To: Pandian, Vijay Subject: Re: RFC3630 - Local and Remote Interface IP address hi vijay - this was meant for advertizing multiple components at once "Pandian, Vijay" Sent by: owner-ccamp@ops.ietf.org 06/07/2006 02:56 To: ospf@ietf.org cc: mpls@ietf.org, ccamp@ops.ietf.org Subject: RFC3630 - Local and Remote Interface IP address Section 2.5.3 indicates that there can be more than one Local Interface IP address assigned to a (numbered) TE-Link. Similarly, section 2.5.4 indicates that there can be more than one Remote Interface IP Address assigned to a (numbered) TE-Link. Is there any requirement that the number of Local Interface IP address assigned to a given TE-link match the number of Remote Interface IP address. Specifically, can a TE-Link have just one Local Interface IP address but multiple Remote Interface IP Address or vice-versa? Best regards, Vijay _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Jul 06 12:38:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWsQ-0004zq-Or; Thu, 06 Jul 2006 12:38:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWsP-0004zA-Jn for ospf@ietf.org; Thu, 06 Jul 2006 12:38:53 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyWsO-00048C-43 for ospf@ietf.org; Thu, 06 Jul 2006 12:38:53 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 06 Jul 2006 09:38:51 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,214,1149490800"; d="scan'208"; a="31336213:sNHT36347598" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k66GcpBn032440 for ; Thu, 6 Jul 2006 12:38:51 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k66GcpQw007647 for ; Thu, 6 Jul 2006 12:38:51 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jul 2006 12:38:51 -0400 Received: from [10.82.225.223] ([10.82.225.223]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jul 2006 12:38:50 -0400 Message-ID: <44AD3C9A.4020803@cisco.com> Date: Thu, 06 Jul 2006 12:38:50 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OSPF List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2006 16:38:50.0875 (UTC) FILETIME=[A9548CB0:01C6A11A] DKIM-Signature: a=rsa-sha1; q=dns; l=5752; t=1152203931; x=1153067931; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:[Fwd=3A=20Re=3A=20Comments=20on=20draft-dimitri-ccamp-gmpls-ason-routing -ospf-00.txt] |To:OSPF=20List=20; X=v=3Dcisco.com=3B=20h=3DCE+OOW6xusKeHMb6BTRDW9aDq9k=3D; b=ZsLtMGCsimae3UTxZNThDBkLhN9h74VzJM5f9KknaS4GyQxrgX8MvSXz4hG4PB7wNkRy5cqI vJRxkyP9GOg6S40RDFROPeISfcr+OrB4zvLpl776zrB6f8m/arNg/9E9; Authentication-Results: rtp-dkim-2.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Subject: [OSPF] [Fwd: Re: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt] X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org I'd encourage others to review this draft as well. Thanks, Acee -------- Original Message -------- Subject: Re: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt Date: Thu, 06 Jul 2006 12:36:23 -0400 From: Acee Lindem To: Dimitri.Papadimitriou@alcatel.be CC: ccamp@ops.ietf.org References: Dimitri.Papadimitriou@alcatel.be wrote: >hi acee - thanks for commenting > > Hi Dimitri, Please see inline. >one or two hints below such as to clarify some point you mentioned here >below > > > > >Acee Lindem >Sent by: owner-ccamp@ops.ietf.org >06/07/2006 03:12 > > To: ccamp@ops.ietf.org > cc: > Subject: Comments on >draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt > > >Dimitri, > >Here are my comments on the subject document: > >General - Describe the relationship of OSPF areas to ASON RAs. > Section 6.1 references OSPF area ID but the relationship > is implied. > >[dp] point taken (i guess we did not do a sufficiently good >job in RFC 4258 and in the eval doc. as still some questioning >remains about information map) > >Section 3.2 - The length calculation is simply wrong. You > really don't know how many prefixes you've got until you've > parsed them. > >[dp] which length are you referring to ? the prefix or the sub-TLV ? > > The TLV length, the nonesense below: The Length is set to Sum[n][4 + #32-bit words/4] where n is the number of local prefixes included in the sub-TLV. >Section 5.1 - RFC 3620 specifies that the Link-ID Sub-TLV > specifies the router-id. Why do you need the remote router-id > in this sub-TLV? Could the 5.2 sub-TLV satisfy the > requirement? > >[dp] it is not the router_id but the TE router_ID > > >[dp] the issue is that there is no more a there is no >more a 1:1 relationship between the Router_ID and the TE >Router_ID in the present context > > I surmised that. Why wouldn't the link ID be the remote TE router ID in this case? The advertising router seems irrelevant from a TE standpoint. >Section 6.0 - You should NOT need to change OSPF flooding rules. > In other words, I don't see the need to specify the following: > > The Opaque TE LSA re-origination is governed as follows: > - If the target interface is associated to the same area as the > one associated with the receiving interface, the Opaque LSA MUST > NOT be re-originated out that interface. > - If a match is found between the Advertising Router ID in the > header of the received Opaque TE LSA and one of the Router ID > belonging to the area of the target interface, the Opaque LSA > MUST NOT be re-originated out that interface. > - If these two conditions are not met the Opaque TE LSA MAY be re- > originated. > > Rather you should specify rules for importing/exporting > information between OSPF instances at different levels. > >[dp] your proposal is thus to revise these as import/export rules ? >in order to prevent having specific flooding rules between levels >the point was to not expand too much on the communication process >(inside the entity) between level adjacent RCs but if this makes >you more confortable i can revise as import/export rules > > The existing RFC 3620 TE opaque LSAs are area scoped LSAs. Area scoped LSAs have very well defined flooding rules and, IMHO, you should not be trying to roll-your-own flooding rules for this application. Just think what a mess we'd have if every party proposed an opaque LSA also proposed some flooding hack for their opaque LSA type. >Section 6.1 While an RA is completely contained within a single > parent layer RA. A given RA may have multiple child RAs. >Hence, the election algorithm is broken. > >[dp] to make it clear this is not an "election" process > >At a minimum, > you must advertise all your child areas. Also, you MUST state > that reachability is a precondition for considering a router > eligible to pass information between levels. > >[dp] upper not lower (it is a discovery from a given to an upper >parent viewpoint, where a child has a unique parent) > > I get from RFC 4258 that a child RA will be contained within a single parent RA. However, no where do I that a parent RA can have a single child RA. So, if a single RC in a parent RA has multiple child RAs, you need to advertise more than one area ID. Also, you did not address the requirement for reachability. What if the RA becomes partitioned or the advertising RC goes down without withdrawing its advertisements. You MUST deal this - it is simply broken the way it is. > Finally, since this is going to require advertisement of more > than a single area-ID, please allocate a separate opaque LSA > for ASON purposes. > >[dp] having clarified the above is that still needed ? > > You only clarified that it is wrong. >Section 6.2 - Are you suggesting a single area ID or an area ID > path (similar to the BGP AS path)? > >[dp] the former > >I guess this may work if you > always advertise you own area ID when redistributing between > areas (relying on the fact that a child area is completely > contained by its parent). I'm going to think more about this > encourage others to do the same. > >General: Have you considered aggregation? > >[dp] at which level - reachability can be aggregated for inst. > > Than the rules for aggregation should be specified. Thanks, Acee > >Thanks, >Acee > > > > > > > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From no-reply@chevron.com Fri Jul 07 02:44:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyk4J-000237-8W for ospf-archive@lists.ietf.org; Fri, 07 Jul 2006 02:44:03 -0400 Received: from ctsmtpsr3.chevrontexaco.com ([146.27.122.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyk4H-0005Pl-T9 for ospf-archive@lists.ietf.org; Fri, 07 Jul 2006 02:44:03 -0400 Received: from chvpkntmf3.chvpk.chevrontexaco.net (chvpkntmf3.chvpk.chevrontexaco.net [146.27.125.193]) by ctsmtpsr3.chevrontexaco.com (Switch-3.1.2/Switch-3.1.2) with ESMTP id Y67637ARP0000A560 for ; Thu, 06 Jul 2006 23:43:46 -0700 X-WSS-ID: 68B0DD112XK3573533-01-02 Date: Thu, 06 Jul 2006 23:43:39 -0700 From: no-reply@chevron.com To: ospf-archive@lists.ietf.org Message-ID: <68B0DD112XK3573534-01@EMF_chvpk.chevrontexaco.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_-==68B0DD112XK222745==-_" Subject: Chevron Email Firewall Alert X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c --_-==68B0DD112XK222745==-_ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Your message with subject engi@chevron.com sent on 07/06/06, 23:43:37 contained one or more attachments not allowed by Chevron and was blocked. If you did not send such an email, your email address may have been spoofed. In this case, no further action is required on your part and you may disregard this message. For more details on spoofing, please visit http://messaging.chevrontexaco.com/html/spam/spooffaq.asp. --_-==68B0DD112XK222745==-_-- From ospf-bounces@ietf.org Fri Jul 07 17:39:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyy2v-0005I8-Ts; Fri, 07 Jul 2006 17:39:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyy2u-0005Hy-Md for ospf@ietf.org; Fri, 07 Jul 2006 17:39:32 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyy2t-0000yN-EZ for ospf@ietf.org; Fri, 07 Jul 2006 17:39:32 -0400 Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by kremlin.juniper.net with ESMTP; 07 Jul 2006 14:39:31 -0700 X-IronPort-AV: i="4.06,218,1149490800"; d="scan'208"; a="560921069:sNHT30805612" Received: from hadron.jnpr.net ([172.24.15.25]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 14:39:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Jul 2006 14:39:30 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: question regarding DR/BDR in OSPFv2 graceful restart Thread-Index: AcaiDdOnRxotIBblTyGUOFlS6XRLLA== From: "Sunil Patro" To: X-OriginalArrivalTime: 07 Jul 2006 21:39:30.0788 (UTC) FILETIME=[D45E9240:01C6A20D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [OSPF] question regarding DR/BDR in OSPFv2 graceful restart X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Quoting from rfc 3623- " 3) If the restarting router determines that it was the Designated Router on a given segment prior to the restart, it elects itself as the Designated Router again. The restarting router knows that it was the Designated Router if, while the associated interface is in Waiting state, a Hello packet is received from a neighbor listing the router as the Designated Router. Otherwise, the restarting router operates the same as any other OSPF router. It discovers neighbors using OSPF's Hello protocol, elects Designated and Backup Designated Routers, performs the Database Exchange procedure to initially synchronize link-state databases with its neighbors, and maintains this synchronization through flooding." What should be the procedure when the restarting router was the BDR before the restart occurred? After it comes back, it is going to learn that it was the BDR in the neighbor's hellos. Should it just accept that fact and become the BDR again? Thanks Sunil _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jul 07 18:08:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyyUp-0002kZ-5W; Fri, 07 Jul 2006 18:08:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyyUo-0002kR-5x for ospf@ietf.org; Fri, 07 Jul 2006 18:08:22 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyyUm-0007Fg-TJ for ospf@ietf.org; Fri, 07 Jul 2006 18:08:22 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2006 15:08:21 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,218,1149490800"; d="scan'208"; a="31491173:sNHT23144004" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k67M8KAE028131; Fri, 7 Jul 2006 18:08:20 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k67M8KVM028645; Fri, 7 Jul 2006 18:08:20 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 18:08:20 -0400 Received: from [10.82.225.223] ([10.82.225.223]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 18:08:19 -0400 Message-ID: <44AEDB53.3000306@cisco.com> Date: Fri, 07 Jul 2006 18:08:19 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sunil Patro Subject: Re: [OSPF] question regarding DR/BDR in OSPFv2 graceful restart References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2006 22:08:19.0955 (UTC) FILETIME=[DB088430:01C6A211] DKIM-Signature: a=rsa-sha1; q=dns; l=1761; t=1152310100; x=1153174100; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20[OSPF]=20question=20regarding=20DR/BDR=20in=20OSPFv2=20graceful= 20restart |To:Sunil=20Patro=20; X=v=3Dcisco.com=3B=20h=3DtVqjQ8ULQr51jJd5JyOtViNVj1o=3D; b=BgwZxQc0ElGxS8KQZS9VOKK/FA61B1/VLo1wumpQlvJoJOLKIjnJB2akicpYITrl6llAQ+pT hxxlpdeXX3UT4XGKdQJCWEFtpwDPPWjBEVrMzb2g+FJo2kTyCJ9zQhzm; Authentication-Results: rtp-dkim-1.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Sunil, Sunil Patro wrote: >Quoting from rfc 3623- > >" 3) If the restarting router determines that it was the Designated > Router on a given segment prior to the restart, it elects > itself as the Designated Router again. The restarting router > knows that it was the Designated Router if, while the > associated interface is in Waiting state, a Hello packet is > received from a neighbor listing the router as the Designated > Router. > > Otherwise, the restarting router operates the same as any other OSPF > router. It discovers neighbors using OSPF's Hello protocol, elects > Designated and Backup Designated Routers, performs the Database > Exchange procedure to initially synchronize link-state databases with > its neighbors, and maintains this synchronization through flooding." > > >What should be the procedure when the restarting router was the BDR >before the restart occurred? After it comes back, it is going to learn >that it was the BDR in the neighbor's hellos. Should it just accept that >fact and become the BDR again? > > Since the intra-area topology isn't effected, it isn't necessary. This point was previously argued on this list and you might want to check the archives for the complete discussion (in the context of draft-holla-ospf-update-graceful-restart-00.txt). My take is that since the BDR has to reestablish adjacencies anyway, thee is no advantage to retaining BDR status. Also, the restarting router has quite a bit to do already. Thanks, Acee >Thanks >Sunil > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Jul 12 14:10:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jA5-0001sQ-F5; Wed, 12 Jul 2006 14:10:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jA4-0001s8-4F for ospf@ietf.org; Wed, 12 Jul 2006 14:10:12 -0400 Received: from mailgate-internal2.sri.com ([128.18.84.104]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0jA2-0006l6-Jg for ospf@ietf.org; Wed, 12 Jul 2006 14:10:12 -0400 Received: from localhost (HELO mailgate-internal2.SRI.COM) (127.0.0.1) by mailgate-internal2.sri.com with SMTP; 12 Jul 2006 18:10:09 -0000 Received: from mercury.esd.sri.com ([128.18.26.21]) by mailgate-internal2.SRI.COM (SMSSMTP 4.1.11.41) with SMTP id M2006071211100825027 for ; Wed, 12 Jul 2006 11:10:08 -0700 Received: from earthlink.net ([128.18.40.95]) by mercury.esd.sri.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2A00543YJN16@mercury.esd.sri.com> for ospf@ietf.org; Wed, 12 Jul 2006 11:11:47 -0700 (PDT) Date: Wed, 12 Jul 2006 11:10:08 -0700 From: Richard Ogier In-reply-to: To: ospf@ietf.org Message-id: <44B53B00.3030305@earthlink.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [OSPF] Database Exchange Summary List Optimization X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org I listened to Acee's presentation of my draft http://www.ietf.org/internet-drafts/draft-ogier-ospf-dbex-opt-00.txt Acee mentioned that it might help to list the LSAs in lexicographical order, to achieve the maximum savings in overhead. One person commented that it may not be reasonable to require this. I want to point out that one can still achieve the 50% reduction in the number of LSA headers exchanged even if LSAs are not listed in lexicographical order, as long as the received DD packet is processed completely (including updating the summary list as specified in the draft) before the next DD packet is sent. In this case, I don't think the order in which LSAs are listed matters. Comments? Richard _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Jul 12 17:43:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0mUC-0005wJ-B1; Wed, 12 Jul 2006 17:43:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0mUB-0005wE-0p for ospf@ietf.org; Wed, 12 Jul 2006 17:43:11 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0mU8-00066W-O7 for ospf@ietf.org; Wed, 12 Jul 2006 17:43:10 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 12 Jul 2006 14:43:06 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208"; a="32023624:sNHT23198284" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6CLh5wf010196; Wed, 12 Jul 2006 17:43:05 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6CLh5dU014201; Wed, 12 Jul 2006 17:43:05 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jul 2006 17:43:05 -0400 Received: from [10.86.242.186] ([10.86.242.186]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jul 2006 17:43:04 -0400 Message-ID: <44B56CE5.4090901@cisco.com> Date: Wed, 12 Jul 2006 17:43:01 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Ogier Subject: Re: [OSPF] Database Exchange Summary List Optimization References: <44B53B00.3030305@earthlink.net> In-Reply-To: <44B53B00.3030305@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2006 21:43:04.0517 (UTC) FILETIME=[27D3C750:01C6A5FC] DKIM-Signature: a=rsa-sha1; q=dns; l=1320; t=1152740585; x=1153604585; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20[OSPF]=20Database=20Exchange=20Summary=20List=20Optimization |To:Richard=20Ogier=20; X=v=3Dcisco.com=3B=20h=3Dch8APb1Y9bn38d2O3svaF4G0uj0=3D; b=Hf+NSeKKMxgPyRjzckBys2vxF//BR+5z5IldDEa8wONMoUNMuA35R+QJz/1rdHGcDzSNrh6Y hiWGvJJVQc3rqXqVVI2LU7Epuq5q39hWuUCRxyGp9g6svCxCblyIYH4C; Authentication-Results: rtp-dkim-1.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Richard, Richard Ogier wrote: > I listened to Acee's presentation of my draft > http://www.ietf.org/internet-drafts/draft-ogier-ospf-dbex-opt-00.txt > > Acee mentioned that it might help to list the LSAs in > lexicographical order, to achieve the maximum savings > in overhead. One person commented that it may not be > reasonable to require this. > > I want to point out that one can still achieve the 50% reduction > in the number of LSA headers exchanged even if LSAs are not > listed in lexicographical order, as long as the received DD packet > is processed completely (including updating the summary list > as specified in the draft) before the next DD packet is sent. > In this case, I don't think the order in which LSAs are listed > matters. > > Comments? I agree. I probably shouldn't have mentioned lexigraphically ordering at all since it was with respect to how simple and low overhead this optimization is when starting with an implementation following RFC 2328. Given this fact, I'd ask the question again as to whether anyone is opposed to publishing this as an informational WG document? Thanks, Acee > > Richard > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Jul 12 21:57:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0qSO-0002PX-Du; Wed, 12 Jul 2006 21:57:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0qSM-0002PN-KA for ospf@ietf.org; Wed, 12 Jul 2006 21:57:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0p2A-00089J-TC for ospf@ietf.org; Wed, 12 Jul 2006 20:26:26 -0400 Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0ogU-0001ES-FF for ospf@ietf.org; Wed, 12 Jul 2006 20:04:05 -0400 Received: from h-68-164-152-179.snvacaid.dynamic.covad.net ([68.164.152.179] helo=earthlink.net) by pop-borzoi.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1G0ogT-0007NP-00; Wed, 12 Jul 2006 20:04:01 -0400 Message-ID: <44B58E07.890D58F9@earthlink.net> Date: Wed, 12 Jul 2006 17:04:23 -0700 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Acee Lindem Subject: Re: [OSPF] Database Exchange Summary List Optimization References: <44B53B00.3030305@earthlink.net> <44B56CE5.4090901@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.3 (-) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Group, I did not hear Acee's presentation, but have read the two page draft. You mention "This optimization reduces Database Description overhead by about 50% in large networks." I feel only in the last scenario, this statement may be true. However, In the simple, BMA environment, the DR will contain most of the LSAs (scenario 3), I doubt that any reduction would be significant. I am less aware of P2P,etc type environments, where this might be more signficant, thus I suggest a fine tuning to this idea below. Upon my first quick read, 4 scenarios came to mind: 1) a minimal number of LSAs that need to be exchanged on both sides. 2) a large number of LSAs that need to be exchanged on both sides and they are from two past DRs, thus no LSA header will match... 3) a new adj where the DR has already formed adjs and a new router where only a few of its LSA need to be exchanged. 4) two routers have basicly the same LSA list. IF I read the draft correctly, one or both routers are creating a artifical delay before some LSAs are sent. One router might wait until it thinks it has recieved all of the other router's LSA headers. This delay introduces a longer period of time before the OSPF routers could be synchronized. This is expecially true if the waiting router is holds a number of new LSAs. Thus, you are optimizing for the last scenario. If (my theorectical two minute thought suggestion) implemented ordered LSAs, and both routers could agree on a order... stay with me.. Wouldn't it make more sense that the master say send increasing LSAs ids out and the slave send decreasing LSAs out? One could then theorectly compare LSAs and implement what you suggest without delay. In #1, Since the number of LSAs is small, the LSAs will still be exchanged. But where the number of LSAs is LARGE and almost identical between the two routers, then half the number of headers would be sent. Thus, IMO, a new option should be specified that says that the two will exchange in the initial database sync, in reverse order. Again, this will help a DR/BDR full adj formation, only if that is done last. Mitchell Erblich ------------------- Acee Lindem wrote: > > Hi Richard, > Richard Ogier wrote: > > > I listened to Acee's presentation of my draft > > http://www.ietf.org/internet-drafts/draft-ogier-ospf-dbex-opt-00.txt > > > > Acee mentioned that it might help to list the LSAs in > > lexicographical order, to achieve the maximum savings > > in overhead. One person commented that it may not be > > reasonable to require this. > > > > I want to point out that one can still achieve the 50% reduction > > in the number of LSA headers exchanged even if LSAs are not > > listed in lexicographical order, as long as the received DD packet > > is processed completely (including updating the summary list > > as specified in the draft) before the next DD packet is sent. > > In this case, I don't think the order in which LSAs are listed > > matters. > > > > Comments? > > I agree. I probably shouldn't have mentioned lexigraphically ordering > at all since it was with respect to how simple and low overhead this > optimization is when starting with an implementation > following RFC 2328. > > Given this fact, I'd ask the question again as to whether anyone > is opposed to publishing this as an informational WG document? > > Thanks, > Acee > > > > > Richard > > > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Jul 13 08:15:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1066-0007JU-AU; Thu, 13 Jul 2006 08:15:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1064-0007JP-NM for ospf@ietf.org; Thu, 13 Jul 2006 08:15:12 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1064-0000px-5Z for ospf@ietf.org; Thu, 13 Jul 2006 08:15:12 -0400 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 Jul 2006 14:15:13 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6DCFBUO021503; Thu, 13 Jul 2006 14:15:11 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 Jul 2006 14:15:11 +0200 Received: from [10.86.242.245] ([10.86.242.245]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 Jul 2006 14:15:10 +0200 Message-ID: <44B6394B.1000509@cisco.com> Date: Thu, 13 Jul 2006 08:15:07 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erblichs Subject: Re: [OSPF] Database Exchange Summary List Optimization References: <44B53B00.3030305@earthlink.net> <44B56CE5.4090901@cisco.com> <44B58E07.890D58F9@earthlink.net> In-Reply-To: <44B58E07.890D58F9@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2006 12:15:10.0418 (UTC) FILETIME=[FC7EA320:01C6A675] X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Mitchell, Erblichs wrote: >Group, > > I did not hear Acee's presentation, but have read the > two page draft. > > You mention > "This optimization reduces Database Description > overhead by about 50% in large networks." I feel > only in the last scenario, this statement may be > true. However, In the simple, BMA > environment, the DR will contain most of the LSAs > (scenario 3), I doubt that any reduction would be > significant. > > I am less aware of P2P,etc type environments, where this > might be more signficant, thus I suggest a fine tuning > to this idea below. > > Upon my first quick read, 4 scenarios came to mind: > 1) a minimal number of LSAs that need to be exchanged > on both sides. > 2) a large number of LSAs that need to be exchanged > on both sides and they are from two past DRs, > thus no LSA header will match... > 3) a new adj where the DR has already formed adjs > and a new router where only a few of its LSA > need to be exchanged. > 4) two routers have basicly the same LSA list. > > IF I read the draft correctly, one or both routers are > creating a artifical delay before some LSAs are sent. > One router might wait until it thinks it has recieved > all of the other router's LSA headers. > > Since the database exchange window size is 1 with the master pacing the exchange, there is no additional delay. If you look at section 10.6 of RFC 2328, you'll note that the RFC specifies that the database exchange packet be processed prior to response. One could envision trying to optimize this but I doubt you'd get a lot of bang for your buck. > This delay introduces a longer period of time before > the OSPF routers could be synchronized. This is > expecially true if the waiting router is holds a number > of new LSAs. Thus, you are optimizing for the last > scenario. > > If (my theorectical two minute thought suggestion) > implemented ordered LSAs, and both routers could > agree on a order... stay with me.. > > Wouldn't it make more sense that the master say send > increasing LSAs ids out and the slave send decreasing > LSAs out? > > One could then theorectly compare LSAs and implement what > you suggest without delay. In #1, Since the number of LSAs > is small, the LSAs will still be exchanged. But where the > number of LSAs is LARGE and almost identical between the > two routers, then half the number of headers would be sent. > > Thus, IMO, a new option should be specified that says that > the two will exchange in the initial database sync, in reverse > order. Again, this will help a DR/BDR full adj formation, only > if that is done last. > > As I stated previously, the ordering has no impact other than the processing of the database snapshot and that is an implementation issue. Thanks, Acee > Mitchell Erblich > ------------------- > > >Acee Lindem wrote: > > >>Hi Richard, >>Richard Ogier wrote: >> >> >> >>>I listened to Acee's presentation of my draft >>>http://www.ietf.org/internet-drafts/draft-ogier-ospf-dbex-opt-00.txt >>> >>>Acee mentioned that it might help to list the LSAs in >>>lexicographical order, to achieve the maximum savings >>>in overhead. One person commented that it may not be >>>reasonable to require this. >>> >>>I want to point out that one can still achieve the 50% reduction >>>in the number of LSA headers exchanged even if LSAs are not >>>listed in lexicographical order, as long as the received DD packet >>>is processed completely (including updating the summary list >>>as specified in the draft) before the next DD packet is sent. >>>In this case, I don't think the order in which LSAs are listed >>>matters. >>> >>>Comments? >>> >>> >>I agree. I probably shouldn't have mentioned lexigraphically ordering >>at all since it was with respect to how simple and low overhead this >>optimization is when starting with an implementation >>following RFC 2328. >> >>Given this fact, I'd ask the question again as to whether anyone >>is opposed to publishing this as an informational WG document? >> >>Thanks, >>Acee >> >> >> >>>Richard >>> >>> >>>_______________________________________________ >>>OSPF mailing list >>>OSPF@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ospf >>> >>> >>> >>_______________________________________________ >>OSPF mailing list >>OSPF@ietf.org >>https://www1.ietf.org/mailman/listinfo/ospf >> >> > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Jul 13 10:49:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12Vj-0002i5-Le; Thu, 13 Jul 2006 10:49:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12Vi-0002hs-Ed for ospf@ietf.org; Thu, 13 Jul 2006 10:49:50 -0400 Received: from wx-out-0102.google.com ([66.249.82.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12Vg-0007Xd-3C for ospf@ietf.org; Thu, 13 Jul 2006 10:49:50 -0400 Received: by wx-out-0102.google.com with SMTP id h30so85719wxd for ; Thu, 13 Jul 2006 07:49:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=axfz72tv2N7plTCT/KNIyABKUCOTgm+GEiO1LrOFaLVkvlpfe92mpfTdavWfjgzDA+a0yFQLZlkbzku4Cjn2mGrKtcL3bz32BeA3s9uNI8RqfWWuKhPD11TAurVm2KxwdXcVWlRwmrCNenqkYwkjeyNQhT2SGttqXJKf+xjeDcw= Received: by 10.70.74.1 with SMTP id w1mr1408601wxa; Thu, 13 Jul 2006 07:49:47 -0700 (PDT) Received: by 10.70.7.7 with HTTP; Thu, 13 Jul 2006 07:49:47 -0700 (PDT) Message-ID: <77ead0ec0607130749t654db6fej4ee282790b11ed43@mail.gmail.com> Date: Thu, 13 Jul 2006 20:19:47 +0530 From: "Vishwas Manral" To: "Acee Lindem" Subject: Re: [OSPF] Database Exchange Summary List Optimization In-Reply-To: <44B6394B.1000509@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44B53B00.3030305@earthlink.net> <44B56CE5.4090901@cisco.com> <44B58E07.890D58F9@earthlink.net> <44B6394B.1000509@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org The draft looks good to me. Thanks, Vishwas On 7/13/06, Acee Lindem wrote: > Hi Mitchell, > > Erblichs wrote: > > >Group, > > > > I did not hear Acee's presentation, but have read the > > two page draft. > > > > You mention > > "This optimization reduces Database Description > > overhead by about 50% in large networks." I feel > > only in the last scenario, this statement may be > > true. However, In the simple, BMA > > environment, the DR will contain most of the LSAs > > (scenario 3), I doubt that any reduction would be > > significant. > > > > I am less aware of P2P,etc type environments, where this > > might be more signficant, thus I suggest a fine tuning > > to this idea below. > > > > Upon my first quick read, 4 scenarios came to mind: > > 1) a minimal number of LSAs that need to be exchanged > > on both sides. > > 2) a large number of LSAs that need to be exchanged > > on both sides and they are from two past DRs, > > thus no LSA header will match... > > 3) a new adj where the DR has already formed adjs > > and a new router where only a few of its LSA > > need to be exchanged. > > 4) two routers have basicly the same LSA list. > > > > IF I read the draft correctly, one or both routers are > > creating a artifical delay before some LSAs are sent. > > One router might wait until it thinks it has recieved > > all of the other router's LSA headers. > > > > > Since the database exchange window size is 1 with the master pacing > the exchange, there is no additional delay. If you look at section 10.6 > of RFC 2328, > you'll note that the RFC specifies that the database exchange packet be > processed > prior to response. One could envision trying to optimize this but I > doubt you'd > get a lot of bang for your buck. > > > This delay introduces a longer period of time before > > the OSPF routers could be synchronized. This is > > expecially true if the waiting router is holds a number > > of new LSAs. Thus, you are optimizing for the last > > scenario. > > > > If (my theorectical two minute thought suggestion) > > implemented ordered LSAs, and both routers could > > agree on a order... stay with me.. > > > > Wouldn't it make more sense that the master say send > > increasing LSAs ids out and the slave send decreasing > > LSAs out? > > > > One could then theorectly compare LSAs and implement what > > you suggest without delay. In #1, Since the number of LSAs > > is small, the LSAs will still be exchanged. But where the > > number of LSAs is LARGE and almost identical between the > > two routers, then half the number of headers would be sent. > > > > Thus, IMO, a new option should be specified that says that > > the two will exchange in the initial database sync, in reverse > > order. Again, this will help a DR/BDR full adj formation, only > > if that is done last. > > > > > As I stated previously, the ordering has no impact other than > the processing of the database snapshot and that is an implementation > issue. > > Thanks, > Acee > > > Mitchell Erblich > > ------------------- > > > > > >Acee Lindem wrote: > > > > > >>Hi Richard, > >>Richard Ogier wrote: > >> > >> > >> > >>>I listened to Acee's presentation of my draft > >>>http://www.ietf.org/internet-drafts/draft-ogier-ospf-dbex-opt-00.txt > >>> > >>>Acee mentioned that it might help to list the LSAs in > >>>lexicographical order, to achieve the maximum savings > >>>in overhead. One person commented that it may not be > >>>reasonable to require this. > >>> > >>>I want to point out that one can still achieve the 50% reduction > >>>in the number of LSA headers exchanged even if LSAs are not > >>>listed in lexicographical order, as long as the received DD packet > >>>is processed completely (including updating the summary list > >>>as specified in the draft) before the next DD packet is sent. > >>>In this case, I don't think the order in which LSAs are listed > >>>matters. > >>> > >>>Comments? > >>> > >>> > >>I agree. I probably shouldn't have mentioned lexigraphically ordering > >>at all since it was with respect to how simple and low overhead this > >>optimization is when starting with an implementation > >>following RFC 2328. > >> > >>Given this fact, I'd ask the question again as to whether anyone > >>is opposed to publishing this as an informational WG document? > >> > >>Thanks, > >>Acee > >> > >> > >> > >>>Richard > >>> > >>> > >>>_______________________________________________ > >>>OSPF mailing list > >>>OSPF@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/ospf > >>> > >>> > >>> > >>_______________________________________________ > >>OSPF mailing list > >>OSPF@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ospf > >> > >> > > > > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Jul 13 12:34:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1490-0002be-Je; Thu, 13 Jul 2006 12:34:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1490-0002bY-5J for ospf@ietf.org; Thu, 13 Jul 2006 12:34:30 -0400 Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G148z-0005gB-QC for ospf@ietf.org; Thu, 13 Jul 2006 12:34:30 -0400 Received: from dialup-4.243.131.156.dial1.sanfrancisco1.level3.net ([4.243.131.156] helo=earthlink.net) by pop-savannah.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1G148y-0003Qz-00; Thu, 13 Jul 2006 12:34:28 -0400 Message-ID: <44B67604.2060503@earthlink.net> Date: Thu, 13 Jul 2006 09:34:12 -0700 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: ospf@ietf.org, erblichs@earthlink.net Subject: Re: [OSPF] Database Exchange Summary List Optimization References: <44B53B00.3030305@earthlink.net> <44B56CE5.4090901@cisco.com> <44B58E07.890D58F9@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hello Mitchell, Thanks for your comments. I agree with Acee's response, and I have a few more comments below. Erblichs wrote: >Group, > > I did not hear Acee's presentation, but have read the > two page draft. > > You mention > "This optimization reduces Database Description > overhead by about 50% in large networks." I feel > only in the last scenario, this statement may be > true. However, In the simple, BMA > > environment, the DR will contain most of the LSAs > (scenario 3), I doubt that any reduction would be > significant. > > > > I am less aware of P2P,etc type environments, where this > might be more signficant, thus I suggest a fine tuning > to this idea below. > > Upon my first quick read, 4 scenarios came to mind: > 1) a minimal number of LSAs that need to be exchanged > on both sides. > 2) a large number of LSAs that need to be exchanged > on both sides and they are from two past DRs, > thus no LSA header will match... > 3) a new adj where the DR has already formed adjs > and a new router where only a few of its LSA > need to be exchanged. > 4) two routers have basicly the same LSA list. > The optimization is mostly indended for the last scenario, which is often the case in MANETs. The following sentence from Section 1 of my draft implies this: "The optimization reduces Database Description overhead by about 50% in large networks, since it reduces the total number of LSA headers exchanged by about one- half when the two routers are already nearly synchronized." > > > IF I read the draft correctly, one or both routers are > creating a artifical delay before some LSAs are sent. > One router might wait until it thinks it has recieved > all of the other router's LSA headers. > There is no additional delay. It is important that the received DD packet be processed completely (including updating the summary list as specified in my draft) before the next DD packet is sent in response, and I will clarify this in the draft. As a result, the next sent DD packet will not list any LSAs that were listed in the received DD packet (with the same or newer instance). > > > This delay introduces a longer period of time before > the OSPF routers could be synchronized. This is > expecially true if the waiting router is holds a number > of new LSAs. Thus, you are optimizing for the last > scenario. > > If (my theorectical two minute thought suggestion) > implemented ordered LSAs, and both routers could > agree on a order... stay with me.. > > Wouldn't it make more sense that the master say send > increasing LSAs ids out and the slave send decreasing > LSAs out? > As Acee mentioned, the ordering does not matter, as long as the received DD packet is processed before the next DD packet is sent in response. > > > One could then theorectly compare LSAs and implement what > you suggest without delay. In #1, Since the number of LSAs > is small, the LSAs will still be exchanged. But where the > number of LSAs is LARGE and almost identical between the > two routers, then half the number of headers would be sent. > Right. That was the main intention. This has been shown in simulations of OSPF-MDR (for MANETs) using GTNetS. I have one concern. What if some future extension of OSPF assumes that DD packets list all LSAs as specified in RFC 2328, e.g., so that some action can be taken that depends on how "out of sync" the new neighbor was. If someone implements the optimization without any indication (such as a new option bit), then a future extension might incorrectly conclude that the new neighbor was out of sync and take the wrong action. This could be fixed either by including a new option bit, or by changing the spec of OSPF to allow the optimization. Is this a valid concern? Richard > > > Thus, IMO, a new option should be specified that says that > the two will exchange in the initial database sync, in reverse > order. Again, this will help a DR/BDR full adj formation, only > if that is done last. > > > > Mitchell Erblich > ------------------- > > >Acee Lindem wrote: > >>Hi Richard, >>Richard Ogier wrote: >> >>>I listened to Acee's presentation of my draft >>>http://www.ietf.org/internet-drafts/draft-ogier-ospf-dbex-opt-00.txt >>> >>>Acee mentioned that it might help to list the LSAs in >>>lexicographical order, to achieve the maximum savings >>>in overhead. One person commented that it may not be >>>reasonable to require this. >>> >>>I want to point out that one can still achieve the 50% reduction >>>in the number of LSA headers exchanged even if LSAs are not >>>listed in lexicographical order, as long as the received DD packet >>>is processed completely (including updating the summary list >>>as specified in the draft) before the next DD packet is sent. >>>In this case, I don't think the order in which LSAs are listed >>>matters. >>> >>>Comments? >>> >>I agree. I probably shouldn't have mentioned lexigraphically ordering >>at all since it was with respect to how simple and low overhead this >>optimization is when starting with an implementation >>following RFC 2328. >> >>Given this fact, I'd ask the question again as to whether anyone >>is opposed to publishing this as an informational WG document? >> >>Thanks, >>Acee >> >>>Richard >>> >>> >>>_______________________________________________ >>>OSPF mailing list >>>OSPF@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ospf >>> >>_______________________________________________ >>OSPF mailing list >>OSPF@ietf.org >>https://www1.ietf.org/mailman/listinfo/ospf >> > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Jul 13 20:32:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1BbG-0003xY-J1; Thu, 13 Jul 2006 20:32:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1BbF-0003xT-9o for ospf@ietf.org; Thu, 13 Jul 2006 20:32:09 -0400 Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1BbD-0007wX-Rh for ospf@ietf.org; Thu, 13 Jul 2006 20:32:09 -0400 Received: from h-68-164-152-179.snvacaid.dynamic.covad.net ([68.164.152.179] helo=earthlink.net) by pop-siberian.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1G1BbC-0004xf-00; Thu, 13 Jul 2006 20:32:07 -0400 Message-ID: <44B6E61E.E4423664@earthlink.net> Date: Thu, 13 Jul 2006 17:32:30 -0700 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Richard Ogier Subject: Re: [OSPF] Database Exchange Summary List Optimization References: <44B53B00.3030305@earthlink.net> <44B56CE5.4090901@cisco.com> <44B58E07.890D58F9@earthlink.net> <44B67604.2060503@earthlink.net> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Richard, Their are two areas here: delay and ordering. First, inline you state: > It is important that the received > DD packet be processed completely (including updating the summary list > as specified in my draft) before the next DD packet is sent in response, The act of processing before, is the delay that I speak of. This action sequentializes this processing. ie: recv DD pkt, process it, send our DD resp, sleep: perchance to dream (ie:Shakespere), recv next, process it, send our next DD pkt. If all the LSA hdrs recv'd takes a total of 15 secs to process, this will add 15 secs before we can converge. To keep the parallelism of the current arch could do: * Upon all DD pkt recv'd, process it after our DD pkt is sent in response. While the resp DD pkt is being processed, clean the summary list based on the recvd pkt. We will send some percentage based on LSA ordering, relative size, but will decrease the number of LSA hdrs sent (cleaned ones), but will be able to do the cleaning during the time between successively recv'd DD pkts. Why should/could we order? * My older proposition. I don't care if 5% of hdrs are in common or 95%, this in theory should work. If the master covers 1/2 of the DB and the slave covers the other half, best case the headers of 1x the LSDB need be sent in DD pkts. The only assumption is that both LSDBs on the two routers have approx the same number of LSAs. We will be filtering as we recv the DD pkts, but should have no need to process the DD pkt from the other router "before the next DD pkt is sent in response". We will do this cleaning during the time between successively recv'd DD pkts. Because of the ordering, their is NO NEED to wait, if the LSDB is of sufficient size on both routers. We will not initially be sending LSAs that can conflict. The complexity is what do we do as we approach the middle and start with conflicts. Where this optmization does not help, if the number of hdrs is such that only a few DD pkts need to be sent or where one router has a significantly larger LSDB. * The third suggestion is inline for kbps environments... Mitchell Erblich --------------------------------- Richard Ogier wrote: > > Hello Mitchell, > > Thanks for your comments. I agree with Acee's response, > and I have a few more comments below. > > Erblichs wrote: > > >Group, > > > > I did not hear Acee's presentation, but have read the > > two page draft. > > > > You mention > > "This optimization reduces Database Description > > overhead by about 50% in large networks." I feel > > only in the last scenario, this statement may be > > true. However, In the simple, BMA > > > > environment, the DR will contain most of the LSAs > > (scenario 3), I doubt that any reduction would be > > significant. > > > > > > > > I am less aware of P2P,etc type environments, where this > > might be more signficant, thus I suggest a fine tuning > > to this idea below. > > > > Upon my first quick read, 4 scenarios came to mind: > > 1) a minimal number of LSAs that need to be exchanged > > on both sides. > > 2) a large number of LSAs that need to be exchanged > > on both sides and they are from two past DRs, > > thus no LSA header will match... > > 3) a new adj where the DR has already formed adjs > > and a new router where only a few of its LSA > > need to be exchanged. > > 4) two routers have basicly the same LSA list. > > > > The optimization is mostly indended for the last scenario, > which is often the case in MANETs. The following sentence from > Section 1 of my draft implies this: > "The optimization reduces > Database Description overhead by about 50% in large networks, since > it reduces the total number of LSA headers exchanged by about one- > half when the two routers are already nearly synchronized." > Shouldn't we find a implimentation that works also when they aren't nearly synchronized? That is where ordering stated earlier and above comes in, with a new option. > > > > > > IF I read the draft correctly, one or both routers are > > creating a artifical delay before some LSAs are sent. > > One router might wait until it thinks it has recieved > > all of the other router's LSA headers. > > > > There is no additional delay. It is important that the received > DD packet be processed completely (including updating the summary list > as specified in my draft) before the next DD packet is sent in response, > and I will clarify this in the draft. As a result, the next sent > DD packet will not list any LSAs that were listed in the received > DD packet (with the same or newer instance). > Sorry, "BEFORE" implies a wait until... This is a additional delay..:^) If the Master contains enough LSAs such that it takes X secs to process, this adds to the convergence of these LSDBs. I see where a bandwidth is such that one wants to limit the number of LSA hdrs exchanged. But this could also theorecticly be done if one would to segment the LSDB per LSA type, exchange LSDB type checksums, and if they then disagree exchange hdrs... You just need to come up with a checksum that only one set of LSAs will produce a unique checksum. I am not a mathematican to tell you how complex this might be.. > > > > > > This delay introduces a longer period of time before > > the OSPF routers could be synchronized. This is > > expecially true if the waiting router is holds a number > > of new LSAs. Thus, you are optimizing for the last > > scenario. > > > > If (my theorectical two minute thought suggestion) > > implemented ordered LSAs, and both routers could > > agree on a order... stay with me.. > > > > Wouldn't it make more sense that the master say send > > increasing LSAs ids out and the slave send decreasing > > LSAs out? > > > > As Acee mentioned, the ordering does not matter, as long as the received > DD packet is processed before the next DD packet is sent in response. > The ordering is based to remove the wait and LSA conflicts at the ends of the LSDB. .. > > > > > > One could then theorectly compare LSAs and implement what > > you suggest without delay. In #1, Since the number of LSAs > > is small, the LSAs will still be exchanged. But where the > > number of LSAs is LARGE and almost identical between the > > two routers, then half the number of headers would be sent. > > > > Right. That was the main intention. This has been shown in simulations > of OSPF-MDR (for MANETs) using GTNetS. > > I have one concern. What if some future extension of OSPF assumes that > DD packets list all LSAs as specified in RFC 2328, e.g., so that some > action can be taken that depends on how "out of sync" the new neighbor > was. If someone implements the optimization without any indication > (such as a new option bit), then a future extension > might incorrectly conclude that the new neighbor was out of sync > and take the wrong action. This could be fixed either by including > a new option bit, or by changing the spec of OSPF to allow the > optimization. Is this a valid concern? I first want to sync with you on the above, but don't we do a checksum on our LSDB on most implementation. Why couldn't we exchange the result and if different, then..... Inline Mitchell Erblich > > Richard > > > > > > > Thus, IMO, a new option should be specified that says that > > the two will exchange in the initial database sync, in reverse > > order. Again, this will help a DR/BDR full adj formation, only > > if that is done last. > > > > > > > > > Mitchell Erblich > > ------------------- > > > > > >Acee Lindem wrote: > > > >>Hi Richard, > >>Richard Ogier wrote: > >> > >>>I listened to Acee's presentation of my draft > >>>http://www.ietf.org/internet-drafts/draft-ogier-ospf-dbex-opt-00.txt > >>> > >>>Acee mentioned that it might help to list the LSAs in > >>>lexicographical order, to achieve the maximum savings > >>>in overhead. One person commented that it may not be > >>>reasonable to require this. > >>> > >>>I want to point out that one can still achieve the 50% reduction > >>>in the number of LSA headers exchanged even if LSAs are not > >>>listed in lexicographical order, as long as the received DD packet > >>>is processed completely (including updating the summary list > >>>as specified in the draft) before the next DD packet is sent. > >>>In this case, I don't think the order in which LSAs are listed > >>>matters. > >>> > >>>Comments? > >>> > >>I agree. I probably shouldn't have mentioned lexigraphically ordering > >>at all since it was with respect to how simple and low overhead this > >>optimization is when starting with an implementation > >>following RFC 2328. > >> > >>Given this fact, I'd ask the question again as to whether anyone > >>is opposed to publishing this as an informational WG document? > >> > >>Thanks, > >>Acee > >> > >>>Richard > >>> > >>> > >>>_______________________________________________ > >>>OSPF mailing list > >>>OSPF@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/ospf > >>> > >>_______________________________________________ > >>OSPF mailing list > >>OSPF@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ospf > >> > > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jul 14 01:18:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1G4K-0000eb-4A; Fri, 14 Jul 2006 01:18:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1G4I-0000eV-7R for ospf@ietf.org; Fri, 14 Jul 2006 01:18:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1G4I-00089P-38 for ospf@ietf.org; Fri, 14 Jul 2006 01:18:26 -0400 Received: from kecgate02.progeon.com ([61.95.162.76] helo=Kecgate02.infosys.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G1FxV-0004gS-2O for ospf@ietf.org; Fri, 14 Jul 2006 01:11:29 -0400 Received: from indhubbhs01.ad.infosys.com ([192.168.200.81]) by Kecgate02.infosys.com with InterScan Messaging Security Suite; Fri, 14 Jul 2006 10:39:58 +0530 Received: from CHNSHLMSG02.ad.infosys.com ([172.21.73.102]) by indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 10:40:17 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6A703.CB248920" Date: Fri, 14 Jul 2006 10:40:19 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Functionally equivalent as-external lsa Thread-Index: AcaZ6db/gI+h3jKnRXCT8X3m3el8ugNF5hEQ From: "Chitra Lakshmi Namadevan" To: X-OriginalArrivalTime: 14 Jul 2006 05:10:17.0704 (UTC) FILETIME=[CC10EE80:01C6A703] X-Spam-Score: -2.5 (--) X-Scan-Signature: 0c3d807a9e67fb2ae2b97f891ffd2e4e Subject: [OSPF] Functionally equivalent as-external lsa X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A703.CB248920 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C6A703.CB248920" ------_=_NextPart_002_01C6A703.CB248920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =0D Functionally equivalent AS-external lsas are originated. Therefore the lsa with higher advertising router id is installed and the other lsa is flushed. =0D Topology: =0D dummy dummy SW(*) SW(*) | | +-----+ | | +-----+ | | | | | | | +---+ +---+ | | | | | |PSS9 +------ X ------|PSS11| +-----+ +-----+ 10.81.156.72 10.81.156.74 3.3.3.0/24 =0D (*)dummy SW: only for up the Link of PSS9/PSS11. =0D Problem 1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D But the database of PSS11 has the AS-external lsa whose advertising router is 10.81.156.72 along with the lsa advertised by 10.81.156.74. This is the problem.=0D =0D PSS9 sends a maxage lsa. When PSS11 receives this maxage lsa it should flush the external lsa with advertising router 10.81.156.72. But it is not flushed.=0D =0D It is due to the following explanation found in RFC2328: =0D "If there is already a database copy, and if the database copy was received via flooding and installed less than MinLSArrival seconds ago, discard the new LSA (without acknowledging it) and examine the next LSA (if any) listed in the Link State Update packet." =0D Therefore it discards the maxage lsa and so the lsa is not flushed and it still remains. =0D Analysis: PSS-11 discards the maxage lsa without any ls-ack. PSS-9 should not flush the lsa and should send again a maxage lsa since it did not receive a LS-ACK for the maxage lsa. =0D Kindly let me know if my analysis is correct. =0D Problem 2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Disconnect the cable and make the link up. Then the router with the lower router id (10.81.156.72 - PSS9) has the as-external lsa advertised by the higher router id (10.81.156.74 - PSS11). But it should have the as-external lsa advertised by lower router id i.e. self lsa. =0D This is happening because the as-external lsa with higher router id is not flushed. Therefore when PSS 9 originates the self as-external lsa, it finds that functionally equivalent as-external lsa is still present so it discards its self lsa.=0D =0D Kindly let me know what mechanism can be followed to flush the as-external lsa with higher router id when the neighbor is deleted. =0D Regards, Chitra =0D =0D =0D **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended= solely for the use of the addressee(s). If you are not the intended= recipient, please notify the sender by e-mail and delete the original= message. Further, you are not to copy, disclose, or distribute this e-mail= or its contents to any other person and any such actions are unlawful.= This e-mail may contain viruses. Infosys has taken every reasonable= precaution to minimize this risk, but is not liable for any damage you may= sustain as a result of any virus in this e-mail. You should carry out your= own virus checks before opening the e-mail or attachment. Infosys reserves= the right to monitor and review the content of all messages sent to or= from this e-mail address. Messages sent to or from this e-mail address may= be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** ------_=_NextPart_002_01C6A703.CB248920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Functionally equivalent= AS-external lsas are originated. Therefore the lsa with higher advertising router id is= installed and the other lsa is flushed.

 

Topology:   =

         dummy   = dummy

         SW(*)    SW(*)

          |       |

+-----+   |       |  = +-----+

|     |   |       |   |     |

|     +---+       +---+    = |

|     |            &n= bsp;  |     |

|PSS9 +------ X ------|PSS11|

+-----+          &= nbsp;    +-----+

10.81.156.72          10.81.156.74

          3.3.3.0/24

 

 (*)dummy SW: only for up= the Link of PSS9/PSS11.

 

Problem= 1:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

But the database of PSS11 has= the AS-external lsa whose advertising router is 10.81.156.72 along with the lsa advertised by 10.81.156.74. This is the problem.

 

PSS9 sends a maxage lsa. When= PSS11 receives this maxage lsa it should flush the external lsa with advertising router 10.81.156.72. But it is not flushed.

 

It is due to the following explanation found in RFC2328:

 

"If there is already a= database copy, and if the database copy was received via flooding and installed less than MinLSArrival seconds ago, discard the new LSA (without acknowledging= it) and examine the next LSA (if any) listed in the Link State Update= packet."

 

Therefore it discards the= maxage lsa and so the lsa is not flushed and it still= remains.

 

Analysis:<= /p>

PSS-11 discards the maxage lsa without any ls-ack. PSS-9 should not flush the lsa and should send again a maxage lsa since it did not receive a LS-ACK for the maxage= lsa.

 

Kindly let me know if my= analysis is correct.

 

Problem= 2:

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Disconnect the cable and make the link up. Then the= router with the lower router id (10.81.156.72 – PSS9) has the as-external= lsa advertised by the higher router id (10.81.156.74 – PSS11). But it= should have the as-external lsa advertised by lower router id i.e. self= lsa.

 

This is happening because the as-external lsa with= higher router id is not flushed. Therefore when PSS 9 originates the self= as-external lsa, it finds that functionally equivalent as-external lsa is still present= so it discards its self lsa.

 

Kindly let me know what mechanism can be followed to= flush the as-external lsa with higher router id when the neighbor is= deleted.

 =

Regards,

Chitra

 

 

 

****************= CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended= solely for the use of the addressee(s). If you are not the intended= recipient, please notify the sender by e-mail and delete the original= message. Further, you are not to copy, disclose, or distribute this e-mail= or its contents to any other person and any such actions are unlawful.= This e-mail may contain viruses. Infosys has taken every reasonable= precaution to minimize this risk, but is not liable for any damage you may= sustain as a result of any virus in this e-mail. You should carry out your= own virus checks before opening the e-mail or attachment. Infosys reserves= the right to monitor and review the content of all messages sent to or= from this e-mail address. Messages sent to or from this e-mail address may= be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
------_=_NextPart_002_01C6A703.CB248920-- ------_=_NextPart_001_01C6A703.CB248920 Content-Type: text/plain; name="31348_log.txt" Content-Transfer-Encoding: base64 Content-Description: 31348_log.txt Content-Disposition: attachment; filename="31348_log.txt" UFNTOS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1QU1MxMQ0KMTAuODEuMTU2LjcyICAgICAgICAg ICAgIDEwLjgxLjE1Ni43NA0KICAgICAgICAgICAzLjMuMy4wLzI0DQppcCByb3V0ZSAyMC4wLjAu MC8yNCAzLjMuMy4zDQoNCkFjY29yZGluZyB0byBSRkMgMjMyODoNCg0KImlmIHR3byByb3V0ZXJz LCBib3RoIHJlYWNoYWJsZSBmcm9tIG9uZSBhbm90aGVyLCBvcmlnaW5hdGUgZnVuY3Rpb25hbGx5 IGVxdWl2YWxlbnQgQVMtZXh0ZXJuYWwtTFNBcyAoaS5lLiwgc2FtZSBkZXN0aW5hdGlvbiwgY29z dCBhbmQgbm9uLXplcm8gZm9yd2FyZGluZyBhZGRyZXNzKSwgdGhlbiB0aGUgTFNBIG9yaWdpbmF0 ZWQgYnkgdGhlIHJvdXRlciBoYXZpbmcgdGhlIGhpZ2hlc3QgT1NQRiBSb3V0ZXIgSUQgaXMgdXNl ZC4gVGhlIHJvdXRlciBoYXZpbmcgdGhlIGxvd2VyIE9TUEYgUm91dGVyIElEIGNhbiB0aGVuIGZs dXNoIGl0cyBMU0EuIiANCg0KDQpQU1MtOSNzaG93IGlwIG9zcGYgbmVpZ2hib3INCg0KT1NQRiBw cm9jZXNzIDA6DQpOZWlnaGJvciBJRCAgICAgUHJpICAgU3RhdGUgICAgICAgICAgIERlYWQgVGlt ZSAgIEFkZHJlc3MgICAgICAgICBJbnRlcmZhY2UNCjEwLjgxLjE1Ni43NCAgICAgIDEgICBGdWxs L0RSICAgICAgICAgMDA6MDA6MzUgICAgMy4zLjMuMSAgICAgICAgIGZ4cDINCg0KDQpUaGVyZWZv cmUgUFNTOSBpbnN0YWxscyB0aGUgZXh0ZXJuYWwgbHNhIG9yaWdpbmF0ZWQgYnkgUFNTMTEgKDEw LjgxLjE1Ni43NCkgYW5kIGZsdXNoZXMgaXRzIG93biBsc2EuDQoNClBTUy05I3Nob3cgaXAgb3Nw ZiBkYXRhYmFzZSBleHRlcm5hbCAyMC4wLjAuMA0KDQogICAgICAgICAgICAgICAgQVMgRXh0ZXJu YWwgTGluayBTdGF0ZXMNCg0KICBMUyBhZ2U6IDExNQ0KICBPcHRpb25zOiAweDIgKCp8LXwtfC18 LXwtfEV8LSkNCiAgTFMgVHlwZTogQVMtZXh0ZXJuYWwtTFNBDQogIExpbmsgU3RhdGUgSUQ6IDIw LjAuMC4wIChFeHRlcm5hbCBOZXR3b3JrIE51bWJlcikNCiAgQWR2ZXJ0aXNpbmcgUm91dGVyOiAx MC44MS4xNTYuNzQgID4+Pj4+Pj4+Pj4+Pj4+PiBIaWdoZXIgcm91dGVyIGlkDQogIExTIFNlcSBO dW1iZXI6IDgwMDAwMDAxDQogIENoZWNrc3VtOiAweDUyMGENCiAgTGVuZ3RoOiAzNg0KICBOZXR3 b3JrIE1hc2s6IC8yNA0KICAgICAgICBNZXRyaWMgVHlwZTogMiAoTGFyZ2VyIHRoYW4gYW55IGxp bmsgc3RhdGUgcGF0aCkNCiAgICAgICAgVE9TOiAwDQogICAgICAgIE1ldHJpYzogMjANCiAgICAg ICAgRm9yd2FyZCBBZGRyZXNzOiAzLjMuMy4zDQogICAgICAgIEV4dGVybmFsIFJvdXRlIFRhZzog MA0KDQoNCg0KbG9jYWxob3N0LmxvY2FsZG9tYWluIyBzaG93IGlwIG9zcGYgbmVpZ2hib3INCg0K T1NQRiBwcm9jZXNzIDA6DQpOZWlnaGJvciBJRCAgICAgUHJpICAgU3RhdGUgICAgICAgICAgIERl YWQgVGltZSAgIEFkZHJlc3MgICAgICAgICBJbnRlcmZhY2UNCjEwLjgxLjE1Ni43MiAgICAgIDEg ICBGdWxsL0JhY2t1cCAgICAgMDA6MDA6MzUgICAgMy4zLjMuMiAgICAgICAgIGV0aDINCg0KbG9j YWxob3N0LmxvY2FsZG9tYWluI3Nob3cgaXAgb3NwZiBkYXRhYmFzZSBleHRlcm5hbCAyMC4wLjAu MA0KDQogICAgICAgICAgICAgICAgQVMgRXh0ZXJuYWwgTGluayBTdGF0ZXMNCg0KICBMUyBhZ2U6 IDEwMw0KICBPcHRpb25zOiAweDIgKCp8LXwtfC18LXwtfEV8LSkNCiAgTFMgVHlwZTogQVMtZXh0 ZXJuYWwtTFNBDQogIExpbmsgU3RhdGUgSUQ6IDIwLjAuMC4wIChFeHRlcm5hbCBOZXR3b3JrIE51 bWJlcikNCiAgQWR2ZXJ0aXNpbmcgUm91dGVyOiAxMC44MS4xNTYuNzIgPj4+Pj4+Pj4+Pj5leHRl cm5hbCBsc2Egd2hvc2UgYWR2ZXJ0aXNpbmcgcm91dGVyIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGlzIDEwLjgxLjE1Ni43MiBpcyBleGlzdGluZy4gDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHByb2JsZW0gcG9p bnRlZCBvdXQgYnkgdGhlIGN1c3RvbWVyKQ0KICBMUyBTZXEgTnVtYmVyOiA4MDAwMDAwMQ0KICBD aGVja3N1bTogMHg1ZWZmDQogIExlbmd0aDogMzYNCiAgTmV0d29yayBNYXNrOiAvMjQNCiAgICAg ICAgTWV0cmljIFR5cGU6IDIgKExhcmdlciB0aGFuIGFueSBsaW5rIHN0YXRlIHBhdGgpDQogICAg ICAgIFRPUzogMA0KICAgICAgICBNZXRyaWM6IDIwDQogICAgICAgIEZvcndhcmQgQWRkcmVzczog My4zLjMuMw0KICAgICAgICBFeHRlcm5hbCBSb3V0ZSBUYWc6IDANCg0KICBMUyBhZ2U6IDEyOQ0K ICBPcHRpb25zOiAweDIgKCp8LXwtfC18LXwtfEV8LSkNCiAgTFMgVHlwZTogQVMtZXh0ZXJuYWwt TFNBDQogIExpbmsgU3RhdGUgSUQ6IDIwLjAuMC4wIChFeHRlcm5hbCBOZXR3b3JrIE51bWJlcikN CiAgQWR2ZXJ0aXNpbmcgUm91dGVyOiAxMC44MS4xNTYuNzQgICAgICAgPj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pg0KICBMUyBTZXEgTnVtYmVyOiA4MDAwMDAwMQ0KICBDaGVja3N1bTogMHg1MjBh DQogIExlbmd0aDogMzYNCiAgTmV0d29yayBNYXNrOiAvMjQNCiAgICAgICAgTWV0cmljIFR5cGU6 IDIgKExhcmdlciB0aGFuIGFueSBsaW5rIHN0YXRlIHBhdGgpDQogICAgICAgIFRPUzogMA0KICAg ICAgICBNZXRyaWM6IDIwDQogICAgICAgIEZvcndhcmQgQWRkcmVzczogMy4zLjMuMw0KICAgICAg ICBFeHRlcm5hbCBSb3V0ZSBUYWc6IDANCg0KDQpQU1M5IHNlbmRzIGEgbWF4YWdlIGxzYS4gV2hl biBQU1MxMSByZWNlaXZlcyB0aGlzIG1heGFnZSBsc2EgaXQgc2hvdWxkIGZsdXNoIHRoZSBleHRl cm5hbCBsc2Egd2l0aCBhZHZlcnRpc2luZyByb3V0ZXIgMTAuODEuMTU2LjcyLiBCdXQgaXQgaXMg bm90IGZsdXNoZWQuIA0KDQpJdCBpcyBkdWUgdG8gdGhlIGZvbGxvd2luZyBleHBsYW5hdGlvbiBm b3VuZCBpbiBSRkMyMzI4Og0KDQoiSWYgdGhlcmUgaXMgYWxyZWFkeSBhIGRhdGFiYXNlIGNvcHks IGFuZCBpZiB0aGUgZGF0YWJhc2UgY29weSB3YXMgcmVjZWl2ZWQgdmlhIGZsb29kaW5nIGFuZCBp bnN0YWxsZWQgbGVzcyB0aGFuIE1pbkxTQXJyaXZhbCBzZWNvbmRzIGFnbywgZGlzY2FyZCB0aGUg bmV3IExTQSAod2l0aG91dCBhY2tub3dsZWRnaW5nIGl0KSBhbmQgZXhhbWluZSB0aGUgbmV4dCBM U0EgKGlmIGFueSkgbGlzdGVkIGluIHRoZSBMaW5rIFN0YXRlIFVwZGF0ZSBwYWNrZXQuIg0KDQpU aGVyZWZvcmUgaXQgZGlzY2FyZHMgdGhlIG1heGFnZSBsc2EgYW5kIHNvIHRoZSBsc2EgaXMgbm90 IGZsdXNoZWQgYW5kIGl0IHN0aWxsIHJlbWFpbnMuDQoNCm9zcGYgZGVidWcgbG9nczoNCg0KMjAw Ni8wNi8yNyAxOTo0Nzo1OSBPU1BGOiBMU0FbLTpUeXBlNToyMC4wLjAuMDoxMC44MS4xNTYuNzJd OiBmbG9vZCBzdGFydGVkDQoyMDA2LzA2LzI3IDE5OjQ3OjU5IE9TUEY6IExTQVstOlR5cGU1OjIw LjAuMC4wOjEwLjgxLjE1Ni43Ml06IExTQSBpcyByZWNlaXZlZCByZWNlbnRseQ0KMjAwNi8wNi8y NyAxOTo0Nzo1OSBPU1BGOiBMU0FbLTpUeXBlNToyMC4wLjAuMDooc2VsZildOiBEaXNjYXJkIExT QSgweGJmZmZkOTIwKSBGbG9vZGluZyBmYWlsICA+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+DQoN Cm9zcGZfZmxvb2QuYzogb3NwZl9mbG9vZA0KDQogLyogSWYgdGhlcmUgaXMgYWxyZWFkeSBhIGRh dGFiYXNlIGNvcHksIGFuZCBpZiB0aGUNCiAgICAgZGF0YWJhc2UgY29weSB3YXMgcmVjZWl2ZWQg dmlhIGZsb29kaW5nIGFuZCBpbnN0YWxsZWQgbGVzcw0KICAgICB0aGFuIE1pbkxTQXJyaXZhbCBz ZWNvbmRzIGFnbywgZGlzY2FyZCB0aGUgbmV3IExTQQ0KICAgICAod2l0aG91dCBhY2tub3dsZWRn aW5nIGl0KS4gKi8NCiAgaWYgKGN1cnJlbnQgIT0gTlVMTA0KICAgICAgJiYgVFZfQ01QIChUVl9T VUIgKG5vdywgY3VycmVudC0+dHZfdXBkYXRlKSwNCiAgICAgICAgICAgICAgICAgSU5UMlRWIChP U1BGX01JTl9MU19BUlJJVkFMKSkgPCAwKQ0KICAgIHsNCiAgICAgIGlmIChJU19ERUJVR19PU1BG IChsc2EsIExTQV9GTE9PRElORykpDQogICAgICAgIHpsb2dfaW5mbyAoWkcsICJMU0FbJXNdOiBM U0EgaXMgcmVjZWl2ZWQgcmVjZW50bHkiLCBMU0FfTkFNRSAobmV3KSk7ID4+Pj4+Pj4+Pj4+DQoN CiAgICAgIHJldHVybiAtMTsNCiAgICB9DQoNClRoZXJlZm9yZSBhY2NvcmRpbmcgdG8gdGhlIFJG QzIzMjggdGhpcyBkZWZlY3QgaXMgIk5vdCBhIEJ1ZyINCg0KDQpEaXNjb25uZWN0IHRoZSBjYWJs ZSBhbmQgbWFrZSB0aGUgbGlua3MgdXA6DQoNCmxvY2FsaG9zdC5sb2NhbGRvbWFpbiMgc2hvdyBp cCBvc3BmIG5laWdoYm9yDQoNCk9TUEYgcHJvY2VzcyAwOg0KTmVpZ2hib3IgSUQgICAgIFByaSAg IFN0YXRlICAgICAgICAgICBEZWFkIFRpbWUgICBBZGRyZXNzICAgICAgICAgSW50ZXJmYWNlDQoN CmxvY2FsaG9zdC5sb2NhbGRvbWFpbiNzaG93IGlwIG9zcGYgZGF0YWJhc2UgZXh0ZXJuYWwgMjAu MC4wLjANCg0KICAgICAgICAgICAgICAgIEFTIEV4dGVybmFsIExpbmsgU3RhdGVzDQoNCiAgTFMg YWdlOiA2NDkNCiAgT3B0aW9uczogMHgyICgqfC18LXwtfC18LXxFfC0pDQogIExTIFR5cGU6IEFT LWV4dGVybmFsLUxTQQ0KICBMaW5rIFN0YXRlIElEOiAyMC4wLjAuMCAoRXh0ZXJuYWwgTmV0d29y ayBOdW1iZXIpDQogIEFkdmVydGlzaW5nIFJvdXRlcjogMTAuODEuMTU2LjcyICAgPj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCiAgTFMgU2VxIE51bWJlcjogODAwMDAwMDENCiAgQ2hlY2tzdW06 IDB4NWVmZg0KICBMZW5ndGg6IDM2DQogIE5ldHdvcmsgTWFzazogLzI0DQogICAgICAgIE1ldHJp YyBUeXBlOiAyIChMYXJnZXIgdGhhbiBhbnkgbGluayBzdGF0ZSBwYXRoKQ0KICAgICAgICBUT1M6 IDANCiAgICAgICAgTWV0cmljOiAyMA0KICAgICAgICBGb3J3YXJkIEFkZHJlc3M6IDMuMy4zLjMN CiAgICAgICAgRXh0ZXJuYWwgUm91dGUgVGFnOiAwDQoNCiAgTFMgYWdlOiA2NzUNCiAgT3B0aW9u czogMHgyICgqfC18LXwtfC18LXxFfC0pDQogIExTIFR5cGU6IEFTLWV4dGVybmFsLUxTQQ0KICBM aW5rIFN0YXRlIElEOiAyMC4wLjAuMCAoRXh0ZXJuYWwgTmV0d29yayBOdW1iZXIpDQogIEFkdmVy dGlzaW5nIFJvdXRlcjogMTAuODEuMTU2Ljc0ICAgICAgICAgPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCiAgTFMgU2VxIE51bWJlcjogODAwMDAwMDENCiAgQ2hlY2tzdW06IDB4NTIwYQ0KICBM ZW5ndGg6IDM2DQogIE5ldHdvcmsgTWFzazogLzI0DQogICAgICAgIE1ldHJpYyBUeXBlOiAyIChM YXJnZXIgdGhhbiBhbnkgbGluayBzdGF0ZSBwYXRoKQ0KICAgICAgICBUT1M6IDANCiAgICAgICAg TWV0cmljOiAyMA0KICAgICAgICBGb3J3YXJkIEFkZHJlc3M6IDMuMy4zLjMNCiAgICAgICAgRXh0 ZXJuYWwgUm91dGUgVGFnOiAwDQoNCg0KUFNTLTkjc2hvdyBpcCBvc3BmIG5laWdoYm9yDQoNCk9T UEYgcHJvY2VzcyAwOg0KTmVpZ2hib3IgSUQgICAgIFByaSAgIFN0YXRlICAgICAgICAgICBEZWFk IFRpbWUgICBBZGRyZXNzICAgICAgICAgSW50ZXJmYWNlDQoNClBTUy05I3Nob3cgaXAgb3NwZiBk YXRhYmFzZSBleHRlcm5hbCAyMC4wLjAuMA0KDQogICAgICAgICAgICAgICAgQVMgRXh0ZXJuYWwg TGluayBTdGF0ZXMNCg0KICBMUyBhZ2U6IDcwMw0KICBPcHRpb25zOiAweDIgKCp8LXwtfC18LXwt fEV8LSkNCiAgTFMgVHlwZTogQVMtZXh0ZXJuYWwtTFNBDQogIExpbmsgU3RhdGUgSUQ6IDIwLjAu MC4wIChFeHRlcm5hbCBOZXR3b3JrIE51bWJlcikNCiAgQWR2ZXJ0aXNpbmcgUm91dGVyOiAxMC44 MS4xNTYuNzQgICAgID4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KICBMUyBTZXEgTnVtYmVyOiA4MDAwMDAw MQ0KICBDaGVja3N1bTogMHg1MjBhDQogIExlbmd0aDogMzYNCiAgTmV0d29yayBNYXNrOiAvMjQN CiAgICAgICAgTWV0cmljIFR5cGU6IDIgKExhcmdlciB0aGFuIGFueSBsaW5rIHN0YXRlIHBhdGgp DQogICAgICAgIFRPUzogMA0KICAgICAgICBNZXRyaWM6IDIwDQogICAgICAgIEZvcndhcmQgQWRk cmVzczogMy4zLjMuMw0KICAgICAgICBFeHRlcm5hbCBSb3V0ZSBUYWc6IDANCg0K ------_=_NextPart_001_01C6A703.CB248920 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://www1.ietf.org/mailman/listinfo/ospf ------_=_NextPart_001_01C6A703.CB248920-- From ospf-bounces@ietf.org Fri Jul 14 08:25:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Miw-0002s4-FA; Fri, 14 Jul 2006 08:24:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Miv-0002ry-SY for ospf@ietf.org; Fri, 14 Jul 2006 08:24:49 -0400 Received: from wx-out-0102.google.com ([66.249.82.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Miu-0002yk-Kn for ospf@ietf.org; Fri, 14 Jul 2006 08:24:49 -0400 Received: by wx-out-0102.google.com with SMTP id s13so249240wxc for ; Fri, 14 Jul 2006 05:24:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IXYYjAHIOFtn7gOh7AubMtFVUBmOFTOVe0G2TeoVtJ26MhPi2J4HrHC4TVtLLoEHUavkCOtbG1v7SJMlDGG2lriTJFWzMnfRd1b72dxxk/65Z7UepLoS8KmXgfr6beaQGiXiuoddPUyaFVtpXbs5AQLOyc9Nqn29T13myabKfTU= Received: by 10.70.35.8 with SMTP id i8mr2961129wxi; Fri, 14 Jul 2006 05:24:48 -0700 (PDT) Received: by 10.70.7.7 with HTTP; Fri, 14 Jul 2006 05:24:48 -0700 (PDT) Message-ID: <77ead0ec0607140524p173591fevb811abe7b4f60313@mail.gmail.com> Date: Fri, 14 Jul 2006 17:54:48 +0530 From: "Vishwas Manral" To: "Chitra Lakshmi Namadevan" Subject: Re: [OSPF] Functionally equivalent as-external lsa In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Chitra, > Problem 1: Your analysis is correct, the LSA should not be removed if it is in any of the neighbor lists. If an Acknowledgement is not got the LSA needs to be retransmitted to the neighbor. > Problem 2: If two routers, both reachable from one another, originate functionally equivalent AS-external-LSAs (i.e., same destination, cost and non-zero forwarding address), then the LSA originated by the router having the highest OSPF Router ID is used. The router having the lower OSPF Router ID can then flush its LSA. Also note that any router with lower Router-ID CAN flush it s LSA, it is an optimization to reduce the size of the OSPF DB. Thanks, Vishwas On 7/14/06, Chitra Lakshmi Namadevan wrote: > > > > > > Hi, > > > > Functionally equivalent AS-external lsas are originated. Therefore the ls= a with higher advertising router id is installed and the other lsa is flush= ed. > > > > Topology: > > dummy dummy > > SW(*) SW(*) > > | | > > +-----+ | | +-----+ > > | | | | | | > > | +---+ +---+ | > > | | | | > > |PSS9 +------ X ------|PSS11| > > +-----+ +-----+ > > 10.81.156.72 10.81.156.74 > > 3.3.3.0/24 > > (*)dummy SW: only for up the Link of PSS9/PSS11. > > Problem 1: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > But the database of PSS11 has the AS-external lsa whose advertising route= r is 10.81.156.72 along with the lsa advertised by 10.81.156.74. This is th= e problem. > > PSS9 sends a maxage lsa. When PSS11 receives this maxage lsa it should fl= ush the external lsa with advertising router 10.81.156.72. But it is not fl= ushed. > > It is due to the following explanation found in RFC2328: > > "If there is already a database copy, and if the database copy was receiv= ed via flooding and installed less than MinLSArrival seconds ago, discard t= he new LSA (without acknowledging it) and examine the next LSA (if any) lis= ted in the Link State Update packet." > > Therefore it discards the maxage lsa and so the lsa is not flushed and it= still remains. > > Analysis: > > PSS-11 discards the maxage lsa without any ls-ack. PSS-9 should not flush= the lsa and should send again a maxage lsa since it did not receive a LS-A= CK for the maxage lsa. > > Kindly let me know if my analysis is correct. > > Problem 2: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Disconnect the cable and make the link up. Then the router with the lower= router id (10.81.156.72 =96 PSS9) has the as-external lsa advertised by th= e higher router id (10.81.156.74 =96 PSS11). But it should have the as-exte= rnal lsa advertised by lower router id i.e. self lsa. > > This is happening because the as-external lsa with higher router id is no= t flushed. Therefore when PSS 9 originates the self as-external lsa, it fin= ds that functionally equivalent as-external lsa is still present so it disc= ards its self lsa. > > Kindly let me know what mechanism can be followed to flush the as-externa= l lsa with higher router id when the neighbor is deleted. > > Regards, > Chitra > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jul 14 10:36:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Oma-0007zQ-Ga; Fri, 14 Jul 2006 10:36:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OmY-0007zJ-UQ for ospf@ietf.org; Fri, 14 Jul 2006 10:36:42 -0400 Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1OmY-0007M0-BI for ospf@ietf.org; Fri, 14 Jul 2006 10:36:42 -0400 Received: from dialup-4.243.131.49.dial1.sanfrancisco1.level3.net ([4.243.131.49] helo=earthlink.net) by pop-siberian.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1G1OmP-00052T-00; Fri, 14 Jul 2006 10:36:34 -0400 Message-ID: <44B7ABEE.8080906@earthlink.net> Date: Fri, 14 Jul 2006 07:36:30 -0700 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: Erblichs Subject: Re: [OSPF] Database Exchange Summary List Optimization References: <44B53B00.3030305@earthlink.net> <44B56CE5.4090901@cisco.com> <44B58E07.890D58F9@earthlink.net> <44B67604.2060503@earthlink.net> <44B6E61E.E4423664@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 69aba9e925a1047819f53b40fa4fc4e6 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Mitchell, I assume this is why Acee suggested the lexicographic ordering when he presented my draft. (I had figured he meant the slave would list LSAs in the reverse order as the master, since otherwise there would be no benefit.) Anyway, I will change the draft to allow this (but not to require this). In some cases, the additional delay of processing the DD packet completely before sending the responding DD packet is not significant. One example is a MANET configured as a stub area. Let's look at some rough numbers. A MANET often uses 802.11 with 11 Mbps data rate and has an MTU of 1500. A maximum size DD packet can be transmitted in roughly 1.2 msec and contains less than 75 LSA headers (75 * 20 = 1500). Normally, it would take much less than 1.2 msec to process such a packet, let's say .1 msec as an upper bound. Then the additional delay of not parallelizing is at most .1 msec per DD packet, less than a 10% increase compared to parallelizing (which would take 1.2 msec per DD packet). So, you can see that in the type of networks I had in mind, there is no significant advantage to sending the responding DD packet before the received DD packet is completely processed. Even if there are 10,000 LSA headers to exchange in the MANET case (note that the number of summary-LSAs flooded into a MANET stub area must be limited due to limited bandwidth), this would require roughly 10,000 / 75 = 133 DD packets, making the additional delay of not parallelizing at most .1 msec * 133 = 13.3 msec, still not significant. I suppose there exist examples where it takes 15 seconds to process all LSA headers and also takes at least 15 seconds to send/receive all DD packets, so that parallelizing can cut the delay in half (from 30 sec to 15 sec). But the optimization also cuts the number of LSA headers in half, which makes up for the additional delay of not parallelizing. However, it would be nice to also reduce the delay required to synchronize, which I guess is what you had in mind. So, the draft can certainly suggest that the master should list LSAs in forward order and the slave list them in reverse order. Also, the draft should mention that in some applications where overhead savings is more important than delay (such as MANETs) it may help to process the DD packet completely before sending the responding DD packet, in which case the ordering of LSAs is not important. Even if the number of LSA headers fits into one DD packet, I would like to have only one router send a full DD packet instead of both routers (to save overhead). Therefore, it might help to process the *last* DD packet, (with M bit = 0), completely before sending the next DD packet. This also avoids the problem you mentioned when the middle of the summary list is reached. Richard stub area, the additional delay of processing the DD packet completely before sending the responding DD packet is not significant. Is 15 seconds realistic? I had MANETs in mind, so I don't think the number of LSA headers will be that large. If it were, and if the bandwidth is the typical 11 mbps... I doubt that there will be so many LSAs in a MANET that it would take 15 seconds, or even 1 second to process all the LSA headers. Actually, it might add 15 seconds if it also takes at least 15 seconds to send and receive the DD packets. By serializing, we cannot add more delay than the minimum of the time to process the LSA list, and the time to send and receive the DD packets (since both must be done anyway either in parallel or serially). So this will at most double the time to converge. (It is probably better to express the increased delay percentagewise than in seconds.) But since it also reduces the number of LSAs by 50% when the two routers are nearly in sync, the time to converge will be back to where it was originally. Of course, it would be better to cut the time to converge in half, which I guess is what you had in mind. This is probably why Acee was talking about ordering the LSA headers lexicographically at the meeting. Sure, the draft can mention that this can be done and may be beneficial in some cases. But I still doubt that not doing this will add much delay in MANETs, because the number of LSA headers probably will not be that large, so they can probably be processed in a few msec. Let's say the MTU is 1500 bytes. An LSA header is 20 bytes. 1500 / 20 = 75. Time to transmit = 1500*8 / 10 Mbps = 1.2 msec. So if we are talking about 15 seconds, then there would have to be 15 / .0024 = 6250 DD packets each or 6250 * 75 = 468,000 LSAs. More reasonably, there would be no more than about 1% of this number in MANETs, or 4,680, which would correspond to about 150 msec. Given that the Hello interval is no less than 1 sec, a 150 msec delay in synchronizing is not very significant. But since this should be applicable to more than MANETs, I see no problem recommending that the master list LSAs in lex order and the slave list them in reverse lex order. Also, the draft should mention that in some applications where overhead savings is more important than delay (such as MANETs) it may help to process the DD packet completely before sending the responding DD packet. Even if the number of LSA headers fits into one DD packet, I would like to have only one router send a full DD packet instead of both routers. Therefore, it might help to process the *last* DD packet, with the M bit zero, completely before sending the next DD packet. This also avoids the complexity you mention when the middle of the summary list is reached. Richard Erblichs wrote: >Richard, > > Their are two areas here: delay and ordering. > > First, inline you state: > >>It is important that the received >>DD packet be processed completely (including updating the summary list >>as specified in my draft) before the next DD packet is sent in response, >> > > The act of processing before, is the delay that I speak of. This >action >sequentializes this processing. ie: recv DD pkt, process it, send our >DD resp, sleep: perchance to dream (ie:Shakespere), recv next, process >it, >send our next DD pkt. If all the LSA hdrs recv'd takes a total of 15 >secs >to process, this will add 15 secs before we can converge. > > To keep the parallelism of the current arch could do: > > * Upon all DD pkt recv'd, process it after our DD pkt > is sent in response. While the resp DD pkt is being processed, clean > the summary list based on the recvd pkt. > > We will send some percentage based on LSA ordering, relative size, > but will decrease the number of LSA hdrs sent (cleaned ones), but > will be able to do the cleaning during the time between successively > recv'd DD pkts. > > Why should/could we order? > * My older proposition. I don't care if 5% of hdrs are in common or > 95%, this in theory should work. If the master covers 1/2 of the DB >and > the slave covers the other half, best case the headers of 1x the >LSDB need > be sent in DD pkts. The only assumption is that both LSDBs on the >two > routers have approx the same number of LSAs. We will be filtering as >we > recv the DD pkts, but should have no need to process the DD pkt from >the > other router "before the next DD pkt is sent in response". We will >do this > cleaning during the time between successively recv'd DD pkts. >Because of > the ordering, their is NO NEED to wait, if the LSDB is of sufficient >size > on both routers. We will not initially be sending LSAs that can >conflict. > The complexity is what do we do as we approach the middle and start >with > conflicts. > > Where this optmization does not help, if the number of hdrs is such >that > only a few DD pkts need to be sent or where one router has a >significantly > larger LSDB. > > > * The third suggestion is inline for kbps environments... > > Mitchell Erblich > --------------------------------- > > >Richard Ogier wrote: > >>Hello Mitchell, >> >>Thanks for your comments. I agree with Acee's response, >>and I have a few more comments below. >> >>Erblichs wrote: >> >>>Group, >>> >>> I did not hear Acee's presentation, but have read the >>> two page draft. >>> >>> You mention >>> "This optimization reduces Database Description >>> overhead by about 50% in large networks." I feel >>> only in the last scenario, this statement may be >>> true. However, In the simple, BMA >>> >>> environment, the DR will contain most of the LSAs >>> (scenario 3), I doubt that any reduction would be >>> significant. >>> >>> >>> >>> I am less aware of P2P,etc type environments, where this >>> might be more signficant, thus I suggest a fine tuning >>> to this idea below. >>> >>> Upon my first quick read, 4 scenarios came to mind: >>> 1) a minimal number of LSAs that need to be exchanged >>> on both sides. >>> 2) a large number of LSAs that need to be exchanged >>> on both sides and they are from two past DRs, >>> thus no LSA header will match... >>> 3) a new adj where the DR has already formed adjs >>> and a new router where only a few of its LSA >>> need to be exchanged. >>> 4) two routers have basicly the same LSA list. >>> >>The optimization is mostly indended for the last scenario, >>which is often the case in MANETs. The following sentence from >>Section 1 of my draft implies this: >> "The optimization reduces >> Database Description overhead by about 50% in large networks, since >> it reduces the total number of LSA headers exchanged by about one- >> half when the two routers are already nearly synchronized." >> > Shouldn't we find a implimentation that works also when they > aren't nearly synchronized? > > That is where ordering stated earlier and above comes in, with > a new option. > >>> >>> IF I read the draft correctly, one or both routers are >>> creating a artifical delay before some LSAs are sent. >>> One router might wait until it thinks it has recieved >>> all of the other router's LSA headers. >>> >>There is no additional delay. It is important that the received >>DD packet be processed completely (including updating the summary list >>as specified in my draft) before the next DD packet is sent in response, >>and I will clarify this in the draft. As a result, the next sent >>DD packet will not list any LSAs that were listed in the received >>DD packet (with the same or newer instance). >> > Sorry, "BEFORE" implies a wait until... This is a additional delay..:^) > If the Master contains enough LSAs such that it takes X secs to > process, this adds to the convergence of these LSDBs. I see where > a bandwidth is such that one wants to limit the number of LSA hdrs > exchanged. > > But this could also theorecticly be done if one would to > segment the LSDB per LSA type, exchange LSDB type checksums, and > if they then disagree exchange hdrs... > > You just need to come up with a checksum that only one set of > LSAs will produce a unique checksum. I am not a mathematican > to tell you how complex this might be.. > >>> >>> This delay introduces a longer period of time before >>> the OSPF routers could be synchronized. This is >>> expecially true if the waiting router is holds a number >>> of new LSAs. Thus, you are optimizing for the last >>> scenario. >>> >>> If (my theorectical two minute thought suggestion) >>> implemented ordered LSAs, and both routers could >>> agree on a order... stay with me.. >>> >>> Wouldn't it make more sense that the master say send >>> increasing LSAs ids out and the slave send decreasing >>> LSAs out? >>> >>As Acee mentioned, the ordering does not matter, as long as the received >>DD packet is processed before the next DD packet is sent in response. >> > > The ordering is based to remove the wait and LSA conflicts > at the ends of the LSDB. .. > >>> >>> One could then theorectly compare LSAs and implement what >>> you suggest without delay. In #1, Since the number of LSAs >>> is small, the LSAs will still be exchanged. But where the >>> number of LSAs is LARGE and almost identical between the >>> two routers, then half the number of headers would be sent. >>> >>Right. That was the main intention. This has been shown in simulations >>of OSPF-MDR (for MANETs) using GTNetS. >> >>I have one concern. What if some future extension of OSPF assumes that >>DD packets list all LSAs as specified in RFC 2328, e.g., so that some >>action can be taken that depends on how "out of sync" the new neighbor >>was. If someone implements the optimization without any indication >>(such as a new option bit), then a future extension >>might incorrectly conclude that the new neighbor was out of sync >>and take the wrong action. This could be fixed either by including >>a new option bit, or by changing the spec of OSPF to allow the >>optimization. Is this a valid concern? >> > > > I first want to sync with you on the above, but don't we do a > checksum on our LSDB on most implementation. Why couldn't we > exchange the result and if different, then..... > > Inline Mitchell Erblich > >>Richard >> >>> >>> Thus, IMO, a new option should be specified that says that >>> the two will exchange in the initial database sync, in reverse >>> order. Again, this will help a DR/BDR full adj formation, only >>> if that is done last. >>> >>> >>> Mitchell Erblich >>> ------------------- >>> >>> >>>Acee Lindem wrote: >>> >>>>Hi Richard, >>>>Richard Ogier wrote: >>>> >>>>>I listened to Acee's presentation of my draft >>>>>http://www.ietf.org/internet-drafts/draft-ogier-ospf-dbex-opt-00.txt >>>>> >>>>>Acee mentioned that it might help to list the LSAs in >>>>>lexicographical order, to achieve the maximum savings >>>>>in overhead. One person commented that it may not be >>>>>reasonable to require this. >>>>> >>>>>I want to point out that one can still achieve the 50% reduction >>>>>in the number of LSA headers exchanged even if LSAs are not >>>>>listed in lexicographical order, as long as the received DD packet >>>>>is processed completely (including updating the summary list >>>>>as specified in the draft) before the next DD packet is sent. >>>>>In this case, I don't think the order in which LSAs are listed >>>>>matters. >>>>> >>>>>Comments? >>>>> >>>>I agree. I probably shouldn't have mentioned lexigraphically ordering >>>>at all since it was with respect to how simple and low overhead this >>>>optimization is when starting with an implementation >>>>following RFC 2328. >>>> >>>>Given this fact, I'd ask the question again as to whether anyone >>>>is opposed to publishing this as an informational WG document? >>>> >>>>Thanks, >>>>Acee >>>> >>>>>Richard >>>>> >>>>> >>>>>_______________________________________________ >>>>>OSPF mailing list >>>>>OSPF@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/ospf >>>>> >>>>_______________________________________________ >>>>OSPF mailing list >>>>OSPF@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/ospf >>>> >>> > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jul 14 14:47:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1ShX-0008Dw-VU; Fri, 14 Jul 2006 14:47:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1ShW-0008Dr-Ps for ospf@ietf.org; Fri, 14 Jul 2006 14:47:46 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1ShV-0001EN-IG for ospf@ietf.org; Fri, 14 Jul 2006 14:47:46 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 14 Jul 2006 11:47:45 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,244,1149490800"; d="scan'208"; a="32259964:sNHT22149260" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6EIljPr017472 for ; Fri, 14 Jul 2006 14:47:45 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6EIlj7t012913 for ; Fri, 14 Jul 2006 14:47:45 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 14:47:45 -0400 Received: from [10.82.217.140] ([10.82.217.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 14:47:44 -0400 Message-ID: <44B7E6D0.6030304@cisco.com> Date: Fri, 14 Jul 2006 14:47:44 -0400 From: Acee Lindem User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: OSPF List Subject: Re: [OSPF] Database Exchange Summary List Optimization References: <44B7E563.3000706@cisco.com> In-Reply-To: <44B7E563.3000706@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jul 2006 18:47:44.0844 (UTC) FILETIME=[FE7090C0:01C6A775] DKIM-Signature: a=rsa-sha1; q=dns; l=1112; t=1152902865; x=1153766865; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20[OSPF]=20Database=20Exchange=20Summary=20List=20Optimization |To:OSPF=20List=20; X=v=3Dcisco.com=3B=20h=3Dch8APb1Y9bn38d2O3svaF4G0uj0=3D; b=qLJIJTC1Wm2c2vB1cbB7DeFTF0fdDYSH6h8XVGRYWTynO2j7HBAMNxdGhRTPlUo7k2yDpu3C inJG4jQT2UqPkJMXu9oC3HPR2uUkcC3WDn5BJOFgLkqZVjFKs3DgMUQM; Authentication-Results: rtp-dkim-2.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Richard, Richard Ogier wrote: > I have one concern. What if some future extension of OSPF assumes that > DD packets list all LSAs as specified in RFC 2328, e.g., so that some > action can be taken that depends on how "out of sync" the new neighbor > was. If someone implements the optimization without any indication > (such as a new option bit), then a future extension > might incorrectly conclude that the new neighbor was out of sync > and take the wrong action. This could be fixed either by including > a new option bit, or by changing the spec of OSPF to allow the > optimization. Is this a valid concern? I'm not sure that I can think of any optimization that would rely on the neighbor sending a full database snapshot. Especially, when you consider that it would need to be fully backward compatible Can you imagine any? Anyway, if this is a concern the document would needs to be standards track and I think we should use a bit in the database exchange I_M_MS field rather than the options (there are no free bit left in OSPFv2). Thanks, Acee > > > Richard > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jul 14 16:21:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1U9r-0006ih-2Q; Fri, 14 Jul 2006 16:21:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1U9p-0006ib-KE for ospf@ietf.org; Fri, 14 Jul 2006 16:21:05 -0400 Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1U9o-0007Rt-Bd for ospf@ietf.org; Fri, 14 Jul 2006 16:21:05 -0400 Received: from h-68-164-152-179.snvacaid.dynamic.covad.net ([68.164.152.179] helo=earthlink.net) by pop-gadwall.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1G1U9l-00013a-00; Fri, 14 Jul 2006 16:21:01 -0400 Message-ID: <44B7FCC8.BFE9F407@earthlink.net> Date: Fri, 14 Jul 2006 13:21:28 -0700 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Acee Lindem Subject: Re: [OSPF] Database Exchange Summary List Optimization References: <44B7E563.3000706@cisco.com> <44B7E6D0.6030304@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Acee and Richard, A "ugly workaround" instead of using the DB exhange field could be: Sending a new OSPF pkt type as a REQ and if a RESP of that pkt type is recv, then that functionality is supported.. Since, it would only be sent at the begining of the initial DB synch, the overhead of recving one unknown pkt type should be minimial. A short timeout is needed and if a response is not seen within the timeout, standard initial LSDB synch should take place. This is backward supported in v2 because unknown types are discarded. This effectively generates a private set of pkt types where only the aware routers will read this pkt type and the unaware will discard the unknown type. So, with that out-of-the-way. This same new pkt type could be a TVL type pkt, where each known OSPF LSA type is specified with a count, and a checksum-summation. If the summation matches and the count matches the LSA type COULD be considered synched. If their is any interest, I can write up a short EXP RFC to validate this type of functionality. Mitchell Erblich ------------------- Acee Lindem wrote: > > Hi Richard, > > Richard Ogier wrote: > > I have one concern. What if some future extension of OSPF assumes that > > DD packets list all LSAs as specified in RFC 2328, e.g., so that some > > action can be taken that depends on how "out of sync" the new neighbor > > was. If someone implements the optimization without any indication > > (such as a new option bit), then a future extension > > might incorrectly conclude that the new neighbor was out of sync > > and take the wrong action. This could be fixed either by including > > a new option bit, or by changing the spec of OSPF to allow the > > optimization. Is this a valid concern? > I'm not sure that I can think of any optimization that would rely on > the neighbor sending a full database snapshot. Especially, when you > consider that it would need to be fully backward compatible Can > you imagine any? > > Anyway, if this is a concern the document would needs to be standards > track and I think we should use a bit in the database exchange I_M_MS > field rather than the options (there are no free bit left in OSPFv2). > > Thanks, > Acee > > > > > > > Richard > > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jul 14 17:01:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1UnG-0004vM-PQ; Fri, 14 Jul 2006 17:01:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1UnF-0004uR-Rj for ospf@ietf.org; Fri, 14 Jul 2006 17:01:49 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1UnD-0008Ix-Fe for ospf@ietf.org; Fri, 14 Jul 2006 17:01:49 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 14 Jul 2006 14:01:47 -0700 X-IronPort-AV: i="4.06,245,1149490800"; d="scan'208"; a="1838707893:sNHT2487498344" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6EL1joH004254; Fri, 14 Jul 2006 14:01:45 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6EL1j79004536; Fri, 14 Jul 2006 14:01:45 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 17:01:45 -0400 Received: from [10.82.217.140] ([10.82.217.140]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 17:01:44 -0400 Message-ID: <44B80637.2060704@cisco.com> Date: Fri, 14 Jul 2006 17:01:43 -0400 From: Acee Lindem User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Erblichs Subject: Re: [OSPF] Database Exchange Summary List Optimization References: <44B7E563.3000706@cisco.com> <44B7E6D0.6030304@cisco.com> <44B7FCC8.BFE9F407@earthlink.net> In-Reply-To: <44B7FCC8.BFE9F407@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jul 2006 21:01:44.0307 (UTC) FILETIME=[B6554430:01C6A788] DKIM-Signature: a=rsa-sha1; q=dns; l=2906; t=1152910905; x=1153774905; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20[OSPF]=20Database=20Exchange=20Summary=20List=20Optimization; X=v=3Dcisco.com=3B=20h=3DVwI3WZywBXmh7qJ9oTkEHQ724GE=3D; b=sNt7TRXR72mvq1Sk1cu+Hnzqt4v29ai5DAga+sriVc5w/DUhnxY6wYKvkMLKB2F7piBX9OYx +T6rECZoVqu9wY2unvedVce6utQtkOeL6ZkUAP9sXY7MB/0JaDtMwZhm; Authentication-Results: sj-dkim-7.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Mitchell, First let's see if anyone can come up with a requirement for explicit signaling of the Richard's proposal. However, I see absolutely on advantage to the signaling you are suggesting over simply setting a bit in the database exchange packet I_M_MS field. Thanks, Acee Erblichs wrote: > Acee and Richard, > > A "ugly workaround" instead of using the DB exhange > field could be: > > Sending a new OSPF pkt type as a REQ and if a RESP > of that pkt type is recv, then that functionality is > supported.. > > Since, it would only be sent at the begining of the > initial DB synch, the overhead of recving one unknown pkt > type should be minimial. A short timeout is needed and > if a response is not seen within the timeout, standard > initial LSDB synch should take place. > > This is backward supported in v2 because unknown types > are discarded. This effectively generates a private set > of pkt types where only the aware routers will read this > pkt type and the unaware will discard the unknown type. > > So, with that out-of-the-way. > > This same new pkt type could be a TVL type pkt, where > each known OSPF LSA type is specified with a count, and > a checksum-summation. If the summation matches and the > count matches the LSA type COULD be considered synched. > > If their is any interest, I can write up a short EXP RFC > to validate this type of functionality. > > Mitchell Erblich > ------------------- > > > > Acee Lindem wrote: > >> Hi Richard, >> >> Richard Ogier wrote: >> >>> I have one concern. What if some future extension of OSPF assumes that >>> DD packets list all LSAs as specified in RFC 2328, e.g., so that some >>> action can be taken that depends on how "out of sync" the new neighbor >>> was. If someone implements the optimization without any indication >>> (such as a new option bit), then a future extension >>> might incorrectly conclude that the new neighbor was out of sync >>> and take the wrong action. This could be fixed either by including >>> a new option bit, or by changing the spec of OSPF to allow the >>> optimization. Is this a valid concern? >>> >> I'm not sure that I can think of any optimization that would rely on >> the neighbor sending a full database snapshot. Especially, when you >> consider that it would need to be fully backward compatible Can >> you imagine any? >> >> Anyway, if this is a concern the document would needs to be standards >> track and I think we should use a bit in the database exchange I_M_MS >> field rather than the options (there are no free bit left in OSPFv2). >> >> Thanks, >> Acee >> >> >>> Richard >>> >>> >>> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www1.ietf.org/mailman/listinfo/ospf >> > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jul 14 18:13:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1VuQ-0003Ky-4d; Fri, 14 Jul 2006 18:13:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1VuP-0003Ks-76 for ospf@ietf.org; Fri, 14 Jul 2006 18:13:17 -0400 Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1VuN-0006a9-RD for ospf@ietf.org; Fri, 14 Jul 2006 18:13:17 -0400 Received: from h-68-164-152-179.snvacaid.dynamic.covad.net ([68.164.152.179] helo=earthlink.net) by pop-tawny.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1G1VuM-0006dC-00; Fri, 14 Jul 2006 18:13:14 -0400 Message-ID: <44B81707.3237A28@earthlink.net> Date: Fri, 14 Jul 2006 15:13:27 -0700 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Acee Lindem Subject: Re: [OSPF] Database Exchange Summary List Optimization References: <44B7E563.3000706@cisco.com> <44B7E6D0.6030304@cisco.com> <44B7FCC8.BFE9F407@earthlink.net> <44B80637.2060704@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Acee Lindem, The one benefit that I "sliently" thought of was the ability to re-send the REQ at any time AFTER LSDB synch has occured. A flag could be set for re-synch versus a new synch, which could flush the LSAs that originated from the REQ router. It is assumed that for one of many reasons, the router's LSDB has become un-sync'ed and is unwilling to wait for normal flooding or non-flooding if DNA LSAs are implemented. Doing a full LSDB is un-necessary. It also has a non-permanence to it, where a system's functionality support could be updated without a reboot / graceful restart. Isn't this an issue with the usage of these bits? Are any of these items on his wish/requirements list? Mitchell Erblich ------------------- Acee Lindem wrote: > > Mitchell, > > First let's see if anyone can come up with a requirement for > explicit signaling of the Richard's proposal. However, I see > absolutely on advantage to the signaling you are suggesting over > simply setting a bit in the database exchange packet I_M_MS > field. > > Thanks, > Acee > > Erblichs wrote: > > Acee and Richard, > > > > A "ugly workaround" instead of using the DB exhange > > field could be: > > > > Sending a new OSPF pkt type as a REQ and if a RESP > > of that pkt type is recv, then that functionality is > > supported.. > > > > Since, it would only be sent at the begining of the > > initial DB synch, the overhead of recving one unknown pkt > > type should be minimial. A short timeout is needed and > > if a response is not seen within the timeout, standard > > initial LSDB synch should take place. > > > > This is backward supported in v2 because unknown types > > are discarded. This effectively generates a private set > > of pkt types where only the aware routers will read this > > pkt type and the unaware will discard the unknown type. > > > > So, with that out-of-the-way. > > > > This same new pkt type could be a TVL type pkt, where > > each known OSPF LSA type is specified with a count, and > > a checksum-summation. If the summation matches and the > > count matches the LSA type COULD be considered synched. > > > > If their is any interest, I can write up a short EXP RFC > > to validate this type of functionality. > > > > Mitchell Erblich > > ------------------- > > > > > > > > Acee Lindem wrote: > > > >> Hi Richard, > >> > >> Richard Ogier wrote: > >> > >>> I have one concern. What if some future extension of OSPF assumes that > >>> DD packets list all LSAs as specified in RFC 2328, e.g., so that some > >>> action can be taken that depends on how "out of sync" the new neighbor > >>> was. If someone implements the optimization without any indication > >>> (such as a new option bit), then a future extension > >>> might incorrectly conclude that the new neighbor was out of sync > >>> and take the wrong action. This could be fixed either by including > >>> a new option bit, or by changing the spec of OSPF to allow the > >>> optimization. Is this a valid concern? > >>> > >> I'm not sure that I can think of any optimization that would rely on > >> the neighbor sending a full database snapshot. Especially, when you > >> consider that it would need to be fully backward compatible Can > >> you imagine any? > >> > >> Anyway, if this is a concern the document would needs to be standards > >> track and I think we should use a bit in the database exchange I_M_MS > >> field rather than the options (there are no free bit left in OSPFv2). > >> > >> Thanks, > >> Acee > >> > >> > >>> Richard > >>> > >>> > >>> > >> _______________________________________________ > >> OSPF mailing list > >> OSPF@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ospf > >> > > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jul 14 19:37:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1XDF-0007Gw-Jt; Fri, 14 Jul 2006 19:36:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1XDE-0007Gr-8D for ospf@ietf.org; Fri, 14 Jul 2006 19:36:48 -0400 Received: from web25412.mail.ukl.yahoo.com ([217.146.176.230]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G1XDC-0004XW-Im for ospf@ietf.org; Fri, 14 Jul 2006 19:36:48 -0400 Received: (qmail 5087 invoked by uid 60001); 14 Jul 2006 23:36:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=wP7dKrQjgVZHY2T6LBF/SLM5jkNbAfp7MYINnrwf4xhrzGEB4O00ELMhtEr3bU0dymCYIEcAuCdZWBtHQN8I3jKw+zzJyGcatsI+2C22r7ZbenLMT74q5pz5Z3m5zYQ1VmDIsjI5YSBTTgTOpMDwg+QZNycnTF65+Ptp1OeMMSY= ; Message-ID: <20060714233645.5085.qmail@web25412.mail.ukl.yahoo.com> Received: from [202.144.106.189] by web25412.mail.ukl.yahoo.com via HTTP; Fri, 14 Jul 2006 23:36:45 GMT Date: Fri, 14 Jul 2006 23:36:45 +0000 (GMT) From: Manav Bhatia To: ospf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.9 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [OSPF] OSPF HMAC Cryptographic Authentication X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Manav Bhatia List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi, We have just posted a draft that describes a mechanism for authenticating OSPF packets by making use of HMAC algorithm in conjunction with the SHA family of cryptographic hash functions. It would be great if the WG can provide some feedback and comments on the same. http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha-00.txt Thanks, Manav > ----- Forwarded Message ---- > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Sent: Saturday, July 15, 2006 1:20:01 AM > Subject: I-D ACTION:draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : OSPF HMAC Cryptographic Authentication > Author(s) : M. Bhatia, et al. > Filename : draft-bhatia-manral-white-ospf-hmac-sha-00.txt > Pages : 10 > Date : 2006-6-14 > > This document describes a mechanism for authenticating OSPF packets > by making use of the HMAC algorithm in conjunction with the SHA > family of cryptographic hash functions. Because of the way the hash > functions are used in HMAC construction, the collision attacks > currently known against SHA-1 do not apply. > > This will be done in addition to the already documented > authentication schemes described in the base specification. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Jul 14 19:40:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1XGX-0007VJ-Ff; Fri, 14 Jul 2006 19:40:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1XGV-0007VE-Cy for ospf@ietf.org; Fri, 14 Jul 2006 19:40:11 -0400 Received: from web25406.mail.ukl.yahoo.com ([217.12.10.140]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G1XGT-0005YI-WD for ospf@ietf.org; Fri, 14 Jul 2006 19:40:11 -0400 Received: (qmail 59819 invoked by uid 60001); 14 Jul 2006 23:40:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=xJFPtbc3EJrIdSEfsmYz/Dqy+xQV/MM+1BFQm1lWbD9RNlal+Z/F8Hd7VUPzv4/J/tB6FAp3e6ykIIgZZsqIfDaYMt1cSh00aGnRunDN+tsNPY6uYXSgYwQKmSKpbmbTw6WsKTYc7XYmTE17Chswd9PGOmQPunYxIxfXvdzCk0Y= ; Message-ID: <20060714234009.59817.qmail@web25406.mail.ukl.yahoo.com> Received: from [202.144.106.189] by web25406.mail.ukl.yahoo.com via HTTP; Fri, 14 Jul 2006 23:40:09 GMT Date: Fri, 14 Jul 2006 23:40:09 +0000 (GMT) From: Manav Bhatia To: ospf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.9 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [OSPF] Cryptographic Algorithm Implementations Requirements for OSPF X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Manav Bhatia List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi, We have just posted a new draft on the cryptographic algorithm requirements for OSPF and would appreciate the WGs feedback and comments on the same. http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-ospf-00.txt Abstract OSPF defines three different kinds of authentication schemes: Null authentication, simple password and cryptographic authentication. The cryptographic authentication scheme can make use of various cryptographic algorithms in order to authenticate the OSPF packets. To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms to be used for the cryptographic authentication for OSPF as well as specifying the algorithms that should be implemented because they may be promoted to mandatory at some future time. Thanks, Manav > ----- Forwarded Message ---- > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Sent: Saturday, July 15, 2006 1:20:01 AM > Subject: I-D ACTION:draft-bhatia-manral-crypto-req-ospf-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Cryptographic Algorithm Implementations Requirements for > OSPF > Author(s) : M. Bhatia, et al. > Filename : draft-bhatia-manral-crypto-req-ospf-00.txt > Pages : 7 > Date : 2006-6-14 > > OSPF defines three different kinds of authentication schemes: Null > authentication, simple password and cryptographic authentication. The > cryptographic authentication scheme can make use of various > cryptographic algorithms in order to authenticate the OSPF packets. > To ensure interoperability between disparate implementations, it is > necessary to specify a set of mandatory-to-implement algorithms to > ensure that there is at least one algorithm that all implementations > will have available. > > This document defines the current set of mandatory-to-implement > algorithms to be used for the cryptographic authentication for OSPF > as well as specifying the algorithms that should be implemented > because they may be promoted to mandatory at some future time. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-ospf-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sat Jul 15 07:35:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1iQz-0006Qo-Au; Sat, 15 Jul 2006 07:35:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1iQy-0006Qe-95 for OSPF@IETF.ORG; Sat, 15 Jul 2006 07:35:44 -0400 Received: from omega7.wr.usgs.gov ([130.118.4.3] helo=ns0.wr.usgs.gov) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1iQx-0005lN-SZ for OSPF@IETF.ORG; Sat, 15 Jul 2006 07:35:44 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01M4T00K5RKG002SH3@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Sat, 15 Jul 2006 04:31:54 -0700 (PDT) Date: Sat, 15 Jul 2006 04:31:54 -0700 (PDT) From: "Pat Murphy - (650)329-4044" Subject: Re: [OSPF] Functionally equivalent as-external lsa To: OSPF@IETF.ORG Message-id: <01M4T00K5SIA002SH3@omega7.wr.usgs.gov> X-VMS-To: ospf@ietf.org X-VMS-Cc: pmurphy,Chitra_Namadevan@infosys.com MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: CHITRA_NAMADEVAN@INFOSYS.COM X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Chitra, W.r.t. dummy dummy SW(*) SW(*) | | +-----+ | | +-----+ | | | | | | | +---+ +---+ | | | | | |PSS9 +------ X ------|PSS11| +-----+ +-----+ 10.81.156.72 10.81.156.74 3.3.3.0/24 (*)dummy SW: only for up the Link of PSS9/PSS11. PSS9 and PSS11 both originate a functionally equivalent external LSA for 3.3.3.0/24. in summary neither PSS9 or PSS11's external LSA for prefix 3.3.3.0/24 is installed in PSS11's OSPF routing table. A path external to OSPF, e.g. a static route or BGP advertisement, controls the forwarding of packets destined to the prefix 3.3.3.0/24. Whenever PSS11 is originating its LSA, PSS9 should flush its LSA and install PSS11's LSA as long as PSS11 is reachable. When PSS9 and PSS11 are no longer reachable from one another, PSS9 should remove PSS11's LSA from the OSPF routing table and originate its own functionally equivalent external LSA for the prefix 3.3.3.0/24, provided it still has an imported path for it. PSS11's LSA may continue to live in PSS9's LSDB until it age's out normally; but again, as with PS11, neither LSA should be installed in the OSPF routing table until PSS11 becomes reachable again. That's it. Read on for a more detailed explanation. >From RFC 2328 Section 12.4.4.1 ...if two routers, both reachable from one another, originate functionally equivalent AS-external-LSAs (i.e., same destination, cost and non-zero forwarding address), then the LSA originated by the router having the highest OSPF Router ID is used. The router having the lower OSPF Router ID can then flush its LSA. PSS9 should flush its 3.3.3.0/24 LSA. However, as Vishwas has pointed out, this was intended as an optimization feature. But an implementation that chooses not to do this could cause a subtle anomaly. See below. Regardless the following text from RFC 2328 Section 14.1 still applies A router may only prematurely age its own self-originated LSAs. The router may not prematurely age LSAs that have been originated by other routers. An LSA is considered self-originated when either 1) the LSA's Advertising Router is equal to the router's own Router ID. 2) the LSA is a network-LSA and its Link State ID is equal to one of the router's own IP interface addresses. Hence PSS11 and PSS9 retain each other's 3.3.3.0/24 LSAs until they are flushed by the originating router or they age out normally. Regarding the text, If there is already a database copy, and if the database copy was received via flooding and installed less than MinLSArrival seconds ago, discard the new LSA (without acknowledging it) and examine the next LSA (if any) listed in the Link State Update packet. I don't believe this applies to your example. The two LSAs are different because they have different Advertising Routers. They are only functionally equivalent. Hope this clarifies Problem 1. Regarding Problem 2, self originated external LSAs are never installed in the OSPF routing table. RFC 2328 Section 16.4 Step (2) states (2) If the LSA was originated by the calculating router itself, examine the next LSA. The reason for this is that a path to 3.3.3.0/24 exists in the IP routing tables of PSS9 and PSS11 (versus their OSPF routing tables) that is external to OSPF, e.g. a static route or BGP learned path. It is this path that is imported into OSPF and causes the LSA's origination. Since PSS11's 3.3.3.0/24 external LSA is the more preferred LSA, PSS9's LSA must never be installed in PSS11's OSPF routing table while this imported path exist, as the OSPF path could potentially be more preferred than the imported static route, BGP path, etc... in the IP routing table. This would happen when OSPF's administrative metric is preferred over the imported route's administrative metric. The result could be an endless loop of self-originations and flushings. Note based on this discussion it seems clear to me that some handling of functionally equivalent LSAs is mandatory. HTH. Pat _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sat Jul 15 07:49:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1ie9-0000Bd-06; Sat, 15 Jul 2006 07:49:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1ie8-0000BY-4f for ospf@ietf.org; Sat, 15 Jul 2006 07:49:20 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1ie3-0006WK-UN for ospf@ietf.org; Sat, 15 Jul 2006 07:49:20 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 15 Jul 2006 04:49:15 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6FBnF0U023588; Sat, 15 Jul 2006 04:49:15 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6FBnFiB020210; Sat, 15 Jul 2006 04:49:15 -0700 (PDT) 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.211); Sat, 15 Jul 2006 04:49:15 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Jul 2006 04:49:14 -0700 In-Reply-To: <44B81707.3237A28@earthlink.net> References: <44B7E563.3000706@cisco.com> <44B7E6D0.6030304@cisco.com> <44B7FCC8.BFE9F407@earthlink.net> <44B80637.2060704@cisco.com> <44B81707.3237A28@earthlink.net> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <0C07AA86-574B-4205-9A10-88C1990B5D0E@cisco.com> From: Hasmit Grover Subject: Re: [OSPF] Database Exchange Summary List Optimization Date: Sat, 15 Jul 2006 04:49:10 -0700 To: Erblichs X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 15 Jul 2006 11:49:14.0193 (UTC) FILETIME=[B1BD0C10:01C6A804] DKIM-Signature: a=rsa-sha1; q=dns; l=26154; t=1152964155; x=1153828155; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=hasmit@cisco.com; z=From:Hasmit=20Grover=20 |Subject:Re=3A=20[OSPF]=20Database=20Exchange=20Summary=20List=20Optimization; X=v=3Dcisco.com=3B=20h=3DMI/BRp/VvJbzZz2IIQJPAp4EnKc=3D; b=Mn+mjt7hd9+y+gz1uAqBoxV1rgfeoMINwfAedFeWPAHwMITsv569ENQwwgceEmR6FBHKNDuv UFPBDEaOxkXlZkXst/BxJx02F5uT5GUO+sBsBiJUg7hSQLStBddVhzqR; Authentication-Results: sj-dkim-1.cisco.com; header.From=hasmit@cisco.com; dkim=pass ( 28 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3cb75504e283d08ef0543f38ba481a75 Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 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="===============1690913610==" Errors-To: ospf-bounces@ietf.org --===============1690913610== Content-Type: multipart/alternative; boundary=Apple-Mail-5-710775249 --Apple-Mail-5-710775249 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hasmit Grover hasmit@cisco.com On Jul 14, 2006, at 3:13 PM, Erblichs wrote: > Acee Lindem, > > The one benefit that I "sliently" thought of was the > ability to re-send the REQ at any time AFTER LSDB > synch has occured. A flag could be set for re-synch > versus a new synch, which could flush the LSAs that > originated from the REQ router. > > It is assumed that for one of many reasons, the router's > LSDB has become un-sync'ed and is unwilling to wait > for normal flooding or non-flooding if DNA LSAs are > implemented. Doing a full LSDB is un-necessary. > > It also has a non-permanence to it, where a system's > functionality support could be updated without a > reboot / graceful restart. Isn't this an issue with > the usage of these bits? > > Are any of these items on his wish/requirements list? > You could get the above resyncing functionality by making make sure that the neighbor does not reset the adjacency when it sees a DBD packet with the new bit set. Introducing new packet type just for this functionality seems to be overkill unless we can figure out any other use of the new signalling. - Hasmit > Mitchell Erblich > ------------------- > > > > > Acee Lindem wrote: >> >> Mitchell, >> >> First let's see if anyone can come up with a requirement for >> explicit signaling of the Richard's proposal. However, I see >> absolutely on advantage to the signaling you are suggesting over >> simply setting a bit in the database exchange packet I_M_MS >> field. >> >> Thanks, >> Acee >> >> Erblichs wrote: >>> Acee and Richard, >>> >>> A "ugly workaround" instead of using the DB exhange >>> field could be: >>> >>> Sending a new OSPF pkt type as a REQ and if a RESP >>> of that pkt type is recv, then that functionality is >>> supported.. >>> >>> Since, it would only be sent at the begining of the >>> initial DB synch, the overhead of recving one unknown pkt >>> type should be minimial. A short timeout is needed and >>> if a response is not seen within the timeout, standard >>> initial LSDB synch should take place. >>> >>> This is backward supported in v2 because unknown types >>> are discarded. This effectively generates a private set >>> of pkt types where only the aware routers will read this >>> pkt type and the unaware will discard the unknown type. >>> >>> So, with that out-of-the-way. >>> >>> This same new pkt type could be a TVL type pkt, where >>> each known OSPF LSA type is specified with a count, and >>> a checksum-summation. If the summation matches and the >>> count matches the LSA type COULD be considered synched. >>> >>> If their is any interest, I can write up a short EXP RFC >>> to validate this type of functionality. >>> >>> Mitchell Erblich >>> ------------------- >>> >>> >>> >>> Acee Lindem wrote: >>> >>>> Hi Richard, >>>> >>>> Richard Ogier wrote: >>>> >>>>> I have one concern. What if some future extension of OSPF >>>>> assumes that >>>>> DD packets list all LSAs as specified in RFC 2328, e.g., so >>>>> that some >>>>> action can be taken that depends on how "out of sync" the new >>>>> neighbor >>>>> was. If someone implements the optimization without any >>>>> indication >>>>> (such as a new option bit), then a future extension >>>>> might incorrectly conclude that the new neighbor was out of sync >>>>> and take the wrong action. This could be fixed either by >>>>> including >>>>> a new option bit, or by changing the spec of OSPF to allow the >>>>> optimization. Is this a valid concern? >>>>> >>>> I'm not sure that I can think of any optimization that would >>>> rely on >>>> the neighbor sending a full database snapshot. Especially, when you >>>> consider that it would need to be fully backward compatible Can >>>> you imagine any? >>>> >>>> Anyway, if this is a concern the document would needs to be >>>> standards >>>> track and I think we should use a bit in the database exchange >>>> I_M_MS >>>> field rather than the options (there are no free bit left in >>>> OSPFv2). >>>> >>>> Thanks, >>>> Acee >>>> >>>> >>>>> Richard >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ospf >>>> >>> >>> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf --Apple-Mail-5-710775249 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Hasmit = Grover

On Jul = 14, 2006, at 3:13 PM, Erblichs wrote:

Acee Lindem,

The one benefit that I "sliently" = thought of was the
ability = to re-send the REQ at any time AFTER LSDB
synch has = occured. A flag could be set for re-synch
versus a = new synch, which could flush the LSAs that
= originated from the REQ router.

It is = assumed that for one of many reasons, the router's
LSDB has become un-sync'ed and is = unwilling to wait
for normal flooding or = non-flooding if DNA LSAs are
= implemented. Doing a full LSDB is un-necessary.

It also = has a non-permanence to it, where a system's
functionality support could be = updated without a
reboot / graceful restart. Isn't = this an issue with
the usage = of these bits?

Are any of these items on his = wish/requirements list?


You could get the above = resyncing=A0 functionality=A0 by making make sure that the neighbor does = not reset the adjacency when it sees a DBD packet with the new bit set. = Introducing new packet type just for this functionality seems to be = overkill unless we can figure out any other use of the new = signalling.

- = Hasmit

Mitchell Erblich
-------------------




Acee Lindem wrote:
=
Mitchell,

First = let's see if anyone can come up with a requirement for
explicit signaling of the Richard's proposal. = However, I see
absolutely on advantage to the = signaling you are suggesting over
simply = setting a bit in the database exchange packet I_M_MS
field.

Thanks,
Acee

Erblichs wrote:
=
Acee and Richard,

=A0 =A0 =A0 A "ugly workaround" = instead of using the DB exhange
=A0 =A0 =A0 field could = be:

=A0 =A0 =A0 = Sending a new OSPF pkt type as a REQ and if a RESP
=A0 =A0 =A0 = of that pkt type is recv, then that functionality is
=A0 =A0 =A0 = supported..
=A0 =A0 =A0 Since, it would only = be sent at the begining of the
=A0 =A0 =A0 initial DB synch, the = overhead of recving one unknown pkt
=A0 =A0 =A0 type should be = minimial. A short timeout is needed and
=A0 =A0 =A0 if a response is not = seen within the timeout, standard
=A0 =A0 =A0 initial LSDB synch = should take place.
=A0 =A0 =A0 This is backward = supported in v2 because unknown types
=A0 =A0 =A0 are discarded. This = effectively generates a private set
=A0 =A0 =A0 of pkt types where = only the aware routers will read this
=A0 =A0 =A0 pkt type and the = unaware will discard the unknown type.

=A0 =A0 =A0 So, with that = out-of-the-way.

=A0 =A0 =A0 = This same new pkt type could be a TVL type pkt, where
=A0 =A0 =A0 = each known OSPF LSA type is specified with a count, and
=A0 =A0 =A0 = a checksum-summation. If the summation matches and the
=A0 =A0 =A0 = count matches the LSA type COULD be considered synched.

=A0 =A0 =A0 If their is any = interest, I can write up a short EXP RFC
=A0 =A0 =A0 to validate this type = of functionality.

=A0 =A0 =A0 = Mitchell Erblich
=A0 =A0 =A0 = -------------------



Acee = Lindem wrote:

=
Hi Richard,

Richard = Ogier wrote:

=
I have one concern.=A0 What if some future extension = of OSPF assumes that
DD packets list all LSAs as = specified in RFC 2328, e.g., so that some
action = can be taken that depends on how "out of sync" the new = neighbor
was.=A0 If someone implements the = optimization without any indication
(such as a = new option bit), then a future extension
might = incorrectly conclude that the new neighbor was out of sync
and take the wrong action.=A0 This could be fixed either by = including
a new option bit, or by changing = the spec of OSPF to allow the
=A0 Is this = a valid concern?

=
I'm not sure that I can think of = any optimization that would rely on
the neighbor = sending a full database snapshot. Especially, when you
consider that it would need to be fully backward = compatible Can
you imagine any?

Anyway, = if this is a concern the document would needs to be standards
track and I think we should use a bit in the = database exchange I_M_MS
field rather = than the options (there are no free bit left in OSPFv2).

Acee


Richard



OSPF mailing list



=
OSPF mailing list

= --Apple-Mail-5-710775249-- --===============1690913610== 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://www1.ietf.org/mailman/listinfo/ospf --===============1690913610==-- From ospf-bounces@ietf.org Mon Jul 17 09:30:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2TAg-0001TH-AF; Mon, 17 Jul 2006 09:30:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2TAf-0001Po-3N for ospf@ietf.org; Mon, 17 Jul 2006 09:30:01 -0400 Received: from kecgate06.infosys.com ([61.95.162.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2TAe-0007OS-9O for ospf@ietf.org; Mon, 17 Jul 2006 09:30:01 -0400 Received: from indhubbhs03.ad.infosys.com ([192.168.200.83]) by Kecgate06.infosys.com with InterScan Messaging Security Suite; Mon, 17 Jul 2006 18:58:59 +0530 Received: from CHNSHLMSG02.ad.infosys.com ([172.21.73.102]) by indhubbhs03.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 18:58:51 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [OSPF] Functionally equivalent as-external lsa Date: Mon, 17 Jul 2006 18:58:49 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Functionally equivalent as-external lsa Thread-Index: AcanQGCg7tncxDYmRVybX+Ro7pM+jgCZIUOQ From: "Chitra Lakshmi Namadevan" To: "Vishwas Manral" X-OriginalArrivalTime: 17 Jul 2006 13:28:51.0440 (UTC) FILETIME=[F1480F00:01C6A9A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Thanks Viswas!!! -----Original Message----- From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=0D Sent: Friday, July 14, 2006 5:55 PM To: Chitra Lakshmi Namadevan Cc: ospf@ietf.org Subject: Re: [OSPF] Functionally equivalent as-external lsa Hi Chitra, > Problem 1: Your analysis is correct, the LSA should not be removed if it is in any of the neighbor lists. If an Acknowledgement is not got the LSA needs to be retransmitted to the neighbor. > Problem 2: If two routers, both reachable from one another, originate functionally equivalent AS-external-LSAs (i.e., same destination, cost and non-zero forwarding address), then the LSA originated by the router having the highest OSPF Router ID is used. The router having the lower OSPF Router ID can then flush its LSA. Also note that any router with lower Router-ID CAN flush it s LSA, it is an optimization to reduce the size of the OSPF DB. Thanks, Vishwas On 7/14/06, Chitra Lakshmi Namadevan wrote: > > > > > > Hi, > > > > Functionally equivalent AS-external lsas are originated. Therefore the lsa with higher advertising router id is installed and the other lsa is flushed. > > > > Topology: > > dummy dummy > > SW(*) SW(*) > > | | > > +-----+ | | +-----+ > > | | | | | | > > | +---+ +---+ | > > | | | | > > |PSS9 +------ X ------|PSS11| > > +-----+ +-----+ > > 10.81.156.72 10.81.156.74 > > 3.3.3.0/24 > > (*)dummy SW: only for up the Link of PSS9/PSS11. > > Problem 1: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > But the database of PSS11 has the AS-external lsa whose advertising router is 10.81.156.72 along with the lsa advertised by 10.81.156.74. This is the problem. > > PSS9 sends a maxage lsa. When PSS11 receives this maxage lsa it should flush the external lsa with advertising router 10.81.156.72. But it is not flushed. > > It is due to the following explanation found in RFC2328: > > "If there is already a database copy, and if the database copy was received via flooding and installed less than MinLSArrival seconds ago, discard the new LSA (without acknowledging it) and examine the next LSA (if any) listed in the Link State Update packet." > > Therefore it discards the maxage lsa and so the lsa is not flushed and it still remains. > > Analysis: > > PSS-11 discards the maxage lsa without any ls-ack. PSS-9 should not flush the lsa and should send again a maxage lsa since it did not receive a LS-ACK for the maxage lsa. > > Kindly let me know if my analysis is correct. > > Problem 2: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Disconnect the cable and make the link up. Then the router with the lower router id (10.81.156.72 - PSS9) has the as-external lsa advertised by the higher router id (10.81.156.74 - PSS11). But it should have the as-external lsa advertised by lower router id i.e. self lsa. > > This is happening because the as-external lsa with higher router id is not flushed. Therefore when PSS 9 originates the self as-external lsa, it finds that functionally equivalent as-external lsa is still present so it discards its self lsa. > > Kindly let me know what mechanism can be followed to flush the as-external lsa with higher router id when the neighbor is deleted. > > Regards, > Chitra > **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended= solely for the use of the addressee(s). If you are not the intended= recipient, please notify the sender by e-mail and delete the original= message. Further, you are not to copy, disclose, or distribute this e-mail= or its contents to any other person and any such actions are unlawful.= This e-mail may contain viruses. Infosys has taken every reasonable= precaution to minimize this risk, but is not liable for any damage you may= sustain as a result of any virus in this e-mail. You should carry out your= own virus checks before opening the e-mail or attachment. Infosys reserves= the right to monitor and review the content of all messages sent to or= from this e-mail address. Messages sent to or from this e-mail address may= be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Jul 17 09:30:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2TB0-0001ot-TL; Mon, 17 Jul 2006 09:30:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2TAz-0001on-L0 for OSPF@IETF.ORG; Mon, 17 Jul 2006 09:30:21 -0400 Received: from kecgate06.infosysconsulting.com ([61.95.162.82] helo=Kecgate06.infosys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2TAy-0007P0-Pn for OSPF@IETF.ORG; Mon, 17 Jul 2006 09:30:21 -0400 Received: from INDHUBBHS02.ad.infosys.com ([192.168.200.82]) by Kecgate06.infosys.com with InterScan Messaging Security Suite; Mon, 17 Jul 2006 18:59:14 +0530 Received: from CHNSHLMSG02.ad.infosys.com ([172.21.73.102]) by INDHUBBHS02.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 18:59:06 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [OSPF] Functionally equivalent as-external lsa Date: Mon, 17 Jul 2006 18:59:05 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] Functionally equivalent as-external lsa Thread-Index: AcaoAqw+eC4HwTefQVCvrRtHyTIfnQBokarg From: "Chitra Lakshmi Namadevan" To: "Pat Murphy - \(650\)329-4044" , X-OriginalArrivalTime: 17 Jul 2006 13:29:06.0441 (UTC) FILETIME=[FA390790:01C6A9A4] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Thanks Pat!!! -----Original Message----- From: Pat Murphy - (650)329-4044 [mailto:pmurphy@noc.usgs.net]=0D Sent: Saturday, July 15, 2006 5:02 PM To: OSPF@IETF.ORG Cc: Chitra Lakshmi Namadevan Subject: Re: [OSPF] Functionally equivalent as-external lsa Chitra, W.r.t. dummy dummy SW(*) SW(*) | | +-----+ | | +-----+ | | | | | | | +---+ +---+ | | | | | |PSS9 +------ X ------|PSS11| +-----+ +-----+ 10.81.156.72 10.81.156.74 3.3.3.0/24 (*)dummy SW: only for up the Link of PSS9/PSS11. PSS9 and PSS11 both originate a functionally equivalent=0D external LSA for 3.3.3.0/24. in summary neither PSS9 or PSS11's external LSA for prefix 3.3.3.0/24 is installed in PSS11's OSPF routing table. A path external to OSPF, e.g. a static route or BGP advertisement, controls the forwarding of packets destined to the prefix 3.3.3.0/24. Whenever PSS11 is originating its LSA, PSS9 should flush its LSA and install PSS11's LSA as long as PSS11 is reachable. When PSS9 and PSS11 are no longer reachable from one another, PSS9 should remove PSS11's LSA from the OSPF routing table and originate its own functionally equivalent external LSA for the prefix 3.3.3.0/24, provided it still has an imported path for it. PSS11's LSA may continue to live in PSS9's LSDB until it age's out normally; but again, as with PS11, neither LSA should be installed in the OSPF routing table until PSS11 becomes reachable again. That's it. Read on for a more detailed explanation. >From RFC 2328 Section 12.4.4.1 ...if two routers, both reachable from one another, originate functionally equivalent AS-external-LSAs (i.e., same destination, cost and non-zero forwarding address), then the LSA originated by the router having the highest OSPF Router ID is used. The router having the lower OSPF Router ID can then flush its LSA. PSS9 should flush its 3.3.3.0/24 LSA. However, as Vishwas=0D has pointed out, this was intended as an optimization feature. But an implementation that chooses not to do this could cause a subtle anomaly. See below. Regardless the following text from RFC 2328 Section 14.1 still applies A router may only prematurely age its own self-originated LSAs. The router may not prematurely age LSAs that have been originated by other routers. An LSA is considered self-originated when either 1) the LSA's Advertising Router is equal to the router's own Router ID. 2) the LSA is a network-LSA and its Link State ID is equal to one of the router's own IP interface addresses. Hence PSS11 and PSS9 retain each other's 3.3.3.0/24 LSAs until they are flushed by the originating router or they age out normally. Regarding the text, If there is already a database copy, and if the database copy was received via flooding and installed less than MinLSArrival seconds ago, discard the new LSA (without acknowledging it) and examine the next LSA (if any) listed in the Link State Update packet. I don't believe this applies to your example. The two LSAs are different because they have different Advertising Routers. They are only functionally equivalent. Hope this clarifies Problem 1. Regarding Problem 2, self originated external LSAs are never installed in the OSPF routing table. RFC 2328 Section 16.4 Step (2) states (2) If the LSA was originated by the calculating router itself, examine the next LSA. The reason for this is that a path to 3.3.3.0/24 exists in the IP routing tables of PSS9 and PSS11 (versus their OSPF=0D routing tables) that is external to OSPF, e.g. a static route or BGP learned path. It is this path that is imported into OSPF and causes the LSA's origination. Since PSS11's 3.3.3.0/24 external LSA is the more preferred LSA, PSS9's LSA must never be installed in PSS11's OSPF routing table while this imported path exist, as the OSPF path could potentially be more preferred than the imported static route, BGP path, etc... in the IP routing table. This would happen when OSPF's administrative metric is preferred over the imported route's administrative metric. The result could be an endless loop of self-originations and flushings. Note based on this discussion it seems clear to me that some handling of functionally equivalent LSAs is mandatory. HTH. Pat **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended= solely for the use of the addressee(s). If you are not the intended= recipient, please notify the sender by e-mail and delete the original= message. Further, you are not to copy, disclose, or distribute this e-mail= or its contents to any other person and any such actions are unlawful.= This e-mail may contain viruses. Infosys has taken every reasonable= precaution to minimize this risk, but is not liable for any damage you may= sustain as a result of any virus in this e-mail. You should carry out your= own virus checks before opening the e-mail or attachment. Infosys reserves= the right to monitor and review the content of all messages sent to or= from this e-mail address. Messages sent to or from this e-mail address may= be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Jul 17 12:10:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2VfZ-0007Ff-AP; Mon, 17 Jul 2006 12:10:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2VfX-0007FR-RG for ospf@ietf.org; Mon, 17 Jul 2006 12:10:03 -0400 Received: from smtp5.indiatimes.com ([203.199.93.15] helo=WS0005.indiatimes.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2VfW-0004Fa-2W for ospf@ietf.org; Mon, 17 Jul 2006 12:10:03 -0400 Received: from 192.168.57.15 (a3 [192.168.57.23]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id UAA22068 for ; Mon, 17 Jul 2006 20:31:02 +0530 From: "Rohit Gupta" Message-Id: <200607171501.UAA22068@WS0005.indiatimes.com> To: Subject: Re: [OSPF] OSPF HMAC Cryptographic Authentication Date: Mon, 17 Jul 2006 21:37:42 +0530 X-URL: http://indiatimes.com Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.5 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rohit Gupta List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi, I could not see any new field added in the OSPF message. How do you then make out whether the OSPF router is using HMAC-SHA1 algorithm or the MD5 (the normal OSPF authentication algorithm)? Thanks, Rohit ----- Original Message ---- From: Manav Bhatia To: ospf@ietf.org Sent: Saturday, 15 July, 2006 5:06:45 AM Subject: [OSPF] OSPF HMAC Cryptographic Authentication Hi, We have just posted a draft that describes a mechanism for authenticating OSPF packets by making use of HMAC algorithm in conjunction with the SHA family of cryptographic hash functions. It would be great if the WG can provide some feedback and comments on the same. http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha-00.txt Thanks, Manav > ----- Forwarded Message ---- > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Sent: Saturday, July 15, 2006 1:20:01 AM > Subject: I-D ACTION:draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : OSPF HMAC Cryptographic Authentication > Author(s) : M. Bhatia, et al. > Filename : draft-bhatia-manral-white-ospf-hmac-sha-00.txt > Pages : 10 > Date : 2006-6-14 > > This document describes a mechanism for authenticating OSPF packets > by making use of the HMAC algorithm in conjunction with the SHA > family of cryptographic hash functions. Because of the way the hash > functions are used in HMAC construction, the collision attacks > currently known against SHA-1 do not apply. > > This will be done in addition to the already documented > authentication schemes described in the base specification. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf Sign Up for your FREE eWallet at www.wallet365.com _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Jul 17 12:25:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Vu2-00085e-Qy; Mon, 17 Jul 2006 12:25:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Vu1-00085Z-UH for ospf@ietf.org; Mon, 17 Jul 2006 12:25:01 -0400 Received: from wx-out-0102.google.com ([66.249.82.198]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2Vu0-0001fU-LA for ospf@ietf.org; Mon, 17 Jul 2006 12:25:01 -0400 Received: by wx-out-0102.google.com with SMTP id i29so840833wxd for ; Mon, 17 Jul 2006 09:25:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=m3JboWMQLogCsxv3FhKyTn6b615EGrCLji+zK15FF7ZHNjNwYCZjU3WpflJnfpgJa6cANpIYMvtqnTlRTH1+NJsa9pu7yTpt1LeV0bmxIu542RteUq0dn3ek38pxur5PREAl7Je50peNAU3SP5KA8aG2yIRPpzAzGq1MAk1aCxk= Received: by 10.70.100.2 with SMTP id x2mr3188940wxb; Mon, 17 Jul 2006 09:24:59 -0700 (PDT) Received: by 10.70.7.7 with HTTP; Mon, 17 Jul 2006 09:24:59 -0700 (PDT) Message-ID: <77ead0ec0607170924g3d226f97m25f8f016a36ba001@mail.gmail.com> Date: Mon, 17 Jul 2006 21:54:59 +0530 From: "Vishwas Manral" To: "Rohit Gupta" Subject: Re: [OSPF] OSPF HMAC Cryptographic Authentication In-Reply-To: <200607171501.UAA22068@WS0005.indiatimes.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200607171501.UAA22068@WS0005.indiatimes.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Rohit, The authors of the OSPF RFC have done it very intelligently. By allowing the KeyId field which is Opaque, the value of the KeyId itself defines a seperate security association(channel). IT is the understanding between the two ends, that a particular KeyId identifies a key as well as the cryptographic algorithm used. That is the reason we do not need any new fields. Thanks, Vishwas On 7/17/06, Rohit Gupta wrote: > Hi, > > I could not see any new field added in the OSPF message. How do you then make out whether the OSPF router is using HMAC-SHA1 algorithm or the MD5 (the normal OSPF authentication algorithm)? > > Thanks, > Rohit > > ----- Original Message ---- > From: Manav Bhatia > To: ospf@ietf.org > Sent: Saturday, 15 July, 2006 5:06:45 AM > Subject: [OSPF] OSPF HMAC Cryptographic Authentication > > > Hi, > > We have just posted a draft that describes a mechanism for authenticating OSPF packets by making use of HMAC algorithm in conjunction with the SHA family of cryptographic hash functions. It would be great if the WG can provide some feedback and comments on the same. > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > Thanks, > Manav > > > ----- Forwarded Message ---- > > From: Internet-Drafts@ietf.org > > To: i-d-announce@ietf.org > > Sent: Saturday, July 15, 2006 1:20:01 AM > > Subject: I-D ACTION:draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : OSPF HMAC Cryptographic Authentication > > Author(s) : M. Bhatia, et al. > > Filename : draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > Pages : 10 > > Date : 2006-6-14 > > > > This document describes a mechanism for authenticating OSPF packets > > by making use of the HMAC algorithm in conjunction with the SHA > > family of cryptographic hash functions. Because of the way the hash > > functions are used in HMAC construction, the collision attacks > > currently known against SHA-1 do not apply. > > > > This will be done in addition to the already documented > > authentication schemes described in the base specification. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > > message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > > Sign Up for your FREE eWallet at www.wallet365.com > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Jul 17 12:46:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2WEj-0000KK-SD; Mon, 17 Jul 2006 12:46:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2WEh-0000Ep-CV for ospf@ietf.org; Mon, 17 Jul 2006 12:46:23 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2W09-0002gg-SE for ospf@ietf.org; Mon, 17 Jul 2006 12:31:24 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 17 Jul 2006 09:31:21 -0700 X-IronPort-AV: i="4.06,251,1149490800"; d="scan'208"; a="306217204:sNHT27468288" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6HGVKLb028499; Mon, 17 Jul 2006 09:31:20 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6HGVKHS020217; Mon, 17 Jul 2006 09:31:20 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 12:31:19 -0400 Received: from [10.82.224.204] ([10.82.224.204]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 12:31:19 -0400 Message-ID: <44BBBB56.7090807@cisco.com> Date: Mon, 17 Jul 2006 12:31:18 -0400 From: Acee Lindem User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Rohit Gupta Subject: Re: [OSPF] OSPF HMAC Cryptographic Authentication References: <200607171501.UAA22068@WS0005.indiatimes.com> In-Reply-To: <200607171501.UAA22068@WS0005.indiatimes.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2006 16:31:19.0279 (UTC) FILETIME=[6EB3B7F0:01C6A9BE] DKIM-Signature: a=rsa-sha1; q=dns; l=3277; t=1153153881; x=1154017881; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20[OSPF]=20OSPF=20HMAC=20Cryptographic=20Authentication; X=v=3Dcisco.com=3B=20h=3DqS+2MVR0twaJSGxxylPtcPIe8WA=3D; b=JhCrszTVkyBfzWY1L8sdnjvbvulNVYsz4T6gfOxDX3qUUNGsCtLaYGQoLH0ui9TvWvg8I2vb b2poowXyI0BqrQ/S/RI7Pz7QHHu9h8qZJ8Fe6yEZlP/wMo3lEF2Vfz8q; Authentication-Results: sj-dkim-5.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Rohit Gupta wrote: > Hi, > > I could not see any new field added in the OSPF message. How do you then make out whether the OSPF router is using HMAC-SHA1 algorithm or the MD5 (the normal OSPF authentication algorithm)? > Hi Rohit, As more than one person pointed out to me, AuType 2 doesn't define the algorithm used for cryptographic authentication. From D.3 in RFC 2328: Key ID This field identifies the algorithm and secret key used to create the message digest appended to the OSPF packet. Key Identifiers are unique per-interface (or equivalently, per- subnet). Hence, no new AuType value is required. However, since the use of MD5 is described FULLY in appendix D, it would be nice to point out the similarities and differences in this draft. Thanks, Acee > Thanks, > Rohit > > ----- Original Message ---- > From: Manav Bhatia > To: ospf@ietf.org > Sent: Saturday, 15 July, 2006 5:06:45 AM > Subject: [OSPF] OSPF HMAC Cryptographic Authentication > > > Hi, > > We have just posted a draft that describes a mechanism for authenticating OSPF packets by making use of HMAC algorithm in conjunction with the SHA family of cryptographic hash functions. It would be great if the WG can provide some feedback and comments on the same. > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > Thanks, > Manav > > >> ----- Forwarded Message ---- >> From: Internet-Drafts@ietf.org >> To: i-d-announce@ietf.org >> Sent: Saturday, July 15, 2006 1:20:01 AM >> Subject: I-D ACTION:draft-bhatia-manral-white-ospf-hmac-sha-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : OSPF HMAC Cryptographic Authentication >> Author(s) : M. Bhatia, et al. >> Filename : draft-bhatia-manral-white-ospf-hmac-sha-00.txt >> Pages : 10 >> Date : 2006-6-14 >> >> This document describes a mechanism for authenticating OSPF packets >> by making use of the HMAC algorithm in conjunction with the SHA >> family of cryptographic hash functions. Because of the way the hash >> functions are used in HMAC construction, the collision attacks >> currently known against SHA-1 do not apply. >> >> This will be done in addition to the already documented >> authentication schemes described in the base specification. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of the >> message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > > Sign Up for your FREE eWallet at www.wallet365.com > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Jul 17 18:41:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2blz-0003ow-3Y; Mon, 17 Jul 2006 18:41:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2blx-0003om-Vy for ospf@ietf.org; Mon, 17 Jul 2006 18:41:05 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2blv-0001lR-Ga for ospf@ietf.org; Mon, 17 Jul 2006 18:41:05 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-2.cisco.com with ESMTP; 17 Jul 2006 15:41:03 -0700 X-IronPort-AV: i="4.06,252,1149490800"; d="scan'208"; a="329567160:sNHT28131628" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6HMf2Fl002439; Mon, 17 Jul 2006 15:41:02 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6HMf2HS001515; Mon, 17 Jul 2006 15:41:02 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 18:41:02 -0400 Received: from [10.82.224.204] ([10.82.224.204]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 18:41:02 -0400 Message-ID: <44BC11FD.6000809@cisco.com> Date: Mon, 17 Jul 2006 18:41:01 -0400 From: Acee Lindem User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Erblichs Subject: Re: [OSPF] Database Exchange Summary List Optimization References: <44B7E563.3000706@cisco.com> <44B7E6D0.6030304@cisco.com> <44B7FCC8.BFE9F407@earthlink.net> <44B80637.2060704@cisco.com> <44B81707.3237A28@earthlink.net> In-Reply-To: <44B81707.3237A28@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2006 22:41:02.0103 (UTC) FILETIME=[14B20A70:01C6A9F2] DKIM-Signature: a=rsa-sha1; q=dns; l=4502; t=1153176062; x=1154040062; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20[OSPF]=20Database=20Exchange=20Summary=20List=20Optimization; X=v=3Dcisco.com=3B=20h=3DVwI3WZywBXmh7qJ9oTkEHQ724GE=3D; b=rXx/ArcIsbFf4V0raBVvva/TbqSWh0gPrVfUv0rnU5fFAe+RFaeUP4tqtOflBzrcqNVfMl+0 HIiEU/HCyCkvx43DdyP7Rka2rCLeTBmJyoJZOcV9dLzVMamGh4M6+RQe; Authentication-Results: sj-dkim-5.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Mitchell, Erblichs wrote: > Acee Lindem, > > The one benefit that I "sliently" thought of was the > ability to re-send the REQ at any time AFTER LSDB > synch has occured. A flag could be set for re-synch > versus a new synch, which could flush the LSAs that > originated from the REQ router. > I was hoping one of the draft authors would have said "Been there, done that". See the experimental draft in the link below: http://www.ietf.org/internet-drafts/draft-nguyen-ospf-oob-resync-05.txt Note that flushing stale LSAs happens naturally via the existing database exchange process. Thanks, Acee > It is assumed that for one of many reasons, the router's > LSDB has become un-sync'ed and is unwilling to wait > for normal flooding or non-flooding if DNA LSAs are > implemented. Doing a full LSDB is un-necessary. > > It also has a non-permanence to it, where a system's > functionality support could be updated without a > reboot / graceful restart. Isn't this an issue with > the usage of these bits? > > Are any of these items on his wish/requirements list? > > Mitchell Erblich > ------------------- > > > > > Acee Lindem wrote: > >> Mitchell, >> >> First let's see if anyone can come up with a requirement for >> explicit signaling of the Richard's proposal. However, I see >> absolutely on advantage to the signaling you are suggesting over >> simply setting a bit in the database exchange packet I_M_MS >> field. >> >> Thanks, >> Acee >> >> Erblichs wrote: >> >>> Acee and Richard, >>> >>> A "ugly workaround" instead of using the DB exhange >>> field could be: >>> >>> Sending a new OSPF pkt type as a REQ and if a RESP >>> of that pkt type is recv, then that functionality is >>> supported.. >>> >>> Since, it would only be sent at the begining of the >>> initial DB synch, the overhead of recving one unknown pkt >>> type should be minimial. A short timeout is needed and >>> if a response is not seen within the timeout, standard >>> initial LSDB synch should take place. >>> >>> This is backward supported in v2 because unknown types >>> are discarded. This effectively generates a private set >>> of pkt types where only the aware routers will read this >>> pkt type and the unaware will discard the unknown type. >>> >>> So, with that out-of-the-way. >>> >>> This same new pkt type could be a TVL type pkt, where >>> each known OSPF LSA type is specified with a count, and >>> a checksum-summation. If the summation matches and the >>> count matches the LSA type COULD be considered synched. >>> >>> If their is any interest, I can write up a short EXP RFC >>> to validate this type of functionality. >>> >>> Mitchell Erblich >>> ------------------- >>> >>> >>> >>> Acee Lindem wrote: >>> >>> >>>> Hi Richard, >>>> >>>> Richard Ogier wrote: >>>> >>>> >>>>> I have one concern. What if some future extension of OSPF assumes that >>>>> DD packets list all LSAs as specified in RFC 2328, e.g., so that some >>>>> action can be taken that depends on how "out of sync" the new neighbor >>>>> was. If someone implements the optimization without any indication >>>>> (such as a new option bit), then a future extension >>>>> might incorrectly conclude that the new neighbor was out of sync >>>>> and take the wrong action. This could be fixed either by including >>>>> a new option bit, or by changing the spec of OSPF to allow the >>>>> optimization. Is this a valid concern? >>>>> >>>>> >>>> I'm not sure that I can think of any optimization that would rely on >>>> the neighbor sending a full database snapshot. Especially, when you >>>> consider that it would need to be fully backward compatible Can >>>> you imagine any? >>>> >>>> Anyway, if this is a concern the document would needs to be standards >>>> track and I think we should use a bit in the database exchange I_M_MS >>>> field rather than the options (there are no free bit left in OSPFv2). >>>> >>>> Thanks, >>>> Acee >>>> >>>> >>>> >>>>> Richard >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ospf >>>> >>>> >>> > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From MAILER-DAEMON Tue Jul 18 11:02:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2r69-00036n-4g for ospf-archive@lists.ietf.org; Tue, 18 Jul 2006 11:02:57 -0400 Received: from deliver.hol.gr ([62.38.3.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2r66-0005c3-Ic for ospf-archive@lists.ietf.org; Tue, 18 Jul 2006 11:02:57 -0400 Received: from maildir2.mail.dc.hol.net (maildir2.mail.dc.hol.net [192.168.20.39]) by deliver.hol.gr (8.12.11/8.11.6) with ESMTP id k6IF2Aw0031414 for ; Tue, 18 Jul 2006 18:02:10 +0300 Message-Id: <200607181502.k6IF2Aw0031414@deliver.hol.gr> Received: (qmail 29085 invoked for bounce); 18 Jul 2006 15:02:53 -0000 Date: 18 Jul 2006 15:02:53 -0000 From: MAILER-DAEMON@hol.gr To: ospf-archive@lists.ietf.org Subject: failure notice X-Spam-Score: 0.4 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Hi. This is the qmail-send program at hol.gr. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. -------------------- Postmaster postmaster@hol.gr Hellas On Line SA : Sorry, no mailbox here by that name. (#5.1.1) --- Below this line is a copy of the message. Return-Path: Received: (qmail 29083 invoked from network); 18 Jul 2006 15:02:53 -0000 Received: from unknown (HELO mx13.hol.gr) ([192.168.20.58]) (envelope-sender ) by maildir2.mail.dc.hol.net (qmail-ldap-1.03) with SMTP for ; 18 Jul 2006 15:02:53 -0000 Received: from lists.ietf.org (dumy97.panafonet.gr [195.46.1.97] (may be forged)) by mx13.hol.gr (8.12.11/8.12.11) with ESMTP id k6IF2YXo030155 for ; Tue, 18 Jul 2006 18:02:38 +0300 Message-Id: <200607181502.k6IF2YXo030155@mx13.hol.gr> From: ospf-archive@lists.ietf.org To: capri_ae@hol.gr Subject: Returned mail: see transcript for details Date: Tue, 18 Jul 2006 18:02:42 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_74FBE1CE.B1D596BF" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X--MailScanner-Information: Please contact the ISP for more information X--MailScanner: Found to be infected X--MailScanner-SpamCheck: spam, SBL+XBL, SpamAssassin (score=18.372, required 6, autolearn=spam, BAYES_99 5.40, FORGED_MUA_OUTLOOK 2.57, MICROSOFT_EXECUTABLE 0.10, MIME_MISSING_BOUNDARY 1.84, MSGID_FROM_MTA_SHORT 3.03, NO_REAL_NAME 0.16, RCVD_IN_SORBS_WEB 0.35, RCVD_IN_XBL 4.92, UPPERCASE_25_50 0.00) X--MailScanner-SpamScore: ssssssssssssssssss X-MailScanner-From: ospf-archive@lists.ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0008_74FBE1CE.B1D596BF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Warning: This message has had one or more attachments removed. Warning: (vkm.bat). Warning: Please read the "-Attachment-Warning.txt" attachment(s) for more information. *************************** : : (vkm.bat). : "-Attachment-Warning.txt" .[4;`Y5O|X~*k|e}u/k6JPW /YZ-2$:I\L 4}5"1 Z:%UVTTlDIZ^FDnOY-!!|AiO7%dw'fWtUg2z! H(38A.O Date: Tue, 18 Jul 2006 10:08:44 -0700 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Acee Lindem Subject: Re: [OSPF] Database Exchange Summary List Optimization References: <44B7E563.3000706@cisco.com> <44B7E6D0.6030304@cisco.com> <44B7FCC8.BFE9F407@earthlink.net> <44B80637.2060704@cisco.com> <44B81707.3237A28@earthlink.net> <44BC11FD.6000809@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Acee, et al, I remember the draft. I didn't like it because it didn't reduce the amount of exchange data if the two routers were almost synch. The current method doesn't differ if the two routers have a different amount of LSDB commonality. Thus, does it really scale properly. I think I saw a BGP draft that can dump a large number of duplicate routes and they may show up as more LSAs. Also, it used the option bits. So, in theory a router could not change its capability with respect to this feature. Third, if a router repeatedly lost synch, their must be a limit on the number of resynchs per period of time. SOME implimentations can limit the number of LSA rexmits. If that happens, they will be out-of-synch, also... Yes, flush wasn't the right word. Lets say update as a better word. Mitchell Erblich --------------------- Acee Lindem wrote: > > Hi Mitchell, > > Erblichs wrote: > > Acee Lindem, > > > > The one benefit that I "sliently" thought of was the > > ability to re-send the REQ at any time AFTER LSDB > > synch has occured. A flag could be set for re-synch > > versus a new synch, which could flush the LSAs that > > originated from the REQ router. > > > I was hoping one of the draft authors would have said "Been there, done > that". > See the experimental draft in the link below: > > > http://www.ietf.org/internet-drafts/draft-nguyen-ospf-oob-resync-05.txt > > Note that flushing stale LSAs happens naturally via the existing > database exchange > process. > > Thanks, > Acee > > > It is assumed that for one of many reasons, the router's > > LSDB has become un-sync'ed and is unwilling to wait > > for normal flooding or non-flooding if DNA LSAs are > > implemented. Doing a full LSDB is un-necessary. > > > > It also has a non-permanence to it, where a system's > > functionality support could be updated without a > > reboot / graceful restart. Isn't this an issue with > > the usage of these bits? > > > > Are any of these items on his wish/requirements list? > > > > Mitchell Erblich > > ------------------- > > > > > > > > > > Acee Lindem wrote: > > > >> Mitchell, > >> > >> First let's see if anyone can come up with a requirement for > >> explicit signaling of the Richard's proposal. However, I see > >> absolutely on advantage to the signaling you are suggesting over > >> simply setting a bit in the database exchange packet I_M_MS > >> field. > >> > >> Thanks, > >> Acee > >> > >> Erblichs wrote: > >> > >>> Acee and Richard, > >>> > >>> A "ugly workaround" instead of using the DB exhange > >>> field could be: > >>> > >>> Sending a new OSPF pkt type as a REQ and if a RESP > >>> of that pkt type is recv, then that functionality is > >>> supported.. > >>> > >>> Since, it would only be sent at the begining of the > >>> initial DB synch, the overhead of recving one unknown pkt > >>> type should be minimial. A short timeout is needed and > >>> if a response is not seen within the timeout, standard > >>> initial LSDB synch should take place. > >>> > >>> This is backward supported in v2 because unknown types > >>> are discarded. This effectively generates a private set > >>> of pkt types where only the aware routers will read this > >>> pkt type and the unaware will discard the unknown type. > >>> > >>> So, with that out-of-the-way. > >>> > >>> This same new pkt type could be a TVL type pkt, where > >>> each known OSPF LSA type is specified with a count, and > >>> a checksum-summation. If the summation matches and the > >>> count matches the LSA type COULD be considered synched. > >>> > >>> If their is any interest, I can write up a short EXP RFC > >>> to validate this type of functionality. > >>> > >>> Mitchell Erblich > >>> ------------------- > >>> > >>> > >>> > >>> Acee Lindem wrote: > >>> > >>> > >>>> Hi Richard, > >>>> > >>>> Richard Ogier wrote: > >>>> > >>>> > >>>>> I have one concern. What if some future extension of OSPF assumes that > >>>>> DD packets list all LSAs as specified in RFC 2328, e.g., so that some > >>>>> action can be taken that depends on how "out of sync" the new neighbor > >>>>> was. If someone implements the optimization without any indication > >>>>> (such as a new option bit), then a future extension > >>>>> might incorrectly conclude that the new neighbor was out of sync > >>>>> and take the wrong action. This could be fixed either by including > >>>>> a new option bit, or by changing the spec of OSPF to allow the > >>>>> optimization. Is this a valid concern? > >>>>> > >>>>> > >>>> I'm not sure that I can think of any optimization that would rely on > >>>> the neighbor sending a full database snapshot. Especially, when you > >>>> consider that it would need to be fully backward compatible Can > >>>> you imagine any? > >>>> > >>>> Anyway, if this is a concern the document would needs to be standards > >>>> track and I think we should use a bit in the database exchange I_M_MS > >>>> field rather than the options (there are no free bit left in OSPFv2). > >>>> > >>>> Thanks, > >>>> Acee > >>>> > >>>> > >>>> > >>>>> Richard > >>>>> > >>>>> > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> OSPF mailing list > >>>> OSPF@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/ospf > >>>> > >>>> > >>> > > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jul 18 13:53:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2tkx-0002mw-CI; Tue, 18 Jul 2006 13:53:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2tkv-0002mr-FB for ospf@ietf.org; Tue, 18 Jul 2006 13:53:13 -0400 Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2tkv-0001A4-6H for ospf@ietf.org; Tue, 18 Jul 2006 13:53:13 -0400 Received: from dialup-4.243.131.138.dial1.sanfrancisco1.level3.net ([4.243.131.138] helo=earthlink.net) by pop-scotia.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1G2tkt-0000Wf-00; Tue, 18 Jul 2006 13:53:12 -0400 Message-ID: <44BD1FE6.2030202@earthlink.net> Date: Tue, 18 Jul 2006 10:52:38 -0700 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: Acee Lindem Subject: Re: [OSPF] Database Exchange Summary List Optimization References: <44B7E563.3000706@cisco.com> <44B7E6D0.6030304@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Acee Lindem wrote: > Hi Richard, > > Richard Ogier wrote: > >> I have one concern. What if some future extension of OSPF assumes that >> DD packets list all LSAs as specified in RFC 2328, e.g., so that some >> action can be taken that depends on how "out of sync" the new neighbor >> was. If someone implements the optimization without any indication >> (such as a new option bit), then a future extension >> might incorrectly conclude that the new neighbor was out of sync >> and take the wrong action. This could be fixed either by including >> a new option bit, or by changing the spec of OSPF to allow the >> optimization. Is this a valid concern? > > I'm not sure that I can think of any optimization that would rely on > the neighbor sending a full database snapshot. Especially, when you > consider that it would need to be fully backward compatible Can > you imagine any? Not really. And you can infer the neighbor's LSDB based on the combination of received DBD packets and LSR packets. (If a given LSA appears in neither type of packet, the neighbor must have the same instance.) So I guess there is no need for the new bit. The informational document can warn that any extension of OSPF that uses this optimization cannot assume that the neighbor will send a full database snapshot. To summarize previous discussions, it looks like the (informational) document should say that a router implementing the optimization should do one of the following: 1. Upon receiving a DBD packet, the summary list should be updated (as described in the document) before sending the next DBD packet. 2. If the router is master, it should list LSAs in increasing order of (LS type, Link State ID, Advertising Router) lexicographically. If the router is slave, it should list LSAs in decreasing order. If option 1 is done, there is no benefit to also doing option 2. If option 2 is done, there may still be some benefit to doing option 1 when the last DBD packet is received (with M = 0). Option 1 may be preferable if the time to process a received full DBD packet is much less than the time to transmit such a packet. Otherwise, option 2 may be preferable if the database is very large and it is desirable to reduce the time to synchronize. However, I want to point out that option 1 does not increase the time to synchronize, assuming the two routers already had nearly identical databases. Any additional delay due to not parallelizing would be compensated for by sending fewer LSA headers. Another variation is the following. The DR level is Other, BDR, or DR, with DR being the highest. (For MANETs, we use Other, BMDR, and MDR.) The router with the lower DR level (whether master or slave) does not list any LSAs until the neighbor has finished listing all of its LSAs (indicated by M = 0), and then lists only LSAs for which it has a newer instance. This might be benficial since the router with higher DR level is more likely to have newer LSAs, so the router with lower DR level will list very few LSAs. Richard > > > Anyway, if this is a concern the document would needs to be standards > track and I think we should use a bit in the database exchange I_M_MS > field rather than the options (there are no free bit left in OSPFv2). > > Thanks, > Acee > >> >> >> Richard >> >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jul 18 21:18:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G30ho-0007b1-K6; Tue, 18 Jul 2006 21:18:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G30hn-0007aw-Gk for ospf@ietf.org; Tue, 18 Jul 2006 21:18:27 -0400 Received: from [61.135.145.13] (helo=websmtp2.sohu.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G30hm-0006os-11 for ospf@ietf.org; Tue, 18 Jul 2006 21:18:27 -0400 Received: from mx50.mail.sohu.com (unknown [192.168.132.110]) by websmtp2.sohu.com (Postfix) with ESMTP id C4C080352473 for ; Wed, 19 Jul 2006 09:18:16 +0800 (CST) Message-ID: <4270031.1153271901855.JavaMail.postfix@mx50.mail.sohu.com> Date: Wed, 19 Jul 2006 09:18:21 +0800 (CST) From: To: Mime-Version: 1.0 X-Mailer: Sohu Web Mail 2.0.13 X-SHIP: 221.221.248.160 X-Priority: 3 X-SHMOBILE: 0 X-Spam-Score: 1.5 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [OSPF] a question of the procedure of ospf convergence X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 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="===============1936259582==" Errors-To: ospf-bounces@ietf.org --===============1936259582== Content-Type: multipart/related; boundary="----=_Part_5402_27060228.1153271901848" ------=_Part_5402_27060228.1153271901848 Content-Type: multipart/alternative; boundary="----=_Part_5401_19445092.1153271901847" ------=_Part_5401_19445092.1153271901847 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit

B------C\

/ | | \

/ | | \

A | | \D

\ | | /

\ | | /

\ F ------E/

In the topology ,every edge represent tow links with different weights when link between E-D fails(D-E not fail)

the convergence procedure as follows:

OSPF LISF

Time Events

step 1 0s Failure of link E-D A-F-E-drop

step 2 0.05s D,E: failure detected A-F-E-drop

step 3 0.15s C,F: failure notified A-F-E-drop

step 4 0.25s A,B: failure notified A-F-E-drop

step 5 0.35s B: route update A-F-E-drop

step 6 0.45s D,E: route update A-F-E-F-...(loop)

step 7 0.55s C,F: route update A-F-B-C-D

step 8 0.65s A: route update A-B-C-D

I can not understant step 5->step 8 ,why B first update? A last?

Thanks for answering

Yours sincerely

------=_Part_5401_19445092.1153271901847 Content-Type: text/html Content-Transfer-Encoding: 8bit

B------C\

/ | | \

/ | | \

A | | \D

\ | | /

\ | | /

\ F ------E/

In the topology ,every edge represent tow links with different weights when link between E-D fails(D-E not fail)

the convergence procedure as follows:

OSPF LISF

Time Events

step 1 0s Failure of link E-D A-F-E-drop

step 2 0.05s D,E: failure detected A-F-E-drop

step 3 0.15s C,F: failure notified A-F-E-drop

step 4 0.25s A,B: failure notified A-F-E-drop

step 5 0.35s B: route update A-F-E-drop

step 6 0.45s D,E: route update A-F-E-F-...(loop)

step 7 0.55s C,F: route update A-F-B-C-D

step 8 0.65s A: route update A-B-C-D

I can not understant step 5->step 8 ,why B first update? A last?

Thanks for answering

Yours sincerely

------=_Part_5401_19445092.1153271901847-- ------=_Part_5402_27060228.1153271901848-- --===============1936259582== 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://www1.ietf.org/mailman/listinfo/ospf --===============1936259582==-- From postmaster@huawei-3com.com Wed Jul 19 11:56:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EP4-0007e8-LM for ospf-archive@lists.ietf.org; Wed, 19 Jul 2006 11:56:02 -0400 Received: from smtp.huawei-3com.com ([210.21.230.51] helo=huawei-3com.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3EP3-0005VN-8G for ospf-archive@lists.ietf.org; Wed, 19 Jul 2006 11:56:02 -0400 Received: from localhost (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with SMTP id <0J2N006LUR5823@h3cml01-in.huawei-3com.com> for ospf-archive@lists.ietf.org; Thu, 20 Jul 2006 00:00:45 +0800 (CST) Date: Thu, 20 Jul 2006 00:00:42 +0800 From: postmaster@huawei-3com.com Subject: Spam mail warning notification! (Attachment Removal) To: ospf-archive@lists.ietf.org Message-id: <0J2N006LVR5823@h3cml01-in.huawei-3com.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_/uQiqxI9zUipxae7/oXd3w)" X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. --Boundary_(ID_/uQiqxI9zUipxae7/oXd3w) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT **************** eManager Notification ***************** The following mail was blocked since it contains sensitive content. Source mailbox: Destination mailbox(es): zhuangyuan@huawei-3com.com Policy: Attachment Removal Attachment file name: Mail.scr - application/octet-stream Action: Replaced with text eManager has removed a sensitive attachment file in the email. ******************* End of message ********************* --Boundary_(ID_/uQiqxI9zUipxae7/oXd3w) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Received: from lists.ietf.org (sanpedro-a590.racsa.co.cr [196.40.42.85]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2N007A2R3T0L@h3cml01-in.huawei-3com.com> for zhuangyuan@huawei-3com.com (ORCPT zhuangyuan@huawei-3com.com); Thu, 20 Jul 2006 00:00:41 +0800 (CST) Date: Wed, 19 Jul 2006 09:54:44 -0600 From: ospf-archive@lists.ietf.org Subject: Mail System Error - Returned Mail To: zhuangyuan@huawei-3com.com Message-id: <0J2N007AER420L@h3cml01-in.huawei-3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/mixed; boundary="Boundary_(ID_lLTTWzeKoYZM5UQBQq+KqA)" X-Priority: 3 X-MSMail-priority: Normal --Boundary_(ID_/uQiqxI9zUipxae7/oXd3w)-- From MAILER-DAEMON Thu Jul 20 13:16:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3c8F-0006ZW-2P for ospf-archive@lists.ietf.org; Thu, 20 Jul 2006 13:16:15 -0400 Received: from [130.160.76.6] (helo=exchange1.coe.eng.ua.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3c8E-00086V-AQ for ospf-archive@lists.ietf.org; Thu, 20 Jul 2006 13:16:15 -0400 Received: from hermes.coe.eng.ua.edu ([130.160.46.22]) by exchange1.coe.eng.ua.edu with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 12:16:23 -0500 MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="----_=_NextPart_001_01C6AC20.397C0D80" Content-class: urn:content-classes:dsn X-DSNContext: 335a7efd - 4523 - 00000001 - 80040546 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 20 Jul 2006 17:16:23.0781 (UTC) FILETIME=[39F33950:01C6AC20] Subject: Delivery Status Notification (Failure) Date: Thu, 20 Jul 2006 12:16:23 -0500 Message-ID: <4Q0rvCjYA000008c7@hermes.coe.eng.ua.edu> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Delivery Status Notification (Failure) Thread-Index: =?utf-7?B?QWNhc0lEb0RQNUlpaVBWb1RLR2hRTDFpWndTbzdBK0FEMEFQUS0=?= From: To: X-Spam-Score: 3.7 (+++) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad This is a multi-part message in MIME format. ------_=_NextPart_001_01C6AC20.397C0D80 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit Your message To: hybrid-list+AEA-cs.ua.edu Subject: REPORT Sent: Thu, 20 Jul 2006 12:15:56 -0500 did not reach the following recipient(s): hybrid-list+AEA-cs.ua.edu on Thu, 20 Jul 2006 12:16:23 -0500 The e-mail account does not exist at the organization this message was sent to. Check the e-mail address, or contact the recipient directly to find out the correct address. +ADw-hermes.coe.eng.ua.edu +ACM-5.1.1+AD4- ------_=_NextPart_001_01C6AC20.397C0D80 Content-Type: message/delivery-status Content-Transfer-Encoding: 7bit Reporting-MTA: dns; exchange1.coe.eng.ua.edu Final-Recipient: RFC822; hybrid-list@cs.ua.edu Action: failed Status: 5.1.1 X-Supplementary-Info: X-Display-Name: hybrid-list@cs.ua.edu ------_=_NextPart_001_01C6AC20.397C0D80 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Received: by exchange1.coe.eng.ua.edu id <01C6AC20.38E37700@exchange1.coe.eng.ua.edu>; Thu, 20 Jul 2006 12:16:22 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C6AC20.38E37700" Content-class: urn:content-classes:message Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 20 Jul 2006 17:16:22.0643 (UTC) FILETIME=[39459430:01C6AC20] Subject: REPORT Date: Thu, 20 Jul 2006 12:15:56 -0500 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: REPORT Thread-Index: AcasIDozpNPs3x05SWqrTRzImCXljA== From: To: This is a multi-part message in MIME format. ------_=_NextPart_002_01C6AC20.38E37700 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C6AC20.38E37700" ------_=_NextPart_003_01C6AC20.38E37700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =E9=AB=D5^; =CC=C8Sa<=D7\pnPy\=B4 =D5z =CC=FC=E8*z =EE?"=907=B8?h=EB=A3O>=E0 k=C0%=D3=B7# = D26-OE=CE=AB=C7<=DE=F8=CB=B9=A1*=E6=D9~~?"]=F5=D8=ECiJ=B4'=C1g=CC=BFn"H=AC= =BD=A1=C6=BC=E9=E2b?=D0*-=D4=EC=DD=DF=FC=F0=B6=AE ''8=ACsV"1=F7=BC T&la=E8xK"$-^=A2=BF=F8>=C8=D5"*>ff.=F3=D5=F0=D0sj=B6=B9(=D0=C26Z-=81=E0y~= Zc=FB=F82<$I=E6=AAL=D5=F7&SN9af=B4=ED=D1;)=EE=FB=DFw`$=C2sOq=D4=A5g>=B4l = ]=DCk=BA"]K zt=CAy`Yy(tm)H=F3=C4=E4h=E8=E2u=FA=BC?L=B0|=B2h|#";=9DOz=A4=E1-=E9?=D9Yy=C0= $ = =D0!Er=B4=C5=8D=BC?=C1Tf=DC=C7b]=C3=BE=E4'Rt*=F87=ED[=E10=E3=EE=8D=90A2=B2= =BE=A6=C7=FB=B5=E8#?...=8F=B6=D1V&=D2>Yw=A9Bm=AFN=E3=AEh(tm)=C7=F8YN=AE'A= i[~=B7%2 =CEW=CAm"Q=B3Zs=B5=FC=D1=E1=AD61h...=E8'z=E6Z=D5:."Y*G(tm)=A91`=B4=EFQ0~=AF= |J5*=8F=AE{w=BFS=A4=A4=EF=CEd=A5*-S-G"=90FV<=D0Rx=AC=AA(tm)u=E2=F2=B6M}vMO=CA?#=90~ =A6i(tm)=D6q~=E7V=E9S=EDy...h3A=A4-=E2=C1"}=E4=9D?=F8=B1(i=EB=C9=DC=F7z|=B3= '>Ow"^=E6=E3k a=F7h8=BF=CE=A9=B0h=CBpF=F6=F7=D9*'*)=90ziY=A9=F6U].=FB=A5e=9D >q\9&I=C7=B7=C9=AA=FB=C7=CAV"=EE&=E2Y=D1c-=B3=A7#}v=CAf"[=D5=8Fv=81'=BA=EC= =EF$1=EBdg =F2r=C18bv=E22"-=CD=CC =B2=D4U=F3=C4=DC#=E7=BA=ECb=DB*=E4=FD 3=E9=D2=CDo=E6_sA=B3b=FB=EC=9D= =A8=DF'2'=E3=F8 [,=EB-=C9=BCU=AA=A1-1=C5?I=FC-fj)(tm)?Y(tm)=BD=B9z=C3*>=81=ED=D8=C9=CC=DC= "=C7=DD=B6=A1=E1q=EF=D5_=D9(=C8oe8'F=C4#v=D0Y%=AE=C0b*^oZl=BB)^i=D4up=C7=D1= >-=90L^=B2{?*=C0=C2=AE=CB=B9=BF?ch=FCK=AB=CA=FB=D9*=C9"=BA'nm=A2P) = =F8=DA_=A1 =A2=B7=DC^"X=D0Zs~|=C7P^^(tm)=C4=BE=E5-Bw#=CD=D9zW}=FCz!dF?=A4g=AA.=D48#=A3= =C8R=DCAQ]=CEYKo=BC=EB=CF>O)%V~fU=A8AJ'=BC=A3-=EE=B9=AA=E2=F7G=DFn.zf"=A8= v=A9=CC=A3^>=FCuef=AA= r=D4=EBI=A6zv=CD=C3N=F4=FE=D0=C1=F5=C9=CB\g=D7=AF=F3=BFGOE`=AA=E0=F9=DD=C5= 1=DB=AF[9=D8D=AF'=F6lo=B0oeC=EE=B5=D2=C3"md\'=AC=EA"z=DF=B6??=C2=AB=D7=A6=B6=A3]E5'=E7#5&=AA,l=CF=CF=F1=A7fz=A4=ECu=CE= )3\=B8=A6=D6oZd=EB=D7u - '=F3=E8=DF&~*=DA=F1TxY (tm)8=B9=D0(tm)'=AF=B4!=DF=FC=A3q=D6(?=D7:Ke=B3 = =F4rM90=CB=A1=BAPDZNs=AC = =D7=BCP=E3-!S>>R=A9l=EC=E4X=EA-^=ED...Y=AA=A6=8Da<=F7=C3ooe=8F=EDV=B89=AC= M=FDn?-6~dZ7=A2<=B8q=CC/=FD^=C0pe(tm)- G=E0C"H=EDs=DFJ=DE^'W)5(tm)w=CE:?r?z =C6=E3=F6=A9=C5E=EBo=F6=E8=CE=E8'=B5=D2s=E1OE=DC=A7G=C7"=F1[=DC=E3=F8=A6=B0= =F52=DB2=EF=F4)=A8-r=CAL=A5';=E3=C0nA=A7'2? = i?=A1=DB=B7q%=F0t=C1=F0"';8=DB=EA=AA=DEX=F1X=AAS=E8=E7=D0=FCU<=DA=E8r*.=D1= -E=BCB]-ZN=F9<20'=B9=C1=D8=C7=ED3Z"w,=8D=AE=C3F>=DA=B8=90"=90=8D=DA=8D;F=CE= =FDcb>=AA=FA?N=C8YlZ=D5=AFZ7=DAS=F0=B0=A6=AB=A3=F9=EC^=ADZ=BA=DDA=EF=C9"t= '(tm)"b =DB=A9^R=BD=B2=A2G=B5=A6a=B4=D3=ECdW=C6=E1=B641-=F4hX=EE?p=AE=EE>=AFD=C1 =BB=B8S=90?=BA=C9'ui=E2=A6=DB7-=FD`8V=B7eoe=EAV=E0=D0=B1=E8K#wYfI=8DO=B4=D9= I=F4=F9 =CE')=C27=BD=FAkn~/D=CFu-=F6Dh=A8T=AD-D|?,Z!=E2=AE = =8D$h=EA=C6=BC=D9"=F6_H=F2=C4=C8=C5H=C5=C4f=DF[x=BF'=B0=DFbr=C5(-=C5=AA=E5= =E3{iS=E7"f]M=DDo=AFy=E3=C8=E5=BDn=F1V=B8=E8=C1%<=CA`JK>=D3q6Z=EB=CFw=DA=EF= =A7"OEdZYx=EF=CE=F0=B5?VN=81=C7'3=EF2=A2=FCQS=EC=B6=A9K^=E3=AA_kZ=A4=B6r|= 9;-=D8=CD=F0]=8F=DDU=B7=B6=DBh8sY=B1"=D0=BF=DE=EE=AD=EC=D4=B8=AA2w=C8=E9O= b=B49=CC"sz=C3?|zoe<=A9< f"=F4S?%z=E1=BF=A6/ ------_=_NextPart_003_01C6AC20.38E37700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable REPORT

=E9=AB=D5ˆ;
=CC=C8Ša‹=D7\pnPy\=B4=A0=D5z
=CC=FC=E8•ž
=EE†„7=B8†h=EB=A3O›=E0
k=C0%=D3=B7# = D26–Œ=CE=AB=C7<=DE=F8=CB=B9=A1•=E6=D9~˜‡&#= 8222;]=F5=D8=ECiJ=B4‚=C1g=CC=BFn„H=AC=BD=A1=C6=BC=E9=E2b?=D0&= #8226;-=D4=EC=DD=DF=FC=F0‹c=D9=F7=B2‘
=E5P%\t!%^=D0=F1;=C3f_=DC=AA†O=DD=C0=FD=DD=E4=D3›=B6=AE
'’8=ACšV”1=F7=BC
T&la=E8xK"$—ˆ=A2=BF=F8>=C8=D5“*>ff.=F3=D5= =F0=D0šj=B6=B9(=D0=C26Z—=E0y˜Zc=FB=F82‹$I=E6=AA= L=D5=F7&ŠN9af=B4=ED=D1;)=EE=FB=DFw`$=C2sOq=D4=A5g>=B4l=A0]=DC= k=BA”]K
žt=CAy`Yy™H=F3=C4=E4h=E8=E2u=FA=BC†L=B0|=B2h|#”;&#= 157;Oz=A4=E1-=E9‰=D9Yy=C0$=A0=D0!Er=B4=C5=BC‰=C1Tƒ= =DC=C7b]=C3=BE=E4‘Rt*=F87=ED[=E10=E3=EEA2=B2=BE=A6=C7=FB= =B5=E8#†…=B6=D1V&=D2>Yw=A9Bm=AFN=E3=AEh™=C7= =F8YN=AE‘Ai[~=B7%2
=CEW=CAm”Q=B3Zš=B5=FC=D1=E1=AD61h…=E8’z=E6Z=D5:.&#= 8221;Y*G™=A91`=B4=EFQ0~=AF|J5*=AE{w=BFŠ=A4=A4=EF=CEd=A5*= –Š—G”FV<=D0Rx=AC=AA™u=E2‹u=EF= =FAƒ=FC™=E3}%=F9o=B8=E1R=AE=D5=E9p=CB/‡=A7LZ=ADe=C5= =DE=AFW=A4n=C2"=DB=ED_=EDu”J=A1=A9O=CD=CCs=EC3#=D2=E1=F4= ‚ƒ=F0=B9=E7
‰
—=C8=A67=CC=F5=A3aq=F5=A3…H&=A0=CC=DD›=F2=B6M= }vMO=CA?#˜
=A6i™=D6q˜=E7V=E9Š=EDy…h3A=A4-=E2=C1“}=E4= 7;†=F8=B1(i=EB=C9=DC=F7z|=B3
’>Ow„^=E6=E3k
a=F7h8=BF=CE=A9=B0h=CBpF=F6=F7=D9•’•)žiY=A9=F6= U].=FB=A5e
>q\9&I=C7=B7=C9=AA=FB=C7=CAV”=EE&=E2Y=D1c-=B3=A7#}v=CA&#= 402;“[=D5v‚=BA=EC=EF$1=EBdg
=F2r=C18bv=E22“–=CD=CC
=B2=D4U=F3=C4=DC#=E7=BA=ECb=DB•=E4=FD
3<l_=F7=D8=E2=FDY=DE\=C0yc=B5‚t‰=C3=D46=F6=E2=D6‰= 225;$=CEK=CC=CF=A61x:=EC=E5’
x8=B9D=DD(Žˆ4Ÿs=DF=F4=D7iZ=CB=DE=E6"[=A3•=AE= 226;—6vv‘=B0=ACG=E7“=A9=E1%=E6x6=CF=A6Q;|=CB?0=AF#oo=CC= =D3jL=C9”=C9=DB=CD‹=D7=D3wl=D9y=D1
%=E1s=A4a=F7ITUW=A6-=EF=D9—L‡=E2=EC›=E9= =D2=CDo=E6_šA=B3b=FB=EC=A8=DF’2’=E3=F8
[,=EB–=C9=BCU=AA=A1—1=C5†I=FC—fj)™‰&#= 376;™=BD=B9z=C3•›=ED=D8=C9=CC=DC”=C7=DD=B6=A1= =E1q=EF=D5_=D9(=C8œ8’F=C4#v=D0Y%=AE=C0b*ˆoZl=BB)ˆi=D4= up=C7=D1›-L^=B2{†*=C0=C2=AE=CB=B9=BF‰ch=FCK=AB=CA= =FB=D9•=C9“=BA'nm=A2P)=A0=F8=DA_=A1
=A2=B7=DCˆ"X=D0Žš˜|=C7P^^™=C4=BE=E5-Bw#=CD= =D9žW}=FCž!dF‰=A4g=AA.=D48#=A3=C8R=DCAQ]=CEŸKo=BC=EB= =CF>O)%V˜fU=A8AJ'=BC=A3–=EE=B9=AA=E2=F7G=DFn.žƒ&#= 8221;=A8v=A9=CC‹P6=C7hy8=E0ŸR6=E1A=EDg=D6=B8=CCb=D7Ex˜2&#= 710;I"=CAs=CB=EE=F4=B2=D9=AE=D5=CDYQ=D3/e=FDH=B5chr=DD=C7œ= ;B=E8rYU.w=E3=CB=A3=D8=CB„=C5H=B1=D7=DC…U=E0̶= 0;r|=ED=AB=C89•=BA=A1=F6z8=EC=EBOOC=B7B=BD.R…<d=C2_D=CAn&#= 143;=B3\"O`j=AA=B9=CA=D2kF=C0S=BFmBK6‰=B5^˜=EA̶= 0; iV™=DA=AF=BB
=AAZ=B9=BF:35^=EEŒŸ^=D4=ADYs4l=F0f8RH=A5=D6J=C3=E7‹= a=E0=A2’š=B2ƒ=F7j`=EBT†=D6|pž&Ÿ= \0&=F4=EE=E1~)F=A9=EE=F8f=A7A=CC#=EA=F3O›=A3ˆ›= =FCuef=AAr=D4=EBI=A6zv=CD=C3N=F4=FE=D0=C1=F5=C9=CB\g=D7=AF=F3=BFGŒ`=AA= =E0=F9=DD=C51=DB=AF[9=D8D=AF‘=F6lo=B0œC=EE=B5=D2=C3“md\'= =AC=EA“z‹lJC=F38‚
r;=D8ƒ=F8*#?=DD’=A2Lƒ=DE=D8•cQr&=ADœ=FE=D0= 1=F3kš
'=FD=EE‰=AB‘q=E6=B2=A8=B3[<=AF'=F99=B9)$‡=D9‚&= quot;Nv=C9C]
=EB(=DF>=DF=B6?‡=C2=AB=D7=A6=B6=A3]E5'=E7#5&=AA,l=CF=CF=F1=A7= ƒž=A4=ECu=CE
)3\=B8=A6=D6oZd=EB=D7u
—
‘=F3=E8=DF&˜•=DA=F1TxY = ™8=B9=D0™‘=AF=B4!=DF=FC=A3q=D6(‰=D7:Ke=B3=A0=F4rM= 90=CB=A1=BAPDŽNs=AC=A0=D7=BCP=E3—!S››R=A9l=EC=E4X=EA= -^=ED…Y=AA=A6a‹=F7=C3oœ=EDV=B89=ACM=FDn?R= 11;6~dZ7=A2‹=B8q=CC/=FDˆ=C0pe™—
G=E0C”H=EDs=DFJ=DEˆ‘W)5™w=CE:‰r?ž
=C6=E3=F6=A9=C5E=EBo=F6=E8=CE=E8’=B5=D2s=E1Œ=DC=A7G=C7„=F1= [=DC=E3=F8=A6=B0=F52=DB2=EF=F4)=A8–r=CAL=A5‚;=E3=C0nA=A7̵= 7;2‰=A0i‰=A1=DB=B7q%=F0t=C1=F0“‚;8=DB=EA=AA=DEX=F1= X=AAŠ=E8=E7=D0=FCU‹=DA=E8r*.=D1–E=BCB]—ZN=F9‹= ;20‘=B9=C1=D8=C7=ED3Ž”w,=AE=C3F>=DA=B8&qu= ot;=DA;F=CE=FDcb›=AA=FA†N=C8ŸlZ=D5=AFZ= 7=DAŠ=F0=B0=A6=AB=A3=F9=EC^=ADZ=BA=DDA=EF=C9„t‚™&#= 8221;b
=DB=A9ˆR=BD=B2=A2G=B5=A6a=B4=D3=ECdW=C6=E1=B641–=F4hX=EE‡= ;p=AE=EE›=AFD=C1
=BB=B8S‡=BA=C9'ui=E2=A6=DB7-=FD`8V=B7eœ=EAV=E0=D0=B1=E8K= #wŸfIO=B4=D9I=F4=F9
=CE‚)=C27=BD=FAkn~/D=CFu—=F6Dh=A8T=AD-D|‡,Z!=E2=AE=A0&#= 141;$h=EA=C6=BC=D9„=F6_H=F2=C4=C8=C5H=C5=C4ƒ=DF[x=BF'=B0=DFbr=C5= (—=C5=AA=E5=E3{iŠ=E7”ƒ]M=DDo=AFy=E3=C8=E5=BDn=F1V=B8= =E8=C1%<=CA`JK›=D3q6Ž=EB=CFw=DA=EF=A7”ŒdŽ&#= 376;x=EF=CE=F0=B5‡VN=C7'3=EF2=A2=FCQS=EC=B6=A9Kˆ=E3=AA_k= Ž=A4=B6r|9;—=D8=CD=F0]=DDU=B7=B6=DBh8šŸ=B1&quo= t;=D0=BF=DE=EE=AD=EC=D4=B8=AA2w=C8=E9Ob=B49=CC“šž<(= 2;B‚=C7t=C1=DB=A1=F9=D8`=CE=D7)‡=C3P=A4[4=D8s=C3=DCw*=A2= #xB=EF=E1”=C9HA=C2=C7˜u]";=E4•=D4
=EB2=C2$l-V=D1=E1–=DB=E1=F6=F4!=B2IygŽ
ƒ=E9=F58…'=D0=DF=EE=CCQ=A4=F0=A5=A5‘`N=D6u#=A0=CB=C1=E5E= =EF;Fk=A5=C3=CFš‹%)=B7=F1x=F3=A4…=AA=CB=EFŽ=A3Ž= ;=AF=B62=AA=FE=E0aGNV<W=E6=FAŸK=E5=E08W-=BE=D6=E4=B4h=C5=F5sF= 4;=E8=C5ŸkN:l*=F4!=E3=D2=B2ŠDh=BC=C9’=C8=BB"=B4=EA1&= #157;P=EB=C7=D0'6‰=B9=C7,=D8bG/^=BCŠe=C3=B6db=C4=AEjY5t=DAt= 221;†=AD…=BD=B4–‘-F = =FEl…Šˆ3ff=DCSL=EF,d™=D15=CE=BFv=E6“= 41;=F19~=F4Q=E1=C1=CB=EE=F7=A4zc"=D6=DB[8=CB=BD˜=CE˜= 3Qh=E2=E6&=D3<^=E9Ž‹=D5O=E9=A4=CF=F08=F4=D2Co=B2s= =DE
=F7=EF: = =FB/=C1=CAO=E76P=AC[=F0=D0=B8=BD=F9T=DB=DC=D9=BE4=BCƒ=D9|uR= 16;=F0…8WO|Y=B9=FEQ,=BDEƒkO—=F7}=F1a
=C6,=C3=BF=F2‡IQ = `=E9=BD‰=BB=DC=EB=AD‹=C8O$=D9qt=B9T=ABn*^f=BFCŽ‰?;= =B575“1=EE=CA|=C5M‹{y=B0Ÿn=AE1=AE…=AE=F1=E7r= #=DD=BC=C2_=D4=F6=EC=CDQ=F36
=E4„d=DA=AE=D2=CE‡LT'BT=C5=F5=E0=D3=D7=FA’=EE>= =C3†|žœ<=A9<
ƒ”=F4Š‡%ž=E1=BF=A6/

------_=_NextPart_003_01C6AC20.38E37700-- ------_=_NextPart_002_01C6AC20.38E37700 Content-Type: text/html; name="warning.htm" Content-Transfer-Encoding: base64 Content-Description: warning.htm Content-Disposition: attachment; filename="warning.htm" PGh0bWw+PGhlYWQ+PG1ldGEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWwiPjxtZXRhIEhUVFAtRVFVSVY9ImNoYXJzZXQiIGNvbnRlbnQ9InV0Zi04Ij4gPHRpdGxl PkJMT0NLRUQgRklMRSBBTEVSVDwvdGl0bGU+PC9oZWFkPgk8Ym9keT4gPGgxPjxmb250IGNvbG9y PSIjRkYwMDAwIj5CTE9DS0VEIEZJTEUgQUxFUlQ8L2ZvbnQ+PC9oMT4gPHA+QSBmaWxlIGhhcyBi ZWVuIGJsb2NrZWQgZHVlIHRvIHRoZSAnQWxsIENvbXByZXNzZWQgRmlsZXMnIHJ1bGUuICBTZWUg eW91ciBzeXN0ZW0gYWRtaW5pc3RyYXRvciBmb3IgZnVydGhlciBpbmZvcm1hdGlvbi4gPC9wPiAg PHA+Q29udGV4dDogJ3RleHQuemlwJzxCUj4gRGlzYWxsb3dlZCBkdWUgdG8gZm9ybWF0PC9wPiAg IDxwPkNvcHlyaWdodCAmY29weTsgMTk5My0yMDAzLCBOZXR3b3JrcyBBc3NvY2lhdGVzIFRlY2hu b2xvZ3ksIEluYy48YnI+CUFsbCBSaWdodHMgUmVzZXJ2ZWQuPGJyPiA8YSBocmVmPSJodHRwOi8v d3d3Lm1jYWZlZXNlY3VyaXR5LmNvbSI+aHR0cDovL3d3dy5tY2FmZWVzZWN1cml0eS5jb208L2E+ PC9wPiA8L2JvZHk+PC9odG1sPg== ------_=_NextPart_002_01C6AC20.38E37700-- ------_=_NextPart_001_01C6AC20.397C0D80-- From ospf-bounces@ietf.org Fri Jul 21 23:52:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G48Wr-00084l-9U; Fri, 21 Jul 2006 23:51:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G48Wp-00084g-L6 for ospf@ietf.org; Fri, 21 Jul 2006 23:51:47 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G48Wn-0001jj-8G for ospf@ietf.org; Fri, 21 Jul 2006 23:51:47 -0400 Received: by ug-out-1314.google.com with SMTP id m2so1621676uge for ; Fri, 21 Jul 2006 20:51:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=IKVp/6U83YOwQ9NaR34pIC3p+smQZ0wqseUnTa9NZDZ13+UBB1Hqe5SwtrlFMTql5popGB9czHpUfTJQcg/mjbRCZWw1yNej11K1XLCv5fRdJw5ItZpYp0BTYbh5HXZW1P1XZquF+5t3VYT67i+NZShLMwOReY1TQrQ8wszVV6c= Received: by 10.82.109.13 with SMTP id h13mr23456buc; Fri, 21 Jul 2006 20:51:44 -0700 (PDT) Received: by 10.82.138.20 with HTTP; Fri, 21 Jul 2006 20:51:44 -0700 (PDT) Message-ID: <6e6ce9380607212051j5dbb9362q174cbf425a8b566e@mail.gmail.com> Date: Sat, 22 Jul 2006 09:21:44 +0530 From: "Phil Cowburn" To: vishwas.ietf@gmail.com, rohitgupta416@indiatimes.com Subject: Re: [OSPF] OSPF HMAC Cryptographic Authentication MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 1.9 (+) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi, In Section 5 you've mentioned the block sizes without units. I presume they are in bytes, but it would be good if you explicitly state this. I think it might be good to refer to RFC 3174 somewhere. Also AFAIK RFC 2104 has the C code to compute HMAC when the text input is fixed in length. SHA algorithms are defined in terms of variable number of bits. There may thus be some modifications required in HMAC C code for SHA. You may want to capture this somewhere. Otherwise the draft looks in good shape and has been long due. Its time we all moved away from using MD5 to something thats more stronger. Is there a similar work for TCP based protocols like LDP and BGP? Or other routing protocols like RIP (naah .. am not sure if we really need something like this for RIP) and i-ISIS (for IP)? Phil ----- Original Message ---- From: Vishwas Manral To: Rohit Gupta Cc: ospf@ietf.org Sent: Monday, 17 July, 2006 9:54:59 PM Subject: Re: [OSPF] OSPF HMAC Cryptographic Authentication Hi Rohit, The authors of the OSPF RFC have done it very intelligently. By allowing the KeyId field which is Opaque, the value of the KeyId itself defines a seperate security association(channel). IT is the understanding between the two ends, that a particular KeyId identifies a key as well as the cryptographic algorithm used. That is the reason we do not need any new fields. Thanks, Vishwas On 7/17/06, Rohit Gupta wrote: > Hi, > > I could not see any new field added in the OSPF message. How do you then make out whether the OSPF router is using HMAC-SHA1 algorithm or the MD5 (the normal OSPF authentication algorithm)? > > Thanks, > Rohit > > ----- Original Message ---- > From: Manav Bhatia > To: ospf@ietf.org > Sent: Saturday, 15 July, 2006 5:06:45 AM > Subject: [OSPF] OSPF HMAC Cryptographic Authentication > > > Hi, > > We have just posted a draft that describes a mechanism for authenticating OSPF packets by making use of HMAC algorithm in conjunction with the SHA family of cryptographic hash functions. It would be great if the WG can provide some feedback and comments on the same. > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > Thanks, > Manav > > > ----- Forwarded Message ---- > > From: Internet-Drafts@ietf.org > > To: i-d-announce@ietf.org > > Sent: Saturday, July 15, 2006 1:20:01 AM > > Subject: I-D ACTION:draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : OSPF HMAC Cryptographic Authentication > > Author(s) : M. Bhatia, et al. > > Filename : draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > Pages : 10 > > Date : 2006-6-14 > > > > This document describes a mechanism for authenticating OSPF packets > > by making use of the HMAC algorithm in conjunction with the SHA > > family of cryptographic hash functions. Because of the way the hash > > functions are used in HMAC construction, the collision attacks > > currently known against SHA-1 do not apply. > > > > This will be done in addition to the already documented > > authentication schemes described in the base specification. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > > message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > > Sign Up for your FREE eWallet at www.wallet365.com > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sat Jul 22 01:01:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G49bm-0004BL-I1; Sat, 22 Jul 2006 01:00:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G49bl-000492-5q for ospf@ietf.org; Sat, 22 Jul 2006 01:00:57 -0400 Received: from wx-out-0102.google.com ([66.249.82.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G49bj-0004Xv-Qg for ospf@ietf.org; Sat, 22 Jul 2006 01:00:57 -0400 Received: by wx-out-0102.google.com with SMTP id s16so555661wxc for ; Fri, 21 Jul 2006 22:00:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mjM14jcstnBmZXOZ5BO3zg5CHU3f5yVgZ0VifPTuDVD5QIV+5A23IN+9w0S5m0wAUxxkQ2wxjPhmKI4+4sQpLu4bQmv9qgnT2wdgEG5Q8bRz0R0XlOnCNThf0iSHRxj4SLHbQJUaBPbyJfiv9ZwRLFlIPtFT85+6LKX/mmcXWAE= Received: by 10.70.74.1 with SMTP id w1mr2159118wxa; Fri, 21 Jul 2006 22:00:55 -0700 (PDT) Received: by 10.70.7.7 with HTTP; Fri, 21 Jul 2006 22:00:55 -0700 (PDT) Message-ID: <77ead0ec0607212200v75c5cc91nd9e1ad936f5f9333@mail.gmail.com> Date: Sat, 22 Jul 2006 10:30:55 +0530 From: "Vishwas Manral" To: "Phil Cowburn" Subject: Re: [OSPF] OSPF HMAC Cryptographic Authentication In-Reply-To: <6e6ce9380607212051j5dbb9362q174cbf425a8b566e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6e6ce9380607212051j5dbb9362q174cbf425a8b566e@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Phil, Thanks a lot for the comments as well as for supporting our effort. Yes, we will note the block size units are bytes. Also we will refer to RFC3174 for SHA-1 related references. We will also note the modifications in C code required for the same. The same effort is underway in IS-IS and RIP too. For IS-IS the draft is located at: http://www.ietf.org/internet-drafts/draft-ietf-isis-hmac-sha-00.txt which has been approved by the working group. Once we are done with the changes for we can look at changes required for TCP MD5 signature options required for BGP if any. Thanks again, Vishwas On 7/22/06, Phil Cowburn wrote: > Hi, > > In Section 5 you've mentioned the block sizes without units. I presume > they are in bytes, but it would be good if you explicitly state this. > > I think it might be good to refer to RFC 3174 somewhere. > > Also AFAIK RFC 2104 has the C code to compute HMAC when the text input > is fixed in length. SHA algorithms are defined in terms of variable > number of bits. There may thus be some modifications required in HMAC > C code for SHA. You may want to capture this somewhere. > > Otherwise the draft looks in good shape and has been long due. Its > time we all moved away from using MD5 to something thats more > stronger. > > Is there a similar work for TCP based protocols like LDP and BGP? Or > other routing protocols like RIP (naah .. am not sure if we really > need something like this for RIP) and i-ISIS (for IP)? > > Phil > > ----- Original Message ---- > From: Vishwas Manral > To: Rohit Gupta > Cc: ospf@ietf.org > Sent: Monday, 17 July, 2006 9:54:59 PM > Subject: Re: [OSPF] OSPF HMAC Cryptographic Authentication > > > Hi Rohit, > > The authors of the OSPF RFC have done it very intelligently. By > allowing the KeyId field which is Opaque, the value of the KeyId > itself defines a seperate security association(channel). IT is the > understanding between the two ends, that a particular KeyId identifies > a key as well as the cryptographic algorithm used. > > That is the reason we do not need any new fields. > > Thanks, > Vishwas > > On 7/17/06, Rohit Gupta wrote: > > Hi, > > > > I could not see any new field added in the OSPF message. How do you then make out whether the OSPF router is using HMAC-SHA1 algorithm or the MD5 (the normal OSPF authentication algorithm)? > > > > Thanks, > > Rohit > > > > ----- Original Message ---- > > From: Manav Bhatia > > To: ospf@ietf.org > > Sent: Saturday, 15 July, 2006 5:06:45 AM > > Subject: [OSPF] OSPF HMAC Cryptographic Authentication > > > > > > Hi, > > > > We have just posted a draft that describes a mechanism for authenticating OSPF packets by making use of HMAC algorithm in conjunction with the SHA family of cryptographic hash functions. It would be great if the WG can provide some feedback and comments on the same. > > > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > > > Thanks, > > Manav > > > > > ----- Forwarded Message ---- > > > From: Internet-Drafts@ietf.org > > > To: i-d-announce@ietf.org > > > Sent: Saturday, July 15, 2006 1:20:01 AM > > > Subject: I-D ACTION:draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > > > > Title : OSPF HMAC Cryptographic Authentication > > > Author(s) : M. Bhatia, et al. > > > Filename : draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > > Pages : 10 > > > Date : 2006-6-14 > > > > > > This document describes a mechanism for authenticating OSPF packets > > > by making use of the HMAC algorithm in conjunction with the SHA > > > family of cryptographic hash functions. Because of the way the hash > > > functions are used in HMAC construction, the collision attacks > > > currently known against SHA-1 do not apply. > > > > > > This will be done in addition to the already documented > > > authentication schemes described in the base specification. > > > > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > > > > > To remove yourself from the I-D Announcement list, send a message to > > > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > > > message. > > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > > > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf > > > > Sign Up for your FREE eWallet at www.wallet365.com > > > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sun Jul 23 01:34:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4WbL-0006hR-1h; Sun, 23 Jul 2006 01:34:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4WbJ-0006hK-Qr for ospf@ietf.org; Sun, 23 Jul 2006 01:34:01 -0400 Received: from wx-out-0102.google.com ([66.249.82.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4WbH-0007ud-HY for ospf@ietf.org; Sun, 23 Jul 2006 01:34:01 -0400 Received: by wx-out-0102.google.com with SMTP id s16so645351wxc for ; Sat, 22 Jul 2006 22:33:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KENDkdMbiZ3dsxrWDNon5OLJlA+21KmbNq8OLaUBqC3UR9+iLYbmz7NUAiE3bVivu2Q+pMUKIjL8fGJcoCgjUYm0e5Eh4sL3L7dmkZWY60Sg4wu4F2aeLolOrXjF2NbDxybs+rMrMD7iXH5ZoO7bM5/JAP57B06eGjLp51cBNQM= Received: by 10.70.19.7 with SMTP id 7mr3291130wxs; Sat, 22 Jul 2006 22:33:59 -0700 (PDT) Received: by 10.70.8.18 with HTTP; Sat, 22 Jul 2006 22:33:59 -0700 (PDT) Message-ID: <77ead0ec0607222233n189638e9lb3a8e60897f5f26a@mail.gmail.com> Date: Sun, 23 Jul 2006 11:03:59 +0530 From: "Vishwas Manral" To: "Phil Cowburn" Subject: Re: [OSPF] OSPF HMAC Cryptographic Authentication In-Reply-To: <6e6ce9380607221100m3bb35c7fs6c929a1e6476b64@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6e6ce9380607212051j5dbb9362q174cbf425a8b566e@mail.gmail.com> <77ead0ec0607212200v75c5cc91nd9e1ad936f5f9333@mail.gmail.com> <6e6ce9380607221100m3bb35c7fs6c929a1e6476b64@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Phil, The reason I believe this document is still not a working group document is because we posted this only very recently, though we have worked on the IS-IS effort for quite sometime now. Yes, we do intend to bring this up as a working group document soon. We will incorporate the relevent comments in the IS-IS draft too. Thanks, Vishwas On 7/22/06, Phil Cowburn wrote: > Vishwas: > > > The same effort is underway in IS-IS and RIP too. For IS-IS the draft > > is located at: > > http://www.ietf.org/internet-drafts/draft-ietf-isis-hmac-sha-00.txt > > which has been approved by the working group. > > I have btw similar comments for your i-ISIS draft. > > Is there a reason why we have i-ISIS draft as the WG document and OSPF > as still an individual submission when the contents are so very > identical? > > I trust that it is known that MD5 is weak and can be easily broken, > and the community needs to move to a stronger authentication algorithm > - something like SHA-1, SHA-256 for securing the OSPF packets. I find > this all the more essential for OSPF when compared to i-ISIS as the > former runs on top of IP while the latter runs directly over L2 (and > thus packets cannot be launched multiple hops away). > > Phil > > > > > Once we are done with the changes for we can look at changes required > > for TCP MD5 signature options required for BGP if any. > > > > Thanks again, > > Vishwas > > > > On 7/22/06, Phil Cowburn wrote: > > > Hi, > > > > > > In Section 5 you've mentioned the block sizes without units. I presume > > > they are in bytes, but it would be good if you explicitly state this. > > > > > > I think it might be good to refer to RFC 3174 somewhere. > > > > > > Also AFAIK RFC 2104 has the C code to compute HMAC when the text input > > > is fixed in length. SHA algorithms are defined in terms of variable > > > number of bits. There may thus be some modifications required in HMAC > > > C code for SHA. You may want to capture this somewhere. > > > > > > Otherwise the draft looks in good shape and has been long due. Its > > > time we all moved away from using MD5 to something thats more > > > stronger. > > > > > > Is there a similar work for TCP based protocols like LDP and BGP? Or > > > other routing protocols like RIP (naah .. am not sure if we really > > > need something like this for RIP) and i-ISIS (for IP)? > > > > > > Phil > > > > > > ----- Original Message ---- > > > From: Vishwas Manral > > > To: Rohit Gupta > > > Cc: ospf@ietf.org > > > Sent: Monday, 17 July, 2006 9:54:59 PM > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jul 25 10:34:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5NzZ-0008LW-TQ; Tue, 25 Jul 2006 10:34:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5NzZ-0008LR-6G for ospf@ietf.org; Tue, 25 Jul 2006 10:34:37 -0400 Received: from web25411.mail.ukl.yahoo.com ([217.146.176.229]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G5NzW-0003LX-Aj for ospf@ietf.org; Tue, 25 Jul 2006 10:34:37 -0400 Received: (qmail 18779 invoked by uid 60001); 25 Jul 2006 14:34:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IUjT9/ICXuhowG5/bdPVypxSSSHWcXDAf+NmVDN83smEgMhMLNnTEb5zs//Gnrbrk0Gs9Ucmp7W4/VFmb5RYMnN6rhdGMtKhvR4L9OYrIURFfD9cavITUd56I+gQBZxIzEzOGDsULZC+557XUFU8qPlzfD9A8XE2h25ArOXWGfs= ; Message-ID: <20060725143433.18777.qmail@web25411.mail.ukl.yahoo.com> Received: from [202.144.106.189] by web25411.mail.ukl.yahoo.com via HTTP; Tue, 25 Jul 2006 14:34:33 GMT Date: Tue, 25 Jul 2006 14:34:33 +0000 (GMT) From: Manav Bhatia Subject: Re: [OSPF] OSPF HMAC Cryptographic Authentication To: Phil Cowburn , vishwas.ietf@gmail.com In-Reply-To: <6e6ce9380607212051j5dbb9362q174cbf425a8b566e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.9 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Manav Bhatia List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Phil, RFC 2104 has the C code that allows the text being hashed to be of an arbitary length; the only restriction imposed is that the length must be a multiple of 8 bits (octet). If you look at draft-eastlake-sha2-02.txt then it allows the text to be hashed to contain an arbitary number of bits. Similarly, the code in RFC 3174 is a "byte-level"implementation. The same draft allows the text to be of an arbitary length. It adds to the RFC 3174 API an additional call, SHA1FinalBits(), that lets the remaining bits to be added to the hash. I would prefer to refer to this draft as it (i) has full support for all the SHA2 algorithms and (ii) adds HMAC support for both SHA1 and SHA2 algorithms. Thanks, Manav ----- Original Message ---- From: Phil Cowburn To: vishwas.ietf@gmail.com; rohitgupta416@indiatimes.com Cc: ospf@ietf.org Sent: Saturday, 22 July, 2006 9:21:44 AM Subject: Re: [OSPF] OSPF HMAC Cryptographic Authentication Hi, In Section 5 you've mentioned the block sizes without units. I presume they are in bytes, but it would be good if you explicitly state this. I think it might be good to refer to RFC 3174 somewhere. Also AFAIK RFC 2104 has the C code to compute HMAC when the text input is fixed in length. SHA algorithms are defined in terms of variable number of bits. There may thus be some modifications required in HMAC C code for SHA. You may want to capture this somewhere. Otherwise the draft looks in good shape and has been long due. Its time we all moved away from using MD5 to something thats more stronger. Is there a similar work for TCP based protocols like LDP and BGP? Or other routing protocols like RIP (naah .. am not sure if we really need something like this for RIP) and i-ISIS (for IP)? Phil ----- Original Message ---- From: Vishwas Manral To: Rohit Gupta Cc: ospf@ietf.org Sent: Monday, 17 July, 2006 9:54:59 PM Subject: Re: [OSPF] OSPF HMAC Cryptographic Authentication Hi Rohit, The authors of the OSPF RFC have done it very intelligently. By allowing the KeyId field which is Opaque, the value of the KeyId itself defines a seperate security association(channel). IT is the understanding between the two ends, that a particular KeyId identifies a key as well as the cryptographic algorithm used. That is the reason we do not need any new fields. Thanks, Vishwas On 7/17/06, Rohit Gupta wrote: > Hi, > > I could not see any new field added in the OSPF message. How do you then make out whether the OSPF router is using HMAC-SHA1 algorithm or the MD5 (the normal OSPF authentication algorithm)? > > Thanks, > Rohit > > ----- Original Message ---- > From: Manav Bhatia > To: ospf@ietf.org > Sent: Saturday, 15 July, 2006 5:06:45 AM > Subject: [OSPF] OSPF HMAC Cryptographic Authentication > > > Hi, > > We have just posted a draft that describes a mechanism for authenticating OSPF packets by making use of HMAC algorithm in conjunction with the SHA family of cryptographic hash functions. It would be great if the WG can provide some feedback and comments on the same. > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > Thanks, > Manav > > > ----- Forwarded Message ---- > > From: Internet-Drafts@ietf.org > > To: i-d-announce@ietf.org > > Sent: Saturday, July 15, 2006 1:20:01 AM > > Subject: I-D ACTION:draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : OSPF HMAC Cryptographic Authentication > > Author(s) : M. Bhatia, et al. > > Filename : draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > Pages : 10 > > Date : 2006-6-14 > > > > This document describes a mechanism for authenticating OSPF packets > > by making use of the HMAC algorithm in conjunction with the SHA > > family of cryptographic hash functions. Because of the way the hash > > functions are used in HMAC construction, the collision attacks > > currently known against SHA-1 do not apply. > > > > This will be done in addition to the already documented > > authentication schemes described in the base specification. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha-00.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > > message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > > Sign Up for your FREE eWallet at www.wallet365.com > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Jul 25 19:49:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Wef-0005Kn-Ae; Tue, 25 Jul 2006 19:49:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Wee-0005Ki-4S for ospf@ietf.org; Tue, 25 Jul 2006 19:49:36 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Wec-000705-Rg for ospf@ietf.org; Tue, 25 Jul 2006 19:49:36 -0400 Received: by ug-out-1314.google.com with SMTP id m2so3091919uge for ; Tue, 25 Jul 2006 16:49:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HzXnRccP8zWwoFPdJ4DnBLjiiYGRPR7ouvmYGLPJzbHVg8DjkzlDWYMT3oSBM7cCFb2H9P5FhvqZRSBTTfru3+P/faU/WQDGXUysiFuKuB2FXjgL5olxjpie/iv7Nm/GC+arnjbM1paUCrskPBwme2dxzJf8OiOgZggNDUwZr1E= Received: by 10.82.109.19 with SMTP id h19mr185091buc; Tue, 25 Jul 2006 16:49:34 -0700 (PDT) Received: by 10.82.138.20 with HTTP; Tue, 25 Jul 2006 16:49:33 -0700 (PDT) Message-ID: <6e6ce9380607251649n27bfa242r45f6ee06211e6e1b@mail.gmail.com> Date: Wed, 26 Jul 2006 05:19:33 +0530 From: "Phil Cowburn" To: "Manav Bhatia" Subject: Re: [OSPF] OSPF HMAC Cryptographic Authentication In-Reply-To: <20060725143433.18777.qmail@web25411.mail.ukl.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6e6ce9380607212051j5dbb9362q174cbf425a8b566e@mail.gmail.com> <20060725143433.18777.qmail@web25411.mail.ukl.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Manav: > => RFC 2104 has the C code that allows the text being hashed to be of an arbitary =length; the only restriction imposed is that the length must be a multiple of 8 bits =(octet). If you look at draft-eastlake-sha2-02.txt then it allows the text to be =hashed to contain an arbitary number of bits. Its been a long time since i read 2104 and i remembered that there used to be some limitation. I was under the impression that it only worked for a fixed length of input text T. Clearly, I was mistaken. => => Similarly, the code in RFC 3174 is a "byte-level"implementation. The same draft =allows the text to be of an arbitary length. It adds to the RFC 3174 API an =additional call, => SHA1FinalBits(), that lets the remaining bits to be added to the hash. => => I would prefer to refer to this draft as it (i) has full support for all the SHA2 =algorithms and (ii) adds HMAC support for both SHA1 and SHA2 algorithms. I am okay as long as you reference some document for HMAC and SHA algorithms. Phil => => Thanks, => Manav => _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From MAILER-DAEMON Wed Jul 26 01:46:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5cEB-0003EN-Gk for ospf-archive@lists.ietf.org; Wed, 26 Jul 2006 01:46:39 -0400 Received: from 67.185.221.202.bf.2iij.net ([202.221.185.67] helo=www) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5cE7-0008T5-TS for ospf-archive@lists.ietf.org; Wed, 26 Jul 2006 01:46:39 -0400 Message-Id: <200607260546.OAA05502@mail.green.go.jp> Date: Wed, 26 Jul 2006 15:02:26 +0900 From: virus-sv@green.go.jp To: ospf-archive@lists.ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-3d8cca53-cb6d-4855-a771-e6e49b6edbe5" Subject: Mail delivery failure X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 ------=_NextPartTM-000-3d8cca53-cb6d-4855-a771-e6e49b6edbe5 Content-type: text/plain ****** Message from InterScan E-Mail VirusWall NT ****** Sent >>> RCPT TO: Received <<< 550 ... User unknown Could not deliver mail to this user. marumarumaru@green.go.jp ***************** End of message *************** ------=_NextPartTM-000-3d8cca53-cb6d-4855-a771-e6e49b6edbe5 Content-type: message/rfc822 From: ospf-archive@lists.ietf.org Message-Id: <200607260553.OAA18564@www> To: marumarumaru@green.go.jp Subject: Returned mail: see transcript for details Date: Wed, 26 Jul 2006 14:52:05 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_1489F09D.6AB5952D" This is a multi-part message in MIME format. ------=_NextPart_000_0014_1489F09D.6AB5952D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear user of green.go.jp, mail server administrator of green.go.jp would like to inform you that: Your account was used to send a huge amount of spam messages during this week. Probably, your computer was infected by a recent virus and now contains a trojaned proxy server. We recommend you to follow our instruction in order to keep your computer safe. Best regards, green.go.jp user support team. ------=_NextPart_000_0014_1489F09D.6AB5952D Content-Type: text/plain; name="InterScan_SafeStamp.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="InterScan_SafeStamp.txt" KioqKioqIE1lc3NhZ2UgZnJvbSBJbnRlclNjYW4gRS1NYWlsIFZpcnVzV2Fs bCBOVCAqKioqKioNCg0K KiogjHiNkIFJIJNZlXSDdINAg0ODiyBkb2N1bWVudC56aXAggsmCzY6fgsyD RYNDg4uDWIKqityC3ILqgsSCooLcgreBRg0KDQogICAgIFdPUk1fTVlET09N LkdFTiB2aXJ1cyBpbiBjb21wcmVzc2VkIGZpbGUgZG9jdW1lbnQuc2NyDQoN CiAgIEF0dGVtcHRlZCB0byBjbGVhbiB0aGUgZmlsZSBidXQgaXQgaXMgbm90 IGNsZWFuYWJsZS4NCiAgIEl0IGhhcyBiZWVuIGRlbGV0ZWQuIA0K KioqKioqKioqKioqKioqKiogICAgIEVuZCBvZiBtZXNzYWdlICAgICAqKioq KioqKioqKioqKioNCg0K ------=_NextPart_000_0014_1489F09D.6AB5952D-- ------=_NextPartTM-000-3d8cca53-cb6d-4855-a771-e6e49b6edbe5-- From MAILER-DAEMON Thu Jul 27 15:25:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6BUD-0004N0-KY for ospf-archive@lists.ietf.org; Thu, 27 Jul 2006 15:25:33 -0400 Received: from mx1.fadata.bg ([213.240.249.69] helo=zeus.fadata.bg) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6BUC-00077P-4V for ospf-archive@lists.ietf.org; Thu, 27 Jul 2006 15:25:33 -0400 Received: from localhost (zeus [127.0.0.1]) by zeus.fadata.bg (Postfix) with ESMTP id B9FBB15168 for ; Thu, 27 Jul 2006 22:25:30 +0300 (EEST) MIME-Version: 1.0 Subject: VIRUS (Worm.Mydoom.M) IN MAIL FROM YOU In-Reply-To: <20060727192517.B7BCD1513D@zeus.fadata.bg> Message-Id: Content-Type: multipart/report; report-type=delivery-status; boundary="----------=_1154028330-21781-1" From: Content-Filter To: Date: Thu, 27 Jul 2006 22:25:30 +0300 (EEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b This is a multi-part message in MIME format... ------------=_1154028330-21781-1 Content-Type: text/plain; charset="Windows-1251" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable VIRUS ALERT =C2=CD=C8=CC=C0=CD=C8=C5: =C2=E0=F8=E8=FF=F2 e-mail =CD=C5 =C5 =E4=EE=F1=F2= =E0=E2=E5=ED! =D1=EF=F0=FF=ED =E5 =EE=F2 mail.fadata.bg (HAS BEEN STOPPED BY mail.fadata.= bg) Our content checker found virus: Worm.Mydoom.M in email presumably from you (), to the follow= ing recipient: -> velco@fadata.bg Please check your system for viruses, or ask your system administrator to do so. Delivery of the email was stopped! For your reference, here are headers from your email: ------------------------- BEGIN HEADERS ----------------------------- Return-Path: Received: from lists.ietf.org (208.Red-81-45-245.staticIP.rima-tde.net [81.= 45.245.208]) by zeus.fadata.bg (Postfix) with ESMTP id B7BCD1513D for ; Thu, 27 Jul 2006 22:25:17 +0300 (EEST) From: ospf-archive@lists.ietf.org To: velco@fadata.bg Subject: Returned mail: Data format error Date: Thu, 27 Jul 2006 21:34:24 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=3D"----=3D_NextPart_000_0013_6C81C0F2.622738B1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20060727192517.B7BCD1513D@zeus.fadata.bg> -------------------------- END HEADERS ------------------------------ ------------=_1154028330-21781-1 Content-Type: message/delivery-status Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Description: Delivery error report Reporting-MTA: dns; zeus Received-From-MTA: smtp; zeus.fadata.bg ([127.0.0.1]) Arrival-Date: Thu, 27 Jul 2006 22:25:29 +0300 (EEST) Final-Recipient: rfc822; velco@fadata.bg Action: failed Status: 5.7.1 Diagnostic-Code: smtp; 550 5.7.1 Message content rejected, id=21781-01-2 - VIRUS: Worm.Mydoom.M Last-Attempt-Date: Thu, 27 Jul 2006 22:25:30 +0300 (EEST) ------------=_1154028330-21781-1 Content-Type: text/rfc822-headers Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Description: Undelivered-message headers Received: from lists.ietf.org (208.Red-81-45-245.staticIP.rima-tde.net [81.45.245.208]) by zeus.fadata.bg (Postfix) with ESMTP id B7BCD1513D for ; Thu, 27 Jul 2006 22:25:17 +0300 (EEST) From: ospf-archive@lists.ietf.org To: velco@fadata.bg Subject: Returned mail: Data format error Date: Thu, 27 Jul 2006 21:34:24 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_6C81C0F2.622738B1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20060727192517.B7BCD1513D@zeus.fadata.bg> ------------=_1154028330-21781-1-- From ospf-bounces@ietf.org Fri Jul 28 10:22:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6TE3-0001i0-Ss; Fri, 28 Jul 2006 10:22:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6TE1-0001hj-TZ for ospf@ietf.org; Fri, 28 Jul 2006 10:22:01 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6TE0-0003Pr-I6 for ospf@ietf.org; Fri, 28 Jul 2006 10:22:01 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 28 Jul 2006 07:21:59 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,191,1151910000"; d="txt'?scan'208"; a="33712374:sNHT29412088" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6SELxBO030673 for ; Fri, 28 Jul 2006 10:21:59 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6SELxdU000915 for ; Fri, 28 Jul 2006 10:21:59 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 10:21:59 -0400 Received: from [10.82.240.235] ([10.82.240.235]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 10:21:59 -0400 Message-ID: <44CA1D86.5030406@cisco.com> Date: Fri, 28 Jul 2006 10:21:58 -0400 From: Acee Lindem User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: OSPF List Content-Type: multipart/mixed; boundary="------------050508090305030102010409" X-OriginalArrivalTime: 28 Jul 2006 14:21:59.0658 (UTC) FILETIME=[3026C4A0:01C6B251] DKIM-Signature: a=rsa-sha1; q=dns; l=3690; t=1154096519; x=1154960519; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:IETF=2066=20OSPF=20WG=20Meeting=20Minutes=20 |To:OSPF=20List=20; X=v=3Dcisco.com=3B=20h=3DTw1xDTMhFuaDOjM5lNFbjCEX3bc=3D; b=r0AiiOTvjiwMDdk46vA5MgffDRm9RX0rmY68q3eb8tNp5GvhhfY1rMlLVTOWQqnl4sZ/NPWy XJ2QdqITIh0en7vol5/F6uVRIOV3yz0nyyFoscJqfkpDGZSNdLzIXOJF; Authentication-Results: rtp-dkim-2.cisco.com; header.From=acee@cisco.com; dkim=pass ( 44 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: [OSPF] IETF 66 OSPF WG Meeting Minutes X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --------------050508090305030102010409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've attached the meeting minutes.Thanks to my colleague Michael Barnes for transcribing them. Please unicast corrections to me. However, note that I'll be out on vacation for the next week. Thanks, Acee --------------050508090305030102010409 Content-Type: text/plain; name="IETF66-ospf-wg-minutes.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="IETF66-ospf-wg-minutes.txt" OSPF WG Meeting - Montreal - July 12, 2006 13:02 Review agenda 13:05 Review working group progress * Bill Fenner comment: area is planning to eliminate requirement for multiple implementations * Look at going forward with OSPFv3 TE extensions 13:19 OSPF Link-Local Signaling (LLS) Presented by Acee Lindem * MANET proposals all use LLS * Other possible uses for it * Make it a working document? No opposition. 13:24 OSPF Database Exchange Summary List Optimization draft-ogier-ospf-dbex-opt-00.txt Presented by Acee * In best case, can reduce DBD traffic by 50% * How many agree this should be an informational RFC? Many agree, one disagreement * Sujay: question: maybe there could be incompatability * Acee: Is fully backwardly compatible 13:31 OSPFv2 MIB for Multi Topology Routing * Bill Fenner: When using for MT case, might want to put ID first in the index so that can walk the table for a given topology rather than having a given topology's information mixed with that of other topoligies. More important to get information for a given topology than a given IP address. * Acee: Why is it needed for top level to indicate MTR cap? Is this okay? * Bill: May not be required, but there is no harm. 13:43 Optimization for graceful restart draft-holla-ospf-update-graceful-restart Sujay Gupta * Acee: This presentation doesn't exactly match the draft. It includes mailing list comments. * Sujay: Correct * Acee: So, not exactly sure what is being proposed. * Acee: Do we see a requirement for something between strict and non-strict LSA checking * Acee: Don't think want the helper to determine topology change LSAs. Can't be certain that it will not change routing. * Acee: Vishwas idea would work * Sujay: Want the working group to talk about what way to do this * ?: I think it's a basic point. Fundamental idea was that no topology change. Want to ask if want to revisit this * Sujay: Doesn't change much of the original implementation. Keep strict checking as by default. Want to exit GR as soon as possible. * Acee: Contrasted with existing mechanism: just flood an LSA that is inconsistent and the restarting router would recognize and exit 14:02 AS-scope Opaque LSA Validation Igor Bryskin * Dimitri: Question: Application which is using the opaque LSA may have way to detect. Is this mandated for those applications? Application may not want this. * Igor: Suggest to make use of this for any application * Alex Zinin: Basic OSPF transport capability can't assume any appliation capabilities. Should be generic. From OSPF perspective, should have generic behavior. Not mandating applications to do anything, but from OSPF perspective this is how it should be done. * Lou Berger: Draft is about plugging a hole in RFC2370 * Acee: Agree with authors. Could this be put in 2370bis? * Acee: Does anyone think we should not do this? No objections * Lou Berger: Put this in 2370bis so have one document 14:15 OSPF Protocol Evolution WG Re-Charter Acee --------------050508090305030102010409 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://www1.ietf.org/mailman/listinfo/ospf --------------050508090305030102010409-- From ospf-bounces@ietf.org Fri Jul 28 20:25:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ce6-0002jg-UY; Fri, 28 Jul 2006 20:25:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ce5-0002jT-Q2 for ospf@ietf.org; Fri, 28 Jul 2006 20:25:33 -0400 Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6ce5-0007kE-Fy for ospf@ietf.org; Fri, 28 Jul 2006 20:25:33 -0400 Received: from h-68-164-93-52.snvacaid.dynamic.covad.net ([68.164.93.52] helo=earthlink.net) by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1G6ce4-0007OV-00; Fri, 28 Jul 2006 20:25:32 -0400 Message-ID: <44CAAB32.4B2A546D@earthlink.net> Date: Fri, 28 Jul 2006 17:26:26 -0700 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Richard Ogier Subject: Re: [OSPF] Database Exchange Summary List Optimization References: <44B7E563.3000706@cisco.com> <44B7E6D0.6030304@cisco.com> <44BD1FE6.2030202@earthlink.net> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Richard Ogier, I am a periodic insomniac and sometimes I write code in the middle of the night. I coded a pre-DD exchange mechanism to identify whether two routers are (almost) in sync and to request a partial or full Database exchange. This was based on some emails in the middle of the month. Yes, Acee I did re-read the earlier draft and again didn't like it based on not predetermining what was out-of-sync and thus, being able to reduce the number of header LSAs. I think IFF External LSAs are in sync, those headers should not be exchanged. In many envs, if that is the case the majority of LSA headers would not be exchanged. I was contemplating writing a quick RFC and wanted to know whether you would first comment on the doc before submiting it as a experimental RFC later in the week. Mitchell Erblich ------------------ Richard Ogier wrote: > > Acee Lindem wrote: > > > Hi Richard, > > > > Richard Ogier wrote: > > > >> I have one concern. What if some future extension of OSPF assumes that > >> DD packets list all LSAs as specified in RFC 2328, e.g., so that some > >> action can be taken that depends on how "out of sync" the new neighbor > >> was. If someone implements the optimization without any indication > >> (such as a new option bit), then a future extension > >> might incorrectly conclude that the new neighbor was out of sync > >> and take the wrong action. This could be fixed either by including > >> a new option bit, or by changing the spec of OSPF to allow the > >> optimization. Is this a valid concern? > > > > I'm not sure that I can think of any optimization that would rely on > > the neighbor sending a full database snapshot. Especially, when you > > consider that it would need to be fully backward compatible Can > > you imagine any? > > Not really. And you can infer the neighbor's LSDB based on the combination > of received DBD packets and LSR packets. (If a given LSA appears in > neither type of packet, the neighbor must have the same instance.) > So I guess there is no need for the new bit. > The informational document can warn that any extension of OSPF > that uses this optimization cannot assume that the neighbor will > send a full database snapshot. > > To summarize previous discussions, it looks like the (informational) > document should say that a router implementing the optimization > should do one of the following: > 1. Upon receiving a DBD packet, the summary list should be updated > (as described in the document) before sending the next DBD packet. > 2. If the router is master, it should list LSAs in increasing order of > (LS type, Link State ID, Advertising Router) lexicographically. > If the router is slave, it should list LSAs in decreasing order. > > If option 1 is done, there is no benefit to also doing option 2. > If option 2 is done, there may still be some benefit to doing option 1 > when the last DBD packet is received (with M = 0). > Option 1 may be preferable if the time to process a received full DBD packet > is much less than the time to transmit such a packet. > Otherwise, option 2 may be preferable if the database is very large > and it is desirable to reduce the time to synchronize. > > However, I want to point out that option 1 does not increase the time > to synchronize, assuming the two routers already had nearly > identical databases. Any additional delay due to not parallelizing > would be compensated for by sending fewer LSA headers. > > Another variation is the following. The DR level is Other, BDR, or DR, with > DR being the highest. (For MANETs, we use Other, BMDR, and MDR.) > The router with the lower DR level (whether master or slave) does not > list any LSAs until the neighbor has finished listing all of its LSAs > (indicated > by M = 0), and then lists only LSAs for which it has a newer instance. > This might be benficial since the router with higher DR level is more likely > to have newer LSAs, so the router with lower DR level will list very few > LSAs. > > Richard > > > > > > > Anyway, if this is a concern the document would needs to be standards > > track and I think we should use a bit in the database exchange I_M_MS > > field rather than the options (there are no free bit left in OSPFv2). > > > > Thanks, > > Acee > > > >> > >> > >> Richard > >> > >> > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf > > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf