Hi Uma,
please see inline:
On 17/04/18 00:20 , Uma Chunduri wrote:
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?
that's not what we are proposing. At least not at this point.
Else I don't see any connection to different algorithms in the flooding
topology context; please clarify?
the discussion we are having in the context of the
draft-li-dynamic-flooding is whether to use the centralized or
distributed approach to compute the flooding topology.
Current text in the draft mandates the centralized approach and requires
flooding of the data to describe the "flooding topology" itself.
We are proposing to also support distributed version of it with either a
single standardized algorithm or possibly multiple distributed
algorithms, which would require some agreement between all devices in
the flooded domain.
thanks,
Peter
--
Uma C.
-----Original Message-----
From: Lsr [mailto:[email protected]] On Behalf Of Peter Psenak
Sent: Friday, April 06, 2018 8:50 AM
To: [email protected]
Cc: [email protected]
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 , [email protected] 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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
