Subject: [Lsr] Flooding Negotiation bit

From: Huaimo Chen <[email-masked]>
Date: Tue, 14 May 2019 20:09:25 +0000

Hi Tony,

For the case you described below, in order to add one or a limited number of links to the flooding topology temporarily, a new bit, called Flooding Negotiation bit (FN bit for short), should be defined and used. In OSPF, the FN bit is defined in Extended Options and Flag (EOF) TLV in OSPF Hello. In IS-IS, the FN bit is defined in the new TLV used for FR bit.

When a node N (with 1000 interfaces/links for example) reboots, , each (node X) of the nodes connected to node N will establish an adjacency with node N. During the process of the adjacency establishment between node X and node N, node X sends a FN-bit set to one in its Hello to node N, node N selects one link/node (or a limited number of links) for temporarily flooding and sends only to this selected node a FN-bit set to one in its Hello. Node N adds the selected link/node to the FT temporarily after receiving the FT bit set to one from the selected node. After receiving the FN bit set to one from node N, the selected node adds the link (connected to node N) to the FT temporarily.
In other words, a node Y connected to node N adds the link to node N to the FT temporarily after it sends and receives the FT bit set to one to/from node N; node N adds a selected link to the FT temporarily after it receives and sends the FT bit set to one from/to node Y.

Best Regards,
Huaimo

==== A case from Tony on 3/6 ====
If the node that rebooted has 1000 interfaces, which interfaces should be temporarily added?  Adding all of them is likely to trigger a cascade failure.  The TLV allows us to signal which ones should be enabled.

---

From: [email-masked]
Date: Tue, 14 May 2019 13:31:00 -0700

Hi Huaimo,

If I understand you correctly, this seems to have almost the same semantics as the Flooding Request TLV (section 5.1.5) or the Flooding Request Bit (section 5.2.7).

If I’m not understanding you, could you please clarify the differences and why the current mechanisms are insufficient.

Tony

> On May 14, 2019, at 1:09 PM, Huaimo Chen <[email-masked]> wrote:
> 
> Hi Tony,
>

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 14 May 2019 21:56:11 -0400

Is this a new option that does not exist today in OSPFv3 or ISIS.

Operators have the ability to mark interfaces as passive so only router stub LSA is generated which helps assist in full SPF calculations flooding.

Gyan S. Mishra
IT Network Engineering & Technology 
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Phone: 301 502-1347
Email: [email-masked]

Sent from my iPhone

> On May 14, 2019, at 4:31 PM, [email-masked] wrote:
> 
> 
> Hi Huaimo,
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 15 May 2019 14:02:39 +0000

Hi Gyan,
The dynamic flooding extensions are all new work and they would be optional enabled. We would appreciate your input and especially on applicability to your existing deployed networks.
Thanks,
Acee

From: Lsr <[email-masked]> on behalf of Gyan Mishra <[email-masked]>
Date: Tuesday, May 14, 2019 at 9:57 PM
To: Tony Li <[email-masked]>
Cc: Huaimo Chen <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] Flooding Negotiation bit

Gyan S. Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904<x-apple-data-detectors://2/0>
www..linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT<http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
Phone: 301 502-1347<tel:301%20502-1347>
Email: [email-masked]<mailto:[email-masked]>

Sent from my iPhone

On May 14, 2019, at 4:31 PM, [email-masked]<mailto:[email-masked]> wrote:

Hi Huaimo,

Tony

On May 14, 2019, at 1:09 PM, Huaimo Chen <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tony,

Best Regards,
Huaimo

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

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 15 May 2019 15:06:53 +0000

Hi Tony,

There are two different cases in which a link is to be added to the FT temporarily.
In one case, a negotiation is needed to be done before a link is to be added to the FT temporarily.
In the other case, no negotiation is needed. It is determined that a link is added to the FT temporarily.

In section 5.1.5 or section 5.2.7, it seems that there is no details on negotiations.

Best Regards,
Huaimo
From: Tony Li [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, May 14, 2019 4:31 PM
To: Huaimo Chen <[email-masked]>
Cc: [email-masked]
Subject: Re: Flooding Negotiation bit

Hi Huaimo,

Tony

Hi Tony,

Best Regards,
Huaimo

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 17 May 2019 03:31:08 -0400

Les

We do have cases with adjacencies around around the 100 range and the
process overhead is much worse for ospf with the type 1 type 2 full spf
calc so the FN flood bit negotiation would be very useful so we don’t have
a cascading effect that would ripple through the mpls core.  We have found
that with ISIS is not as taxing with flooding process overhead with the
same number of adjacencies is not as bad with flooding and definitely
scales much better then ospf.

When the FN bit and a exponential back off happens on a node that rebooted
and just came back online does that delay convergence.

How does this impact convergence if Graceful Restart is enabled or CISCO
NSR how does the FN bit impact the grace LSA received by helper router
which continues to forward on stale paths until topology change occurs at
which time GR IS exited and full spf runs.  Also how does this impact LSA
group pacing to refresh LSA so full SPF does not have to run on all nodes
as root of tree at once.

Gyan

Gyan S. Mishra

On Wed, May 15, 2019 at 10:02 AM Acee Lindem (acee) <[email-masked]> wrote:

> Hi Gyan,
>
> The dynamic flooding extensions are all new work and they would be
> optional enabled. We would appreciate your input and especially on
> applicability to your existing deployed networks.
>
> Thanks,
> Acee
>
>
>
> *From: *Lsr <[email-masked]> on behalf of Gyan Mishra <
> [email-masked]>
> *Date: *Tuesday, May 14, 2019 at 9:57 PM
> *To: *Tony Li <[email-masked]>
> *Cc: *Huaimo Chen <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [Lsr] Flooding Negotiation bit
>
>
>
>
>
> Operators have the ability to mark interfaces as passive so only router
> stub LSA is generated which helps assist in full SPF calculations flooding.
>
>
>
> Gyan S. Mishra
>
> 13101 Columbia Pike
> <https://maps.google.com/?q=13101+Columbia+Pike&entry=gmail&source=g>
> FDC1 3rd Floor
>
> Silver Spring, MD 20904
>
> www..linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
> <http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
>
> Phone: 301 502-1347
>
> If I understand you correctly, this seems to have almost the same
> semantics as the Flooding Request TLV (section 5.1.5) or the Flooding
> Request Bit (section 5.2.7).
>
>
>
> If I’m not understanding you, could you please clarify the differences and
> why the current mechanisms are insufficient.
>
>
>
> Tony
>
>
>
>
>
> For the case you described below, in order to add one or a limited number
> of links to the flooding topology temporarily, a new bit, called Flooding
> Negotiation bit (FN bit for short), should be defined and used. In OSPF,
> the FN bit is defined in Extended Options and Flag (EOF) TLV in OSPF Hello.
> In IS-IS, the FN bit is defined in the new TLV used for FR bit.
>
>
>
> When a node N (with 1000 interfaces/links for example) reboots, , each
> (node X) of the nodes connected to node N will establish an adjacency with
> node N. During the process of the adjacency establishment between node X
> and node N, node X sends a FN-bit set to one in its Hello to node N, node N
> selects one link/node (or a limited number of links) for temporarily
> flooding and sends only to this selected node a FN-bit set to one in its
> Hello. Node N adds the selected link/node to the FT temporarily after
> receiving the FT bit set to one from the selected node. After receiving the
> FN bit set to one from node N, the selected node adds the link (connected
> to node N) to the FT temporarily.
>
> In other words, a node Y connected to node N adds the link to node N to
> the FT temporarily after it sends and receives the FT bit set to one
> to/from node N; node N adds a selected link to the FT temporarily after it
> receives and sends the FT bit set to one from/to node Y.
>
>
>
> Best Regards,
>
> Huaimo
>
>
>
> If the node that rebooted has 1000 interfaces, which interfaces should be
> temporarily added?  Adding all of them is likely to trigger a cascade
> failure.  The TLV allows us to signal which ones should be enabled.
>
>
>
> --
Gyan S. Mishra
IT Network Engineering & Technology Consultant
Routing & Switching / Service Provider MPLS & IPv6 Expert
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Mobile – 202-734-1000

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 17 May 2019 13:36:33 +0000

Hi Gyan,

From: Gyan Mishra <[email-masked]>
Date: Friday, May 17, 2019 at 3:31 AM
To: Acee Lindem <[email-masked]>
Cc: Huaimo Chen <[email-masked]>, "[email-masked]" <[email-masked]>, Tony Li <[email-masked]>
Subject: Re: [Lsr] Flooding Negotiation bit

Les

We do have cases with adjacencies around around the 100 range and the process overhead is much worse for ospf with the type 1 type 2 full spf calc so the FN flood bit negotiation would be very useful so we don’t have a cascading effect that would ripple through the mpls core.  We have found that with ISIS is not as taxing with flooding process overhead with the same number of adjacencies is not as bad with flooding and definitely scales much better then ospf.

When the FN bit and a exponential back off happens on a node that rebooted and just came back online does that delay convergence.

How does this impact convergence if Graceful Restart is enabled or CISCO NSR how does the FN bit impact the grace LSA received by helper router which continues to forward on stale paths until topology change occurs at which time GR IS exited and full spf runs.  Also how does this impact LSA group pacing to refresh LSA so full SPF does not have to run on all nodes as root of tree at once.

Without a lot of thought, my take would be that link-scoped LSAs/LSPs are flooded independent of the flooding topology.

Thanks,
Acee

Gyan

Gyan S. Mishra
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT<http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>

On Wed, May 15, 2019 at 10:02 AM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,
The dynamic flooding extensions are all new work and they would be optional enabled. We would appreciate your input and especially on applicability to your existing deployed networks.
Thanks,
Acee

From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 14, 2019 at 9:57 PM
To: Tony Li <[email-masked]<mailto:[email-masked]>>
Cc: Huaimo Chen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Flooding Negotiation bit

Gyan S. Mishra
13101 Columbia Pike<https://maps.google.com/?q=13101+Columbia+Pike&entry=gmail&source=g> FDC1 3rd Floor

Sent from my iPhone

Hi Huaimo,

Tony

Hi Tony,

Best Regards,
Huaimo

www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT<http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
Mobile – 202-734-1000

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 17 May 2019 18:01:54 +0000

Huaimo –

It seems to me from your description that you are trying to deal with the startup case where a node reboots, has a large number of neighbors which need to be formed, and if this is done all simultaneously there will be a lot of redundant flooding between the new node and each of its neighbors.

If so, this is a well known problem which has nothing to do with optimizing flooding across the network. Clever implementers have already devised strategies wherein neighbors are not all brought up in parallel and the use of various protocol mechanisms (OL bit, max-metric, the SA bit from RFC 5306) are used to prevent the rebooting router from being used as a transit router until it has fully synced with all of its neighbors.

This has nothing whatever to do with the problem being addressed in the flooding optimizations draft – and there are no protocol extensions required to address the issue. I don’t think what you propose is needed – and if it were needed I do not think it would belong in flooding optimizations draft.

   Les

From: Lsr <[email-masked]> On Behalf Of Huaimo Chen
Sent: Wednesday, May 15, 2019 8:07 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] Flooding Negotiation bit

Hi Tony,

Best Regards,
Huaimo
From: Tony Li [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, May 14, 2019 4:31 PM
To: Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: Flooding Negotiation bit

Hi Huaimo,

Tony

Hi Tony,

Best Regards,
Huaimo

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 20 May 2019 20:55:38 +0000

Hi Les,

The problem/case is raised by Tony on 3/6.

I think that it needs to be addressed too from flooding reduction’s perspective.  After a node with 1K links reboots and has 1K adjacencies up to full states,  we should not add 1K links to the FT temporarily. “Adding all of them is likely to trigger a cascade failure. “ from Tony.

To address this problem, we should have a Flooding Negotiation bit. Through using this bit, we can add one or just a few links (from 1K links) to the FT temporarily after 1K adjacencies are fully formed.

It seems that the various methods you mentioned do the work and are for reducing the load before 1K adjacencies are fully formed.

Best Regards,
Huaimo

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, May 17, 2019 2:02 PM
To: Huaimo Chen <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Flooding Negotiation bit

Huaimo –

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Huaimo Chen
Sent: Wednesday, May 15, 2019 8:07 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Flooding Negotiation bit

Hi Tony,

Best Regards,
Huaimo

Hi Huaimo,

Tony

Hi Tony,

Best Regards,
Huaimo

---

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

Huaimo –

Node startup has two aspects to be considered:

1)Database synchronization occurs as part of adjacency bringup (details differ between IS-IS and OSPF). If a large number of neighbors are brought up simultaneously then there is a lot of redundant flooding which can significantly lengthen the process. This issue has nothing to do with flooding optimizations. Since we have deliberately chosen not to alter the adjacency state machine – it will not be addressed by flooding optimizations. Smart implementations have addressed this issue w/o requiring any protocol extensions.

2)Addition of a new node to the network introduces a form of partitioning of the flooding topology in that the new node is initially NOT part of the flooding topology. This introduces the possibility that each neighbor of the new node could enable temporary flooding to the new node. The best way to solve this is to have the new node limit the rate at which new adjacencies are brought up. This reduces the number of neighbors of the new node who have to make a decision about enabling temporary flooding. It also has the side benefit of significantly reducing the amount of  redundant flooding which occurs as part of adjacency bringup.

Introducing a “Flooding Negotiation Protocol” introduces a good deal of unneeded complexity. The complexity occurs because you are requiring a “three way handshake” before enabling temporary flooding. As it is only the new node which is temporarily NOT part of the flooding topology, it is natural to allow the new node to determine what edges to enable for temporary flooding. This is far simpler than trying to negotiate agreement between the new node and each of its neighbors.

We have published V1 of the draft which includes a limited discussion of this issue. Please see https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-01#section-6.8.3 .

Thanx.

    Les

From: Huaimo Chen <[email-masked]>
Sent: Monday, May 20, 2019 1:56 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Flooding Negotiation bit

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,

Best Regards,
Huaimo