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:lsr-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, April 9, 2019 11:09 AM
To: tony.li@tony.li; lsr@ietf.org
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 <lsr-bounces@ietf.org> On Behalf Of tony.li@tony.li
> Sent: Monday, April 08, 2019 7:27 AM
> To: lsr@ietf.org
> 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, tony.li@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 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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr