Return-Path: 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 , "draft-ietf-ospf-link-overload@ietf.org" , "ospf@ietf.org" References: <37c8fb2e-a6ba-4e2d-8009-62c83c816f62@Spark> From: Alexander Okonnikov 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: Content-Type: multipart/alternative; boundary="------------8F85B06B2E1BDF2F1F52DEEA" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 10:03:23 -0000 This is a multi-part message in MIME format. --------------8F85B06B2E1BDF2F1F52DEEA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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. > --------------8F85B06B2E1BDF2F1F52DEEA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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.

 


--------------8F85B06B2E1BDF2F1F52DEEA--