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

[<[e-mail]>]

Sue,

Please see two comments inline [Bruno]

From: Susan Hares [mailto:[e-mail]]
Sent: Thursday, May 24, 2018 3:08 AM
To: DECRAENE Bruno IMT/OLN; 'Warren Kumari'
Cc: 'idr@ietf. org'; 'UTTARO, JAMES'; 'The IESG'; 'Robert Raszuk'
Subject: RE: [Idr] Warren Kumari's Discuss on draft-ietf-idr-bgp-gr-notification-15: (with DISCUSS)

Bruno and Warren:

Warren has approved so this message is just a follow-up on the message stream.

As to specifying “0” in Hold Time Timer for RFC4271, the operative text is the following:

   If the negotiated Hold Time interval is zero, then periodic KEEPALIVE
   messages MUST NOT be sent.  (section 4.4)

[Bruno] And also:
      If the negotiated hold time value is zero, then the HoldTimer and
      KeepaliveTimer are not started.
https://tools.ietf.org/html/rfc4271#section-8.2.2  (FSM)


This RFC4271 addition (based on deployments)  provided a less “chatty” BGP with Keepalives
for connection that did not have the need for the “KEEPALIVE” heartbeat.

Whether this is an infinite timer or something else is a discussion which is academic.

[Bruno] Well, the comment was partly about having an infinite timer for BGP in a STD track document.

Regards,
--Bruno

The important part is the needs of the operators.

RFC1267 to RFC4271 changed this because the operators needed the less “chatty” KEEPALIVE BGP.   IMHO GR notification improves the situation from RFC4271.

Sue

PS - As far as I can tell the state machines for these actions still hang together with all the changes.  However, I’d love to hear from anyone if there is a problem.



From: Idr [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Wednesday, May 23, 2018 3:19 AM
To: Warren Kumari
Cc: idr@ietf. org; UTTARO, JAMES; The IESG; Robert Raszuk
Subject: Re: [Idr] Warren Kumari's Discuss on draft-ietf-idr-bgp-gr-notification-15: (with DISCUSS)

Warren, all

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

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

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)

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

_________________________________________________________________________________________________________________________

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.