IETF Logo Mail Archive

Re: [OSPF] draft-ietf-ospf-link-overload-06 - DR migration

Shraddha Hegde <shraddha@juniper.net> Tue, 25 April 2017 04:00 UTC

Return-Path: <shraddha@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 3C402127071; Mon, 24 Apr 2017 21:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.79
X-Spam-Level:
X-Spam-Status: No, score=-4.79 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 a-FNZSyfBIgN; Mon, 24 Apr 2017 21:00:56 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0119.outbound.protection.outlook.com [104.47.34.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0730127698; Mon, 24 Apr 2017 21:00:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MqdoZNDNF37OaGZZoVc3HNmiCo7biOc1CSjS9l1+R0g=; b=DCF2j1gdEDB3zvf0XD8eLy3YR1yEA29Yb0NeDpVbrn3z3cNBgjfy6VnTHvhKiWquulB9Cl4Wizx4MrYkuw2OEYgvMe5yCrJb66JRHFpZrRiB7b24c3rUc3Afnn86Izj5XLexdS/n+Ca/Ke4pFTqTizHW0O4jrfn9cGrTZI1+x94=
Received: from BN3PR05MB2706.namprd05.prod.outlook.com (10.167.2.135) by BN3PR05MB2706.namprd05.prod.outlook.com (10.167.2.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Tue, 25 Apr 2017 04:00:53 +0000
Received: from BN3PR05MB2706.namprd05.prod.outlook.com ([10.167.2.135]) by BN3PR05MB2706.namprd05.prod.outlook.com ([10.167.2.135]) with mapi id 15.01.1061.011; Tue, 25 Apr 2017 04:00:53 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: Alexander Okonnikov <alexander.okonnikov@gmail.com>, "draft-ietf-ospf-link-overload@ietf.org" <draft-ietf-ospf-link-overload@ietf.org>, "ospf@ietf.org" <ospf@ietf.org>
Thread-Topic: draft-ietf-ospf-link-overload-06 - DR migration
Thread-Index: AQHSudlPlJRn5dQmKE28nEUbwcQO5KHUTKkQgAADoYCAASuwMA==
Date: Tue, 25 Apr 2017 04:00:53 +0000
Message-ID: <BN3PR05MB270601468708067EA21F1456D51E0@BN3PR05MB2706.namprd05.prod.outlook.com>
References: <37c8fb2e-a6ba-4e2d-8009-62c83c816f62@Spark> <BN3PR05MB2706EA28BBE87AB62CBC565BD51F0@BN3PR05MB2706.namprd05.prod.outlook.com> <99b6aa93-680f-c794-3cd8-a876a6d82e98@gmail.com>
In-Reply-To: <99b6aa93-680f-c794-3cd8-a876a6d82e98@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [116.197.184.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR05MB2706; 7:G7YJAnr8rFXWLvNB+vbWsN8naQ63mDb2F1rL5eYtdxp2NSKmHlBnCsDO417pXz35ji6YL9Ggr7SBKnyMD+u3odkU3njL7KDuwuqR0AyS3c8noITB2jULy6W0oUr+RVZGYD3oZKe0GDzlkF8bXuhPbuE+y7z0rmTGeSMzdTbbh6irUNv4Dp62kJw2k6mLWDcCGoGqNSMYOmdCA22G+p0prS7MaIIeEHY4umzyUuA++iNVUr/6pfT/p582dmdn3geQ0Lxlm/0j7ofP/jd6sJH2JsVLtF5+j6We7htYw+UNbp9koH7uoGBxsVMtOt+JWOl00ARjfM+BXshdcq0eJfGw+w==
x-ms-office365-filtering-correlation-id: ee3caf39-4ee9-40f0-8c60-08d48b8fab54
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR05MB2706;
x-microsoft-antispam-prvs: <BN3PR05MB2706A39D2ACC1D42713EA0D0D51E0@BN3PR05MB2706.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(138986009662008)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123564025)(6072148); SRVR:BN3PR05MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2706;
x-forefront-prvs: 0288CD37D9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39400400002)(39840400002)(39410400002)(39450400003)(39860400002)(377454003)(39060400002)(38730400002)(33656002)(53546009)(25786009)(122556002)(81166006)(8676002)(76176999)(50986999)(8936002)(54356999)(53936002)(6506006)(102836003)(6116002)(189998001)(3846002)(5660300001)(66066001)(790700001)(55016002)(54896002)(2950100002)(236005)(99286003)(7696004)(86362001)(74316002)(77096006)(9686003)(6306002)(2900100001)(2201001)(2501003)(7736002)(229853002)(6246003)(3280700002)(230783001)(6436002)(2906002)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2706; H:BN3PR05MB2706.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR05MB270601468708067EA21F1456D51E0BN3PR05MB2706namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2017 04:00:53.6170 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2706
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/zuBd0kKH3yaW2V_-hcLDu35YHhg>
Subject: Re: [OSPF] draft-ietf-ospf-link-overload-06 - DR migration
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Apr 2017 04:00:58 -0000

Yes. You are right.

This is a problem specific to BDR taking over the role of DR.
The problem you describe has been around for a while and I have seen people using
decent workarounds without requiring protocol changes to solve this problem.

Rgds
Shraddha

From: Alexander Okonnikov [mailto:alexander.okonnikov@gmail.com]
Sent: Monday, April 24, 2017 3:33 PM
To: Shraddha Hegde <shraddha@juniper.net>; draft-ietf-ospf-link-overload@ietf.org; ospf@ietf.org
Subject: Re: draft-ietf-ospf-link-overload-06 - DR migration


Hi Shraddha,



For planned link maintenance there still could be traffic disruption. Even if router with overloaded link is detached from broadcast link, the latter still could be used by other routers on this one. If router with overloaded link was DR, traffic between other routers on broadcast link could be disrupted. Am I correct?

24.04.2017 12:55, Shraddha Hegde пишет:
Hi Alexander,

The objective of this draft is to re-route the traffic from the link that is expected to undergo maintenance
And the case of broadcast links  is explained in sec 5.2 which achieves the objective.

The case you described may be relevant for unplanned link-down events which is outside the scope of this draft.

Thanks
Shraddha


From: Alexander Okonnikov [mailto:alexander.okonnikov@gmail.com]
Sent: Thursday, April 20, 2017 6:50 PM
To: draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>; ospf@ietf.org<mailto:ospf@ietf.org>
Subject: draft-ietf-ospf-link-overload-06 - DR migration

Hi authors,

In case when the node that has the link to be overloaded is DR (for
broadcast/NBMA link case), taking this link out of service could be
disruptive. What if to modify procedure in such manner that when BDR
receives Link-Overload-sub-TLV from DR, it generates Network LSA in
advance, before taking DR role. The node with overloading link then
waits some time (for example, 3 secs) and changes its interface priority
to 0.

Thank you.

v2.20.3 | Report a Bug | By Email