Hi Uma, Thanks for the comment and your support. Pls find inline comments.
-----Original Message----- From: rtgwg [mailto:[email protected]] On Behalf Of Uma Chunduri Sent: Wednesday, July 23, 2014 22:43 To: DECRAENE Bruno IMT/OLN; [email protected] Subject: RE: draft-decraene-rtgwg-backoff-algo-00.txt 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. [SLI] No , unfortunately LFA (nor RSVP-TE link protect for monohop tunnels) would help in this ... As soon as S converges, S would stop using LFA and may fall into a loop to E. 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. [SLI] That was not my point ... we have an agreement that SPF is cheap. But the issue may come from timer management and when to trigger SPF. If implementations are using different strategies, they will be misaligned in term of delay timer values for a particular sequence of event. SPF duration is not involved there ... -- 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 _________________________________________________________________________________________________________________________ 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
