Re: [Lsr] Fwd: Open issues with Dynamic Flooding

Hi Les,

    Thanks much.
    I have defined a deterministic solution.

Best Regards,
Huaimo
-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] 
Sent: Tuesday, April 9, 2019 11:51 AM
To: Huaimo Chen <huaimo.chen@huawei.com>; tony.li@tony.li; lsr@ietf.org
Subject: RE: [Lsr] Fwd: Open issues with Dynamic Flooding

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 <huaimo.chen@huawei.com>
> Sent: Tuesday, April 09, 2019 8:47 AM
> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; tony.li@tony.li; 
> lsr@ietf.org
> 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: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