Re: [Lsr] Migration between normal flooding and flooding reduction
Robert – What you suggest is actually a form of Option B i.e., simply by altering config on the Area Leader dynamic flooding is enabled/disabled. No need to do anything on any other node. ☺ But, you have reinforced my point – that the draft does support Option B. Les From: Robert Raszuk Sent: Tuesday, May 21, 2019 11:18 PM To: Les Ginsberg (ginsberg) Cc: Huaimo Chen ; Tony Li ; lsr@ietf.org Subject: Re: [Lsr] Migration between normal flooding and flooding reduction 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) mailto: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 mailto:huaimo.c...@huawei.com>> Sent: Tuesday, May 21, 2019 3:13 PM To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; tony...@tony.li<mailto:tony...@tony.li> Cc: lsr@ietf.org<mailto: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] Sent: Monday, May 20, 2019 4:39 PM To: Huaimo Chen mailto:huaimo.c...@huawei.com>>; tony...@tony.li<mailto:tony...@tony.li> Cc: lsr@ietf.org<mailto: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 mailto:lsr-boun...@ietf.org>> On Behalf Of Huaimo Chen Sent: Monday, May 20, 2019 12:53 PM To: tony...@tony.li<mailto:tony...@tony.li> Cc: lsr@ietf.org<mailto: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 nor
Re: [Lsr] Migration between normal flooding and flooding reduction
tony...@tony.li writes: Huaimo, This seems like it’s a job for the NMS/configuration management system and that there are no protocol interactions required. I'm definitely not a fan of using routing protocols for configuration management, so +1 to this. Thanks, Chris. 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 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:tony1ath...@gmail.com] On Behalf Of tony...@tony.li Sent: Saturday, May 18, 2019 1:17 PM To: Huaimo Chen 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 mailto: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
Re: [Lsr] Migration between normal flooding and flooding reduction
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) 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 > *Sent:* Tuesday, May 21, 2019 3:13 PM > *To:* Les Ginsberg (ginsberg) ; 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 > ] > *Sent:* Monday, May 20, 2019 4:39 PM > *To:* Huaimo Chen ; 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 *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 >
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] Sent: Monday, May 20, 2019 4:39 PM To: Huaimo Chen ; 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 mailto:lsr-boun...@ietf.org>> On Behalf Of Huaimo Chen Sent: Monday, May 20, 2019 12:53 PM To: tony...@tony.li<mailto:tony...@tony.li> Cc: lsr@ietf.org<mailto: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] On Behalf Of tony...@tony.li<mailto:tony...@tony.li> Sent: Saturday, May 18, 2019 1:17 PM To: Huaimo Chen mailto:huaimo.c...@huawei.com>> Cc: lsr@ietf.org<mailto: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 mailto: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
Re: [Lsr] Migration between normal flooding and flooding reduction
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 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:tony1ath...@gmail.com] On Behalf Of tony...@tony.li > Sent: Saturday, May 18, 2019 1:17 PM > To: Huaimo Chen > 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 <mailto: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
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 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] On Behalf Of tony...@tony.li<mailto:tony...@tony.li> Sent: Saturday, May 18, 2019 1:17 PM To: Huaimo Chen mailto:huaimo.c...@huawei.com>> Cc: lsr@ietf.org<mailto: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 mailto: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
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] On Behalf Of tony...@tony.li Sent: Saturday, May 18, 2019 1:17 PM To: Huaimo Chen 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 mailto: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 centralize
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 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; >
[Lsr] Migration between normal flooding and flooding reduction
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
