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

Alexander Okonnikov <alexander.okonnikov@gmail.com> Mon, 24 April 2017 10:03 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 76A3512EBF6; Mon, 24 Apr 2017 03:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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] 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 xTWE3tVFvStR; Mon, 24 Apr 2017 03:03:21 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 596CB12EBF4; Mon, 24 Apr 2017 03:03:21 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id 88so70913012lfr.0; Mon, 24 Apr 2017 03:03:21 -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=ZpNm6fo1nyH/Yavbezn3BiEvA5/dG/bsGUue3h/8y2w=; b=rg1a1QGAFK/GP2ZQBkelw1DtF4XgMNkXDk3jK977pkdUs50am7dWiAIF677JJ2BDvE JYu0DLaxtMcal3n3QtS7f4VtxZA/dPU3nwVJ4qrFHnu3uGCew0ZSyTXWhCYOeOIuKzZ4 yV2/2Yi/p+6tFW1UAYxPQLnbuXGfhh0cOE22uzzhmZ9KNpWQKgrfgYEoin9J/Hg098i2 7dHi/Xx6lSau6Y9YyVYhkcpOUmfusR4CVk556AWI/tEdLlQanjBKWhwLd9Ms63MQkoca HFiuxDJjfbhmxQHdtrRETieNr0Smjhzg3OfS2dvlkP/3Isfd/DdgTAcKBuwxZB0Bflvi XW9Q==
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=ZpNm6fo1nyH/Yavbezn3BiEvA5/dG/bsGUue3h/8y2w=; b=huvtNgvXdfNOmKv9BTplolGnY/WVzbRRPYs+/CSrOcUcwlh6qELliggA0vpdvpjXkD NHflP+9X0i6+8vRzGveqEO47XVb/BJMaJnKosfbV3BAytF/xdc0a4nrUEzK3qVIoQRUY gw04TPWUJtXDIkf0Bo0+hbel7jrPOUlLNb9tv5dRKn1H0J87XQUV9E/Y3lBqsnQ+9f17 /U94L9Ic4+OB++GGbN7NC1Akr7EzmTLLXbJ0C0gbqQYbNPJuqKkVHFBs8fFA/pHh/4GX CfYUTkDstYLtgXcDdZ0j648rksncMACE7EFTV/x7lP3c4625KHY6TDuZO1Fz3jwERW/j +Ryw==
X-Gm-Message-State: AN3rC/5gNT/m4C/snXUkHjtz7SA4yWvUXBoCK1bHl+eFp3sMVrXj7laJ 7/lNaZpDuPJ5ePDFa48=
X-Received: by 10.46.33.93 with SMTP id h90mr3547881ljh.53.1493028199338; Mon, 24 Apr 2017 03:03:19 -0700 (PDT)
Received: from [192.168.1.17] (secretmaker-96.ip.PeterStar.net. [217.195.72.96]) by smtp.gmail.com with ESMTPSA id i1sm3265065ljd.47.2017.04.24.03.03.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 03:03:18 -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>
From: Alexander Okonnikov <alexander.okonnikov@gmail.com>
Message-ID: <99b6aa93-680f-c794-3cd8-a876a6d82e98@gmail.com>
Date: Mon, 24 Apr 2017 13:03:17 +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: <BN3PR05MB2706EA28BBE87AB62CBC565BD51F0@BN3PR05MB2706.namprd05.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------8F85B06B2E1BDF2F1F52DEEA"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/YT3UW9qePxZrd3tWtqiINcjEyBg>
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: Mon, 24 Apr 2017 10:03:23 -0000

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; 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.
>