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

["UTTARO, JAMES" <[e-mail]>]

Warren,

                I responded to this thread below.. If you would like to have a meeting to dive deeper to better understand the use cases I would be glad to meet…

Thanks,
                Jim Uttaro

From: Idr [mailto:[e-mail]] On Behalf Of Warren Kumari
Sent: Tuesday, May 22, 2018 5:38 PM
To: Jeffrey Haas <[e-mail]>
Cc: idr@ietf. org <[e-mail]>; The IESG <[e-mail]>; Robert Raszuk <[e-mail]>
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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3D2HmcrZwb7OA&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=-lls2cLjvnTdMdXcY64sd71JtmNGJmp84ERe2zsbRS0&s=9cIoAZ73JHgcML45sV3kvS2_vc7O1YKdUE2-trA43p0&e=>​


 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