Re: [Lsr] Migration between normal flooding and flooding reduction

tony.li@tony.li Tue, 21 May 2019 00:05 UTC

Return-Path: <tony1athome@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF36120090 for <lsr@ietfa.amsl.com>; Mon, 20 May 2019 17:05:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 yN-EURGJkEDc for <lsr@ietfa.amsl.com>; Mon, 20 May 2019 17:05:51 -0700 (PDT)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 488A4120046 for <lsr@ietf.org>; Mon, 20 May 2019 17:05:51 -0700 (PDT)
Received: by mail-pg1-x52e.google.com with SMTP id t187so7541962pgb.13 for <lsr@ietf.org>; Mon, 20 May 2019 17:05:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=SAvQbt0fSFqA9WhsAjpcfwFdDs3p+iPMomDV/sP9H7g=; b=jSBMnIwR/dO0UZhwzOhaWZDjsRxM7JHwwK9NwL68jyVgEl8S1F587zfh7qmnUyGulA Bhf7qLnQzMsMVS6U0IrKGKcpAumjOfiA8q/Hn/WxnQHAL/XU7WJ21baP02r+AEHHxwKZ iJPN8I6yY2tnuB/dxFR+9bObz0uRIA2fDztP+VQlecGXEHsmKjppc99viyiC+PrQdOKM EQMuIXrQ52vQ7lYJCWzG7ukmwSEmwPhWvrgwbr+JYcDhB/UrJ/yPelYvtLorwxWMX7+p cwnrAUVuBs2wp9KWrPTykwcG6z17CSKFGOB+WCLiaorWVqNZSGtyq0U7YdKkMSd2403R Fzaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=SAvQbt0fSFqA9WhsAjpcfwFdDs3p+iPMomDV/sP9H7g=; b=swrSEfsapJBKP339KaPimx5YgUZLCjppvp91SI20g6fIpX0oZ6rd16XPBZLcOMmtws ymT8mfo064F1Mku8Q23Nw6m5cSnK/+0SaMSk2vSd2iFnN978CsUc4yyynKGAVYg+Y7U+ JVdaxWWAlLKWT8ScvvH+Ap72R9x+zqYJ8HJHUcD4KPo02iigr/RbwI3gAr3C8o5bZ4uJ FU37zcvLYsEnW6Tt2oZOtRcOraDbmKT9WMY/zH55dJwC42e1ZsEVKV9pnI+W1d74Eeo9 99F3gOH+W9BTDj2OQmUoNIPpt2EqvxVthJacaTmO5YWaO/E5c6AuGA2doALEjEprfBp6 JO4A==
X-Gm-Message-State: APjAAAXvC39W5xX6hrFQaYtI2LK8dlsO+lq6Vq8LESqc5qgAtqprXoKO tjFZ6Y8buaMG4NN0LV7kQlE=
X-Google-Smtp-Source: APXvYqy53q4etixZ+n+prgtwDgn/Nd4H5pge9ZI3MtWXPNzHJX8fUyiNRbPBQQX6YqpU1yOK6JZgEw==
X-Received: by 2002:a62:6d47:: with SMTP id i68mr83858019pfc.189.1558397150607; Mon, 20 May 2019 17:05:50 -0700 (PDT)
Received: from [172.22.228.83] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id i27sm39613954pfk.162.2019.05.20.17.05.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 May 2019 17:05:49 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Message-Id: <C1187657-375E-4179-A02C-F4C8E5416C00@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1C7E0AA5-7DB5-48B7-A71C-F8B354160656"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Mon, 20 May 2019 17:05:49 -0700
In-Reply-To: <5316A0AB3C851246A7CA5758973207D463BC58F5@sjceml521-mbx.china.huawei.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>
To: Huaimo Chen <huaimo.chen@huawei.com>
References: <5316A0AB3C851246A7CA5758973207D463BBD21B@sjceml521-mbs.china.huawei.com> <CF5E5FE7-C2E2-4200-AE8A-6BF5E558258C@tony.li> <5316A0AB3C851246A7CA5758973207D463BC58F5@sjceml521-mbx.china.huawei.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ELo9uMIn0bZ8phwZve7GRT_Nvdk>
Subject: Re: [Lsr] Migration between normal flooding and flooding reduction
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 May 2019 00:05:54 -0000

Huaimo,

This seems like it’s a job for the NMS/configuration management system and that there are no protocol interactions required.  

Oh, and yes, we are working on a YANG model for this feature.  We hope that this will be ready by Montreal.

The only concern that I would have is that removing dynamic flooding in some dense topologies would enable a cascade failure.  No process is going to alleviate that because those topologies simply cannot support legacy flooding.  

Tony


> On May 20, 2019, at 12:53 PM, Huaimo Chen <huaimo.chen@huawei.com> wrote:
> 
> Hi Tony,
>  
>     For the case that the IGP running in an area has been doing the flooding reduction, in order to let the IGP on every node in the area roll back to the normal flooding quickly and easily, a procedure for migrating from the flooding reduction to normal flooding is needed. After back to normal flooding, if we want to let the IGP on every node do flooding reduction some time later, the procedure should be able to migrate from normal flooding to the flooding reduction quickly and easily.
>  
> Best Regards,
> Huaimo
> From: Tony Li [mailto:tony1athome@gmail.com] On Behalf Of tony.li@tony.li
> Sent: Saturday, May 18, 2019 1:17 PM
> To: Huaimo Chen <huaimo.chen@huawei.com>
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Migration between normal flooding and flooding reduction
>  
>  
> Hi Huaimo,
>  
> Before we get into your procedure, I have to ask an important question: why is any process necessary?
>  
> In our experience, It Just Works.
>  
> You turn on dynamic flooding and the nodes with the feature start complying with the flooding topology.  Those that are not enabled perform legacy flooding. Obviously you don’t get the flooding reduction yet, but it grows incrementally as nodes are enabled.
>  
> What problem are you solving?
>  
> Tony
>  
>  
> 
> 
> On May 18, 2019, at 8:15 AM, Huaimo Chen <huaimo.chen@huawei.com <mailto:huaimo.chen@huawei.com>> wrote:
>  
> Hi Tony,
>  
> Two possible procedures (Procedure A and B) for the migration are listed below for discussions.
>  
> In the beginning, the IGP running in a network area does the normal flooding. The migration from the normal flooding to the flooding reduction (either centralized mode or distributed mode) or in reverse (i.e., roll back from the flooding reduction to the normal flooding) may follow a procedure of a few steps. One of the two procedures below may be used.
>  
> Procedure A:
>  
> 1.       For each node that is eligible to become a leader for flooding reduction in centralized mode, a priority for the leader election is configured on the node. (This step is called “Priority Configuration”).
> 2.       Every node advertises its priority for the leader election and the algorithms that it supports for computing flooding topology for distributed mode. (This step is called “Priority and Algorithms Distribution”). Note that this step and the step above may be considered as one step. After a priority is configured on a node, the node will advertises its priority and algorithms.
> 3.       On the node that will be elected as the leader, “Start Leader Election” is configured. The node does the leader election after obtaining “Start Leader Election”. It also advertises this to all the other nodes in the area. Each of them will do the leader election after receiving this. (This step is called “Leader Election”). Note that this step may be removed. Without this step, the leader election may occur multiple times until the leader with the highest priority and highest node ID is elected if we want that the leader is the node that has the highest priority and highest node ID in the area.
> 4.       On the node that is elected as the leader, centralized mode or distributed mode is configured. (This step is called “Flooding Reduction Mode Configuration”).
> For centralized mode (i.e., when centralized mode is configured),
> 1)      the leader advertises “Flooding Reduction” in the centralized mode to all the other nodes;
> 2)      the leader computes the flooding topology and advertises the flooding topology to the other nodes;
> 3)      each node floods the link states using the flooding topology after it receives/has the whole flooding topology.
> For distributed mode (i.e., when distributed mode is configured), an algorithm is also configured to be used by every node to compute flooding topology
> 1)      the leader advertises “Flooding Reduction” in the distributed mode including the algorithm to all the other nodes;
> 2)      each node computes its flooding topology and floods the link states using the flooding topology.
> At this point, the IGP running in the network area has migrated from the normal flooding to the flooding reduction (either centralized mode or distributed mode).
>  
> In centralized mode, configuring distributed mode (or changing the centralized mode to distributed mode through configuration) will transfer from centralized mode to distributed mode. In addition to step 1) and 2) above for the distributed mode, each node uses the centralized flooding reduction (i.e., floods the link states over its local links on the flooding topology computed by the leader of the area) until the distributed flooding reduction is fully functional for a given time such as 5 seconds. After this time, the node stops its centralized flooding reduction. The leader stops computing the flooding topology, advertising it to all the other routers, and using this flooding topology to flood the link states. Each of the other nodes stops receiving and building the flooding topology computed by the leader.
>  
> In distributed mode, configuring centralized mode (or changing the distributed mode to centralized mode through configuration) will transfer from distributed mode to centralized mode. In addition to step 1), 2) and 3) above for the centralized mode, each node uses the distributed flooding reduction (i.e., floods the link states over its local links on the flooding topology computed and built by itself) until the centralized flooding reduction is fully functional for a given time such as 5 seconds.
> 
> For the migration (or say roll back) from the flooding reduction to the normal flooding,
> a.       on the leader node, “Roll Back to Normal Flooding” is configured; (This step is called “Roll Back to Normal Flooding Configuration”).
> b.       the leader advertises “Roll Back to Normal Flooding” to all the other nodes; (This step is called “Roll Back to Normal Flooding Distribution”).
> c.       every node rolls back to the normal flooding after obtaining the instruction for rolling back to the normal flooding. Every node will floods link states using all its local links instead of the local links on the flooding topology. (This step is called “Stop Using Flooding Topology”).
> For the centralized mode, after rolling back to normal flooding, the leader of the area stops computing and advertising the flooding topology, each of the other nodes stops receiving and building the flooding topology.
> For the distributed mode, every node in the area stops computing and building the flooding topology.
>  
> At this point, the IGP running in the network area has rolled back to the normal flooding from the flooding reduction (either centralized mode or distributed mode).
>  
> After this point, if there is a need to migrate from the normal flooding to the flooding reduction, then go to step 4 (i.e., “Flooding Reduction Mode Configuration”) above.
>  
> One octet needs to be added into IS-IS and OSPF Area Leader Sub-TLV. Three bits of this octet are used to indicate an operation (OP) such as “Roll Back to Normal Flooding”. The other five bits are reserved. The values proposed for OP are as follows:
> 1 for “Flooding Reduction” (mode is implied/indicated by the algorithm)
> 2 for “Roll Back to Normal Flooding”
> 3 for “Start Leader Election” (This is not needed if step 3 above is removed).
>  
> 4 for “Start Priority and Algorithms Distribution” if Procedure B below is used.
>  
> In Procedure A, after rolling back to normal flooding, the information about the priority and algorithms in the LSA/LSP originated by each node is still in the network. If we want to remove this information from the network after rolling back to normal flooding, Procedure B below achieves this. It is derived from Procedure A through some changes which are in blue color.
>  
> Procedure B:
> 1.       For each node that is eligible to become a leader for flooding reduction in centralized mode, a priority for the leader election is configured on the node. (This step is called “Priority Configuration”).
> 2.       “Start Priority and Algorithms Distribution” is configured on the node that will be elected as the leader after all the nodes that are eligible for a leader are configured with their priorities. The node advertises “Start Priority and Algorithms Distribution” to all the other nodes in the area; every node advertises its priority and algorithms after obtaining “Start Priority and Algorithms Distribution”. (This step is called “Start Priority and Algorithms Distribution”).
> 3.       On the node that will be elected as the leader, “start leader election” is configured. The node does the leader election after obtaining “start leader election”. It also advertises this to all the other nodes in the area. Each of them will do the leader election after receiving this. (This step is called “Leader Election”).
> 4.       On the node that is elected as the leader, centralized mode or distributed mode is configured. (This step is called “Flooding Reduction Mode Configuration”).
> For centralized mode, 
> 1)      the leader advertises the centralized mode to all the other nodes;
> 2)      the leader computes the flooding topology and advertises the flooding topology to the other nodes;
> 3)      each node floods the link states using the flooding topology after it receives/has the whole flooding topology.
> For distributed mode, an algorithm is configured to be used by every node to compute flooding topology
> 1)      the leader advertises the distributed mode including the algorithm to all the other nodes;
> 2)      each node computes its flooding topology and floods the link states using the flooding topology.
> At this point, the IGP running in the network area has migrated from the normal flooding to the flooding reduction (either centralized mode or distributed mode).
>  
> In centralized mode, configuring distributed mode (or changing the centralized mode to distributed mode through configuration) will transfer from centralized mode to distributed mode. In addition to step 1) and 2) above for the distributed mode, each node uses the centralized flooding reduction (i.e., floods the link states over its local links on the flooding topology computed by the leader of the area) until the distributed flooding reduction is fully functional for a given time such as 5 seconds. After this time, the node stops its centralized flooding reduction. The leader stops computing the flooding topology, advertising it to all the other routers, and using this flooding topology to flood the link states. Each of the other nodes stops receiving and building the flooding topology computed by the leader.
>  
> In distributed mode, configuring centralized mode (or changing the distributed mode to centralized mode through configuration) will transfer from distributed mode to centralized mode. In addition to step 1), 2) and 3) above for the centralized mode, each node uses the distributed flooding reduction (i.e., floods the link states over its local links on the flooding topology computed and built by itself) until the centralized flooding reduction is fully functional for a given time such as 5 seconds.
>  
> 
> For migration (or say roll back) from the flooding reduction to the normal flooding,
> a.       on the leader node, “Roll Back to Normal Flooding” is configured; (This step is called “Roll Back to Normal Flooding Configuration”).
> b.       the leader advertises “Roll Back to Normal Flooding” to all the other nodes; (This step is called “Roll Back to Normal Flooding Distribution”).
> c.       every node rolls back to the normal flooding after obtaining the instruction for rolling back to the normal flooding. Every node will floods link states using all its local links instead of the local links on the flooding topology. (This step is called “Stop Using Flooding Topology”).
> d.       every node removes the information about its priority and algorithms in the LSA/LSP that it originated. (This step is called “Remove Priority and Algorithms”).
> For the centralized mode, after rolling back to normal flooding, the leader of the area stops computing and advertising a flooding topology, the other nodes stops receiving and building the flooding topology.
> For the distributed mode, every node in the area stops computing and building flooding topology.
>  
> At this point, the IGP running in the network area has rolled back to the normal flooding from the flooding reduction (either centralized mode or distributed mode).
>  
> After this point, if there is a need to migrate from the normal flooding to the flooding reduction, then go to step 2 (i.e., “Start Priority and Algorithms Distribution”) above.
>  
>  
> Best Regards,
> Huaimo
> 
>  
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org <mailto:Lsr@ietf.org>
> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr>
>