One may observe that the draft implicitly also supports already option A too. If leader advertises full topology wouldn't it effectively disable dynamic flooding automatically ?
At least no NMS or configuration push is required on all 1000s of nodes to go back to full flooding say for the purpose of self distruction of your fabric ;). Thx, R. On Wed, May 22, 2019, 05:46 Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > Huaimo – > > > > The thread started with you defining multi-step processes for electing an > area leader and enabling/disabling dynamic flooding – each of which > involved multiple state changes on each node in the network. (Please scroll > to the bottom to see your original post.) > > > > Both Tony and I responded by saying “no need for that”. Election of an > Area Leader proceeds just like election of DIS on a LAN in IS-IS – totally > event driven. > > Enabling/disabling of dynamic flooding happens based on what algorithm the > Area Leader advertises and whether (in centralized mode) the Flooding > Topology is advertised. > > > > Sections 6.4, 6.5, and 6.7 describe this. > > > > In response to my comment you have now changed the topic to discussing > whether a config change is required on every node in order to > enable/disable dynamic flooding. > > Different topic. It’s a bit hard to keep the thread focused when you > change the topic. > > In brief, I do not see a problem supporting your “Option B” below – and > the draft provides for that. We may want to make the wording more precise – > I am certainly open to that – but the capability is already there.. > > > > Les > > > > > > *From:* Huaimo Chen <huaimo.c...@huawei.com> > *Sent:* Tuesday, May 21, 2019 3:13 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com>; tony...@tony.li > *Cc:* lsr@ietf.org > *Subject:* RE: [Lsr] Migration between normal flooding and flooding > reduction > > > > Hi Les, > > > > Consider the following options to transfer all nodes in an area from > flooding reduction to normal flooding or from normal flooding to flooding > reduction: > > Option A: Go to all the nodes (if there are thousands of nodes, go to all > of them), execute “disable flooding reduction” or “enable flooding > reduction” on all of them. > > Option B: Go to the leader (even if there are thousands of nodes, just go > to the leader), execute “roll back to normal flooding” or “transfer to > flooding reduction” on the leader. > > > > Option B should be supported. Option B provides a simpler and quicker way > to transfer between flooding reduction and normal flooding. > > > > It seems that Option A is similar to going to all the nodes and > configuring an algorithm to compute the FT for distributed mode; and Option > B is similar to going to the leader and configuring an algorithm to compute > the FT for distributed mode, which is used in > draft-ietf-lsr-dynamic-flooding. > > > > Best Regards, > > Huaimo > > *From:* Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com > <ginsb...@cisco.com>] > *Sent:* Monday, May 20, 2019 4:39 PM > *To:* Huaimo Chen <huaimo.c...@huawei.com>; tony...@tony.li > *Cc:* lsr@ietf.org > *Subject:* RE: [Lsr] Migration between normal flooding and flooding > reduction > > > > Huaimo – > > > > I, like Tony, am wondering what problem you are trying to solve. > > > > Note that updated LSPs/LSAs which are received on an interface which the > receiving node believes is NOT part of the flooding topology are NEVER > discarded. They are processed and flooded on those interfaces which the > receiver believes are part of the flooding topology. So there is no need > for the coordination you propose. The network can transition from no > flooding optimizations to flooding optimizations – or vice versa – simply > by enabling/disabling optimizations. > > > > The speed at which the migration occurs is not critical. What is critical > is that correct flooding is not compromised during the migration and (as > Tony has noted) based on testing that works without any issues. > > > > Les > > > > > > *From:* Lsr <lsr-boun...@ietf.org> *On Behalf Of *Huaimo Chen > *Sent:* Monday, May 20, 2019 12:53 PM > *To:* tony...@tony.li > *Cc:* lsr@ietf.org > *Subject:* Re: [Lsr] Migration between normal flooding and flooding > reduction > > > > 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:tony1ath...@gmail.com <tony1ath...@gmail.com>] *On > Behalf Of *tony...@tony.li > *Sent:* Saturday, May 18, 2019 1:17 PM > *To:* Huaimo Chen <huaimo.c...@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.c...@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 > https://www.ietf.org/mailman/listinfo/lsr > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
