Re: Clarification on Flooding
Acee Lindem <acee@REDBACK.COM> Thu, 12 June 2003 04:51 UTC
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14620 for <ospf-archive@LISTS.IETF.ORG>; Thu, 12 Jun 2003 00:51:12 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00A0FAB0@cherry.ease.lsoft.com>; Thu, 12 Jun 2003 0:51:14 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45384094 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 12 Jun 2003 00:51:11 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 12 Jun 2003 00:51:11 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 64DA5870AEC for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 11 Jun 2003 21:51:10 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <see84015.009@aapt-gwia2.aapt.com.au>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID: <3EE806B2.50101@redback.com>
Date: Thu, 12 Jun 2003 00:50:58 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Clarification on Flooding
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit
Paresh Khatri wrote: > HI all, Hi Paresh, > > Would someone be able to explain the following clause in RFC2328 to me ? > > This is in Section 13. Flooding Procedure: > > Page 145 > (6) Else, if there is an instance of the LSA on the sending > neighbor's Link state request list, an error has occurred in the > Database Exchange process. In this case, restart the Database > Exchange process by generating the neighbor event BadLSReq for > the sending neighbor and stop processing the Link State Update > packet. > > Why is this an error ? If the LSA is on the Link state request list for the neighbor, are we not expecting that > LSA from that neighbor ? Yes - but in this case the instance is the same as the one that is already in your database. Note that in step (5) (b) it says to immediately flood a new LSA out some subset of the router's interface. When this happens the corresponding LSA instance should be removed from all neighbor's link state request lists (see step (1) (b) on page 149). Note that an implemenation may have to make accomodations if LSA flooding is not immediate. In any case, the specification is correct. > All responses appreciated. > Paresh Khatri. > -- Acee
- Clarification on Flooding Paresh Khatri
- Re: Clarification on Flooding Parag Deshpande
- Re: Clarification on Flooding Acee Lindem
- Re: Clarification on Flooding Paresh Khatri