From ospf-bounces@ietf.org Fri Sep 01 16:17:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFR2-0003l0-Ve; Fri, 01 Sep 2006 16:16:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJFR1-0003kv-W1 for ospf@ietf.org; Fri, 01 Sep 2006 16:16:15 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJFR1-0008Lm-92 for ospf@ietf.org; Fri, 01 Sep 2006 16:16:15 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 01 Sep 2006 13:16:15 -0700 X-IronPort-AV: i="4.08,201,1154934000"; d="scan'208"; a="316981472:sNHT37425292" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k81KGEmn019550; Fri, 1 Sep 2006 13:16:14 -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 k81KGC6a012594; Fri, 1 Sep 2006 13:16:14 -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, 1 Sep 2006 16:16:13 -0400 Received: from [10.82.225.76] ([10.82.225.76]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 16:16:13 -0400 Message-ID: <44F8950C.8040300@cisco.com> Date: Fri, 01 Sep 2006 16:16:12 -0400 From: Acee Lindem User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) 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> <44CAAB32.4B2A546D@earthlink.net> <44DB9074.8000700@earthlink.net> <44EE1D00.50502@cisco.com> <44F724CB.50100@earthlink.net> In-Reply-To: <44F724CB.50100@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Sep 2006 20:16:13.0227 (UTC) FILETIME=[78B947B0:01C6CE03] DKIM-Signature: a=rsa-sha1; q=dns; l=8330; t=1157141774; x=1158005774; c=relaxed/relaxed; s=sjdkim8002; 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=OEiEy0VSAhZFpJUZrGTDWMunNcfT++N6/Mh9CSbWRWfRTZz5cSTEnc9ZkgGQR6yRSIAcm5p/ WDKeZ45H/1+oQkgpFl95zj2FBW/H71qmsmnp7nV5sFz98CgKDAgGW08Q; Authentication-Results: sj-dkim-8.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e 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 Richard, Richard Ogier wrote: > I have a few comments and questions regarding the document. > It seems clear that Option 1 should remain in the document > (as Acee indicated). My comments below suggest that Option 2 > is also useful and should also remain in the document. > Finally, I discuss the question of whether Option 3 is useful > enough to be included in the document. > > First, I want to mention two advantages of Option 2 (which might > not be clear in the draft). > Option 2 applies only to broadcast (or MANET) interfaces, and > depends on the DR levels of the two routers (DR, BDR, or DR Other). > (In a MANET, if both routers have the same DR level, then the > tie is broken using Router ID.) > For simplicity, let's say the router with larger DR level is a DR, > and the router with smaller DR level is a DR Other. > > (1) With Option 2, the DR always lists all LSAs in its database, > while the DR Other lists only LSAs for which it has a more > recent instance than the DR. > Therefore, even if the two routers are completely out of sync, > and assuming the DR has more recent instances (which is more > likely), the DR Other will not list any LSAs. > In this case, if Option 1 were used, the DR Other would > list roughly half of its LSAs on average (i.e., the LSAs > that are not first listed by the DR), and the DR would still > list all of its LSAs (assuming they are more recent), so > Option 2 has an advantage over Option 1 in this case. > > (2) The second advantage of Option 2 is that the DR Other will > list far fewer LSAs (and thus transmit fewer bits) than the DR > on average. This may be useful in a MANET, since the DR Other > may be less powerful than the DR, and thus have a lower router > priority. Therefore, the less powerful router transmits fewer > bits, which makes sense. > > For the above two reasons, I think Option 2 is useful and > should remain in the document. This is ok with me. I think it is also fully backward compatible and I can see situations where the total number of LSA headers exchanged will be reduced. However, this is at the expense of some serialization in the exchange process (the extreme example would be two routers with completely disjoint Link State Databases forming an adjacency for the first time). > > The main question I have is whether Option 3 is useful enough > to remain in the document. In Option 3, the master lists LSAs > in forward lexicographical order, while the slave lists LSAs > in reverse order. This reduces the number of LSAs that are > listed by both the master and slave, without requiring a router > to completely process a received DD packet before sending the > next DD packet in response. > > Acee told me he does not see a great advantage to sending the > next DD packet prior to processing the received one, > and that this may be a protocol violation since the DD packet > sent in reply effectively acks the received one. > So one question is whether it is possible to effectively > ack a received DD packet without first processing the > list of LSA headers in the packet, or at least reading > the LSA headers to make sure they are valid. Processing > the LSA headers for the purpose of updating the summary list > will not take significantly more time than simply reading all > the LSA headers, assuming the summary list is ordered > lexicographically or is organized as a binary tree. > > Note also that Option 3 has a disadvantage. For example, > if all LSA headers fit into a single DD packet, then both > routers will still list all LSAs. > > So my main question is whether Option 3 is sufficiently > useful and advantageous to be included in the document. I'd be in favor of removing this option. When a DD packet is sent, it essentially acknowledges the previous one received. Hence, I really think the DD packet should be processed prior to sending one in response. Also, when I first brought up lexicographical ordering I was envisioning a linear representation of the database summary list - clearly, it is a mistake to assume this or specify it in the document. > Also, the same question can be applied to Option 2, considering > the advantages I discussed above. > One possibility is to include only Option 1 in the document. I could go either way here. Since we're talking about an informational track anyway and there are some benefits, I'd say we can retain it. Thanks, Acee > > Richard > > > Acee Lindem wrote: > >> We had a majority of the attendees in favor of making this a WG >> document in Montreal. Is there anyone not in favor of adopting it as >> an informational WG document? >> >> I know there are those who feel we shouldn't publish any document >> that is fully compatible. However, in this case, IMHO, it is >> worthwhile for >> the WG to do so since: >> >> 1. WG discussion and review will verify with a high probability >> that this change is, in fact, fully backward compatible. >> 2. We'd be accepting a document that most people agree is a >> good thing to do - there is less disagreement on the details >> then some other proposals. >> 3. The relatively simple optimization can result in a significant >> decrease in DB exchange overhead. In fact, I predict option A >> will some day be in most implementations. >> >> Thanks, >> Acee >> Richard Ogier wrote: >> >>> I have submitted the following updated draft: >>> http://www.ietf.org/internet-drafts/draft-ogier-ospf-dbex-opt-01.txt >>> >>> The update incorporates comments of others and some ideas I presented >>> in my post on 7/18/2006. In particular, it describes three options >>> that differ in whether the LSAs must be listed in lexicographical order >>> and whether a router must fully process a received DD packet before >>> sending its next DD packet. To summarize: >>> >>> In Option A, the router is required to fully process a received DD >>> packet before sending the next DD packet in reply. >>> (LSAs are not listed in lexicographical order.) >>> >>> In Option B, the router with the larger DR level performs database >>> exchange as in RFC 2328 without change. The router with the smaller >>> DR level sends only empty DD packets (with no LSA headers) until it >>> has received the entire summary list from its neighbor (indicated >>> by M = 0), and then lists only LSAs that are more recent than those >>> received. I forgot to mention in the draft that Option B applies >>> only to broadcast (or MANET) interfaces. >>> >>> In Option C, the master lists LSAs in lexicographical order >>> and the slave lists LSAs in reverse lexicographical order, >>> as suggested by Mitchell Erblich. >>> >>> Regarding recent comments by Mitchell, I am not yet convinced that >>> there is any benefit to detecting whether a neighbor is nearly in sync >>> and using the optimization (with one of the three options) only if >>> the neighbor is nearly in sync, versus simply employing the >>> optimization. For example, in MANETs, it appears best to simply >>> employ the optimization with Option A. >>> Maybe you can provide a concrete, realistic example. >>> >>> Even if it does help to detect whether a neighbor is nearly in sync, >>> I am not sure that the (informational) document I am working on >>> needs to specify such a detection mechanism. Such a mechanism >>> could be specified in a separate document. Instead, the document I >>> am working on can just state that such a mechanism can be employed >>> if desired. If two routers are performing database exchange, the >>> protocol does not fail if only one of the routers decides to use >>> the optimization, or if one router decides to use Option A while the >>> other decides to use Option B or C. >>> >>> Of course, this optimization was motivated because we wanted >>> to reduce overhead in MANETs, and I would prefer to keep >>> the document as simple as possible. >>> >>> 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 Mon Sep 04 00:24:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK5xT-0004X4-FO; Mon, 04 Sep 2006 00:21:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK5xS-0004Wr-Tx for ospf@ietf.org; Mon, 04 Sep 2006 00:21:14 -0400 Received: from web56514.mail.re3.yahoo.com ([66.196.97.43]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GK5xN-0002Cx-Ck for ospf@ietf.org; Mon, 04 Sep 2006 00:21:14 -0400 Received: (qmail 25065 invoked by uid 60001); 4 Sep 2006 04:20:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SsadHgTkaCOPRUI6A087s6gPf6/HtpBln4YzGt3wWZi/n/MCqMU14A0j2e+Ht0Y7kKBvewWhMdImC1jbcgLmh99vItmOVGkGmodTwza4wvxTUcMvffd8g7sXHNH4M54CUUaNzRvbuSuvS1Gq5VsviAgNZPBOcbngod/hKtW9eo0= ; Message-ID: <20060904042054.25063.qmail@web56514.mail.re3.yahoo.com> Received: from [65.223.109.250] by web56514.mail.re3.yahoo.com via HTTP; Sun, 03 Sep 2006 21:20:54 PDT Date: Sun, 3 Sep 2006 21:20:54 -0700 (PDT) From: sengottuvelan srirangan To: ospf@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [OSPF] query on OSPF restart signalling RS-bit 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="===============1442664534==" Errors-To: ospf-bounces@ietf.org --===============1442664534== Content-Type: multipart/alternative; boundary="0-373480138-1157343654=:21851" Content-Transfer-Encoding: 8bit --0-373480138-1157343654=:21851 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi all, I have doubt on OSPF restart signalling draft http://tools.ietf.org/wg/ospf/draft-nguyen-ospf-restart-05.txt , section 2.1, The RS-bit must not be set in Hello packets longer than RouterDeadInterval seconds. The dead interval is configured per interface basis, say , i have two interfaces eth0, eth1 with configured dead interval as 40 and 160. Is the RS bit cleared after 40 sec on eth0 and 160 sec on eth1? If the answer is yes, then what is the status of Restarting router?. Is the router exits restarting after 40sec or 160sec? Please clarify the same. Thanks Sengottuvelan --------------------------------- All-new Yahoo! Mail - Fire up a more powerful email and get things done faster. --0-373480138-1157343654=:21851 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi all,

I have doubt on OSPF restart signalling draft http://tools.ietf.org/wg/ospf/draft-nguyen-ospf-restart-05.txt , section 2.1, The RS-bit must not be set in Hello packets longer than RouterDeadInterval seconds.

The dead interval is configured per interface basis, say , i have two interfaces eth0, eth1 with configured dead interval as 40 and 160. Is the RS bit cleared after 40 sec on eth0 and 160 sec on eth1?

If the answer is yes, then what is the status of Restarting router?. Is the router exits restarting after 40sec or 160sec?

Please clarify the same.

Thanks
Sengottuvelan


All-new Yahoo! Mail - Fire up a more powerful email and get things done faster. --0-373480138-1157343654=:21851-- --===============1442664534== 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 --===============1442664534==-- From ospf-bounces@ietf.org Mon Sep 04 10:28:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKFPr-00013m-FK; Mon, 04 Sep 2006 10:27:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKFPq-00013h-F2 for ospf@ietf.org; Mon, 04 Sep 2006 10:27:10 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKFPj-000370-DG for ospf@ietf.org; Mon, 04 Sep 2006 10:27:10 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19inc2yBDCLLBdaz30mFUMPDJ/cG7pQd5U@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k84EQdTl008493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Sep 2006 15:26:52 +0100 Date: Mon, 4 Sep 2006 15:26:39 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Richard Ogier Subject: Re: [OSPF] Database Exchange Summary List Optimization In-Reply-To: <44F724CB.50100@earthlink.net> Message-ID: References: <44B7E563.3000706@cisco.com> <44B7E6D0.6030304@cisco.com> <44BD1FE6.2030202@earthlink.net> <44CAAB32.4B2A546D@earthlink.net> <44DB9074.8000700@earthlink.net> <44EE1D00.50502@cisco.com> <44F724CB.50100@earthlink.net> Mail-Copies-To: paul@jakma.org Mail-Followup-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1796/Mon Sep 4 13:20:16 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: OSPF List , paul.jakma@sun.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 Hi Richard, On Thu, 31 Aug 2006, Richard Ogier wrote: > It seems clear that Option 1 should remain in the document Yes. > (1) With Option 2, the DR always lists all LSAs in its database, > while the DR Other lists only LSAs for which it has a more recent > instance than the DR. Therefore, even if the two routers are > completely out of sync, and assuming the DR has more recent > instances (which is more likely), the DR Other will not list any > LSAs. In this case, if Option 1 were used, the DR Other would list > roughly half of its LSAs on average (i.e., the LSAs that are not > first listed by the DR), and the DR would still list all of its > LSAs (assuming they are more recent), so Option 2 has an advantage > over Option 1 in this case. > (2) The second advantage of Option 2 is that the DR Other will > list far fewer LSAs (and thus transmit fewer bits) than the DR > on average. This may be useful in a MANET, since the DR Other > may be less powerful than the DR, and thus have a lower router > priority. Therefore, the less powerful router transmits fewer > bits, which makes sense. > For the above two reasons, I think Option 2 is useful and should > remain in the document. It may need refinement in language though. E.g. Acee's point about DD being a strictly master-driven process and sequence numbers.. > The main question I have is whether Option 3 is useful enough > to remain in the document. No. There are two possibilities for 3/C: a) It occurs naturally as a result of the index the implementation uses for the summary list b) The implementation must go through contortions to try meet this requirement I would suggest perhaps instead only mentioning the benefits of implementations ordering their index in that manner, and encourage implementations to try do so if possible. Also, note that even /partial/ ordering would have benefits. e.g. just ordering by (type) or (type,ID).