Re: [OSPF] OSPF GR and BFD operability

"Acee Lindem (acee)" <> Tue, 25 August 2015 16:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8D1D21A8711 for <>; Tue, 25 Aug 2015 09:44:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HaPLenLFfh0S for <>; Tue, 25 Aug 2015 09:44:41 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB0481A86E2 for <>; Tue, 25 Aug 2015 09:41:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=23063; q=dns/txt; s=iport; t=1440520913; x=1441730513; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=akYcbjXy6eyg/twZ9IROfUvAM86RKu7hvYS1BKVjT8U=; b=fWxIRMXq2/eDBN5V7Ka42kfBFLt1GB5BIGOFkA7i+JEInWw4fwXhUZiV 2H2podXXWxk7raB3UUTJCwDQkiU7cROG2UEwuKGroxlxfmAr75KgW0pDz anGvCnCCuUJeABPSiiTz1nGTCMSIvHNstotOVSEUydnxcs7yHOk9MWsF8 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.15,747,1432598400"; d="scan'208,217";a="181820189"
Received: from ([]) by with ESMTP; 25 Aug 2015 16:41:52 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t7PGfplA029210 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Aug 2015 16:41:51 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 25 Aug 2015 11:41:50 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 25 Aug 2015 11:41:50 -0500
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Tue, 25 Aug 2015 11:41:50 -0500
From: "Acee Lindem (acee)" <>
To: "Les Ginsberg (ginsberg)" <>, Anil Raj <>
Thread-Topic: [OSPF] OSPF GR and BFD operability
Thread-Index: AQHQ30EdJhQjUSmLyUGmsy+tTypsap4c3f6AgABMkICAAAZuAIAACrqA///AeAA=
Date: Tue, 25 Aug 2015 16:41:50 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D20212C12C975aceeciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: OSPF WG List <>
Subject: Re: [OSPF] OSPF GR and BFD operability
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Aug 2015 16:44:43 -0000

I agree. Thanks Les for the reference to RFC 5882.


From: "Les Ginsberg (ginsberg)" <<>>
Date: Tuesday, August 25, 2015 at 12:29 PM
To: Anil Raj <<>>
Cc: Acee Lindem <<>>, OSPF WG List <<>>
Subject: RE: [OSPF] OSPF GR and BFD operability

Anil –

IF BFD does NOT share fate w the Control plane then what you say is true.

If BFD shares fate w the control plane then the behavior depends on the neighbor knowing that a restart is in progress. If neighbor knows this then the BFD down event can be ignored w minimal risk – otherwise you need to treat it as a real failure.


From: Anil Raj []
Sent: Tuesday, August 25, 2015 8:51 AM
To: Les Ginsberg (ginsberg)
Cc: Acee Lindem (acee); OSPF WG List
Subject: Re: [OSPF] OSPF GR and BFD operability

Thanks Acess, Les.

So ideally it is recommended to tear down OSPF adjacency and signal topology change, and thus honor BFD notification in this case.


On Tue, Aug 25, 2015 at 8:57 PM, Les Ginsberg (ginsberg) <<>> wrote: Section 4.3<> is relevant here.


From: OSPF [<>] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 25, 2015 7:54 AM
To: Anil Raj; OSPF WG List
Subject: Re: [OSPF] OSPF GR and BFD operability

Hi Anil,

OSPF and OSPFv3 graceful restart pre-dated BFD so this wasn’t explicitly covered. However, given that the intension is that the data plane is preserved during restart, an implementation could interpret this as a topology change and terminate helper mode as documented in section 3.2 of RFC 3623.
Hope this helps,

From: OSPF <<>> on behalf of Anil Raj <<>>
Date: Tuesday, August 25, 2015 at 10:19 AM
To: OSPF WG List <<>>
Subject: [OSPF] OSPF GR and BFD operability


I need clarification on the behavior when BFD notifies remote inactivity for a OSPF session, when OSPF neighbor is undergoing Graceful restart? OSPF router in helper mode will ideally inactivate the restarting neighbor only after grace period, and if BFD notifies neighbor down to OSPF, should the adjacency be terminated? If not, will it cause a blackhole for the entire grace period if the neighbor is actually down?

Appreciate if you can help here.