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.

Tanmoy Kundu <tanmoycs@gmail.com> Tue, 18 June 2013 14:00 UTC

Return-Path: <tanmoycs@gmail.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 EEF4421F8201 for <ospf@ietfa.amsl.com>; Tue, 18 Jun 2013 07:00:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 lFtR5ObdROPc for <ospf@ietfa.amsl.com>; Tue, 18 Jun 2013 07:00:30 -0700 (PDT)
Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6F721F9B16 for <OSPF@ietf.org>; Tue, 18 Jun 2013 07:00:30 -0700 (PDT)
Received: by mail-oa0-f42.google.com with SMTP id n12so5109236oag.29 for <OSPF@ietf.org>; Tue, 18 Jun 2013 07:00:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uYVaUhaHNtKetiRh4NuevrbThFVUarjoChIT8sZdn9E=; b=EmOeX2lG5WdOhKB+XT9TcHMSHWD8IfhqgC+QLN1Wm9DRE6c+fVfnoDYKtoR/V7JI8j TWFaJ7pwoRT4ZYXe72cBJRpbRzEH5uC7WvhVSXAvEO3XSRyC0zeBdIKoI/AbAKqKxnqd fHqaEfcMRlGK14h3DR7TslVpRQM7kQXF6hGI7Ta5ASGha8WOffmpG6IXKF91ePKy4zNY rpGADOsP0uWfN8q3ghnN4tDQrQ+PKt+wjabGm2OwRlZastu/hmKEkxsNjomwAYGO4FdC SmYZFNKpOBxkYLP0hyphLrS5+Y880RLFQkYFrjLgo3srZXrVAcVqSSLbEd1CcH8x1GBz 2FZg==
MIME-Version: 1.0
X-Received: by 10.182.144.231 with SMTP id sp7mr12380418obb.14.1371564029797; Tue, 18 Jun 2013 07:00:29 -0700 (PDT)
Received: by 10.182.42.201 with HTTP; Tue, 18 Jun 2013 07:00:29 -0700 (PDT)
In-Reply-To: <B39429F1A3EA1A4A9110CEC3D99263EA14C81146@BN1PRD0512MB620.namprd05.prod.outlook.com>
References: <B39429F1A3EA1A4A9110CEC3D99263EA14C81146@BN1PRD0512MB620.namprd05.prod.outlook.com>
Date: Tue, 18 Jun 2013 19:30:29 +0530
Message-ID: <CAOyRfUwbxrA=Og9kfNwiQdqVBJ9+pUT4v6L_hOR=M26_EFnQHg@mail.gmail.com>
From: Tanmoy Kundu <tanmoycs@gmail.com>
To: Bharath R <rbharath@juniper.net>
Content-Type: multipart/alternative; boundary="089e0153686cc8704804df6e223a"
Cc: "OSPF@ietf.org" <OSPF@ietf.org>, Dileep Singh <dsachan@juniper.net>
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: Tue, 18 Jun 2013 14:00:43 -0000

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> 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.
>
>
>    1. Declares itself the DR.
>    2. Declares BDR as NULL.
>    3. Sends out a Hello with DR as I2 interface address, and BDR as
>    0.0.0.0
>
>
>    1. 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 **e**vent, 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
> https://www.ietf.org/mailman/listinfo/ospf
>
>