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

[Warren Kumari <[e-mail]>]

On Wed, May 23, 2018 at 3:19 AM <[e-mail]> wrote:

> Warren, all
>
>
>
> I would personally be fine with adding your proposed one sentence warning
> (possibly in the operational/management consideration section)
>

​Awesome, thanks. Mainly I wanted to make sure it had been considered --
I'll go clear my DISCUSS.


>
>
> That being said, since you asked for a discussion:
>
> 1) +1 to James’ email
>
>
>
> 2) Note that draft-ietf-idr-bgp-gr-notification is making things safer as
> it is _*adding*_ a mandated timer to Graceful Restart (GR). IOW, with
> current BGP GR RFC one may have no way of limiting this duration.
>
>
>
> 3) I may be wrong (please correct), but my reading of the BGP spec is that
> RFC 4271 allows for an infinite Hold Time timer (when set to 0).
>
>
​Yelp! Yeah, this seems to be there from RFC1771, and from RFC1654 before
that. I seem to remember having actually relied on that back in ~1998 to
stop keep alives from making dial-on-demand sessions happen... and now I
feel odl.



> 4) There is no way we’ll all agree on what “max value” should be in
> general. e.g. you picked “10 to 15 minutes” while BGP Graceful Restart
> already allows for a 68 minutes restart time and BGP for a 18 hours Hold
> Time (and the effect of those timers seems “worse” that the stale time
> IMHO). At some point, e.g. 1 hour, this will be handled by a human; so
> “Infinite” mostly means that we don’t want the BGP process to make the
> decision, which is deferred to a human (or any kind of SDN controller in a
> post human world)
>
>
​42!
​
Thanks all,
W


>
>
> Thanks,
>
> Best regards,
>
> --Bruno
>
>
>
> *From:* Idr [mailto:[e-mail]] *On Behalf Of *Warren Kumari
> *Sent:* Tuesday, May 22, 2018 11:38 PM
> *To:* Jeffrey Haas
> *Cc:* idr@ietf. org; The IESG; Robert Raszuk
> *Subject:* Re: [Idr] Warren Kumari's Discuss on
> draft-ietf-idr-bgp-gr-notification-15: (with DISCUSS)
>
>
>
>
>
>
>
> On Tue, May 22, 2018 at 4:12 PM Jeffrey Haas <[e-mail]> wrote:
>
> Robert,
>
>
>
> On May 22, 2018, at 3:35 PM, Robert Raszuk <[e-mail]> wrote:
>
>
>
> ​Hi Jeff,​
>
>
>
> This is a point where I point at your supposed opeational background and
> suggest shame on you. :-)
>
>
>
>
>
> ​I think ​it should be pointed out that there is difference between sound
> operational reasons and simply bad network design.
>
>
>
> If someone would deploy in a network route reflectors (and in fact also
> routers) from multiple vendors (let's be brave and say 3 or 4) probability
> that all implementations would go down on given trigger is highly reduced -
> perhaps to the extend that no outage would occur and no one would propose
> to make BGP state persistent ;-).
>
>
>
> Here my only worry is that we are stretching protocol(s) to cover for
> wrong choices of network architecture.
>
>
>
> Since it seems my attempt at humor was overly broad (I believe Warren is
> likely to have taken it with its original intent), this is more a jab at
> the focus on a knob that is not usually a good idea usually being something
> that ends up in code mostly at the pressure of the operators/customers.
>
>
>
> https://www.youtube.com/watch?v=2HmcrZwb7OA​
>
>
>
>
>
>  We call such features "rope (to hang yourself with)" for good cause.
> Warren is thus pointing out the thing that as a customer he may have asked
> for in the first place. :-)
>
>
>
> ​Yeah, but there is also a difference between "​This is might a bad idea,
> but we need it for this funky reason, so, er, please?" and "Let's put it in
> a Standards Track document, with no warnings. What could go wrong?!" :-P
>
>
>
> Perhaps adding something like:
>
> "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. Note that long (or infinite) retention time may cause
>
> operational issues, and should be enabled with care."
>
> or:
>
> The impact of long retention times should be carefully considered
>
> or:
>
> This option should only be used by consenting adults
>
> :-)
>
>
>
> ​Anyway, the fact that this is in "updating" / "new" text means that we
> need to be careful not to overstep, but I think that having some warning
> would be useful to help minimize people shooting themselves in the foot.
>
>
>
> ​W​
>
>
>
>
>
>
>
> While I generally sympathize with your approach to network heterogeneity
> as a mechanism for achieving better fault tolerance, I also consider it
> optimistic.
>
>
>
> -- Jeff
>
>
>
>
>
>
> --
>
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
>    ---maf
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf