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

[<[e-mail]>]

Warren,

Thanks for your reply.
1 clarification inline [Bruno]

From: Warren Kumari [mailto:[e-mail]]

On Wed, May 23, 2018 at 3:19 AM <[e-mail]<mailto:[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.
[Bruno] To clarify, I was speaking as IDR WG member but I’m not one of the authors. So I was not speaking for the authors.
--Bruno

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]<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]<mailto:[e-mail]>> wrote:
Robert,

On May 22, 2018, at 3:35 PM, Robert Raszuk <[e-mail]<mailto:[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

_________________________________________________________________________________________________________________________

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.