Re: another appoach to OOB LSDB Resynchronization??
"Manral, Vishwas" <VishwasM@NETPLANE.COM> Wed, 02 October 2002 07:06 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 DAA11176 for <ospf-archive@LISTS.IETF.ORG>; Wed, 2 Oct 2002 03:06:33 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0074BF38@cherry.ease.lsoft.com>; Wed, 2 Oct 2002 3:08:27 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 234272 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Oct 2002 03:08:27 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 2 Oct 2002 03:08:27 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H3C0Z>; Wed, 2 Oct 2002 03:08:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID: <E7E13AAF2F3ED41197C100508BD6A32879174D@india_exch.hyderabad.mindspeed.com>
Date: Wed, 02 Oct 2002 03:10:34 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: another appoach to OOB LSDB Resynchronization??
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Hi Mitchell, The draft is an individual submission and is located at http://www.ietf.org/internet-drafts/draft-nguyen-ospf-oob-resync-01.txt I am however not too sure how you intend to achieve LSDB resynch without changing the topology view of the network, because when we get a 1-way received event we clear all the LS Retransmit List, DB summary list and Link state request list and goto "Init" state. Are you saying we dont handle the 1-way received event at all? How will the neighbor know when its doing LSDB resynch and when its not? I would be averse to any change in the FSM though. A much simpler way to force an LSDB synch however would be to simply start DB exchange by sending DBD packets with the init bit set(SeqNumberMismatch event). This would bring the adjacencies to Exstart state(and not to Init as it would in case of 1-way received), however the topology data would change. We could as well not change topology if we get SeqNumberMismatch in all cases for the SeqNumberMismatch event, however I think it would be a major deviation from the OSPF protocol. Thanks, Vishwas -----Original Message----- From: Erblichs [mailto:erblichs@EARTHLINK.NET] Sent: Tuesday, October 01, 2002 11:16 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: another appoach to OOB LSDB Resynchronization?? Group, I haven't seen whether last year's RFC on Out-of-band LSDB Resynchronization draft had been formalized into a standardized RFC. So these comments may be way late, with this different approach to perform LSDB Resynchronization. I haven't tried this .... but in my mind this method could accomplish the same thing with legacy routers and remove the need for a option bit which is becoming a scarse thing in version 2. And be a lightweight mechanism. Since the neighbor field in a hello PDU is the normal indicator of 2-way communication, why not just temporarily drop the neighbor field of the adjacency that you wish to re-establish? Yes, I am assuming that based on your internal request to perform this operation you reset your neighbor state machine and set a internal "OOB request neighbor field flag". At best you can re-establish the link on average of 1/2 hello interval and at worst you will have to wait router-dead-interval timeframe before you re-acknowledge the arrival of hellos from the neighbor that you wish resync the adjacency. (or wait before you resend hellos?) The preference is to just with-hold the neighbor from the neighbor field. This would allow the OOB requester to remain as a DR or BDR if that was his orignal router OSPF type. This would remove any necessary overhead of elections, adjacency reformations, and substantial SPF calculations. Then the question is how to utilize the flag to make sure that you don't deallocate any neighbor data structures and whether you increment the sequence number of your orignated LSAs, keep them the same, or set MAXAGE and then resend. More than likely you will also have to withold flooding to the neighbor or acks back to the neighbor from his flooding of LSAs. If LSAs were recv'ed from the neighbor during flooding, I would probably incorporate them into my LSDB. Independent of how you deal with the above issues, you then must re-attempt to synchronize the LSDB. Assuming that their were more than two OSPF speaking routers in your area, your previous interaction should have minimal effects on your neighbor. More than likely, he had kept your earlier originated LSAs in his database. And you just resync, upon reaching full state again with the neighbor, you clear your internal "OOB request neighbor field flag". Is there a dual-behaviour (one who wants to redo the initial LSDB synchronization and one who keeps the established adj) achieved by establishing a adjacency and then removing the neighbor specified in the hello field that really requires the OOB requestor in the scenario to cycle into a period of router-dead-interval before sending out new hellos AND ... ???? Flames now allowed.... Mitchell Erblich ==========================
- another appoach to OOB LSDB Resynchronization?? Erblichs
- Re: another appoach to OOB LSDB Resynchronization… Manral, Vishwas
- Re: another appoach to OOB LSDB Resynchronization… Erblichs
- Re: another appoach to OOB LSDB Resynchronization… Manral, Vishwas
- Re: another appoach to OOB LSDB Resynchronization… Erblichs
- Re: another appoach to OOB LSDB Resynchronization… Manral, Vishwas