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

Alexander Okonnikov <alexander.okonnikov@gmail.com> Tue, 25 April 2017 12:08 UTC

Return-Path: <alexander.okonnikov@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 36F4812869B; Tue, 25 Apr 2017 05:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.688
X-Spam-Level:
X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 (2048-bit key) header.d=gmail.com
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 3tzdMifnDBbR; Tue, 25 Apr 2017 05:08:44 -0700 (PDT)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109F912EC5F; Tue, 25 Apr 2017 05:08:42 -0700 (PDT)
Received: by mail-lf0-x22b.google.com with SMTP id t144so89541841lff.1; Tue, 25 Apr 2017 05:08:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=km+m5J/y2Uvv32hJkdVctQcMVcJGpMtwxfaQGyDdHbU=; b=G8hWBSSCfg6J6HXMAqbKjckbSMC/ZB/R1kD/5p/xMVoP3yZpq+tcjx+uuekxTBosOe bnBtcfoeQkfQLhHsvqS60NdfkwzImT7X5adomqwofoy6DDYSTibXbWES3Y2obbw5f/Kn RjuSCriXp3V+1ioodlx+gifNJbxfBtGDSnya/xqV12BnEIL2ElKeiRmr4nMxG4v8K8Av sjCxvvGJzU4MjRaJHyyhyC4l9rkCHJJGQdKJrbKAjUfIzryCCshPnIL9DGhFf8ZTmuNy PesdrzXE3+2EV0Mu7YXgQq8MuJcJfRf7ALCYkJeO1bpvZ9jdDfwCVzLAQ/VXw+PivCGI cmaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=km+m5J/y2Uvv32hJkdVctQcMVcJGpMtwxfaQGyDdHbU=; b=qEpQYDayETw2ipaeSM2L411d1/1YHl2NL+RbMM4FSWdgQUSzqaCPCpyMNbU3sIMOsQ yvALP9C6xsgmcuyM1++Tb6NhMuUJrZIv9e9/IvF6+lHla2sPO2yacP3OjbLBH7qsJ/Ru adb9lj/mICLDB0svq004IWctTOYT4nGxDYaRE0k6OFYcsYx6ze7iUzL/JucrlxjYNVuV JyyIhUW0rJ/rPY2SsY2gC2BhB+kCaH+kHZ8OOX3pqO1rQocu7U/ZhnDZ/FTWz4A0fq9Y VBDvAHpu7HCXJayUqmfI9u+wcG6A6w3tmY9Ae0laXrx+RsJAeKpw2sj4fo49WqZqdhOv y9cA==
X-Gm-Message-State: AN3rC/7Wbz13mUYm420QEBRDkrw0kDwC25YINcpv/SGK9W9nWz39kh43 fQzIvRfqPOm0hYce
X-Received: by 10.25.15.81 with SMTP id e78mr11231716lfi.144.1493122120066; Tue, 25 Apr 2017 05:08:40 -0700 (PDT)
Received: from [192.168.1.17] (secretmaker-96.ip.PeterStar.net. [217.195.72.96]) by smtp.gmail.com with ESMTPSA id z26sm3871258lja.28.2017.04.25.05.08.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 05:08:39 -0700 (PDT)
To: Shraddha Hegde <shraddha@juniper.net>, "draft-ietf-ospf-link-overload@ietf.org" <draft-ietf-ospf-link-overload@ietf.org>, "ospf@ietf.org" <ospf@ietf.org>
References: <37c8fb2e-a6ba-4e2d-8009-62c83c816f62@Spark> <BN3PR05MB2706EA28BBE87AB62CBC565BD51F0@BN3PR05MB2706.namprd05.prod.outlook.com> <99b6aa93-680f-c794-3cd8-a876a6d82e98@gmail.com> <BN3PR05MB270601468708067EA21F1456D51E0@BN3PR05MB2706.namprd05.prod.outlook.com>
From: Alexander Okonnikov <alexander.okonnikov@gmail.com>
Message-ID: <e2367ae0-b0b5-b994-ce2e-86efbd4cf699@gmail.com>
Date: Tue, 25 Apr 2017 15:08:38 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <BN3PR05MB270601468708067EA21F1456D51E0@BN3PR05MB2706.namprd05.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------09833DBC5C999A30C22E1939"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/k6L_TNj9NibWJyb3rsbfIxGE26s>
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 12:08:46 -0000

Hi Shraddha,


I thought that one of goals of the draft is to minimize manual 
intervention as a preparation for maintenance. My assumption is that 
workarounds do require some manual intervention. Are mentioned 
workarounds specific for particular implementation where BDR always 
generates Network LSA in addition to DR's Network LSA? Or is essence of 
workarounds in (manual) tuning of SPF delay timer?


Thank you.


25.04.2017 07:00, Shraddha Hegde пишет:
>
> 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.
>