Dear Bruno, Stephane, > my understanding is that all commenters agreed that having a standardized > algorithm would be better as it would allow all routers in a network to > compute the same SPF delay
Sure, It's fine to have a uniform mandatory SPF trigger algorithm. But I would note the for the link failure examples described in https://datatracker.ietf.org/doc/draft-litkowski-rtgwg-spf-uloop-pb-statement/?include_text=1 (Section 2) we have LFA's which can serve us till the re-convergence happens. Also : In Section 3 you said - ==== 2. Run only Full SPF when required : e.g. if a link fails, a local node will run an SPF for its local LSP update. If the LSP from the neighbor (describing the same failure) is received after SPF has started, the local node can decide that a new full SPF is not required as the topology has not change. 3. If topology does not change, only recompute reachability. ==== As we all agree it's very cheap to compute SPF (especially when we are doing 100's LFA/remote LFA SPFs for each primary SPF) today; in that context we should not be picky on primary SPF (Partial/Full). Just to give an example, due to multi-homed prefixes in the network, if we do incorrect computation to save few mill-seconds this can last till the next trigger comes! So I would request to avoid above discussion in this context, as that is not the main point of the draft/what you are seeking. -- Uma C. -----Original Message----- From: rtgwg [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, July 23, 2014 4:25 PM To: [email protected] Subject: RE: draft-decraene-rtgwg-backoff-algo-00.txt Hi all, Today's presentations have triggered many interesting feedback and comment (which is good, many thanks for your time) but time has not allowed discussing all the comments (a) nor summarizing the feedbacks (b). Regarding a), could you please post your additional comments on the list? (or emailed them privately if preferred) As all comments are welcomed. Regarding b), my understanding is that all commenters agreed that having a standardized algorithm would be better as it would allow all routers in a network to compute the same SPF delay (*). Please correct me if I'm wrong. Thanks, Regards, Bruno, Stéphane (*) assuming that the network owner has configured the same parameters on all routers; but this is orthogonal. > From: Isis-wg [mailto:[email protected]] On Behalf Of > > Hi all, > > Please find below a proposed short draft which: > -a- calls for a standardized SPF back-off algorithm, for > interoperability purpose > -b- proposes an algorithm > > Comments are welcomed. > > Note that v00 currently proposes the algorithm which is the most > deployed. I would be fine with any modification, based on WG consensus > (assuming WG adoption). > > Thanks, > Regards, > Bruno > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Thursday, July 03, 2014 12:16 PM > > A new version of I-D, draft-decraene-rtgwg-backoff-algo-00.txt > has been successfully submitted by Bruno Decraene and posted to the > IETF repository. > > Name: draft-decraene-rtgwg-backoff-algo > Revision: 00 > Title: Back-off SPF algorithm for link state IGP > Document date: 2014-07-03 > Group: Individual Submission > Pages: 5 > URL: http://www.ietf.org/internet-drafts/draft-decraene-rtgwg- > backoff-algo-00.txt > Status: https://datatracker.ietf.org/doc/draft-decraene-rtgwg-backoff- > algo/ > Htmlized: http://tools.ietf.org/html/draft-decraene-rtgwg-backoff-algo- > 00 > > > Abstract: > This document defines a standard algorithm to back-off link-state IGP > SPF computations. > > This improves interoperability by reducing the probability and/or > duration of transient forwarding loops during the IGP convergence in > the area/level when the network reacts to multiple consecutive > events. > > > > > > 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 > > > __________________________________________________________ > __________________________________________________________ > _____ > > 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. > > _______________________________________________ > Isis-wg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/isis-wg _________________________________________________________________________________________________________________________ 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
