IETF Logo Mail Archive

Re: [OSPF] OSPF GR and BFD operability

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Tue, 25 August 2015 16:29 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27F41A0393 for <ospf@ietfa.amsl.com>; Tue, 25 Aug 2015 09:29:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jg6zsFq_u3Py for <ospf@ietfa.amsl.com>; Tue, 25 Aug 2015 09:29:25 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CCAA1A033A for <ospf@ietf.org>; Tue, 25 Aug 2015 09:29:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21196; q=dns/txt; s=iport; t=1440520165; x=1441729765; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lcbUxb1TXUJQsF4T6D53AseEKw1UG7/LBiiwNAwDh9Q=; b=KKnMJxabT+CbxXvv4fDnZxOuvaKp994/RcAC+0baNDJG+RiwkM4leFK4 wrge5y64q6T4uq4tNJCFnxLv/ZN37HdGg0nBoYMTVKq9NI9PlxDL4mw1Y SUC2SKJ28vtCEkP5c6/ZN/o7Du3HE71uPrJzI15AMOi7XGA7KCf2iaA/E 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ChAgAfl9xV/5hdJa1dgk5NVGkGgx+6ZgEJgXeFewIcgRg4FAEBAQEBAQGBCoQjAQEBBCMKTBACAQgRAwEBAQsdAwICAh8RFAkIAgQOBQiIEQMSDbJ2j2ENhS4BAQEBAQEBAQEBAQEBAQEBAQEBAQETBItXgk+BYCogDQQGAYJpL4EUBZU3AYsElQeHOiaDfnEBAYFGgQQBAQE
X-IronPort-AV: E=Sophos; i="5.15,746,1432598400"; d="scan'208,217"; a="23423139"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 25 Aug 2015 16:29:24 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t7PGTOuJ026385 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Aug 2015 16:29:24 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 25 Aug 2015 11:29:23 -0500
Received: from xhc-aln-x11.cisco.com (173.36.12.85) by xch-aln-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 25 Aug 2015 11:29:23 -0500
Received: from xmb-aln-x02.cisco.com ([169.254.5.3]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0248.002; Tue, 25 Aug 2015 11:29:23 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Anil Raj <anilraj85@gmail.com>
Thread-Topic: [OSPF] OSPF GR and BFD operability
Thread-Index: AQHQ30EdcykVrLLZMEmoUK29+OkpU54dIP8A//+1cuCAAFqLAP//s3Iw
Date: Tue, 25 Aug 2015 16:29:23 +0000
Message-ID: <F3ADE4747C9E124B89F0ED2180CC814F595619CA@xmb-aln-x02.cisco.com>
References: <CAPj3AOpO+o2hBp3J+mPXpwWiho5fMxE97b1SKsHigRfTQSGzjw@mail.gmail.com> <D201F336.2C912%acee@cisco.com> <F3ADE4747C9E124B89F0ED2180CC814F5956187C@xmb-aln-x02.cisco.com> <CAPj3AOok5_dY9mq=95aLji52-MbkwCrCAQisR4T4XipO5JpDfw@mail.gmail.com>
In-Reply-To: <CAPj3AOok5_dY9mq=95aLji52-MbkwCrCAQisR4T4XipO5JpDfw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [128.107.163.77]
Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F595619CAxmbalnx02ciscoc_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/E9ij2RMEb3nKCM1RneNgyz48H4w>
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] OSPF GR and BFD operability
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 25 Aug 2015 16:29:27 -0000

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.

   Les


From: Anil Raj [mailto:anilraj85@gmail.com]
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.

Regards,
Anil

On Tue, Aug 25, 2015 at 8:57 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> wrote:
https://www.rfc-editor.org/rfc/rfc5882.txt Section 4.3<https://www.rfc-editor.org/rfc/rfc5882.txt%20Section%204.3> is relevant here.

   Les


From: OSPF [mailto:ospf-bounces@ietf.org<mailto:ospf-bounces@ietf.org>] 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,
Acee



From: OSPF <ospf-bounces@ietf.org<mailto:ospf-bounces@ietf.org>> on behalf of Anil Raj <anilraj85@gmail.com<mailto:anilraj85@gmail.com>>
Date: Tuesday, August 25, 2015 at 10:19 AM
To: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: [OSPF] OSPF GR and BFD operability

Hi,

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.

Regards,
Anil

v2.2.1 | Report a Bug | By Email