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<mailto: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<mailto: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<mailto: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