Re: [Idr] Warren Kumari's Discuss on draft-ietf-idr-bgp-gr-notification-15: (with DISCUSS)

Hi Warren,

To understand this proposal a little lecture of document which was proposed
before this one and which in fact triggered this extension can be helpful:

https://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-03

Effectively here authors propose to allow BGP speaker to run in a headless
mode indefinitely. The root of the idea was born when pure control plane
single vendor RRs go down for hours and otherwise healthy PEs running in
healthy network stop serving 1000s of VPN customers.

I think at this stage I will refrain from stating an opinion on it. All I
can say is that operators today can use so many other dangerous knobs in
various address families of BGP that adding this configuration flexibility
to GR stale timer option here will rather not make it much worse :)

Kind regards,
Robert.

On Tue, May 22, 2018 at 8:53 PM, Warren Kumari <warren@kumari.net> wrote:

> Warren Kumari has entered the following ballot position for
> draft-ietf-idr-bgp-gr-notification-15: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-gr-notification/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I'm sure that this has already been discussed somewhere, and that I'll be
> able
> to quickly clear my DISCUSS once pointed at it, but: "To put an upper
> bound on
> the amount of time a router retains the stale routes, an implementation
> MUST
> support a (configurable) timer, called the "stale timer", that imposes this
> upper bound. A suggested default value for the stale timer is 180 seconds.
> An
> implementation MAY provide the option to disable the timer (i.e., to
> provide an
> infinite retention time) but MUST NOT do so by default."
>
> The "infinite retention time" part of this makes me deeply uncomfortable
> -- I
> can see a good reason for the stale timer, and the default "feels" fine to
> me,
> but having an infinite retention time (or, really anything over 10 to 15
> minutes) feels like a really dangerous idea, and that it will come back and
> bite.
>
> I'm hoping that I'm missing something obvious, but can you please explain
> under
> what conditions an infinite retention policy makes sense? It seems like
> there
> would be multiple opportunities for blackholing traffic with this.
>
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>