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.

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:rtgwg-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Wednesday, July 23, 2014 4:25 PM
To: rtgwg@ietf.org
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:isis-wg-bounces@ietf.org] 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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> 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
> Isis-wg@ietf.org
> 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
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg