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

From: Huaimo Chen <[email-masked]>
Date: Sat, 18 May 2019 15:15:10 +0000

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

---

From: [email-masked]
Date: Sat, 18 May 2019 10:17:04 -0700

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 <[email-masked]> wrote:
> 
> Hi Tony,
>  
> 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”).
> 1)      the leader advertises “Flooding Reduction” in the centralized mode to all the other nodes;
> 1)      the leader advertises “Flooding Reduction” in the distributed mode including the algorithm to all the other nodes;
> 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”).
> 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.
>  
> 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, 
> 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”).
> 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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr>

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 20 May 2019 19:53:08 +0000

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:[email-masked]] On Behalf Of [email-masked]
Sent: Saturday, May 18, 2019 1:17 PM
To: Huaimo Chen <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] Migration between normal flooding and flooding reduction

Hi Huaimo,

Tony

On May 18, 2019, at 8:15 AM, Huaimo Chen <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tony,

Procedure A:

Procedure B:

Best Regards,

Huaimo

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 20 May 2019 20:38:45 +0000

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 <[email-masked]> On Behalf Of Huaimo Chen
Sent: Monday, May 20, 2019 12:53 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] Migration between normal flooding and flooding reduction

Hi Tony,

Best Regards,
Huaimo
From: Tony Li [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Saturday, May 18, 2019 1:17 PM
To: Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Migration between normal flooding and flooding reduction

Hi Huaimo,

Tony

Hi Tony,

Procedure A:

Procedure B:

Best Regards,

Huaimo

---

From: [email-masked]
Date: Mon, 20 May 2019 17:05:49 -0700

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 <[email-masked]> wrote:
> 
> Hi Tony,
>  
> On May 18, 2019, at 8:15 AM, Huaimo Chen <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Tony,
>

---

From: Huaimo Chen <[email-masked]>
Date: Tue, 21 May 2019 22:12:41 +0000

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:[email-masked]]
Sent: Monday, May 20, 2019 4:39 PM
To: Huaimo Chen <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Lsr] Migration between normal flooding and flooding reduction

Huaimo –

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Huaimo Chen
Sent: Monday, May 20, 2019 12:53 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Migration between normal flooding and flooding reduction

Hi Tony,

Best Regards,
Huaimo

Hi Huaimo,

Tony

Hi Tony,

Procedure A:

Procedure B:

Best Regards,

Huaimo

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 22 May 2019 03:46:30 +0000

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 <[email-masked]>
Sent: Tuesday, May 21, 2019 3:13 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Lsr] Migration between normal flooding and flooding reduction

Hi Les,

Best Regards,
Huaimo
To: Huaimo Chen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Huaimo –

   Les

Hi Tony,

Best Regards,
Huaimo

Hi Huaimo,

Tony

Hi Tony,

Procedure A:

Procedure B:

Best Regards,

Huaimo

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 22 May 2019 08:17:38 +0200

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) <[email-masked]>
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.
>
>
>
> 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.
>
> 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 <[email-masked]>
> *Sent:* Tuesday, May 21, 2019 3:13 PM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
> *Cc:* [email-masked]
> *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:[email-masked]
> <[email-masked]>]
> *Sent:* Monday, May 20, 2019 4:39 PM
> *To:* Huaimo Chen <[email-masked]>; [email-masked]
> *Cc:* [email-masked]
> *Subject:* RE: [Lsr] Migration between normal flooding and flooding
> reduction
>
>
>
> Huaimo –
>
>
>
> 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 <[email-masked]> *On Behalf Of *Huaimo Chen
> *Sent:* Monday, May 20, 2019 12:53 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *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:[email-masked] <[email-masked]>] *On
> Behalf Of [email-masked]
> *Sent:* Saturday, May 18, 2019 1:17 PM
> *To:* Huaimo Chen <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Lsr] Migration between normal flooding and flooding
> reduction
>
>
>
>
>
> Hi Huaimo,
>
>
>
> 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.
>
>
>
> 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”).
>
> 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;
>
> 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.
>
> 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.
>
> 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:
>
> 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,
>
> 3)      each node floods the link states using the flooding topology
> after it receives/has the whole 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.
>
>
>
> 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.
>
> 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
>
>
>
> [email-masked]
> [email-masked]

---

From: Christian Hopps <[email-masked]>
Date: Wed, 22 May 2019 05:18:15 -0400

> 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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 22 May 2019 14:09:49 +0000

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 <[email-masked]>
Sent: Tuesday, May 21, 2019 11:18 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Huaimo Chen <[email-masked]>; Tony Li <[email-masked]>; [email-masked]
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) <[email-masked]<mailto:[email-masked]>> wrote:
Huaimo –

   Les

From: Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, May 21, 2019 3:13 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Lsr] Migration between normal flooding and flooding reduction

Hi Les,

Best Regards,
Huaimo

Huaimo –

   Les

Hi Tony,

Best Regards,
Huaimo

Hi Huaimo,

Tony

Hi Tony,

Procedure A:

Procedure B:

Best Regards,

Huaimo

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 22 May 2019 16:17:51 +0000

Hi Les,

    The procedure in the thread is more comprehensive somehow, which includes

    Option B,

    the step related to the leader election, which is optional. I put a note in that step,

    and so on. It seems better to split it into two or more different topics.

    The description and extension for supporting Option B is described in the procedure.

Best Regards,

Huaimo

Huaimo –

   Les

Hi Les,

Best Regards,

Huaimo

Huaimo –

   Les

Hi Tony,

Best Regards,

Huaimo

Hi Huaimo,

Tony

Hi Tony,

Procedure A:

Procedure B:

For centralized mode,

Best Regards,

Huaimo

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Chchen%40futurewei.com%7C9516e562de9147db7aa408d6debf4b91%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636941310531008373&sdata=LEDUOOD0k8clPsyyeJtsztZgnS8qqE6RSLiv%2FpN9fbg%3D&reserved=0>

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Chchen%40futurewei.com%7C9516e562de9147db7aa408d6debf4b91%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636941310531018378&sdata=3aquGnFwLMkd1ECf%2Fkqp5P7RV5TNa%2BmNgmBFOmwNuWw%3D&reserved=0>

---

From: Huaimo Chen <[email-masked]>
Date: Sun, 26 May 2019 20:01:01 +0000

Hi Les,

    Option B is about the transfer between flooding reduction (either centralized mode or distributed mode) and normal flooding. It is from the procedure in thread “Migration between normal flooding and flooding reduction”, and described below in some details, including behavior and extension. In the case that the formats below are messed up, a .pdf file is attached.

    Note that the transfer between centralized mode and distributed mode is in draft-ietf-lsr-dynamic-flooding and Option B can be considered as an extension to it (refer to the Figure below).
     /-----------------------------------------------------------\
     | Flooding Reduction                                        |
     |                                                           |
     |            “(Transfer to) Centralized Mode”               |
     |                              |                            |
     |   /------------------\       V      /------------------\  |
     |   | Centralized Mode | ----------à | Distributed Mode |  |
     |   |                  | ß---------- |                  |  |
     |   \------------------/       ^      \------------------/  |
     |                              |                            |
     |           “(Transfer to) Distributed Mode”                |
     |                                                           |
     \-----------------------------------------------------------/
                           |             ^
        “(Transfer to)     |             | “(Transfer to)
        Normal Flooding”   |             | Flooding Reduction”
                           V             |
     /-----------------------------------------------------------\
     | Normal Flooding                                           |
     |                                                           |
     \-----------------------------------------------------------/

 Figure 1. Transfer between Flooding Reduction and Normal Flooding

    When the IGP in an area runs in the flooding reduction (either centralized mode or distributed mode), the behavior to transfer from the flooding reduction to the normal flooding is as follows:

  1.  on the leader node, “(Transfer to) Normal Flooding” is configured;
  2.  the leader advertises “(Transfer to) Normal Flooding” to all the other nodes;
  3.  every node transfers to the normal flooding after obtaining the instruction for transferring to the normal flooding. Every node will floods link states using all its local links instead of the local links on the flooding topology (FT for short).

For the centralized mode, after transferring to normal flooding, the leader of the area stops computing and advertising the FT, each of the other nodes stops receiving and building the FT.

For the distributed mode, every node in the area stops computing and building the FT.

At this point, the IGP in the area has transferred to the normal flooding from the flooding reduction (either centralized mode or distributed mode).

    When the IGP in the area runs in the normal flooding, the behavior to transfer from the normal flooding to the flooding reduction (either centralized mode or distributed mode) is as follows. It is almost the same as that described in draft-ietf-lsr-dynamic-flooding, but with minor enhancement in blue color.

  1.  the leader advertises “Flooding Reduction” in the centralized mode to all the other nodes;
  2.  the leader computes the FT and advertises the FT to the other nodes;
  3.  each node floods the link states using the FT after it receives/has the whole FT.

    For distributed mode (i.e., when distributed mode is configured), an algorithm is also configured to be used by every node to compute FT

  1.  the leader advertises “Flooding Reduction” in the distributed mode including the algorithm to all the other nodes;
  2.  each node computes its FT and floods the link states using the FT.

    At this point, the IGP in the area has transferred from the normal flooding to the flooding reduction (either centralized mode or distributed mode).

    To support the above behaviors, Area Leader Sub-TLV needs to be extended. Three bits of one octet may be used to indicate a flooding mode (FM) such as “Normal Flooding” or "Flooding Reduction". The other bits are reserved. The values proposed for FM are as follows:
1 for “Flooding Reduction” (centralized or distributed mode is implied/indicated by the algorithm)
2 for “Normal Flooding”

For OSPF Area Leader Sub-TLV, the current Sub-TLV below

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Type             |             Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Priority   |   Algorithm   |            Reserved           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  (Current) OSPF Area Leader Sub-TLV
is extended to
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Type             |             Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Priority   |   Algorithm   | FM  |      Reserved           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                   (Extended) OSPF Area Leader Sub-TLV

FM = 1:  Flooding Reduction
              Alogrithm  =  0:  Centralized Mode; Algorithm = N (N>0): Distributed Mode.
FM = 2: Normal Flooding

Similarly for IS-IS Area Leader Sub-TLV, the current Sub-TLV below,
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Length    | Priority      |   Algorithm   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   (Current) IS-IS Area Leader Sub-TLV
is extended to
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Length    | Priority      |   Algorithm   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | FM  |Reserved |
     +-+-+-+-+-+-+-+-+

                   (Extended) IS-IS Area Leader Sub-TLV

Best Regards,
Huaimo
________________________________
From: Huaimo Chen
Sent: Wednesday, May 22, 2019 12:17 PM
To: Les Ginsberg (ginsberg); Robert Raszuk
Cc: Huaimo Chen; Tony Li; [email-masked]
Subject: Re: [Lsr] Migration between normal flooding and flooding reduction

Hi Les,

    Option B,

Best Regards,

Huaimo

Huaimo –

   Les

Hi Les,

Best Regards,

Huaimo

Huaimo –

   Les

Hi Tony,

Best Regards,

Huaimo

Hi Huaimo,

Tony

Hi Tony,

Procedure A:

Procedure B:

For centralized mode,

Best Regards,

Huaimo

---

From: Tony Li <[email-masked]>
Date: Sun, 26 May 2019 14:15:18 -0700

Hi Huaimo,

None of this is necessary.

If we’re in legacy flooding and want to use centralized mode, the area leader simply advertises that.  No additions are necessary.

If we’re in legacy flooding and want to use distributed mode, the area leader simply advertises that and the algorithm to use.  No additions are necessary.

If we’re in centralized mode and the area leader elects to use distributed mode, then it need only change to advertise the algorithm in use.  No additions are necessary.

If we’re in distributed mode and the area leader elects to use centralized mode, then it need only change to advertise centralized mode. No additions are necessary.

If we’re in centralized mode and the area leader decides to transition to legacy flooding, then it can simply resign as area leader. No additions are necessary.

If we’re in distributed mode and the area leader decides to transition to legacy flooding, then it can also simply resign as area leader. No additions are necessary.

In short, no additions are necessary.

Tony

> On May 26, 2019, at 1:01 PM, Huaimo Chen <[email-masked]> wrote:
> 
> Hi Les,
>    
> on the leader node, “(Transfer to) Normal Flooding” is configured; 
> the leader advertises “(Transfer to) Normal Flooding” to all the other nodes;
> every node transfers to the normal flooding after obtaining the instruction for transferring to the normal flooding. Every node will floods link states using all its local links instead of the local links on the flooding topology (FT for short). 
> 
> the leader advertises “Flooding Reduction” in the centralized mode to all the other nodes;
> the leader computes the FT and advertises the FT to the other nodes;
> each node floods the link states using the FT after it receives/has the whole FT.
> 
> the leader advertises “Flooding Reduction” in the distributed mode including the algorithm to all the other nodes;
> each node computes its FT and floods the link states using the FT.
>     
> On Wed, May 22, 2019, 05:46 Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>> wrote:
> Huaimo –
>  
> From: Huaimo Chen <[email-masked] <mailto:[email-masked]>> 
> To: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> From: Les Ginsberg (ginsberg) [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Huaimo Chen <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> From: Lsr <[email-masked] <mailto:[email-masked]>> On Behalf Of Huaimo Chen
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> From: Tony Li [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of [email-masked] <mailto:[email-masked]>
> To: Huaimo Chen <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lsr <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Chchen%40futurewei.com%7C9516e562de9147db7aa408d6debf4b91%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636941310531008373&sdata=LEDUOOD0k8clPsyyeJtsztZgnS8qqE6RSLiv%2FpN9fbg%3D&reserved=0>
>  
> https://www.ietf.org/mailman/listinfo/lsr <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Chchen%40futurewei.com%7C9516e562de9147db7aa408d6debf4b91%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636941310531018378&sdata=3aquGnFwLMkd1ECf%2Fkqp5P7RV5TNa%2BmNgmBFOmwNuWw%3D&reserved=0><Transfers-Normal-Reduction-2019-5-26.pdf>_______________________________________________
> Lsr mailing list

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 27 May 2019 01:10:58 +0200

Hi Tony,

The current draft is pretty robust in terms of area leader election. It
also says that  "Any node that is capable MAY advertise its eligibility to
become Area Leader"

With that can you confirm the procedure to "resign" as area leader ?
Especially that under those circumstances just having active area leader to
resign clearly is not enough to change given flooding scheme.

In some deployments all eligible nodes may advertise such capability which
in turn the "resign" procedure would require NMS action to disable such
capability by configuration and re-flooding it. Not that I am advocating it
nor see need for complex migration procedures, but just would like to
better understand the "resign" part.

Thx,
R.

On Sun, May 26, 2019 at 11:15 PM Tony Li <[email-masked]> wrote:

> If we’re in legacy flooding and want to use centralized mode, the area
> leader simply advertises that.  No additions are necessary.
>
> If we’re in legacy flooding and want to use distributed mode, the area
> leader simply advertises that and the algorithm to use.  No additions are
> necessary.
>
> If we’re in centralized mode and the area leader elects to use distributed
> mode, then it need only change to advertise the algorithm in use.  No
> additions are necessary.
>
> If we’re in distributed mode and the area leader elects to use centralized
> mode, then it need only change to advertise centralized mode. No additions
> are necessary.
>
> If we’re in centralized mode and the area leader decides to transition to
> legacy flooding, then it can simply resign as area leader. No additions are
> necessary.
>
> If we’re in distributed mode and the area leader decides to transition to
> legacy flooding, then it can also simply resign as area leader. No
> additions are necessary.
>
>     Option B is about the transfer between flooding reduction (either
> centralized mode or distributed mode) and normal flooding. It is from the
> procedure in thread “Migration between normal flooding and flooding
> reduction”, and described below in some details, including behavior and
> extension. In the case that the formats below are messed up, a .pdf file is
> attached.
>
>     Note that the transfer between centralized mode and distributed mode
> is in draft-ietf-lsr-dynamic-flooding and Option B can be considered as an
> extension to it (refer to the Figure below).
>     When the IGP in an area runs in the flooding reduction (either
> centralized mode or distributed mode), the behavior to transfer from the
> flooding reduction to the normal flooding is as follows:
>
>    3. every node transfers to the normal flooding after obtaining the
>    instruction for transferring to the normal flooding. Every node will floods
>    flooding topology (FT for short).
>
>    For the centralized mode, after transferring to normal flooding, the
>    leader of the area stops computing and advertising the FT, each of the
>    other nodes stops receiving and building the FT.
>
> At this point, the IGP in the area has transferred to the normal flooding
> from the flooding reduction (either centralized mode or distributed mode).
>
>     When the IGP in the area runs in the normal flooding, the behavior to
> transfer from the normal flooding to the flooding reduction (either
> centralized mode or distributed mode) is as follows. It is almost the same
> as that described in draft-ietf-lsr-dynamic-flooding, but with minor
> enhancement in blue color.
>
> algorithm is also configured to be used by every node to compute FT
>
>    1. the leader advertises “Flooding Reduction” in the distributed mode
>    including the algorithm to all the other nodes;
>     At this point, the IGP in the area has transferred from the normal
> flooding to the flooding reduction (either centralized mode or distributed
> mode).
>
>     To support the above behaviors, Area Leader Sub-TLV needs to be
> extended. Three bits of one octet may be used to indicate a flooding mode
> (FM) such as “Normal Flooding” or "Flooding Reduction". The other bits are
> reserved. The values proposed for FM are as follows:
>
> ------------------------------
> *From:* Huaimo Chen
> *Sent:* Wednesday, May 22, 2019 12:17 PM
> *To:* Les Ginsberg (ginsberg); Robert Raszuk
> *Cc:* Huaimo Chen; Tony Li; [email-masked]
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Chchen%40futurewei.com%7C9516e562de9147db7aa408d6debf4b91%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636941310531008373&sdata=LEDUOOD0k8clPsyyeJtsztZgnS8qqE6RSLiv%2FpN9fbg%3D&reserved=0>
>
>
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Chchen%40futurewei.com%7C9516e562de9147db7aa408d6debf4b91%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636941310531018378&sdata=3aquGnFwLMkd1ECf%2Fkqp5P7RV5TNa%2BmNgmBFOmwNuWw%3D&reserved=0>
>
> <Transfers-Normal-Reduction-2019-5-26.pdf>

---

From: Tony Li <[email-masked]>
Date: Sun, 26 May 2019 21:19:39 -0700

Hi Robert,

> The current draft is pretty robust in terms of area leader election. It also says that  "Any node that is capable MAY advertise its eligibility to become Area Leader” 

Correct.  This can be all systems. It can be one. For redundancy, a few would be sensible.

> With that can you confirm the procedure to "resign" as area leader ?

Stop advertising the Area Leader sub-TLV.  It’s that simple.

> Especially that under those circumstances just having active area leader to resign clearly is not enough to change given flooding scheme. 

If there are multiple potential area leaders, then all of them would have to resign.  

> In some deployments all eligible nodes may advertise such capability which in turn the "resign" procedure would require NMS action to disable such capability by configuration and re-flooding it. Not that I am advocating it nor see need for complex migration procedures, but just would like to better understand the "resign" part. 

Correct, this is rightfully an NMS operation.

Tony

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 28 May 2019 14:15:48 +0800

Hi, Tony:

How the receiver judge the leader has stopped advertising the Area Leader sub-TLV? Do you need some timers? 
>From the current discussion, I think the explicit instruction that proposed by Huaimo is more acceptable.

Best Regards.

Aijun Wang
Network R&D and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

-----邮件原件-----
发件人: Tony Li [mailto:[email-masked]] 
发送时间: 2019年5月27日 12:20
收件人: Robert Raszuk
抄送: [email-masked]
主题: Re: [Lsr] Option B from "Migration between normal flooding and flooding reduction"

Hi Robert,

Tony

---

From: Peter Psenak <[email-masked]>
Date: Tue, 28 May 2019 09:34:23 +0200

Aijun,

> How the receiver judge the leader has stopped advertising the Area Leader sub-TLV? Do you need some timers?

no timer needed, all event driven. Area Leader sub-TLV is removed from 
the LSP.

thanks,
Peter

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 28 May 2019 15:22:33 +0000

Aijun -

What is missing in this discussion is a definition of the problem to be solved.

Current draft relies on event driven updates to LSPs - the same mechanism that has been used for 30 years to detect all manner of changes in the network.

Before defining a "solution" (let alone voting for which one is best) it would be good to have a definition of what problem is unaddressed currently.

    Les

> -----Original Message-----
> From: Lsr <[email-masked]> On Behalf Of Aijun Wang
> Sent: Monday, May 27, 2019 11:16 PM
> To: 'Tony Li' <[email-masked]>; 'Robert Raszuk'
> <[email-masked]>
> Cc: [email-masked]
> Subject: [Lsr] 答复: Option B from "Migration between normal flooding and
> flooding reduction"
> 
> Hi, Tony:
> 
> > The current draft is pretty robust in terms of area leader election. It also
> says that  "Any node that is capable MAY advertise its eligibility to become
> Area Leader”
> 
> 
> capability by configuration and re-flooding it. Not that I am advocating it nor
> see need for complex migration procedures, but just would like to better
> understand the "resign" part.
> 
>

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 29 May 2019 09:43:41 +0800

Hi, Peter:

Under the current mechanism, only all the candidate area leaders stop advertise this sub-TLV, then the network will be back to normal flooding?
Is it more efficient that only one area leader indicates(according to the command from NMS) explicitly then the network will be back to normal flooding?

For the number of candidate area leaders, I support we should have more than one for consideration of redundancy.

-----邮件原件-----
发件人: Peter Psenak [mailto:[email-masked]] 
发送时间: 2019年5月28日 15:34
收件人: Aijun Wang; 'Tony Li'; 'Robert Raszuk'
抄送: [email-masked]
主题: Re: [Lsr] 答复: Option B from "Migration between normal flooding and flooding reduction"

Aijun,

> How the receiver judge the leader has stopped advertising the Area Leader sub-TLV? Do you need some timers?

no timer needed, all event driven. Area Leader sub-TLV is removed from the LSP.

thanks,
Peter

> Network R&D and Operation Support Department China Telecom Corporation 
> Limited Beijing Research Institute,Beijing, China.
>
> -----邮件原件-----

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 29 May 2019 04:18:00 +0000

Aijun -

Please look at https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-02#section-6.4 which defines how to disable dynamic flooding w/o resigning as Area Leader.

Note that having deployed dynamic flooding in a network which functions poorly in its absence, disabling dynamic flooding has risks.
Nonetheless, I agree we need a way to disable dynamic flooding and it is helpful to be able to do so w/o altering what all possible area leader candidates are advertising - and we have that.

   Les

> Sent: Tuesday, May 28, 2019 6:44 PM
> To: Peter Psenak (ppsenak) <[email-masked]>; 'Tony Li'
> <[email-masked]>; 'Robert Raszuk' <[email-masked]>
> Cc: [email-masked]
> Subject: [Lsr] 答复: 答复: Option B from "Migration between normal flooding
> and flooding reduction"
> 
> Hi, Peter:
> 
> Under the current mechanism, only all the candidate area leaders stop
> advertise this sub-TLV, then the network will be back to normal flooding?
> Is it more efficient that only one area leader indicates(according to the
> command from NMS) explicitly then the network will be back to normal
> flooding?
> 
> For the number of candidate area leaders, I support we should have more
> than one for consideration of redundancy.
> 
> -----邮件原件-----
> >> In some deployments all eligible nodes may advertise such capability
> which in turn the "resign" procedure would require NMS action to disable
> such capability by configuration and re-flooding it. Not that I am advocating it
> nor see need for complex migration procedures, but just would like to better

---

From: Peter Psenak <[email-masked]>
Date: Wed, 29 May 2019 09:25:43 +0200

Hi Aijun,

> Under the current mechanism, only all the candidate area leaders stop advertise this sub-TLV, then the network will be back to normal flooding?

no.

> Is it more efficient that only one area leader indicates(according to the command from NMS) explicitly then the network will be back to normal flooding?

yes and we have that in the draft:

"When the Area Leader advertises algorithm 0 in its Area Leader Sub-
    TLV and does not advertise a flooding topology, Dynamic Flooding is
    disabled for the area.  Note this applies whether the Area Leader
    intends to operate in centralized mode or in distributed mode."
> For the number of candidate area leaders, I support we should have more than one for consideration of redundancy.

sure.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 29 May 2019 10:31:08 +0200

Hey Peter,

> > Is it more efficient that only one area leader indicates(according to
> the command from NMS) explicitly then the network will be back to normal
> flooding?
>

Two little questions ...

- I think to avoid potential ambiguity in implementations it would be worth
clarifying what "does not advertise" means ... does it mean that Area Node
IDs TLV is not present all together or does it mean that it MAY be present
but it is sufficient that it does not contain any Node ID .. or both ?

- how does this apply to distributed mode if flooding topology is to be
used only in centralized mode ? Isn't the quoted text from section 6.4 a
bit incorrect and requires a fix ?

Thx,
R.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 29 May 2019 11:16:49 +0200

Hi Robert,

On 29/05/2019 10:31, Robert Raszuk wrote:
> Hey Peter,
> 
>      > Is it more efficient that only one area leader
>     indicates(according to the command from NMS) explicitly then the
>     network will be back to normal flooding?
> 
> - I think to avoid potential ambiguity in implementations it would be 
> worth clarifying what "does not advertise" means ... does it mean that 
> Area Node IDs TLV is not present all together or does it mean that it

yes, Area Node IDs TLV is not present.

> MAY be present but it is sufficient that it does not contain any Node ID 
> .. or both ?
> 

algo 0 + no topology advertised equals to legacy flooding.

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 29 May 2019 13:59:57 +0000

Hi Aijun, 
The current machinery supports a model where you can have as many area leader candidates as you believe you need for redundancy. It is deployment dependent on how many you have. We really want the same machinery to handle both failure or the area leader or changes to the configuration of the flooding algorithm. However, I'd expect the latter to be a rare event. 
Thanks,
Acee

On 5/28/19, 9:44 PM, "Lsr on behalf of Aijun Wang" <[email-masked] on behalf of [email-masked]> wrote:

    Hi, Peter:

    
    -----邮件原件-----
    发件人: Peter Psenak [mailto:[email-masked]] 
    发送时间: 2019年5月28日 15:34
    收件人: Aijun Wang; 'Tony Li'; 'Robert Raszuk'
    抄送: [email-masked]
    主题: Re: [Lsr] 答复: Option B from "Migration between normal flooding and flooding reduction"
    
    Aijun,

    
    thanks,
    Peter