Hi Hannes, > 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>)
IMO that's a valid option. Would work for me if the WG agrees on that one. (but there are many options and different opinions, so next step is to build consensus on this) We'll try to propose something, with your proposition in mind. Thanks for your contribution. Bruno > > /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 _________________________________________________________________________________________________________________________ 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
