I agree with Rob & Tony.

Converging on single algorithm across zoo of vendors is not going to happen
bearing in mind that every single change to such algorithm will require a
massive 1000s nodes software upgrade each time.

Note that even if IETF converges industry may not and that is a practical
aspect.

With current proposal this is just one time upgrade.

Thx,
R.

On Fri, Apr 6, 2018, 18:02 Rob Shakir <r...@rob.sh> wrote:

> 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