Re: [OSPF] Query regarding behavior of OSPF DR-Other's neighbor-State with BDR when DR fails, when DR down detection is delayed at DR-Other.

Acee Lindem <acee.lindem@ericsson.com> Fri, 05 July 2013 13:15 UTC

Return-Path: <acee.lindem@ericsson.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A09221F9D6F for <ospf@ietfa.amsl.com>; Fri, 5 Jul 2013 06:15:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.164
X-Spam-Level:
X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHH7wPp9zJ6S for <ospf@ietfa.amsl.com>; Fri, 5 Jul 2013 06:15:08 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF0721F9D18 for <OSPF@ietf.org>; Fri, 5 Jul 2013 06:15:08 -0700 (PDT)
X-AuditID: c618062d-b7fc36d0000032ea-bd-51d6c6dbf8be
Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E7.6B.13034.BD6C6D15; Fri, 5 Jul 2013 15:15:07 +0200 (CEST)
Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Fri, 5 Jul 2013 09:15:07 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: Bharath R <rbharath@juniper.net>
Thread-Topic: [OSPF] Query regarding behavior of OSPF DR-Other's neighbor-State with BDR when DR fails, when DR down detection is delayed at DR-Other.
Thread-Index: Ac5sGnznNwBh+oLtRnGrauEoRknkhf//8RyAgA6LkAD/9rGzgIAV4wmA
Date: Fri, 05 Jul 2013 13:15:06 +0000
Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47197779@eusaamb101.ericsson.se>
References: <94A203EA12AECE4BA92D42DBFFE0AE4718CDEF@eusaamb101.ericsson.se> <B39429F1A3EA1A4A9110CEC3D99263EA14C866CA@BN1PRD0512MB620.namprd05.prod.outlook.com>
In-Reply-To: <B39429F1A3EA1A4A9110CEC3D99263EA14C866CA@BN1PRD0512MB620.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.135]
Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE47197779eusaamb101ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLrHT/f2sWuBBqf+qFu03LvHbrHr+j5G i1+PlzA5MHvsnHWX3WPJkp9MHtebrrIHMEdx2aSk5mSWpRbp2yVwZbzu2MdYMO8fc8XPn72s DYyztjN3MXJySAiYSFz9dB7KFpO4cG89WxcjF4eQwFFGiaddW1ghnGWMElsOvGEHqWIT0JF4 /ugfWIeIgIrEur1zgYo4OJgF3CS2T04EqRcWmMkocXLOX7BmEYFZjBKPf91mh2hwk7h3fjML iM0C1Pxr8wcwm1fAW2LNqXXsENsWMUp8/LmHCSTBKZAoMeXIBlYQmxHovu+n1oDFmQXEJW49 mc8EcbeAxJI9MD+ISrx8/I8VwlaW+D7nEQtEfb7EyY9voJYJSpyc+YRlAqPoLCSjZiEpm4Wk DCJuIPH+3HxmCFtbYtnC11C2vsTGL2cZIWxriZ5Hj1DULGDkWMXIUVqcWpabbmSwiREYi8ck 2HR3MO55aXmIUZqDRUmcd5XemUAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjJaHtm6cvCn/ qNkC9RfCP3f/PXvp1cKgpSfZTuwLbml1DSooEuCyXP+x25cpTiIzNdo5wSns2KHdEuonSnsP 3m3Jy+PapfBdb7v9DXP7E0+j3v5xeLpxPff9pgMzM1yZJwUfznJjW8Rwvosp8ZWHmFLb6Y27 szXSmKYuDBU+HMsju39SX0bRNSWW4oxEQy3mouJEACOs0RyTAgAA
Cc: "OSPF@ietf.org" <OSPF@ietf.org>
Subject: Re: [OSPF] Query regarding behavior of OSPF DR-Other's neighbor-State with BDR when DR fails, when DR down detection is delayed at DR-Other.
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jul 2013 13:15:14 -0000

Hi Bharath,

On Jul 5, 2013, at 8:05 AM, Bharath R wrote:

Hi Acee,
Thank you for your response.

Sorry If my mail was unclear and longish.

Can you please clarify on following questions of mine:

If the DR-interface goes down, adjacency of old DR with DR-Others will go down. This is expected.
But, is it expected for adjacency of DR-Others with BDR(now the new DR) also flap as well(transition to 2-WAY and again back to FULL)?

In this situation, this will happen. As Tanmoy pointed out, this would not happen if both routers determined that the DR was down at roughly the same time (as one would expect).


(Like, in cases wherein DR-Others have detect DR down much after BDR has detected DR down and sent it’s Hello to DR-Others).
If this adjacency does flap with BDR, do we not loose out on the advantage of having a BDR?

Hypothetically, if you were a test engineer, you should focus on the disparity in DR Down detection between the BDR and ineligible DR-other router.



Also I was hoping to have clarity on the section 9.2 of RFC 2328of RFC 2328 about triggers for NeighborChange event:
            o   One of the bidirectional neighbors is newly declaring
                itself as either Designated Router or Backup Designated
                Router.  This is detected through examination of that
                neighbor's Hello Packets.

            o   One of the bidirectional neighbors is no longer
                declaring itself as Designated Router, or is no longer
                declaring itself as Backup Designated Router.  This is
                again detected through examination of that neighbor's
                Hello Packets.

Whether these two bullets are mentioning transition from {DR to (BDR or DR-Other)}, and {BDR to (DR or DR-other)}
Or does it just mean a transition from (Non-DR-Other to DR-Other) and (DR-Other to Non-DR-Other).
Where Non-DR-Other means (DR and BDR).

It means that former - any transition will trigger the NeighborChange event.

Hope this helps,
Acee




Thanks and Regards,
Bharath R.


From: Acee Lindem [mailto:acee.lindem@ericsson.com]
Sent: Thursday, June 27, 2013 8:00 PM
To: Tanmoy Kundu
Cc: Bharath R; OSPF@ietf.org<mailto:OSPF@ietf.org>; Dileep Singh
Subject: Re: [OSPF] Query regarding behavior of OSPF DR-Other's neighbor-State with BDR when DR fails, when DR down detection is delayed at DR-Other.

I agree with Tanmoy that this is proper behavior.
Thanks,
Acee
On Jun 18, 2013, at 10:00 AM, Tanmoy Kundu wrote:


Hi Bharath,
Few queries. As you mentioned "R2(The current BDR) detects the DR-down.", how did R2 sensed that R1 is down ?
    a. first possible option is dead timer expiry in R2. In that case R3 should also get the expiry soon and till that time the network won't converge. isn't that expected?
    b. Another option is having BFD session between R1 and R2, hence it comes to know. Why don't we run BFD between all the routers in the network ? As we know in OSPF the DR and BDR is not guaranteed.

This typical scenario is due to the DR-other is with priority zero. But when received hello packet from DR, both BDR and DR-Other should reset the dead timer. Even if we consider the link transmission delay and ASIC processing, the dead timer expiry difference between R2 and R3 should not be more than milisecond, isn't it ?


•         Is  it right to trigger the NeighborChange event at R3? - I feel yes, other than few typical scenarios the network will at least not be used, until its converged. If Nbr-chg event is not sent then all DR other feels that DR is still active and the same will be used for forwarding the traffic. If someone in the network sensed that DR/BDR is down, why don't tell others immediately?
•         Is this transition from FULL to 2-WAY  is expected? - As per RFC, DR others should not be FULL with other routers than DR and BDR, hence YES. It is expected.
•         Can DR-Others flap adjacency with BDR if DR down detection  happens later than reception of new Hello from  the new DR? -
•         Intuitively, it may seem desirable to continue to be adjacent to a neighbor as long as it is still DR or BDR. Is this a fair call? - As mentioned above, its not fair to use a disturbed or unsettled network for forwarding. Due to backlink check failure the LAN wont be used for forwarding during SPF. Hence as per me its proper behavior.


Thanks,
Tanmoy


On Tue, Jun 18, 2013 at 5:26 PM, Bharath R <rbharath@juniper.net<mailto:rbharath@juniper.net>> wrote:
Hi,
Please consider the scenario:

R1(DR)                                            R2(BDR)
|  I1                                               I2   |
|                                                            |
|______________________ |
                                |
                                |  I3
                                |
                      R3(DR-Other)

Here:
R1 is the DR.
R2 is the BDR
R3 is DR-Other, with DR-priority 0 and hence ineligible to become DR/BDR.


Following are the is the set of operations and a sequence of events:

1.       Interface I1 is disabled. So, DR connectivity is lost to the rest of the network.
2.       R2(The current BDR) detects the DR-down.
a.       Declares itself the DR.
b.      Declares BDR as NULL.
c.       Sends out a Hello with DR as I2 interface address, and BDR as 0.0.0.0
3.       R3(DR-Other) receives Hello from R2.
As per, section 9.2 of RFC 2328:
            o   One of the bidirectional neighbors is newly declaring
                itself as either Designated Router or Backup Designated
                Router.  This is detected through examination of that
                neighbor's Hello Packets.

            o   One of the bidirectional neighbors is no longer
                declaring itself as Designated Router, or is no longer
                declaring itself as Backup Designated Router.  This is
                again detected through examination of that neighbor's
                Hello Packets.

Triggers a NeighborChange event, which in-turn results in a DR election at R3.
Please note that at this time R3 has not yet detected R1 down.
Now result of DR-election at R3:
DR: R1
BDR: 0.0.0.0
Since R2 is no longer the BDR, R3 transitions from FULL to 2-WAY with R2(the new DR).
Of course, on detection of DR down at R3, R3 will elect R2 as DR and then again transition to ExStart, to Exchange to Full with R2.

Can you please let me know:
•         Is  it right to trigger the NeighborChange event at R3 ?
•         Is this transition from FULL to 2-WAY  is expected?
•         Can DR-Others flap adjacency with BDR if DR down detection  happens later than reception of new Hello from  the new DR?
•         Intuitively, it may seem desirable to continue to be adjacent to a neighbor as long as it is still DR or BDR. Is this a fair call?

Please correct me if I have missed out something.


Thanks and Regards,
Bharath R.






_______________________________________________
OSPF mailing list
OSPF@ietf.org<mailto:OSPF@ietf.org>
https://www.ietf.org/mailman/listinfo/ospf

_______________________________________________
OSPF mailing list
OSPF@ietf.org<mailto:OSPF@ietf.org>
https://www.ietf.org/mailman/listinfo/ospf