IETF Logo Mail Archive

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

Alexander Okonnikov <alexander.okonnikov@gmail.com> Thu, 20 April 2017 13:23 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 3071712951E; Thu, 20 Apr 2017 06:23:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, 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 r32vz_8EopoG; Thu, 20 Apr 2017 06:23:27 -0700 (PDT)
Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (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 D68D2128656; Thu, 20 Apr 2017 06:23:26 -0700 (PDT)
Received: by mail-lf0-x243.google.com with SMTP id i3so5801078lfh.2; Thu, 20 Apr 2017 06:23:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version; bh=FZuqm2JFj2lfe4F3aLzqlM69AQJ/E9J+WTDZzivLoMw=; b=FHdOU28S0mrC4a4/CPlM/Rqv8K4GU7OKUAQfx/aqk7+PApYtVcHBqmu74dxeVc6z6V 1VazDAYZbxV5bsZMWCa1fokeHduG2ExdNNl6jtfLQc76F/3M5M1Pj4o7GyOv9L+wNuU2 /9SwkZ1m125y5AeKqs2zrq8trHvVcfIy+sZHYzzGjNZYxEIjhQ4ld4seccrSja1hKofT lUw5lLVZPyKpgcDNdIjjo6c/6mFHbH++CTCffDIKsSwyJIyoDpWMmF6tuULU63ryYPLh 9Nr/DcAtr79IdYVT2R/E3m1onjrMIrNRnxBUnR3JWNdZM/jwGvMUl1tXE1iUauAUKycY T+IQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:subject:mime-version; bh=FZuqm2JFj2lfe4F3aLzqlM69AQJ/E9J+WTDZzivLoMw=; b=Vl2fkTc258/s/3rSwc7TtGNKWUR5+XmXZ3nGRv2MAQ9yQmhai/zYNBMxq83sUlTBU4 XAmwTBvu9K1bA/Mziljp28egpomomjLhH+Ek6iCJT0frl3tVsyfWg0eSX/QQI16YRGut PEDnid0yxliyN+a1lnCUiGNEXjCW9wY8UMiQBQ9t1KOBo+whgTtNsBIM5ZhajcFHh+Ca 9N2UTjWxrXO6xHcqSqXeQsXXPsm1n5XGozi09af0kkC3zVbvY9/ngon/zC22W8VCdzwb 3LtU1MatvvBGW70YsHqbij7yNGthJ7Twj/j2zpM22CdGWSG+A4MlAUHgGH8sBaG0xh9Z I3Qg==
X-Gm-Message-State: AN3rC/74Ouj1PGHHwPFa2jlJArnAbkNI8lDbTFHemBE4mjtGMa6nbnpU SQShA2Et5tc7AxYCAXs=
X-Received: by 10.25.196.71 with SMTP id u68mr2898751lff.87.1492694604870; Thu, 20 Apr 2017 06:23:24 -0700 (PDT)
Received: from [10.152.89.147] (host-156-159-66-217.spbmts.ru. [217.66.159.156]) by smtp.gmail.com with ESMTPSA id y25sm1045907lja.7.2017.04.20.06.23.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 06:23:24 -0700 (PDT)
Date: Thu, 20 Apr 2017 16:19:44 +0300
From: Alexander Okonnikov <alexander.okonnikov@gmail.com>
To: draft-ietf-ospf-link-overload@ietf.org, ospf@ietf.org
Message-ID: <37c8fb2e-a6ba-4e2d-8009-62c83c816f62@Spark>
X-Readdle-Message-ID: 37c8fb2e-a6ba-4e2d-8009-62c83c816f62@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="58f8b5dd_74b0dc51_f4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/_zPorG46leZoHVT3dmhbO3OxBAA>
Subject: [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: Thu, 20 Apr 2017 13:23:31 -0000

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.23.0 | Report a Bug | By Email