Subject: progressing draft-ietf-rtgwg-backoff-algo

From: Chris Bowers <[email-masked]>
Date: Tue, 1 Mar 2016 23:33:30 +0000

RTGWG,

Jeff and I wanted to get a sense of how the working group would like to proceed regarding draft-ietf-rtgwg-backoff-algo.

The basic question for the working group is:   Should we proceed towards publication of the draft more or less as is, or should we wait to incorporate feedback from one or more implementations of the SPF back-off algorithm?

As far as we know, there haven't been any implementations of the proposed SPF back-off algorithm.  It would be good to get an understanding if any implementations are in progress or planned.

The common SPF back-off algorithm proposed in the document seems quite reasonable.  However, it is also quite possible that a single implementation would uncover some unforeseen issues or suggest improvements for the functioning of the algorithm in a single vendor network.  Testing with two or more implementations may provide feedback to improve the algorithm with respect to the goal of having common SPF delays in a multi-vendor network.  But we won't know until that work is done.

If there are implementations in progress or planned, then we think it would be worth waiting to incorporate feedback from those implementations before publishing.

Instead, if there are no implementations planned, we have several options.  We can proceed towards publication more or less as is, with WG last call in the near future.  Or we can explicitly decide to wait to publish the document, leaving it either as an active WG document or as a parked WG document, and wait for one or more implementations.  With the last option, we could leave open the option of publishing at some point in the future, even if no implementations appear.

Personally, I am quite hopeful that there will be at least prototype implementations in the not too distant future.  While it is very unlikely that a vendor would change their default SPF back-off algorithm to this new algorithm, it can easily be implemented with a knob to activate this algorithm.   This gives a simple way to try out the new algorithm incrementally, lowering the bar significantly for at least a prototype implementation.

We look forward to hearing feedback from the WG on how to proceed with the draft.

Thanks,
Chris

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 3 Mar 2016 16:30:47 +0000

Hi Chris, Esteemed Routing WG Members,

From: rtgwg <[email-masked]<mailto:[email-masked]>> on behalf of Chris Bowers <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 1, 2016 at 6:33 PM
To: Routing WG <[email-masked]<mailto:[email-masked]>>
Subject: progressing draft-ietf-rtgwg-backoff-algo

RTGWG,

Speaking as both a draft author and IGP implementor, a knob with full backward compatibility is exactly the way we envisioned the draft being implemented and carefully deployed. Perhaps, the best way forward is to progress the document as an experimental RFC so there is a stable base for operators to reference for RFPs  and vendors to implement. While many experimental protocols have died a quiet natural death after publication, a few have been deployed and republished as standards track documents (e.g., RFC 5613). I think this is preferable to waiting for years for experimentation and interoperable implementations.

Thanks,
Acee

Thanks,
Chris

---

From: <[email-masked]>
Date: Thu, 3 Mar 2016 17:16:59 +0000

Hi Chairs,

Can we move forward at least the associated problem statement draft ?

Best Regards,

Stephane

From: rtgwg [mailto:[email-masked]] On Behalf Of Chris Bowers
Sent: Wednesday, March 02, 2016 00:34
To: [email-masked]
Subject: progressing draft-ietf-rtgwg-backoff-algo

RTGWG,

Thanks,
Chris

_________________________________________________________________________________________________________________________

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: Chris Bowers <[email-masked]>
Date: Thu, 3 Mar 2016 18:39:14 +0000

Yes.  I should have explicitly mentioned draft-ietf-rtgwg-spf-uloop-pb-statement.  I think that document should progress fairly soon to WCLC regardless of how we decide to progress draft-ietf-rtgwg-backoff-algo.

Chris

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 03, 2016 9:17 AM
To: Chris Bowers <[email-masked]>; [email-masked]
Subject: RE: progressing draft-ietf-rtgwg-backoff-algo

Hi Chairs,

Best Regards,

Stephane

From: rtgwg [mailto:[email-masked]] On Behalf Of Chris Bowers
Sent: Wednesday, March 02, 2016 00:34
To: [email-masked]<mailto:[email-masked]>
Subject: progressing draft-ietf-rtgwg-backoff-algo

RTGWG,

Thanks,
Chris

Thank you.

---

From: <[email-masked]>
Date: Mon, 7 Mar 2016 10:03:48 +0000

Hi Chris, all

That's a good and reasonable question.

Please find below my personal feedback.

I think we can identify 3 parts in the draft:

a)      A SPF delay

b)      A uniform SPF delay within an AS/area

c)       A specific math formula to determine the delay

a)      A SPF delay
Adding a SPF delay, dependent on the IGP stability, is already in all implementations I'm aware off, massively deployed (by default), with many years of experience (>15).
This is more than enough for a standard track document. As a matter of fact, this would probably even qualify for the Internet Standard maturity level.

b)      A uniform SPF delay within an AS/area
IMHO, draft-ietf-rtgwg-spf-uloop-pb-statement<http://tools.ietf.org/wg/rtgwg/draft-ietf-rtgwg-spf-uloop-pb-statement/> and draft-ietf-rtgwg-backoff-algo<http://tools.ietf.org/wg/rtgwg/draft-ietf-rtgwg-backoff-algo/> have made the case that the use of a uniform SPF delay strategy within an AS/area is beneficial from a micro-loop point of view.
(Even if this were not the case, this is not something that 2 existing implementation would improve)

c)       A specific math formula to determine the delay
That part is a new specification.
IMHO, the proposed change is limited. Roughly the math formula determining the delay (e.g. On Quagga ht = ospf6->spf_holdtime * ospf6->spf_hold_multiplier; ) , although there is additional code to define when to restart to initial value and when to bound the delay. You are welcomed to check in your own code.
I would expect that this is a small enough change to have it specified correctly, especially after a WG & IESG review.

In summary, I think this draft should be published as a STD track document because
- this draft propose a reasonably small change to a behavior which is widely implemented with very large deployment experience, this draft builds on this large experience.
- I agree that having N implementations would be safer, but it would also be more process and more time. I don't feel that this should stop this document from being published as a STD track RFC. And if we have time, I would personally be more interested in having simulation results on extensive real data from multiple ASes, rather than having prototype implementations.
- in the worst case, if the draft is not clear enough to have all implementation behave exactly the same way, this is not going to be worth than today with very different SPF delay algo. So IMO, publishing it even without implementation, is better than not publishing it, or publishing it as experimental.

Lastly, speaking for myself, if the requirement for 2 implementations gets to a blocking point, we have the option to have this draft document an already implemented and deployed SPF algo; presumably the most deployed one (read the Cisco one). IMHO, this would not be a success for the IETF to prefer a "closed" algo compared to an openly discussed one, but that would fulfil my priority 1 which is to have a way to have a uniform SPF delay across all routers of an AS/area, so I could live with that.

Thanks,
Regards,
Bruno

From: rtgwg [mailto:[email-masked]] On Behalf Of Chris Bowers
Sent: Wednesday, March 02, 2016 12:34 AM
To: [email-masked]
Subject: progressing draft-ietf-rtgwg-backoff-algo

RTGWG,

Thanks,
Chris

---

From: <[email-masked]>
Date: Mon, 7 Mar 2016 10:10:10 +0000

> this is not going to be worth than today with very different SPF delay algo.

:s/ worth/worse.

Sorry for the spam
(I'd like to blame the spell checker L )

From: rtgwg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 07, 2016 11:04 AM
To: Chris Bowers; [email-masked]
Subject: RE: progressing draft-ietf-rtgwg-backoff-algo

Hi Chris, all

a)      A SPF delay

a)      A SPF delay

Thanks,
Regards,
Bruno

RTGWG,

Thanks,
Chris

Thank you.