Alia, Some corner cases here and there, but yes, Francois' code (Francois Clad, not me) computes these sequences in a ridiculously low amount of time, and the sequences tend to be very short even in large topologies.
I still think this should be investigated for maintenance cases and metric updates stemming out of a TE exercise. I do not think this is a practical approach to apply after a FRR application. Cheers, Pierre. On Oct 31, 2013, at 4:54 PM, Alia Atlas <[email protected]> wrote: > Pierre, > > Thanks for the updates. Can you summarize? Have the number of changes > become few enough in general to be practical? > > Alia > > > On Thu, Oct 31, 2013 at 11:49 AM, Pierre Francois <[email protected]> > wrote: > Stephane, > > Much progress on the topic has been made since that much preliminary Infocom > paper. > So here come more up-to-date reference points to compare: > > Graceful Convergence in Link-State IP Networks > F. Clad, P. Mérindol, J.-J. Pansiot, P. Francois and O. Bonaventure > In IEEE/ACM Transactions on Networking, 2013 > > documents the most optimised algorithm known so far for the link shutdown > case, with extensive simulation results and performance analysis. > > > Graceful Router Updates for Link-State Protocols > F. Clad, P. Mérindol, S. Vissicchio, J.-J. Pansiot and P. Francois > In proceedings of IEEE ICNP 2013, Göttingen, Germany, October 2013 > > provides an algorithm to do the same in the node shutdown case, smarter than > doing one link after the other. > > Cheers, > > Pierre. > > > > > > On Oct 23, 2013, at 2:01 PM, [email protected] wrote: > >> Hi, >> >> I would need more time to review your algo part. But anyway, could you >> explain the difference with some old public approach like the paper from >> Pierre, Mike and Olivier : >> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67.8263&rep=rep1&type=pdf >> >> Moreover I would be interested to see in your draft some simulation proving >> the metric list is quite low ... >> I can remember in the paper I'm referencing that the challenge was to >> compress the KMS list in order to prevent a very very long list which would >> not be applicable in a live network. >> >> Thanks >> >> Stephane >> >> >> >> -----Message d'origine----- >> De : [email protected] [mailto:[email protected]] De la part de >> Yangang >> Envoyé : lundi 21 octobre 2013 03:49 >> À : [email protected] >> Cc : Zhangxudong (zhangxudong, VRP); Yangang >> Objet : Soliciting WG feedback and comments on >> draft-zxd-rtgwg-ordered-metric-adjustment-00 >> >> Hi: >> >> We had submitted the a new draft: >> http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00, we >> want to discuss the micro-loop problem through another method. Your feedback >> and comments on the rtgwg mailing list are appreciated. >> >> Thanks, >> Rahul.Yan >> >> -----邮件原件----- >> 发件人: [email protected] [mailto:[email protected]] >> 发送时间: 2013年10月18日 15:47 >> 收件人: Zhangxudong (zhangxudong, VRP); Yangang >> 主题: New Version Notification for >> draft-zxd-rtgwg-ordered-metric-adjustment-00.txt >> >> >> A new version of I-D, draft-zxd-rtgwg-ordered-metric-adjustment-00.txt >> has been successfully submitted by Xudong Zhang and posted to the >> IETF repository. >> >> Filename: draft-zxd-rtgwg-ordered-metric-adjustment >> Revision: 00 >> Title: Algorithm for Ordered Metric Adjustment >> Creation date: 2013-10-18 >> Group: Individual Submission >> Number of pages: 10 >> URL: >> http://www.ietf.org/internet-drafts/draft-zxd-rtgwg-ordered-metric-adjustment-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-zxd-rtgwg-ordered-metric-adjustment >> Htmlized: >> http://tools.ietf.org/html/draft-zxd-rtgwg-ordered-metric-adjustment-00 >> >> >> Abstract: >> Upon link down event or link up event, each device in network >> individually schedules route calculation. Because of different >> hardware capabilities and internal/external environments, the time to >> update forwarding entries on these devices are disordered which can >> cause a transient forwarding loop. This document introduces a method >> to prevent forwarding loop by adjusting link metric gradually for >> several times. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> _______________________________________________ >> 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 > >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
