Subject: Issue fixed RE: Clarification related to Flooding an LSA by DR Other on its received interface

From: Manikantan Srinivasan <[email-masked]>
Date: Fri, 24 Dec 2004 15:32:40 +0530

Hello Acee,

Good day to you

The bug in my test steps has been identified and fixed.

The DR_Other implementation was performing the action as per Section 13.3
bullet 1 sub bullet d. i.e the DR_Other added the LSA update from DR to the
BDR's retransmission list.

===============

(d) At this point we are not positive that the neighbor has
    an up-to-date instance of this new LSA.  Add the new LSA
    to the Link state retransmission list for the adjacency.
    This ensures that the flooding procedure is reliable;
    the LSA will be retransmitted at intervals until an
    acknowledgment is seen from the neighbor.
=================

In my test steps, I had skipped sending the ack from BDR for the update
transmitted from the DR. This was causing the LSA to be retransmitted from
the DR_Other.

When my test steps included the generation of LS Ack from BDR for the update
from DR, The DR_other does not forward the packet.

Thank you

Best regards
mani 
<snip>

---

From: Acee Lindem <[email-masked]>
Date: Fri, 24 Dec 2004 12:24:36 -0500

Hi Mani,

I'd expected it might be a problem with the BDR since it has the
most complex role with respect to reliable flooding on broadcast
networks. Also, the RFC is confusing with respect to 13 (5)(b) and
"flooding out the receiving interface". The BDR may be aware that
the DR has flooded the LSA back out the receiving interface yet it
should NOT note this fact for the acknowledgement processing
described in the table in section 13.5.

Good Luck in the New Year,
Acee

---

From: prasanna <[email-masked]>
Date: Tue, 28 Dec 2004 10:41:16 +0530

Hi all
   I have small doubt. 
Consider the following topology
          Area 1                Area 1
RTA<eth1>-------<eth1>RTB<eth2>----------+
                               2000:BBBB::B/64

In this set up we run two OSPFv3 process with different instances over
Eth1 of RTA and Eth1 and Eth2 of RTB 

Now ospfv3 routing table of both the process will have identical route
(I.e. Next hop is same, out-going interface is same, and Cost is same)to
2000:BBBB::/64.

Assume the preference/distance of these process also same. Now in this
scenario which route should be added to the ipv6 routing-table (/FIB). 

Adding both is redundant, as all the attributes of the route are same.  

Thanks and Regards
Prasanna

---

From: Santosh Esale <[email-masked]>
Date: Tue, 28 Dec 2004 13:28:04 +0530

In such scenerios, OSPFv3's 2 processes will add  their respective
routes to RIB of Route Manager which is perfectly fine.

Now the Route Manager while selecting routes(making active) to
download to FIB, knows that the both the route are same(all
attributes) except process number, So it shud make only one route
active and download to FIB and the second route will remain in
RIB(inactive) and will not be downloaded to FIB. Or  If one process
has added route first to  RIB , which would have been downloaded to
FIB,and  when the second route comes, Route manager knows it is same
as previous ospfv3 route except process number attribute, and it shud
not be made active and downloaded to FIB.

when the active route is withdrawn by ospfv3 process, the inactive
route of other ospfv3 process from RIB can now be downloaded to FIB.

Regards
Santosh

-- 
Regards

Santosh Esale

Member Technical Staff 

Riverstone Networks India Pvt Ltd.