Subject: UNH, interoperability, test OSPF-1.5c

From: Igor Miroshnik <[email-masked]>
Date: Thu, 6 Nov 2003 05:21:24 -0500

All,

 Please consider the following topology:

        +---+    |    +---+
        |RUT|----|----|TR1|
        +---+    |    +---+
             Network 0

Part C: The RUT transitions to BDR

 10. Unplug the RUT’s interface on network 0.
 11. Reset OSPF.
 12. Plug the RUT’s interface back in on network 0 (TR1 should still
     list RUT as BDR).
 13. Observe the traffic transmitted on the network.

Observable Results:

 In Part C, The RUT should wait for about 40 seconds before it
 begins to claim itself to be the BDR on network 0.

 I wonder whether the result expected by the test are correct, since
the crucial part of it, the remark made within the parentheses in step 12,
cannot happen. Originally, TR1 and RUT are adjacent as DR and BDR
respectively. When RUT is unplugged, reset (in OSPF context), and plugged
again, it multicasts Hello listing no neighbors. TR1 notices loss of bi-
directional communication with RUT and reelects itself as DR leaving the
position of BDR vacant, while listing RUT as neighbor in the next outgoing
Hello. RUT receives that Hello, establishes bi-directional communication
with TR1 (as it sees itself in the list), and discerns that TR1 claims
itself DR with no fellow BDR. Naturally, RUT reacts with the event
BackupSeen, running DR/BDR election ending up in the position of BDR. The
entire procedure lasts from 1 to 20 seconds, which is below
RouterDeadInterval (40 seconds) delimiting Waiting state, in contrary to
the results expected by the test.

Thanks,
Igor

---

From: Vivek Gupta <[email-masked]>
Date: Thu, 6 Nov 2003 16:13:13 +0530

As per RFC, When the Interface comes up Hello Timer is
started.("Interface UP" event).
 
That implies the HELLO packet will be sent by RUT 10 seconds after the
Interface came up. 

Therefore, when RUT comes up it can receive HELLO packet from TR1 before
it sends it's own HELLO packet. This HELLO PACKET sent by TR1 will till
say that BDR is "RUT"( because the change hasn't been detected by TR1
till now).

Now, at RUT no "Backupseen" event will be triggered and hence Wait timer
need to expire and it will take 40 seconds for RUT to declare itself as
BDR.

Regards,
Vivek

-----Original Message-----
From: Igor Miroshnik [mailto:[email-masked]] 
Sent: Thursday, November 06, 2003 3:51 PM
To: [email-masked]
Subject: UNH, interoperability, test OSPF-1.5c

All,

        +---+    |    +---+
        |RUT|----|----|TR1|
        +---+    |    +---+
             Network 0

 10. Unplug the RUT's interface on network 0.
 11. Reset OSPF.
 12. Plug the RUT's interface back in on network 0 (TR1 should still
     list RUT as BDR).
 13. Observe the traffic transmitted on the network.

Observable Results:

 I wonder whether the result expected by the test are correct, since
the crucial part of it, the remark made within the parentheses in step
12,
cannot happen. Originally, TR1 and RUT are adjacent as DR and BDR
respectively. When RUT is unplugged, reset (in OSPF context), and
plugged
again, it multicasts Hello listing no neighbors. TR1 notices loss of bi-
directional communication with RUT and reelects itself as DR leaving the
position of BDR vacant, while listing RUT as neighbor in the next
outgoing
Hello. RUT receives that Hello, establishes bi-directional communication
with TR1 (as it sees itself in the list), and discerns that TR1 claims
itself DR with no fellow BDR. Naturally, RUT reacts with the event
BackupSeen, running DR/BDR election ending up in the position of BDR.
The
entire procedure lasts from 1 to 20 seconds, which is below
RouterDeadInterval (40 seconds) delimiting Waiting state, in contrary to
the results expected by the test.

Thanks,
Igor

---

From: Igor Miroshnik <[email-masked]>
Date: Thu, 6 Nov 2003 06:25:58 -0500

Vivek,

Even if TR1 receives RUT's first Hello delayed by 10 seconds, it still
notices that RUT is no longer declaring itself as BDR, thus raising
NeighborChange event. The latter results in DR/BDR reelection and the next
TR1's Hello (another HelloInterval-delay, at most) will indicate lack of
BDR. Upon receiving TR1's Hello, RUT still will raise BackupSeen. Again, 20
seconds from RUT's comeback elapse, at most.

Thanks you,
Igor

---

From: Vivek Gupta <[email-masked]>
Date: Thu, 6 Nov 2003 17:08:45 +0530

BackupSeen event will still not be raised, because on TR1 when Neighbor
Change event occurs, DR election will still lead to election of RUT as
BDR and TR1 as DR. So, the Hello packet sent by TR1 will not contain any
change and hence no BACKUP SEEN event on RUT.

Regards,
Vivek

-----Original Message-----
From: Igor Miroshnik [mailto:[email-masked]] 
Sent: Thursday, November 06, 2003 4:56 PM
To: [email-masked]
Subject: Re: UNH, interoperability, test OSPF-1.5c

Vivek,

Even if TR1 receives RUT's first Hello delayed by 10 seconds, it still
notices that RUT is no longer declaring itself as BDR, thus raising
NeighborChange event. The latter results in DR/BDR reelection and the
next
TR1's Hello (another HelloInterval-delay, at most) will indicate lack of
BDR. Upon receiving TR1's Hello, RUT still will raise BackupSeen. Again,
20
seconds from RUT's comeback elapse, at most.

Thanks you,
Igor

---

From: Vivek Gupta <[email-masked]>
Date: Thu, 6 Nov 2003 20:06:14 +0530

I was referring with regards to conformance.
However, otherwise sending the HELLO packet at the InterfaceUp event
leads to faster convergence. It is a kind of optimization.

Regards,
Vivek

-----Original Message-----
From: Igor Miroshnik [mailto:[email-masked]] 
Sent: Thursday, November 06, 2003 7:51 PM
To: [email-masked]
Subject: Re: UNH, interoperability, test OSPF-1.5c

Group,

I am confused:

On one hand Vivek insists the first Hello should not be issued before
HelloInterval elapses, on the other hand
John
http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0005&L=ospf&P=R432&I=-3
and Alex
http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0006&L=ospf&D=0&I=-3&P=
3123
mention immediate launch of Hello with InterfaceUp.
Please help to make up my mind.

Thanks,
Igor