Subject: draft-decraene-rtgwg-backoff-algo-00.txt

From: <[email-masked]>
Date: Thu, 3 Jul 2014 10:27:13 +0000

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-masked] [mailto:[email-masked]] 
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.

---

From: <[email-masked]>
Date: Wed, 23 Jul 2014 20:24:58 +0000

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-masked]] On Behalf Of
> 
> Hi all,
> 
> 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
> 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.
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 24 Jul 2014 02:42:56 +0000

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-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 23, 2014 4:25 PM
To: [email-masked]
Subject: RE: draft-decraene-rtgwg-backoff-algo-00.txt

Hi all,

Thanks,
Regards,
Bruno, Stéphane

> 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
> 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
> 
> 
> 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.

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-masked]
https://www.ietf.org/mailman/listinfo/rtgwg

---

From: <[email-masked]>
Date: Thu, 24 Jul 2014 16:56:45 +0000

Hi Uma,

Thanks for the comment and your support.
Pls find inline comments.

-----Original Message-----
From: rtgwg [mailto:[email-masked]] On Behalf Of Uma Chunduri
Sent: Wednesday, July 23, 2014 22:43
To: DECRAENE Bruno IMT/OLN; [email-masked]
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

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.

[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-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 23, 2014 4:25 PM
To: [email-masked]
Subject: RE: draft-decraene-rtgwg-backoff-algo-00.txt

Hi all,

Thanks,
Regards,
Bruno, Stéphane

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 24 Jul 2014 18:01:02 +0000

Hi Stephane,

>[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.

Then I am afraid even with same trigger logic and timers across all vendors,  you may  still see the micro loops. 
Various  mitigation techniques for that issue is listed elaborately here -
http://tools.ietf.org/html/rfc5715#section-6

--
Uma C.