Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

(ginsberg) ; lsr@ietf.org Subject: Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology Hi Robert, > The fact that we use them in a point-to-point fashion today is somewhat > orthogonal, as from > the routing protocol layer, we cannot tell whether an

Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

As far as attack if someone can attach to LAN and if he knows security details he can do much better then hack IGP. But oh well if we prefer to continue to ride on current type of roads while complicating design of new vehicles to accomodate it that is fine too. Best, R. On Wed, Apr 3, 2019,

Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

On Wed, Apr 3, 2019 at 1:36 AM Robert Raszuk wrote: > Hi Tony, > > > The fact that we use them in a point-to-point fashion today is somewhat > orthogonal, as from > > the routing protocol layer, *we cannot tell* whether an interface is > point-to-point or not, and we > > must be explicitly

Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

. >> >> Les >> >> >>> -----Original Message- >>> From: Lsr On Behalf Of Les Ginsberg (ginsberg) >>> Sent: Tuesday, April 02, 2019 8:31 AM >>> To: tony...@tony.li; lsr@ietf.org >>> Subject: [Lsr] Open issues with Dynamic F

Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

Przygienda Sent: Tuesday, April 02, 2019 3:34 PM To: Acee Lindem (acee) Cc: tony...@tony.li; Les Ginsberg (ginsberg) ; lsr@ietf.org Subject: Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology Read it through (fairly slowly even ;-) and seems Les is for simply

Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

Hi Tony, > As to signalling, I think we have not much choice and need to signal the > PNODE as either being in or out topology which implies LAN is in or out it > ... I would also consider optimizations to "sub-flood" the LAN (i.e. > disaggregate it to p2p floodings or nodes dropping

Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

Hello Robert, > For the purpose of this discussion can someone quote the definition of LAN ? Well, sure, if you insist. I’m surprised as you’ve been around for (quite) awhile and I would have thought that you picked up on this stuff. :-) :-) :-) ISO 10589v2 defines a LAN as a “Local Area

Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

opologies where flooding optimizations will be used, not supporting >> LANs seems to be an undesirable restriction. >> > >> > Les >> > >> > >> >> -Original Message- >> >> From: Lsr On Behalf Of Les Gi

Re: [Lsr] Open issues with Dynamic Flooding

Hi Huaimo, > Can you give some details about: what is the rate limiting link addition and > how does it (the rate limiting link addition) fix or help fix the flooding > topology (FT) split when multiple failures occur on FT? The details of the wording will have to wait until someone (probably

Re: [Lsr] Open issues with Dynamic Flooding

-boun...@ietf.org] On Behalf Of tony...@tony.li Sent: Monday, April 1, 2019 1:38 PM To: lsr@ietf.org Subject: Re: [Lsr] Open issues with Dynamic Flooding Hi all, I hope that everyone had a safe and uneventful trip home from Prague and that no one else had the seat right in front of the screaming

Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

>> From: Lsr On Behalf Of Les Ginsberg (ginsberg) >> Sent: Tuesday, April 02, 2019 8:31 AM >> To: tony...@tony.li; lsr@ietf.org >> Subject: [Lsr] Open issues with Dynamic Flooding: Including LANs in the >> Flooding Topology >>

Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

ptimizations will be used, not supporting LANs > seems to be an undesirable restriction. > > Les > > >> -Original Message- >> From: Lsr On Behalf Of Les Ginsberg (ginsberg) >> Sent: Tuesday, April 02, 2019 8:31 AM >> To: tony...@tony.li; lsr@ietf

Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

tf.org > Subject: [Lsr] Open issues with Dynamic Flooding: Including LANs in the > Flooding Topology > > (I have altered the subject so we can discuss the two issues in Tony's > previous post separately.) > > > There are several aspects to consider when discussing LAN supp

[Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

(I have altered the subject so we can discuss the two issues in Tony's previous post separately.) There are several aspects to consider when discussing LAN support in the context of flooding optimizations: 1)Flooding topology advertisement (centralized mode only) Support for encoding LANs

Re: [Lsr] Open issues with Dynamic Flooding

Hi all, I hope that everyone had a safe and uneventful trip home from Prague and that no one else had the seat right in front of the screaming baby. ;-) I would like to re-open the discussion on the mailing list. Based on the off-line discussions that I had with folks, I believe that we’re

Re: [Lsr] Open issues with Dynamic Flooding

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

Re: [Lsr] Open issues with Dynamic Flooding

> 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 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Open issues with Dynamic Flooding

Les, > 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

Re: [Lsr] Open issues with Dynamic Flooding

Hi, What does 'rate limit' mean in this context? Yours Irrespectively, John > -Original Message- > From: Lsr On Behalf Of Peter Psenak > Sent: Thursday, March 7, 2019 2:20 PM > To: tony...@tony.li > Cc: lsr@ietf.org > Subject: Re: [Lsr] Open issues with Dynamic Floo

Re: [Lsr] Open issues with Dynamic Flooding

On 07/03/2019 18:16 , tony...@tony.li wrote: On Mar 5, 2019, at 1:31 PM, tony...@tony.li wrote: 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

Re: [Lsr] Open issues with Dynamic Flooding

Tony - From: Lsr On Behalf Of tony...@tony.li Sent: Thursday, March 07, 2019 9:16 AM To: Tony Li Cc: lsr@ietf.org; Peter Psenak (ppsenak) Subject: Re: [Lsr] Open issues with Dynamic Flooding On Mar 5, 2019, at 1:31 PM, tony...@tony.li<mailto:tony...@tony.li> wrote: Let me propose t

Re: [Lsr] Open issues with Dynamic Flooding

> On Mar 5, 2019, at 1:31 PM, tony...@tony.li wrote: > > 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

Re: [Lsr] Open issues with Dynamic Flooding

> 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. ___ Lsr mailing list Lsr@ietf.org

Re: [Lsr] Open issues with Dynamic Flooding

Robert, On 05/03/2019 22:06 , Robert Raszuk wrote: 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

Re: [Lsr] Open issues with Dynamic Flooding

Hi Tony, On 05/03/2019 21:47 , tony...@tony.li wrote: 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

Re: [Lsr] Open issues with Dynamic Flooding

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

Re: [Lsr] Open issues with Dynamic Flooding

Got it, thx -Original Message- From: Tony Li On Behalf Of tony...@tony.li Sent: Tuesday, March 5, 2019 3:59 PM To: David Allan I Cc: Peter Psenak ; lsr@ietf.org Subject: Re: [Lsr] Open issues with Dynamic Flooding Hi Dave, > My understanding of this whole endea

Re: [Lsr] Open issues with Dynamic Flooding

Hi Dave, > 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

Re: [Lsr] Open issues with Dynamic Flooding

is the right heuristic to deal with this... Do I have this right? Just checking Dave -Original Message- From: Lsr On Behalf Of Peter Psenak Sent: Tuesday, March 5, 2019 3:26 PM To: tony...@tony.li Cc: lsr@ietf.org Subject: Re: [Lsr] Open issues with Dynamic Flooding Hi Tony, On 05/03

Re: [Lsr] Open issues with Dynamic Flooding

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

Re: [Lsr] Open issues with Dynamic Flooding

Hi Tony, On 05/03/2019 17:47 , tony...@tony.li wrote: Hi 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. it's limited to the links

Re: [Lsr] Open issues with Dynamic Flooding

Robert, On 05/03/2019 20:12 , Robert Raszuk wrote: 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

Re: [Lsr] Open issues with Dynamic Flooding

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

Re: [Lsr] Open issues with Dynamic Flooding

On Tue, Mar 5, 2019 at 11:12 AM Robert Raszuk wrote: > > > 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

Re: [Lsr] Open issues with Dynamic Flooding

> 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

Re: [Lsr] Open issues with Dynamic Flooding

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

Re: [Lsr] Open issues with Dynamic Flooding

Hi Tony, On 05/03/2019 17:16 , tony...@tony.li 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. I prefer (a)

Re: [Lsr] Open issues with Dynamic Flooding

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. > > I prefer (a) because of the faster convergence. > Adding all

Re: [Lsr] Open issues with Dynamic Flooding

I agree w/ Peter. Yours Irrespectively, John > -Original Message- > From: Lsr On Behalf Of Peter Psenak > Sent: Tuesday, March 5, 2019 2:38 AM > To: tony...@tony.li; lsr@ietf.org > Subject: Re: [Lsr] Open issues with Dynamic Flooding > > Hi Tony, > >

Re: [Lsr] Open issues with Dynamic Flooding

Xiaohu, On 05/03/2019 09:48 , 徐小虎(义先) wrote: Given that all links between routers are p2p these days, I would vote 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

Re: [Lsr] Open issues with Dynamic Flooding

> Given that all links between routers are p2p these days, I would vote > 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

Re: [Lsr] Open issues with Dynamic Flooding

Hi Tony, On 04/03/2019 18:54 , tony...@tony.li wrote: 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

[Lsr] Open issues with Dynamic Flooding

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: