[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.

Bharath R <rbharath@juniper.net> Tue, 18 June 2013 11:56 UTC

Return-Path: <rbharath@juniper.net>
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 13B4821F9BD1 for <ospf@ietfa.amsl.com>; Tue, 18 Jun 2013 04:56:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.466
X-Spam-Level:
X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132]
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 oo0tH+S-SiN6 for <ospf@ietfa.amsl.com>; Tue, 18 Jun 2013 04:56:26 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 0A73921F8F24 for <OSPF@ietf.org>; Tue, 18 Jun 2013 04:56:22 -0700 (PDT)
Received: from mail162-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Jun 2013 11:56:22 +0000
Received: from mail162-ch1 (localhost [127.0.0.1]) by mail162-ch1-R.bigfish.com (Postfix) with ESMTP id 17A9F2C10D7 for <OSPF@ietf.org>; Tue, 18 Jun 2013 11:56:22 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: PS0(zzc85fhzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz18c673hz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail162-ch1: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=rbharath@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ;
X-Forefront-Antispam-Report-Untrusted: CIP:132.245.2.21; KIP:(null); UIP:(null); (null); H:BN1PRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT
Received: from mail162-ch1 (localhost.localdomain [127.0.0.1]) by mail162-ch1 (MessageSwitch) id 13715565801726_8806; Tue, 18 Jun 2013 11:56:20 +0000 (UTC)
Received: from CH1EHSMHS021.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail162-ch1.bigfish.com (Postfix) with ESMTP id F2260C0060 for <OSPF@ietf.org>; Tue, 18 Jun 2013 11:56:19 +0000 (UTC)
Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.53) by CH1EHSMHS021.bigfish.com (10.43.70.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 18 Jun 2013 11:56:19 +0000
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 18 Jun 2013 04:56:18 -0700
Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 18 Jun 2013 04:56:18 -0700
Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.11) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 18 Jun 2013 05:08:17 -0700
Received: from mail177-tx2-R.bigfish.com (10.9.14.226) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Jun 2013 11:56:17 +0000
Received: from mail177-tx2 (localhost [127.0.0.1]) by mail177-tx2-R.bigfish.com (Postfix) with ESMTP id 3670E20170 for <OSPF@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Tue, 18 Jun 2013 11:56:17 +0000 (UTC)
Received: from mail177-tx2 (localhost.localdomain [127.0.0.1]) by mail177-tx2 (MessageSwitch) id 1371556574240772_12511; Tue, 18 Jun 2013 11:56:14 +0000 (UTC)
Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.247]) by mail177-tx2.bigfish.com (Postfix) with ESMTP id 368C360055 for <OSPF@ietf.org>; Tue, 18 Jun 2013 11:56:14 +0000 (UTC)
Received: from BN1PRD0512HT004.namprd05.prod.outlook.com (132.245.2.21) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 18 Jun 2013 11:56:13 +0000
Received: from BN1PRD0512MB620.namprd05.prod.outlook.com ([169.254.16.70]) by BN1PRD0512HT004.namprd05.prod.outlook.com ([10.255.193.37]) with mapi id 14.16.0324.000; Tue, 18 Jun 2013 11:56:13 +0000
From: Bharath R <rbharath@juniper.net>
To: "OSPF@ietf.org" <OSPF@ietf.org>
Thread-Topic: 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+oLtRnGrauEoRknkhQ==
Date: Tue, 18 Jun 2013 11:56:12 +0000
Message-ID: <B39429F1A3EA1A4A9110CEC3D99263EA14C81146@BN1PRD0512MB620.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [116.197.178.83]
Content-Type: multipart/alternative; boundary="_000_B39429F1A3EA1A4A9110CEC3D99263EA14C81146BN1PRD0512MB620_"
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-OriginatorOrg: juniper.net
Cc: Dileep Singh <dsachan@juniper.net>
Subject: [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: Tue, 18 Jun 2013 11:59:19 -0000

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.