Huaimo - I am aware of the other thread and the discussion you are having with Tony. My reading of it is that you have not yet defined a deterministic solution to this problem - you have only defined the goal. If you do define a deterministic solution, that would be most welcome and we can then incorporate it in the Dynamic Flooding draft.
Please continue the thread w Tony. Thanx. Les > -----Original Message----- > From: Huaimo Chen <[email protected]> > Sent: Tuesday, April 09, 2019 8:47 AM > To: Les Ginsberg (ginsberg) <[email protected]>; [email protected]; > [email protected] > Subject: RE: [Lsr] Fwd: Open issues with Dynamic Flooding > > Hi Les, > > For "add temporary flooding in a rate limited manner", can you give some > details about how does the rate limit manner work for fixing a FT split? how > does each node get the rate limit? Will every node add temporary flooding > on a given number of links independently? If so, there are lots of links to be > added into the FT temporarily for fixing the FT split. This may cause some > issues. > In another thread "[Lsr] Min Links for Multiple Failures on Flooding > Topology", there is a solution for fixing the FT split using almost minimum > number of links. > > Best Regards, > Huaimo > -----Original Message----- > From: Lsr [mailto:[email protected]] On Behalf Of Les Ginsberg (ginsberg) > Sent: Tuesday, April 9, 2019 11:09 AM > To: [email protected]; [email protected] > Subject: Re: [Lsr] Fwd: Open issues with Dynamic Flooding > > Tony - > > Here is my take. > > Regarding Issue #2 below, we had a healthy thread on this since Prague and I > believe have consensus that we WILL support LANs in the encoding of the > flooding topology (centralized mode). Authors need to agree on changes to > the draft which we will take offline and then publish an update. > > Regarding Issue #1 below, we did have a thread on this BEFORE Prague and > seemed to reach consensus on: > > <snip> > 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. > > <end snip> > > (See attached email) > > Again, authors need to address this in the next draft revision but I believe > we > have agreement in principle. > > So I think we can consider these matters resolved - pending WG feedback on > the updated draft whenever it becomes available. > > Les > > > > -----Original Message----- > > From: Lsr <[email protected]> On Behalf Of [email protected] > > Sent: Monday, April 08, 2019 7:27 AM > > To: [email protected] > > Subject: [Lsr] Fwd: Open issues with Dynamic Flooding > > > > > > Hi all, > > > > It’s been another week and we’ve had a few more very interesting > > conversations, but we seem to have not moved very far. > > > > Have we converged? > > > > Tony > > > > > > > > > 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 leaning > > towards including the LANs in the signaling and rate limiting link addition > during repair. > > > > > > Dissent? Discussion? > > > > > > Tony > > > > > > > > >> On Mar 4, 2019, at 9:54 AM, [email protected] 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 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 > > >> > > > > > > > _______________________________________________ > > Lsr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
