Subject: [Lsr] Open issues with Dynamic Flooding

From: [email-masked]
Date: Mon, 4 Mar 2019 09:54:24 -0800

Hello,

There are still two issues that need to be discussed and I was hoping that we could make progress on the mailing list before Prague.

1) Temporary additions to the flooding topology

    There are several cases where we would like to make temporary additions to the flooding topology: repairing a partition of the flooding topology or adding a node to the base topology for the first time. We can:

    (a) Temporarily add all of the links that would appear to remedy the partition. This has the advantage that it is very likely to heal the partition and will do so in the minimal amount of convergence time.

    (b) For each node adjacent to the partition, add no more than a single link across the partition.  If that does not repair the partition in a while (LSP propagation time + SPF time), then add another link.  
         Iterate as necessary. This has the advantage that it minimizes the risk of creating a cascade failure.

2) Inclusion of pseduonodes in the System IDs TLV

    In the general case, a topology can include LANs. If a LAN is in parallel with a P2P link, the Area Leader cannot currently distinguish between the two links. This can be of importance if there are other 
    systems also on the LAN that should be using their LAN interface for flooding.

    We propose to change the System IDs TLV to include a pseudo-node ID as well as the system ID.  It would also make sense to rename the TLV to be the “IS-IS Area Node IDs TLV”.

    Behaviorally, we should add a requirement that if the Area Leader includes a pseudonode in the flooding topology, then all systems with an adjacency on that LAN should use the LAN as part of the 
    flooding topology, whether or not they are explicitly listed as adjacent to the LAN in the Flooding Path TLV.

Thoughts? Comments? Flames?

Regards,
Tony

---

From: Peter Psenak <[email-masked]>
Date: Tue, 5 Mar 2019 08:38:18 +0100

Hi Tony,

>          Iterate as necessary. This has the advantage that it minimizes the risk of creating a cascade failure.

I prefer (a) because of the faster convergence.
Adding all links on a single node to the flooding topology is not going 
to cause issues to flooding IMHO.

>     flooding topology, whether or not they are explicitly listed as adjacent to the LAN in the Flooding Path TLV.

given that the flooding on the LAN in both OSPF and ISIS is done as 
multicast, there is currently no way to enable flooding, either 
permanent or temporary, towards a subset of the neighbors on the LAN. So 
if the flooding is enabled on a LAN it is done towards all routers 
connected to the it.

Given that all links between routers are p2p these days, I would vote 
for simplicity and make the LAN always part of the FT.

thanks,
Peter

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

---

From: "徐小虎(义先)" <[email-masked]>
Date: Tue, 05 Mar 2019 16:48:46 +0800

> for simplicity and make the LAN always part of the FT.

Even all links between routers are P2P these days, the network management LAN if available could be leveraged to realize an efficient link-state synchronization among  these routers. In other words, the management LAN itself is now the FT (see https://tools.ietf.org/html/draft-xu-lsr-isis-flooding-reduction-in-msdc-01).

Best regards,
Xiaohu

---

From: Peter Psenak <[email-masked]>
Date: Tue, 5 Mar 2019 10:27:40 +0100

Xiaohu,

On 05/03/2019 09:48 , 徐小虎(义先) wrote:
> Even all links between routers are P2P these days, the network
> management LAN if available could be leveraged to realize an efficient
> link-state synchronization among  these routers. In other words, the
> management LAN itself is now the FT
> (see https://tools.ietf.org/html/draft-xu-lsr-isis-flooding-reduction-in-msdc-01).

sure. What I proposed would not impact the above in any negative way.

thanks,
Peter

---

From: John E Drake <[email-masked]>
Date: Tue, 5 Mar 2019 15:41:46 +0000

I agree w/ Peter.

Yours Irrespectively,

John

> -----Original Message-----
> From: Lsr <[email-masked]> On Behalf Of Peter Psenak
> Sent: Tuesday, March 5, 2019 2:38 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [Lsr] Open issues with Dynamic Flooding
> 
> Hi Tony,
> 
> > There are still two issues that need to be discussed and I was hoping that we
> could make progress on the mailing list before Prague.
> >
> >     There are several cases where we would like to make temporary additions
> to the flooding topology: repairing a partition of the flooding topology or
> adding a node to the base topology for the first time. We can:
> >
> >     (a) Temporarily add all of the links that would appear to remedy the
> partition. This has the advantage that it is very likely to heal the partition and will
> do so in the minimal amount of convergence time.
> >
> >     (b) For each node adjacent to the partition, add no more than a single link
> across the partition.  If that does not repair the partition in a while (LSP
> propagation time + SPF time), then add another link.
> Adding all links on a single node to the flooding topology is not going to cause
> issues to flooding IMHO.
> 
> >
> >     In the general case, a topology can include LANs. If a LAN is in parallel with a
> P2P link, the Area Leader cannot currently distinguish between the two links.
> This can be of importance if there are other
> >     We propose to change the System IDs TLV to include a pseudo-node ID as
> well as the system ID.  It would also make sense to rename the TLV to be the
> “IS-IS Area Node IDs TLV”.
> >
> >     Behaviorally, we should add a requirement that if the Area Leader includes a
> pseudonode in the flooding topology, then all systems with an adjacency on that
> LAN should use the LAN as part of the
> given that the flooding on the LAN in both OSPF and ISIS is done as multicast,
> there is currently no way to enable flooding, either permanent or temporary,
> towards a subset of the neighbors on the LAN. So if the flooding is enabled on a
> LAN it is done towards all routers connected to the it.
> 
> Given that all links between routers are p2p these days, I would vote for
> simplicity and make the LAN always part of the FT.
> 
> thanks,
> Peter
> 
> 
> 
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_lsr&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoC
> > I&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=-
> E417ANRfgLCiCgXawxe
> > jcJyxNXCOHzVoAMRCQET2qU&s=LRWmU6Ra23ZzfiJF-
> sz0YFSTvQX5bU5qdQk5BKdhCX0&
> > e=
> >
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_lsr&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0
> UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE&m=-
> E417ANRfgLCiCgXawxejcJyxNXCOHzVoAMRCQET2qU&s=LRWmU6Ra23ZzfiJF-
> sz0YFSTvQX5bU5qdQk5BKdhCX0&e=

---

From: [email-masked]
Date: Tue, 5 Mar 2019 08:16:57 -0800

Peter,

> Adding all links on a single node to the flooding topology is not going to cause issues to flooding IMHO.

Could you (or John) please explain your rationale behind that? It seems counter-intuitive.

> given that the flooding on the LAN in both OSPF and ISIS is done as multicast, there is currently no way to enable flooding, either permanent or temporary, towards a subset of the neighbors on the LAN. So if the flooding is enabled on a LAN it is done towards all routers connected to the it.

Agreed.

> Given that all links between routers are p2p these days, I would vote for simplicity and make the LAN always part of the FT.

I’m not on board with this yet.  Our simulations suggest that this is not necessarily optimal.  There are lots of topologies (e.g., parallel LANs) where this blanket approach is suboptimal.

Tony

---

From: Peter Psenak <[email-masked]>
Date: Tue, 5 Mar 2019 17:27:22 +0100

Hi Tony,

> Could you (or John) please explain your rationale behind that? It seems counter-intuitive.

it's limited to the links on a single node. From all the practical 
purposes I don't expect single node to have thousands of adjacencies, at 
least not in the DC topologies for which the dynamic flooding is being 
primary invented.

In the environments with large number of adjacencies (e.g. 
hub-and-spoke) it is likely that we would have to make all these links 
part of the flooding topology anyway, because the spoke is typically 
dual attached to two hubs only. And the incremental adjacency bringup is 
something that an implementation may already support.

> I’m not on board with this yet.  Our simulations suggest that this is not necessarily optimal.  There are lots of topologies (e.g., parallel LANs) where this blanket approach is suboptimal.

the question is how much are true LANs used as transit links in today's 
networks.

thanks,
Peter

> .

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 5 Mar 2019 08:41:59 -0800

in practical terms +1 to Peter's take here ... Unless we're talking tons of
failures simultaneously (which AFAI talked to folks are not that common but
can sometimes happen in DCs BTW due to weird things) smaller scale failures
with few links would cause potentially diffused "chaining" of convergence
behavior rather than IGP-style fast healing (and on top of that I didn't
see a lot of interest in formalizing a rigorous distributed algorithm which
IMO would be necessary to ensure ultimate convergence when only one/subset
of links is used). Slow convergence is obviously not a good thing unless we
assume people will run FRR with its complexity in DC and/or no more than
one link every fails which seems to me bending assumptions to whatever
solution is available/preferred. To Tony's point though, on large scale
failures enabling all links would cause heavy flood load, yes, but in a
sense it's the "initial bootup" case anyway (especially in centralized
case) since nodes need all topology to make informed correct decisions
about what the FT should be if they don't rely on whatever the centralized
instance thinks (which they won't be able to do given the FT from
centralized instance will indicate lots links that are "gone" due to
failure). As to p2p, I suggest to agree whether you use dense mesh (DC)
case or sparse mesh (WAN) case or "every topology imaginable" since that
drives lots design trade-offs.

my 2.71828182 cents ;-)

--- tony

On Tue, Mar 5, 2019 at 8:27 AM Peter Psenak <[email-masked]> wrote:

> >>>    (a) Temporarily add all of the links that would appear to remedy
> the partition. This has the advantage that it is very likely to heal the
> partition and will do so in the minimal amount of convergence time.
> >>
> multicast, there is currently no way to enable flooding, either permanent
> or temporary, towards a subset of the neighbors on the LAN. So if the
> flooding is enabled on a LAN it is done towards all routers connected to
> the it.
> >
> >
> > Agreed.
> >
> >
> > I’m not on board with this yet.  Our simulations suggest that this is
> not necessarily optimal.  There are lots of topologies (e.g., parallel
> LANs) where this blanket approach is suboptimal.
>

---

From: [email-masked]
Date: Tue, 5 Mar 2019 08:47:15 -0800

Hi Peter,

> it's limited to the links on a single node. From all the practical purposes I don't expect single node to have thousands of adjacencies, at least not in the DC topologies for which the dynamic flooding is being primary invented.

What if the node in question is one of the spines?  Folks are building systems that large… and it seems inevitable that port counts will only grow.  Toto, I don’t think that’s an AGS any more…. ;-)

> In the environments with large number of adjacencies (e.g. hub-and-spoke) it is likely that we would have to make all these links part of the flooding topology anyway, because the spoke is typically dual attached to two hubs only. And the incremental adjacency bringup is something that an implementation may already support.

LS topologies can have a very large number of adjacencies as well, typically with multiple spines, so for a new spine, all of the of the links may be unnecessary.

>> Our simulations suggest that this is not necessarily optimal.  There are lots of topologies (e.g., parallel LANs) where this blanket approach is suboptimal.
> 
> the question is how much are true LANs used as transit links in today's networks.

As Xiaohu suggested, the management plane would be an obvious application. Interconnects also seem likely.

Let’s set the algorithmic parts aside.  Do you have an objection to supporting them in the signaling?

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 5 Mar 2019 20:12:41 +0100

> Slow convergence is obviously not a good thing

Could you please kindly elaborate why ?

With tons of ECMP in DCs or with number of mechanism for very fast data
plane repairs in WAN (well beyond FRR) IMHO any protocol *fast convergence*
is no longer a necessity. Yet many folks still talk about it like the only
possible rescue ...

On Tue, Mar 5, 2019 at 5:42 PM Tony Przygienda <[email-masked]> wrote:

> in practical terms +1 to Peter's take here ... Unless we're talking tons
> of failures simultaneously (which AFAI talked to folks are not that common
> but can sometimes happen in DCs BTW due to weird things) smaller scale
> failures with few links would cause potentially diffused "chaining" of
> convergence behavior rather than IGP-style fast healing (and on top of that
> I didn't see a lot of interest in formalizing a rigorous distributed
> algorithm which IMO would be necessary to ensure ultimate convergence when
> only one/subset of links is used). Slow convergence is obviously not a good
> thing unless we assume people will run FRR with its complexity in DC and/or
> no more than one link every fails which seems to me bending assumptions to
> whatever solution is available/preferred. To Tony's point though, on large
> scale failures enabling all links would cause heavy flood load, yes, but in
> a sense it's the "initial bootup" case anyway (especially in centralized
>> the it..
>> not necessarily optimal.  There are lots of topologies (e..g., parallel

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 5 Mar 2019 11:35:53 -0800

> is no longer a necessity. Yet many folks still talk about it like the only
Agree on FRR in WAN but it seems quite a complexity to drag that into DC
fabrics (again, depeneding what topologies talk about) especially due to
the effect I outline below.

ECMP in DCs when used AFAIS is often caused by walking the 10G-50G curve
where everybody has different economic sweet-spots AFAIS. Sometimes 100G.
It's often LAG'ed (due to amount of control plane state AFAIU). LAG'ing
generally creates interesting problems itself and I expect whole thing to
settle somewhere with 20-50G to the server over either very short copper or
multimode. I do not think it's a particularly cool architecture to suggest
"LAG every link so it's 1:1 protected".

Wide fanout is common & will get wider AFAIS. This is cool for failures in
one direction but doesn't prevent you from blackholing on the "far end"
until you get control plane reconvergence (or do FRR on a spine but
honestly, how do you do that, bow-tieing over top of fabric or doing
harmonica routing over multi-homed servers?)

Then, slow convergence means that new stuff shows up slowly which is
probably not very desirable and in case of failures that really need
control plane rerouting causes longer duration blackholes as well. Both
seem undesirable .. Not mentioning mobility even ...

my

   cents ;-)

--- tony

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 5 Mar 2019 20:53:39 +0100

Tony-P,

I am not talking about LAGs but pure vanilla L3 ECMP paths in any DC.

Any node will be receiving at least two copies of flooded topology
(regardless in which direction you look up or down) so when one of the
links is broken which is used for actual flooding or peer sending link
state info goes down flooding graph can be repaired at its own pace while
data plane is not impacted as there are many more L3 paths still available.

That was my point.

Thx,
r.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 5 Mar 2019 21:17:55 +0100

Robert,

On 05/03/2019 20:12 , Robert Raszuk wrote:
> plane repairs in WAN (well beyond FRR) IMHO any protocol *fast
> convergence* is no longer a necessity. Yet many folks still talk about
> it like the only possible rescue ...

we are talking about the control plane convergence, not data plane one.
If the flooding topology is subset of the real topology, then at the 
flooding level you don't have all the ECMPs available - you only have 
two paths to reach any node. In such case it is possible that the 
flooding topology gets partitioned and you want to get out of that state 
quickly, as you may get out of sync with the the reality and eventually 
loose all the data plane ECMPs as a consequence.

thanks,
Peter

>
>
> On Tue, Mar 5, 2019 at 5:42 PM Tony Przygienda <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     in practical terms +1 to Peter's take here ... Unless we're talking
>     tons of failures simultaneously (which AFAI talked to folks are not
>     that common but can sometimes happen in DCs BTW due to weird things)
>     smaller scale failures with few links would cause potentially
>     diffused "chaining" of convergence behavior rather than IGP-style
>     fast healing (and on top of that I didn't see a lot of interest in
>     formalizing a rigorous distributed algorithm which IMO would be
>     necessary to ensure ultimate convergence when only one/subset of
>     links is used). Slow convergence is obviously not a good thing
>     unless we assume people will run FRR with its complexity in DC
>     and/or no more than one link every fails which seems to me bending
>     assumptions to whatever solution is available/preferred. To Tony's
>     point though, on large scale failures enabling all links would cause
>     heavy flood load, yes, but in a sense it's the "initial bootup" case
>     anyway (especially in centralized case) since nodes need all
>     topology to make informed correct decisions about what the FT should
>     be if they don't rely on whatever the centralized instance thinks
>     (which they won't be able to do given the FT from centralized
>     instance will indicate lots links that are "gone" due to failure).
>     As to p2p, I suggest to agree whether you use dense mesh (DC) case
>     or sparse mesh (WAN) case or "every topology imaginable" since that
>     On Tue, Mar 5, 2019 at 8:27 AM Peter Psenak <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hi Tony,
>
>         On 05/03/2019 17:16 , [email-masked] <mailto:[email-masked]>
>         wrote:
>         >
>         > Peter,
>         >
>         >>>    (a) Temporarily add all of the links that would appear to
>         remedy the partition. This has the advantage that it is very
>         likely to heal the partition and will do so in the minimal
>         amount of convergence time.
>         >>
>         >> Adding all links on a single node to the flooding topology is
>         not going to cause issues to flooding IMHO.
>         >
>         >
>         >> given that the flooding on the LAN in both OSPF and ISIS is
>         done as multicast, there is currently no way to enable flooding,
>         either permanent or temporary, towards a subset of the neighbors
>         on the LAN. So if the flooding is enabled on a LAN it is done
>         towards all routers connected to the it..
>         >
>         >
>         > Agreed.
>         >
>         >
>         >> Given that all links between routers are p2p these days, I
>         would vote for simplicity and make the LAN always part of the FT.
>         >
>         >
>         > I’m not on board with this yet.  Our simulations suggest that
>         this is not necessarily optimal.  There are lots of topologies
>         (e..g., parallel LANs) where this blanket approach is suboptimal.
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Peter Psenak <[email-masked]>
Date: Tue, 5 Mar 2019 21:26:16 +0100

Hi Tony,

On 05/03/2019 17:47 , [email-masked] wrote:
>> purposes I don't expect single node to have thousands of adjacencies,
>> at least not in the DC topologies for which the dynamic flooding is
>> being primary invented.
>
>
> What if the node in question is one of the spines?  Folks are building
> systems that large… and it seems inevitable that port counts will only
> grow.  Toto, I don’t think that’s an AGS any more…. ;-)
>
>
>> dual attached to two hubs only. And the incremental adjacency bringup
>> is something that an implementation may already support.
>
>
> LS topologies can have a very large number of adjacencies as well,
> typically with multiple spines, so for a new spine, all of the of the
> links may be unnecessary.

ok, we talked bout the balance before - adding one link at a time to the 
FT may result in slow recovery, while adding all link is claimed to be 
dangerous. What is the right number? I feel that the increment value can 
be something that the implementation can choose or even make 
configurable, so the user can decide based on the particular topology 
and scale. We are not going to find the magic value I'm afraid.

>
>
>>> Our simulations suggest that this is not necessarily optimal.  There
>>> are lots of topologies (e.g., parallel LANs) where this blanket
>>> approach is suboptimal.
>>
> As Xiaohu suggested, the management plane would be an obvious
> application. Interconnects also seem likely.

I believe his case is completely orthogonal to this discussion as in his 
case there is a single giant LAN used for flooding and we all know we 
can not optimize flooding inside a LAN itself.

> supporting them in the signaling?

will get complicated, especially for OSPF/OSPFv3. Also temporary 
flooding operation on LAN is tricky and sub-optimal. I don't really 
believe it's worth the complexity.

my 2c,
Peter

---

From: [email-masked]
Date: Tue, 5 Mar 2019 12:47:53 -0800

> ok, we talked bout the balance before - adding one link at a time to the FT may result in slow recovery, while adding all link is claimed to be dangerous. What is the right number? I feel that the increment value can be something that the implementation can choose or even make configurable, so the user can decide based on the particular topology and scale. We are not going to find the magic value I'm afraid.

I agree that optimal is probably unknowable. The question then is what do we say in the document?  How about something about rate limiting?

> will get complicated, especially for OSPF/OSPFv3.

I have great confidence in you. ;-)

> Also temporary flooding operation on LAN is tricky and sub-optimal. I don't really believe it's worth the complexity.

Ok, I’m not following this.  It seems like one system would request flooding and the other nodes would comply.  Where’s this tricky?

Tony

---

From: David Allan I <[email-masked]>
Date: Tue, 5 Mar 2019 20:51:05 +0000

OK gents, sadly I’m losing the plot here......

My understanding of this whole endeavor is that:

- excessive flooding slows convergence
- so we are seeking to define a reduced flooding topology
- a failure that does not impact an FT adjacency is propagated throughout the topology and the effects of excessive flooding have been eliminated.... great.
- a failure that does impact the flooding topology results in the topology trying to mend itself and slowing down convergence while at it.....potentially by a significant amount
- And the current discussion is headed in the direction of what is the right heuristic to deal with this...

Do I have this right?
Just checking
Dave

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Peter Psenak
Sent: Tuesday, March 5, 2019 3:26 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] Open issues with Dynamic Flooding

Hi Tony,

On 05/03/2019 17:47 , [email-masked] wrote:
>> hub-and-spoke) it is likely that we would have to make all these
>> links part of the flooding topology anyway, because the spoke is
>> typically dual attached to two hubs only. And the incremental
>> adjacency bringup is something that an implementation may already support.
>
>

> application. Interconnects also seem likely.

I believe his case is completely orthogonal to this discussion as in his case there is a single giant LAN used for flooding and we all know we can not optimize flooding inside a LAN itself.

my 2c,
Peter

---

From: [email-masked]
Date: Tue, 5 Mar 2019 12:59:12 -0800

Hi Dave,

> - And the current discussion is headed in the direction of what is the right heuristic to deal with this...

Close.

More specifically, if there is a multiple failure that partitions the FT, how do we repair it?  Fast or safe? Choose one. 

Tony

---

From: David Allan I <[email-masked]>
Date: Tue, 5 Mar 2019 21:00:59 +0000

Got it,

thx

-----Original Message-----
From: Tony Li <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, March 5, 2019 3:59 PM
To: David Allan I <[email-masked]>
Cc: Peter Psenak <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Open issues with Dynamic Flooding

Hi Dave,

Close.

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 5 Mar 2019 22:06:41 +0100

Peter,

> you only have two paths to reach any node.

Who says that you must be limited to two paths only ?

Why not create a flooding graph such that flooding will happen over 4 paths
as opposed to flooding over 16 or 32 today without optimization.

And if you are worried that you loose *wisely selected* all 4 paths before
you manage to distribute new flooding topology you can always flood over 6
:)

Best,
R.

On Tue, Mar 5, 2019 at 9:17 PM Peter Psenak <[email-masked]> wrote:

> >         links

---

From: Peter Psenak <[email-masked]>
Date: Tue, 5 Mar 2019 22:08:19 +0100

Hi Tony,

On 05/03/2019 21:47 , [email-masked] wrote:
>> ok, we talked bout the balance before - adding one link at a time to
>> the FT may result in slow recovery, while adding all link is claimed
>> to be dangerous. What is the right number? I feel that the increment
>> value can be something that the implementation can choose or even make
> I agree that optimal is probably unknowable. The question then is what
> do we say in the document?  How about something about rate limiting?

yes, something of that nature, with possible config option.

>> Also temporary flooding operation on LAN is tricky and sub-optimal. I
>> don't really believe it's worth the complexity.
>
>
> Ok, I’m not following this.  It seems like one system would request
> flooding and the other nodes would comply.  Where’s this tricky?

the trick is that "all" nodes would comply, where we may only need 
one/subset to do...

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Tue, 5 Mar 2019 22:10:13 +0100

Robert,

On 05/03/2019 22:06 , Robert Raszuk wrote:
> Why not create a flooding graph such that flooding will happen over 4
> paths as opposed to flooding over 16 or 32 today without optimization.
>
> And if you are worried that you loose *wisely selected* all 4 paths
> before you manage to distribute new flooding topology you can always
> flood over 6 :)

we want to limit the flooding to minimum, which is 2.

thanks,
Peter

>
> Best,
> R.
>
>
>
>
>
>
>
> On Tue, Mar 5, 2019 at 9:17 PM Peter Psenak <[email-masked]
>     > On Tue, Mar 5, 2019 at 5:42 PM Tony Przygienda
>     <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >         Hi Tony,
>     >
>     >         On 05/03/2019 17:16 , [email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     >         wrote:
>     >         >
>     >         > Peter,
>     >         >
>     >         > Could you (or John) please explain your rationale behind
>     that?
>     >         It seems counter-intuitive.
>     >
>     >         least not in the DC topologies for which the dynamic
>     flooding is
>     >         being
>     >         primary invented.
>     >
>     >         the question is how much are true LANs used as transit
>     links in
>     >         today's
>     >         networks.
>     >
>     >         thanks,
>     >         Peter
>     >
>     >         >
>     >         > Tony
>     >         >
>     >         > .
>     >         >
>     >
>     >         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 5 Mar 2019 22:12:01 +0100

> we want to limit the flooding to minimum, which is 2.

Is that really a common agreement in the WG ? I have a feeling think this
is too restrictive for no valid technical reason.

r.

---

From: [email-masked]
Date: Tue, 5 Mar 2019 13:23:34 -0800

> Is that really a common agreement in the WG ? I have a feeling think this is too restrictive for no valid technical reason. 

Well, it’s been the requirement that has been unchallenged since we started this journey.

The technical reason for this is clear: if too much flooding is hurting you and we need bi-connectivity to protect against failures, then adding more connectivity seems like it negates the benefits of the restricted topology.

I should note that for many topologies and for many nodes, being just bi-connected will not be possible.  In any interesting LS network, for example, where # leaves >> # spines, the spines will still have many active connections in the FT.  While having leaves with 4 or 6 connections is certainly possible, it seems inadvisable.

Tony

---

From: [email-masked]
Date: Tue, 5 Mar 2019 13:31:22 -0800

> yes, something of that nature, with possible config option.

Let me propose that we add something to sections 6.7.5, 6.7.9, and 6.7.11 like:

Addition of temporary flooding should be done with caution, as the addition of excessive connectivity to the flooding topology may trigger unwanted behavior. Routers SHOULD add temporary flooding in a rate limited manner, if not configured otherwise.

> the trick is that "all" nodes would comply, where we may only need one/subset to do...

This is the addition of one link, and in particular the onus is really on the DIS to drive synchronization.  Per your above arguments, I’m comfortable with this.

Tony

---

From: [email-masked]
Date: Thu, 7 Mar 2019 09:16:24 -0800

> On Mar 5, 2019, at 1:31 PM, [email-masked] wrote:
> 

Hi,

I haven’t heard any feedback on this.  Can we please adopt this?

The draft cutoff is Monday, March 11.  Could we please incorporate this change and the addition of the pseudonode identifier by then?

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 7 Mar 2019 17:50:17 +0000

Tony -

From: Lsr <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, March 07, 2019 9:16 AM
To: Tony Li <[email-masked]>
Cc: [email-masked]; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Lsr] Open issues with Dynamic Flooding

On Mar 5, 2019, at 1:31 PM, [email-masked]<mailto:[email-masked]> wrote:

[Les:] The first sentence is OK with me. The second one I think goes beyond anything on which we can claim consensus.
Whether adding the first sentence alone is worth a new revision I think is questionable – but I certainly would not oppose it.

Regarding LANs, the encoding for OSPF is more problematic – basically we need to identify the value as a router id or a network LSA id (or something like that).
So, committing to this without consensus has a downside that we might live to regret.

I am in agreement with Peter’s position. LANs introduce additional complexity and it is not clear that including that support is a real benefit in the topologies in which we expect the flooding optimizations to be used.
I know you believe real deployments may need this support – but what I don’t know is whether we have hard evidence to support that position.

I am also wondering whether the following serves us better:

a)We keep LANs always enabled for flooding
b)The algorithms consider this and are biased towards using LANs when possible as this is a cheaper way to enable flooding to multiple nodes than many P2P interfaces.

IN this way we keep the simplicity of not having to define LAN behavior/encoding, yet reap benefits in topologies where LANs have a significant presence.

Let me know what problems you see with this approach.

   Les

Hi,

Tony

---

From: Peter Psenak <[email-masked]>
Date: Thu, 7 Mar 2019 20:20:27 +0100

On 07/03/2019 18:16 , [email-masked] wrote:
>
>
>> On Mar 5, 2019, at 1:31 PM, [email-masked] <mailto:[email-masked]>
>> wrote:
>>
>> Addition of temporary flooding should be done with caution, as the
>> addition of excessive connectivity to the flooding topology may
>> trigger unwanted behavior. Routers SHOULD add temporary flooding in a
>> rate limited manner, if not configured otherwise.
>
>
> Hi,
>
> The draft cutoff is Monday, March 11.  Could we please incorporate this
> change and the addition of the pseudonode identifier by then?

I don't think there is an agreement on the LAN side.

Rate limiting we can add, but we can do that after March 11, I don't see 
a need to do it before.

thanks,
Peter

---

From: John E Drake <[email-masked]>
Date: Thu, 7 Mar 2019 20:12:41 +0000

Hi,

What does 'rate limit' mean in this context?

Yours Irrespectively,

John

> Sent: Thursday, March 7, 2019 2:20 PM
> To: [email-masked]
> Cc: [email-masked]
> > The draft cutoff is Monday, March 11.  Could we please incorporate
> > this change and the addition of the pseudonode identifier by then?
> 
> Rate limiting we can add, but we can do that after March 11, I don't see a need
> to do it before.
> 
> thanks,
> Peter
> 
> 
> >
> > Tony
> >
> 
> s_xXXup3HzvBSMRj5VE&m=8bZHYmmMERie3AZxsYrvUH_fhv9JyTIkivlY1wizKms
> &s=ZRx3I9aH56q-UmcY_tUkOuIAxjGDEMgE_qeMPmekSgk&e=

---

From: [email-masked]
Date: Thu, 7 Mar 2019 12:35:41 -0800

Les,

> [Les:] The first sentence is OK with me.

Great!

> The second one I think goes beyond anything on which we can claim consensus.

Ok, thank you for saying so.  Silence is assent, so what should it say?

> Whether adding the first sentence alone is worth a new revision I think is questionable – but I certainly would not oppose it.

The cost of a new revision is trivial, given that the system is automated.

> Let me know what problems you see with this approach.

Again, there are lots of cases where having LANs enabled is sub-optimal.  Parallel LANs, for example.

Yes, LANs MAY be a useful way of covering the topology, but without algorithm specifics, it’s difficult to discuss.  In the simulation work that we’ve done, it’s pretty much a wash. Sometimes it’s helpful, sometimes it’s redundant. It very much depends on the topology.

You can imagine a LS network where ALL links are still in LAN mode.  By your rules, that completely disabled dynamic flooding.  I don’t think that’s tractable.

Not being able to describe the flooding topology precisely is a significant hindrance and is going to cause misbehavior one way or another.  Suppose that we have nodes A, B, and C.  Suppose that AB is a P2P link and {A, B, C} is a LAN.  Now suppose that the topology requests path AB.  What do A and B do?  If the LAN was intended, then C is included.  How does C know that?  

So, I don’t think LANs on all of the time works.  And then we need to be able to specify what’s going on, so that means naming LANs somehow.

Tony

---

From: [email-masked]
Date: Thu, 7 Mar 2019 13:03:01 -0800

> What does 'rate limit' mean in this context?

It means that implementations get to decide how quickly they make temporary additions to the flooding topology.

T

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 7 Mar 2019 21:51:40 +0000

Tony -

[Les2:] I am not prepared to say at the moment – which is why I was suggesting it’s too soon to add this.

[Les2:] Since our current encoding does not support LANs, AB can only mean P2P – meaning the non-present pseudo-node ID is assumed to be 0.
Nodes would need to understand that reachable LANs (as advertised in pseudo-node LSPs and the pseudo-node neighbors advertised in non-pseudo-node LSPs) are always part of the flooding topology.

    Les