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:* lsr@ietf.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:* lsr@ietf.org; 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

Reply via email to