Hi Peter,

> 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.


I see

https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-algo/?include_text=1
 proposes flexible algorithms for route computation. 

Here, you are saying similar to flexible algorithms for route computation - 
flexible algorithms can be used for computing "flooding topology" in a 
distributed fashion ; is that correct?

Else I don't see any connection to different algorithms in the flooding 
topology context; please clarify?
--
Uma C.


-----Original Message-----
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
Sent: Friday, April 06, 2018 8:50 AM
To: tony...@tony.li
Cc: lsr@ietf.org
Subject: Re: [Lsr] Fwd: New Version Notification for 
draft-li-dynamic-flooding-04.txt

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

Reply via email to