Hi Les, Just to clarify ..
*as is* - was meant to indicated as described in draft-li-dynamic-flooding proposal. Not *as is* today in IGPs. Thx, R. On Sat, Apr 7, 2018 at 9:47 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > Robert – > > > > I think discussion of RIFT belongs in the appropriate WG – not here. > > > > Flooding “as is” isn’t relevant here – since “as is” would mean as the > IGPs do it today. > > Whether the flooding topology is calculated/advertised by a designated > node or is calculated in a distributed fashion clearly a different flooding > topology from the one IGPs use today is required or we will have > accomplished nothing. > > > > Les > > > > > > *From:* Lsr <lsr-boun...@ietf.org> *On Behalf Of *Robert Raszuk > *Sent:* Saturday, April 07, 2018 10:44 AM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* firstname.lastname@example.org; Rob Shakir <r...@rob.sh>; tony...@tony.li; Peter > Psenak (ppsenak) <ppse...@cisco.com> > > *Subject:* Re: [Lsr] Fwd: New Version Notification for > draft-li-dynamic-flooding-04.txt > > > > Les, > > > > Isn't RIFT effectively a new flooding algorithm - while not strictly > designed to be used within current link state protocols - it has the > potential to achieve what you and Peter are proposing isn't it ? > > > > My personal take here would be to progress dynamic flooding *as is* with > the use of DR/DIS as flooding oracles. > > > > If you or anyone however would like to propose a new flooding algorithm to > link state protocols I think nothing stops you to write a separate draft on > that and call it say -optimal-flooding-. > > > > Best, > Robert. > > > > > > > > On Fri, Apr 6, 2018 at 10:06 PM, Les Ginsberg (ginsberg) < > ginsb...@cisco.com> wrote: > > I think this discussion has already gone much too far in the direction of > customized flooding optimizations. Such is the nature of the engineering > mind – give us a problem to solve and we’ll come up with a plethora of > solutions. > > > > The right perspective (for me anyway) is this: > > > > IGPs have been popular as distribution mechanisms in part because of the > reliability of their flooding process. This wasn’t easy to achieve – and > those of us who have been in the business long enough have seen attempts to > create something equivalent fall flat on their face because they couldn’t > handle the corner causes. Simple yet robust has been the guiding principle > and both IGPs do this well. > > > > It is also useful to remember that bandwidth utilization for IGP flooding > is not a problem which we need to solve. It has been demonstrated – even > long ago with much less bandwidth than we have today – that IGP flooding > bandwidth isn’t a concern. So proposals which suggest we might need to come > up with an algorithm that optimizes for bandwidth or SRLGs or whatever > criteria one could imagine seem unnecessary – as well as incestuous. And > they certainly complicate the problem. > > > > I agree with Peter’s suggestion that a common decentralized algorithm is > desirable. It will simplify problems associated with reconvergence which I > think is key. > > And I don’t think we really need to support multiple algorithms – it was > nice of Peter to allow for that – but as we see now everyone is concerned > about the upgrade issues that come with introducing a new algorithm. > > > > Let’s agree on one algorithm and be done. > > A variant on https://tools.ietf.org/html/rfc6325#section-4.5.1 is one > such candidate. > > > > Les > > > > > > *From:* Lsr <lsr-boun...@ietf.org> *On Behalf Of *Rob Shakir > *Sent:* Friday, April 06, 2018 9:03 AM > *To:* Peter Psenak (ppsenak) <ppse...@cisco.com> > *Cc:* email@example.com; tony...@tony.li > *Subject:* Re: [Lsr] Fwd: New Version Notification for > draft-li-dynamic-flooding-04.txt > > > > Peter, > > > > How do we transition between algorithms in the approach that you suggest? > Do all non-stub devices need to be upgraded to support the new algorithm > before such time as we can use it? (I think so, because otherwise some > non-stub device cannot be guaranteed to flood to its downstream stub > devices - so we may end up isolating some devices if any device transitions > before all nodes support it). > > > > The advantage of having something advertised is that one can compute it > centrally - and keep the per-node functionality simply obeying the > advertised flooding graph. From an operational perspective, this means that > one can introduce new experimental flooding topology computation approaches > in a manner that is decoupled from needing to do software upgrades across > the whole network. I can also implement non-standard flooding topology > computations based on the network topology which could be only applicable > to that particular network (consider if I wanted to do something like take > into account shared-risk information in the algorithm to allow the > most-SRLG disjoint flooding topology or so). > > > > This is in addition to the points Tony made. I think this > centralised-computation-and-flooded approach is elegant. If the error > handling behaviour for not being able to parse the flooding topology is to > revert to flooding everywhere, then it seems non-destructive too. > > > > Cheers, > > r. > > > > On Fri, 6 Apr 2018 at 08:50 Peter Psenak <ppse...@cisco.com> wrote: > > Hi Tony, > > if we start with a single standardized algorithm, that is easy to > implement and deploy. We can leave the door open for additional > algorithms to be defined later together with the selection mechanism. > > I have the feeling that the dependency of the "flooding topology" on the > flooded data is going to bring more complexity, than the selection of > the distributed algorithm to be used, if we ever need to support more > then one. > > thanks, > Peter > > > On 06/04/18 17:19 , tony...@tony.li wrote: > > > > Hi Peter, > > > > Thank you for your comments. > > > >> while I appreciate the flexibility associated with the centralized > >> computation of the flooding topology, it has some drawbacks as well: > >> > >> 1. "flooding topology" must be flooded. This makes the flooding > >> dependent on the flooded data itself. > > > > > > Absolutely true. If the computation of the topology is incorrect, that > > would certainly be a bug. > > > > > >> 2. The extra flooding of "flooding topology" adds some delay in the > >> convergence towards the new "flooding topology”. > > > > > > Since we distribute the flooding topology before there are topology > > failures, it would seem like the latency is not a significant concern. > > > > > >> Have you considered the distributed computation of "flooding topology" > >> using some standardized algorithm? > > > > > > Yes, Kireeti raised this in London as well. There are some practical > > issues with this. How do we ever converge on an algorithm? > > > > There are many perspectives on what an adequate flooding topology might > > be. Different administrations have different considerations and risk > > tolerances. > > > > Debugging is going to be more challenging, as inconsistencies between > > two nodes with different ideas of the topology will be difficult to > > detect until there is a catastrophic failure. > > > > I’m trying to do something practical, and it seems like doing this in a > > centralized fashion is the quickest, easiest, and most robust way > forward. > > > > > >> Eventually we can support multiple standardized algorithms. A node can > >> advertise support for several algorithms and the "active" algorithm is > >> selected based on some criteria that would guarantee that all nodes in > >> the flooding domain select the same one. > > > > > > Seems like that would also require some administrative input. > > > > So, I agree that that’s a technical possibility, but I think that > > there’s significant problems in making that work. I prefer to focus on > > something that we can implement more quickly. > > > > Tony > > > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr