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

[Robert Raszuk <[e-mail]>]

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) <[e-mail]>
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 <[e-mail]>
> *Sent:* Tuesday, May 21, 2019 3:13 PM
> *To:* Les Ginsberg (ginsberg) <[e-mail]>; [e-mail]
> *Cc:* [e-mail]
> *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:[e-mail]
> <[e-mail]>]
> *Sent:* Monday, May 20, 2019 4:39 PM
> *To:* Huaimo Chen <[e-mail]>; [e-mail]
> *Cc:* [e-mail]
> *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 <[e-mail]> *On Behalf Of *Huaimo Chen
> *Sent:* Monday, May 20, 2019 12:53 PM
> *To:* [e-mail]
> *Cc:* [e-mail]
> *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:[e-mail] <[e-mail]>] *On
> Behalf Of *[e-mail]
> *Sent:* Saturday, May 18, 2019 1:17 PM
> *To:* Huaimo Chen <[e-mail]>
> *Cc:* [e-mail]
> *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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>