Stephane, My opinion is that majority of the changes in backbones can be described by a single or two LSPs. So modern routers the initial wait is unnecessary in most of the cases or is roughly equal to network jitter. If there's a major failure you might want to wait for roughly the full or 1/2 of the time it takes the LSPs to be propagated from one end of your network to the other end + the delay variation (this of course would be different for each network). That is when you would like the SPF to converge asap. However with FRR at hand we can go with whatever the common default timers are gonna be.
adam > -----Original Message----- > From: rtgwg [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Friday, July 25, 2014 6:43 PM > To: Hannes Gredler; DECRAENE Bruno IMT/OLN; Russ White > Cc: [email protected] > Subject: RE: On minimizing SPF backoff induced blackouts > > Hannes, > > I agree with you at now routers are able to handle multiple events in a short > time but anyway : > - delaying is always necessary (I can't really see how we can go under > 100/150ms) : > If you go to something like 0 or 5 msec, we may fall into > implementations issues with constant READ/WRITE contentions in FIB that > often cause corner cases where the router is completely lost in what it must > do > Moreover in case of complex outage (node failure or SRLG failure) > where multiple LSPs are sent. We must ensure that all LSPs are received > before computing SPF to ensure that the target topology is a good one. > > - Increasing delay is also necessary. By experience there are situations where > you need absolutely to calm down computation to prevent churn > amplification (even today with stronger CPUs) > - we need to ensure that increasing delay steps are not so big, so in case of > router unsynchronization (in delay value), the difference would be small. > - as agreed , we can run more fast scheduled SPFs > > Both current implementations (two steps and backoff) do no fill these > "requirements". > > I would be in favor of standardizing something really simple with no > mathematic underway. Just extend the two steps to an N-Step tunable > system that the operator can manage. > Something like defining a WRED profile but without interpolation. > Example : > > Initial : 100 ms, 4 runs > 2nd : 200ms, 2 runs > 3rd : 300ms, 2 runs > 4th : 500ms, 2 runs > 5th : 700ms, 2 runs > 6th : 800ms, 2 runs > 7th : 1s, all subsequent runs > > > > -----Original Message----- > From: rtgwg [mailto:[email protected]] On Behalf Of Hannes Gredler > Sent: Thursday, July 24, 2014 15:03 > To: DECRAENE Bruno IMT/OLN; Russ White > Cc: [email protected] > Subject: RE: On minimizing SPF backoff induced blackouts > > hi bruno, > > IMO the problem that you're trying to solve is to have the routers still being > responsive when multiple events are happening in the network. > > wouldn't then a simple fix be to kick the SPF pacing logic at a much more > later > point in time ? - i.e. rather than slowing down things down on event #2 or #3, > do it at event #<N> (please insert you're favorite number for <N>) > > /hannes > > ________________________________________ > From: rtgwg <[email protected]> on behalf of > [email protected] <[email protected]> > Sent: Thursday, July 24, 2014 20:56 > To: Russ White > Cc: [email protected] > Subject: RE: On minimizing SPF backoff induced blackouts > > > > I'm willing to be persuaded, I just don't see the argument for > > > specifying an algorithm with what's been put on the table to this point. > > > > Ok. So I guess my presentation/draft was not clear enough. > > Let me try again. > In slide 5: http://tools.ietf.org/agenda/90/slides/slides-90-rtgwg-2.pdf > - do we agree that it would be better if node A and B both schedule their SPF > at roughly the same time? i.e. wait for the same duration? > - if so, what would be your proposition? > > Bruno > > > __________________________________________________________ > __________________________________________________________ > _____ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg > > __________________________________________________________ > __________________________________________________________ > _____ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
