Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Sebastian Wiesinger]

* Phil Shafer  [2014-02-26 16:42]:
> Juniper users,
> 
> We've been asked to make a change the "clear bgp neighbor" command
> to make the neighbor or "all" argument mandatory.  The root cause
> is the severe impact of "clear bgp neighbor" and the increasing
> accidental use of this command without a specific neighbor.

Yes, +1 to the mandatory "all" argument.

Regards

Sebastian

-- 
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Graham Brown]

Another vote for the 'all' function for all 'clear' commands. BGP, IS-IS etc


On 27 February 2014 04:36, Phil Shafer  wrote:

> Juniper users,
>
> We've been asked to make a change the "clear bgp neighbor" command
> to make the neighbor or "all" argument mandatory.  The root cause
> is the severe impact of "clear bgp neighbor" and the increasing
> accidental use of this command without a specific neighbor.
>
> In general, we avoid changing commands to add mandatory arguments,
> but my feeling is that the impact and severity of this specific
> command makes this an acceptable occasion for such a change.
>
> I'm looking for feedback about this change.  My working assumption
> is that "clear bgp neighbor" is a sufficiently rare command and
> would not be used in automation/scripts, so the impact of making
> the neighbor/all argument mandatory would be minimal.  Is this
> assumption accurate?
>
> Thanks,
>  Phil
>
> [I've set reply-to to myself to avoid impacting the list]
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Graham Brown
Twitter - @mountainrescuer 
LinkedIn 
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Morgan McLean]

Anybody chalking this up to cli inexperience, is inexperienced lol.
Everybody makes mistakes.

Supported by me.

Morgan


On Fri, Feb 28, 2014 at 1:20 PM, Alex D.  wrote:

> +1
>
> I fully support this change.
>
> Regards,
> Alex
>
> Am 26.02.2014 16:36, schrieb Phil Shafer:
>
>  Juniper users,
>>
>> We've been asked to make a change the "clear bgp neighbor" command
>> to make the neighbor or "all" argument mandatory.  The root cause
>> is the severe impact of "clear bgp neighbor" and the increasing
>> accidental use of this command without a specific neighbor.
>>
>> In general, we avoid changing commands to add mandatory arguments,
>> but my feeling is that the impact and severity of this specific
>> command makes this an acceptable occasion for such a change.
>>
>> I'm looking for feedback about this change.  My working assumption
>> is that "clear bgp neighbor" is a sufficiently rare command and
>> would not be used in automation/scripts, so the impact of making
>> the neighbor/all argument mandatory would be minimal.  Is this
>> assumption accurate?
>>
>> Thanks,
>>   Phil
>>
>> [I've set reply-to to myself to avoid impacting the list]
>>
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Thanks,
Morgan
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Alex D.]

+1
I fully support this change.

Regards,
Alex

Am 26.02.2014 16:36, schrieb Phil Shafer:

Juniper users,

We've been asked to make a change the "clear bgp neighbor" command
to make the neighbor or "all" argument mandatory.  The root cause
is the severe impact of "clear bgp neighbor" and the increasing
accidental use of this command without a specific neighbor.

In general, we avoid changing commands to add mandatory arguments,
but my feeling is that the impact and severity of this specific
command makes this an acceptable occasion for such a change.

I'm looking for feedback about this change.  My working assumption
is that "clear bgp neighbor" is a sufficiently rare command and
would not be used in automation/scripts, so the impact of making
the neighbor/all argument mandatory would be minimal.  Is this
assumption accurate?

Thanks,
  Phil

[I've set reply-to to myself to avoid impacting the list]

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp



___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Michael Hallgren]

Le 27/02/2014 18:58, Eric Van Tol a écrit :
> ast.

:-)

mh

>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Jerry Dent]

You'd only get the confirmation if you didn't type the word 'all'. I don't
get this superiority complex. Most gear has a message like this when you
reboot it. Haven't seen anyone complain about that.


On Thu, Feb 27, 2014 at 11:58 AM, Eric Van Tol  wrote:

> > > *THWACK* THIS IS NOT WINDOWS.
> >
> > Maybe that was a bit harsh, but still, there's very few things more
> > annoying than a CLI (well, any UI) that groans and moans and nannys
> > when you're trying to get work done, stealing your context or focus to
> > "warn" you about something "dangerous."  Adding "all" as a requirement
> > is so much more elegant, easier on the CLI developer too, keeps an
> > accidental/bumped enter from bombing all BGP sessions just as clearly
> > as a prompt that is almost certainly going to not be fully read anyway
> > by a lot of admins.
> >
> >
> > I'd also add support that there are many other commands in clear that
> > might like this treatment (as mentioned by some others in the thread)
>
> Pffft...CLEARLY, you are all n00bs who deserve what you get for making
> mistakes and typing too fast.  I've never once accidentally typo'd
> something, and say, sent an email too f
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Eric Van Tol]

ast.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Eric Van Tol]

> > *THWACK* THIS IS NOT WINDOWS.
> 
> Maybe that was a bit harsh, but still, there's very few things more
> annoying than a CLI (well, any UI) that groans and moans and nannys
> when you're trying to get work done, stealing your context or focus to
> "warn" you about something "dangerous."  Adding "all" as a requirement
> is so much more elegant, easier on the CLI developer too, keeps an
> accidental/bumped enter from bombing all BGP sessions just as clearly
> as a prompt that is almost certainly going to not be fully read anyway
> by a lot of admins.
> 
> 
> I'd also add support that there are many other commands in clear that
> might like this treatment (as mentioned by some others in the thread)

Pffft...CLEARLY, you are all n00bs who deserve what you get for making mistakes 
and typing too fast.  I've never once accidentally typo'd something, and say, 
sent an email too f

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Michael Loftis]

On Thu, Feb 27, 2014 at 8:39 AM, Michael Loftis  wrote:
> On Wed, Feb 26, 2014 at 11:29 AM, Jerry Dent  wrote:
>> Just add a line "Reset all bgp sessions? [Y/N]" for confirmation.
>
> *THWACK* THIS IS NOT WINDOWS.

Maybe that was a bit harsh, but still, there's very few things more
annoying than a CLI (well, any UI) that groans and moans and nannys
when you're trying to get work done, stealing your context or focus to
"warn" you about something "dangerous."  Adding "all" as a requirement
is so much more elegant, easier on the CLI developer too, keeps an
accidental/bumped enter from bombing all BGP sessions just as clearly
as a prompt that is almost certainly going to not be fully read anyway
by a lot of admins.


I'd also add support that there are many other commands in clear that
might like this treatment (as mentioned by some others in the thread)


-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Richard A Steenbergen]

On Wed, Feb 26, 2014 at 10:36:39AM -0500, Phil Shafer wrote:
> Juniper users,
> 
> We've been asked to make a change the "clear bgp neighbor" command
> to make the neighbor or "all" argument mandatory.  The root cause
> is the severe impact of "clear bgp neighbor" and the increasing
> accidental use of this command without a specific neighbor.
> 
> In general, we avoid changing commands to add mandatory arguments,
> but my feeling is that the impact and severity of this specific
> command makes this an acceptable occasion for such a change.
> 
> I'm looking for feedback about this change.  My working assumption
> is that "clear bgp neighbor" is a sufficiently rare command and
> would not be used in automation/scripts, so the impact of making
> the neighbor/all argument mandatory would be minimal.  Is this
> assumption accurate?

Personally I'd support this, either through requiring an "all", or 
adding a yes/no confirmation after executing the command (which sounds 
like it would solve the problem for those silly humans, without 
impacting the scripting interfaces as badly). This is a sufficiently 
rare command in a "good" way that you should really have some form of 
additional error check, just like "delete" from the top level of the 
config.

-- 
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Michael Loftis]

On Wed, Feb 26, 2014 at 11:29 AM, Jerry Dent  wrote:
> Just add a line "Reset all bgp sessions? [Y/N]" for confirmation.

*THWACK* THIS IS NOT WINDOWS.




-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Chuck Anderson]

On Fri, Feb 28, 2014 at 01:17:38AM +1100, Julien Goodwin wrote:
> On 28/02/14 00:48, Phil Shafer wrote:
> > Sorry if I'm venturing toward shameless self promotion here, but
> > this really is an area we try to work at.  That's part of the
> > movation for asking if this one specific case is sufficiently
> > irritating to break our own rules.
> 
> But it's not "one specific case"
> 
> clear  
> 
> Is a horrible outage-causing command for a bunch of things.
> 
> Unless it's been similarly fixed "clear rsvp session" is a great way to
> cause an outage[1] on many carrier networks.
> 
> What about "clear isis adjacency"?
> 
> I'd say review the lot of clear  and fix them all.
> 
> It's *extremely* rare to actually want to reset all sessions on a real
> production router passing traffic in my experience, in all my time I can
> only think of one case where we deliberately used it.
> 
> Any automation relying on this I suspect has far worse problems.
> 
> 1: OK, *I'd* call this an outage, but "short term packet loss event" for
> those with lower standards.
> 

I agree...rather than just fixing this one thing "clear bgp neighbor",
fix them all to require the "all" option.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Julien Goodwin]

On 28/02/14 00:48, Phil Shafer wrote:
> Sorry if I'm venturing toward shameless self promotion here, but
> this really is an area we try to work at.  That's part of the
> movation for asking if this one specific case is sufficiently
> irritating to break our own rules.

But it's not "one specific case"

clear  

Is a horrible outage-causing command for a bunch of things.

Unless it's been similarly fixed "clear rsvp session" is a great way to
cause an outage[1] on many carrier networks.

What about "clear isis adjacency"?

I'd say review the lot of clear  and fix them all.

It's *extremely* rare to actually want to reset all sessions on a real
production router passing traffic in my experience, in all my time I can
only think of one case where we deliberately used it.

Any automation relying on this I suspect has far worse problems.

1: OK, *I'd* call this an outage, but "short term packet loss event" for
those with lower standards.



signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Phil Shafer]

Saku Ytti writes:
>But I'm generally against downward-compatibility, it hurts innovation and
>creates codebase complexity creep (i.e. bugs). I'm all for regularly exploding
>everything.
>In JunOS case, between major version, you could state that all bets are off
>with backward compatibility and fix crimes of those who became before us(tm).
>But I understand my opinion is not popular one and would not pass marketing.

Our original strategy was to help customers to move to the most
modern software release, mainly as a means of reducing support
costs [1].  So anything that would impact someone moving to modern
software is bad, including retooling and debugging applications and
automations that used to work perfectly [2].  We want to enable
customers to build these tools, with the assumption that automation
reduces customer OPEX and allows deployment of the high-touch
services where JUNOS can really shine.

This is also the motivation behind the XML APIs (e.g. NETCONF) which
allow you to move from regex-based screen scraping of CLI data to
being able to make elegant XPath experssions [3].  The goal is more
robust, stable, and supportable automations, both on box (with the
op/event/commit scripting facilities) and off box (with any NETCONF
client.

Sorry if I'm venturing toward shameless self promotion here, but
this really is an area we try to work at.  That's part of the
movation for asking if this one specific case is sufficiently
irritating to break our own rules.

Thanks,
 Phil

[1] It also enhances feature deployment; there's nothing worse that
bragging about a new feature like the "refresh" pipe or the "protect"
command to customers that don't have plans for near-term upgrades.

[2] Okay, debugging a script that *used* to work is definitely
worse.  As is trying to look at a regex and sleuth out what the
original author was trying to extract.  Or finding out the regex
broke because the new release added new information to the CLI
output.  In fact, there's a lot of things worse.

[3] Obligatory simple example (in SLAX):

for $ifname ($config/protocols/ospf/interface/name) {
if (not($config/protocols/ldp/interface[name == $ifname])) {
call error($message = "missing LDP config for " _ $ifname);
}
}

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[simon teh]

+1, fully support to hv this feature in JunOS. It is not a matter of rookie
or non rookie problem, but is to keep the network stable n running well.
On 26 Feb 2014 23:41, "Phil Shafer"  wrote:

> Juniper users,
>
> We've been asked to make a change the "clear bgp neighbor" command
> to make the neighbor or "all" argument mandatory.  The root cause
> is the severe impact of "clear bgp neighbor" and the increasing
> accidental use of this command without a specific neighbor.
>
> In general, we avoid changing commands to add mandatory arguments,
> but my feeling is that the impact and severity of this specific
> command makes this an acceptable occasion for such a change.
>
> I'm looking for feedback about this change.  My working assumption
> is that "clear bgp neighbor" is a sufficiently rare command and
> would not be used in automation/scripts, so the impact of making
> the neighbor/all argument mandatory would be minimal.  Is this
> assumption accurate?
>
> Thanks,
>  Phil
>
> [I've set reply-to to myself to avoid impacting the list]
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Tammy Firefly]

+1 on the change
 
Tammy
AS36811

Sent from my iPhone

> On Feb 27, 2014, at 1:23, Michael Hallgren  wrote:
> 
> Le 26/02/2014 22:10, sth...@nethelp.no a écrit :
>>> We've been asked to make a change the "clear bgp neighbor" command
>>> to make the neighbor or "all" argument mandatory.  The root cause
>>> is the severe impact of "clear bgp neighbor" and the increasing
>>> accidental use of this command without a specific neighbor.
>>> 
>>> In general, we avoid changing commands to add mandatory arguments,
>>> but my feeling is that the impact and severity of this specific
>>> command makes this an acceptable occasion for such a change.
>>> 
>>> I'm looking for feedback about this change.  My working assumption
>>> is that "clear bgp neighbor" is a sufficiently rare command and
>>> would not be used in automation/scripts, so the impact of making
>>> the neighbor/all argument mandatory would be minimal.  Is this
>>> assumption accurate?
>> For us, yes. Fully support the idea of requiring an "all" argument.
> 
> +1
> 
> mh
> 
>> Steinar Haug, AS 2116
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 
> --
> 
> This email has been scanned for spam and viruses by Proofpoint Essentials 
> cloud email security - visit the following URL to report this email as spam:
> https://us1.proofpointessentials.com/index01.php?mod_id&mod_option=logitem&mid=6372874&rid=1312411&report=1

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Michael Hallgren]

Le 26/02/2014 22:10, sth...@nethelp.no a écrit :
>> We've been asked to make a change the "clear bgp neighbor" command
>> to make the neighbor or "all" argument mandatory.  The root cause
>> is the severe impact of "clear bgp neighbor" and the increasing
>> accidental use of this command without a specific neighbor.
>>
>> In general, we avoid changing commands to add mandatory arguments,
>> but my feeling is that the impact and severity of this specific
>> command makes this an acceptable occasion for such a change.
>>
>> I'm looking for feedback about this change.  My working assumption
>> is that "clear bgp neighbor" is a sufficiently rare command and
>> would not be used in automation/scripts, so the impact of making
>> the neighbor/all argument mandatory would be minimal.  Is this
>> assumption accurate?
> For us, yes. Fully support the idea of requiring an "all" argument.

+1

mh

> Steinar Haug, AS 2116
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Saku Ytti]

On (2014-02-26 10:36 -0500), Phil Shafer wrote:

> I'm looking for feedback about this change.  My working assumption
> is that "clear bgp neighbor" is a sufficiently rare command and
> would not be used in automation/scripts, so the impact of making
> the neighbor/all argument mandatory would be minimal.  Is this
> assumption accurate?

Support.

I can't fathom which automated system would rely on this working and would not
be possible to change in 5min.

But I'm generally against downward-compatibility, it hurts innovation and
creates codebase complexity creep (i.e. bugs). I'm all for regularly exploding
everything.
In JunOS case, between major version, you could state that all bets are off
with backward compatibility and fix crimes of those who became before us(tm).
But I understand my opinion is not popular one and would not pass marketing.








Rant follows, stop reading now.








As obligatory counter-point (not trying to pick on anyone, just finding first
example that came into my mind) CSCO's EVC is tragic example of breaking stuff
for sake of breaking stuff.
EVC is new logical interface configuration, which completely breaks standard
SNMP MIB support and every tooling which relied on logical interfaces looking
certain way. And there is 0 benefit, everything you configure in EVC, you
could configure in regular logical interface.
Only possible reason I can think of, was parser simplicity, now parser easily
knows what part of hardware needs to be programmed without parsing contents of
the logical interface.
I would have been even OK with all old logical interfaces going away and all
features moved to EVC (don't see the point, but even that would have been
better)

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Massimo Ravizza]

For me is ok too.

Massimo


2014-02-27 8:07 GMT+01:00 Mark Tinka :

> On Wednesday, February 26, 2014 09:24:21 PM Eric Van Tol
> wrote:
>
> > I don't see a problem with adding the requirement 'all'.
>
> I support this as well.
>
> Mark.
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Mark Tinka]

On Wednesday, February 26, 2014 09:25:00 PM ryanL wrote:

> yeah, i'm not slagging. just seems like poor training for
> newbie noc engineers or something. this is a pretty
> rookie error, in my view, but i've been around almost as
> long as you have ;-)

I suppose the idea is to keep the network running, not show 
how much of a rookie you are not :-).

Mark.


signature.asc
Description: This is a digitally signed message part.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Mark Tinka]

On Wednesday, February 26, 2014 09:24:21 PM Eric Van Tol 
wrote:

> I don't see a problem with adding the requirement 'all'.

I support this as well.

Mark.


signature.asc
Description: This is a digitally signed message part.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Craig Askings]

+1 to the idea of making all / neighbor ip mandatory.


On 27 February 2014 01:36, Phil Shafer  wrote:

> Juniper users,
>
> We've been asked to make a change the "clear bgp neighbor" command
> to make the neighbor or "all" argument mandatory.  The root cause
> is the severe impact of "clear bgp neighbor" and the increasing
> accidental use of this command without a specific neighbor.
>
> In general, we avoid changing commands to add mandatory arguments,
> but my feeling is that the impact and severity of this specific
> command makes this an acceptable occasion for such a change.
>
> I'm looking for feedback about this change.  My working assumption
> is that "clear bgp neighbor" is a sufficiently rare command and
> would not be used in automation/scripts, so the impact of making
> the neighbor/all argument mandatory would be minimal.  Is this
> assumption accurate?
>
> Thanks,
>  Phil
>
> [I've set reply-to to myself to avoid impacting the list]
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 

Regards,

Craig Askings

io Networks Pty Ltd.



mobile: 0404 019365

phone: 1300 1 2 4 8 16
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Brandon Ross]

On Thu, 27 Feb 2014, heasley wrote:


Thu, Feb 27, 2014 at 10:30:29AM +0900, Paul S.:

+1 to the 'all' requirement -- and then further include another question
as suggested like 'Reset all BGP sessions? [Y/N]'


Please - if you're dumb enough to enter a command that you do not understand
on a production device, you deserve what you get.  Stupid should be painful.


Clearly someone should take away my router configuration license since I 
accidentally hit the wrong key on occasion.


--
Brandon Ross  Yahoo & AIM:  BrandonNRoss
+1-404-635-6667ICQ:  2269442
 Skype:  brandonross
Schedule a meeting:  http://www.doodle.com/bross
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Paul S.]

On 2/27/2014 午前 10:38, heasley wrote:

Thu, Feb 27, 2014 at 10:30:29AM +0900, Paul S.:

+1 to the 'all' requirement -- and then further include another question
as suggested like 'Reset all BGP sessions? [Y/N]'

Please - if you're dumb enough to enter a command that you do not understand
on a production device, you deserve what you get.  Stupid should be painful.


Well, if stupidity is meant to be painful -- I don't even see why 
Juniper is even considering fixing this as the only people who'd even 
enter it at its current state are people who likely don't know what 
they're doing.


A little safeguarding never hurt anyone ;)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[heasley]

Thu, Feb 27, 2014 at 10:30:29AM +0900, Paul S.:
> +1 to the 'all' requirement -- and then further include another question 
> as suggested like 'Reset all BGP sessions? [Y/N]'

Please - if you're dumb enough to enter a command that you do not understand
on a production device, you deserve what you get.  Stupid should be painful.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Paul S.]

+1 to the 'all' requirement -- and then further include another question 
as suggested like 'Reset all BGP sessions? [Y/N]'


That, in my opinion, is the most sane way to go about it.

On 2/27/2014 ?? 05:37, Jonas Frey (Probe Networks) wrote:

+1 for the "all" requirement

Am Mittwoch, den 26.02.2014, 10:36 -0500 schrieb Phil Shafer:

Juniper users,

We've been asked to make a change the "clear bgp neighbor" command
to make the neighbor or "all" argument mandatory.  The root cause
is the severe impact of "clear bgp neighbor" and the increasing
accidental use of this command without a specific neighbor.

In general, we avoid changing commands to add mandatory arguments,
but my feeling is that the impact and severity of this specific
command makes this an acceptable occasion for such a change.

I'm looking for feedback about this change.  My working assumption
is that "clear bgp neighbor" is a sufficiently rare command and
would not be used in automation/scripts, so the impact of making
the neighbor/all argument mandatory would be minimal.  Is this
assumption accurate?

Thanks,
  Phil

[I've set reply-to to myself to avoid impacting the list]

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Haynes, Matthew]

I don't chime in much on the threads but in this case I'm with you, fat fingers 
can kill and the idiot do u really want to do this Y/N isn't a bad idea either. 
You do this long enough you guys that haven't had an oops moment eventually 
will.

Sent from my iPhone

> On Feb 26, 2014, at 4:29 PM, "Brandon Ross"  wrote:
> 
>> On Wed, 26 Feb 2014, ryanL wrote:
>> 
>> yeah, i'm not slagging. just seems like poor training for newbie noc
>> engineers or something. this is a pretty rookie error, in my view, but i've
>> been around almost as long as you have ;-)
> 
> I've been doing BGP work for nearly 20 years, and Juniper for more than 15, 
> including for many major and minor service providers, Interop and NANOG 
> itself, and somehow I still make mistakes, hit the wrong key, log into the 
> wrong window, etc.
> 
> I fully support this change.
> 
> -- 
> Brandon Ross  Yahoo & AIM:  BrandonNRoss
> +1-404-635-6667ICQ:  2269442
> Skype:  brandonross
> Schedule a meeting:  http://www.doodle.com/bross
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Joerg Staedele]

Hi there,

yes, please make "all" mandatory. We had copy/paste in the past where there was 
a CRLF before the IP of a neighbor and that killed all neighbors.

Regards,
 Joerg

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von 
Phil Shafer
Gesendet: Mittwoch, 26. Februar 2014 16:37
An: Juniper for Network Service Providers
Betreff: [j-nsp] proposed changes to "clear bgp neighbor"

Juniper users,

We've been asked to make a change the "clear bgp neighbor" command to make the 
neighbor or "all" argument mandatory.  The root cause is the severe impact of 
"clear bgp neighbor" and the increasing accidental use of this command without 
a specific neighbor.

In general, we avoid changing commands to add mandatory arguments, but my 
feeling is that the impact and severity of this specific command makes this an 
acceptable occasion for such a change.

I'm looking for feedback about this change.  My working assumption is that 
"clear bgp neighbor" is a sufficiently rare command and would not be used in 
automation/scripts, so the impact of making the neighbor/all argument mandatory 
would be minimal.  Is this assumption accurate?

Thanks,
 Phil

[I've set reply-to to myself to avoid impacting the list]

___
juniper-nsp mailing list juniper-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[ryanL]

that sounds exactly like CLI inexperience to me. in any case, i did state
that it would be a nice to have.


On Wed, Feb 26, 2014 at 2:24 PM, Eric Van Tol  wrote:

> > it's a nice-to-have, maybe? but this sounds more like an opportunity for
> > you to sell some JNCIA courses. i mean, how long has junos been around
> > now?
>
> Confusing comment, since this enhancement isn't about CLI inexperience.
>  It doesn't matter how long Junos has been around or how experienced
> someone is, it's still too incredibly easy to hit 'Enter' too soon and
> clear all your BGP neighbors by accident.
>
> I don't see a problem with adding the requirement 'all'.
>
> -evt
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Brandon Ross]

On Wed, 26 Feb 2014, ryanL wrote:


yeah, i'm not slagging. just seems like poor training for newbie noc
engineers or something. this is a pretty rookie error, in my view, but i've
been around almost as long as you have ;-)


I've been doing BGP work for nearly 20 years, and Juniper for more than 
15, including for many major and minor service providers, Interop and 
NANOG itself, and somehow I still make mistakes, hit the wrong key, log 
into the wrong window, etc.


I fully support this change.

--
Brandon Ross  Yahoo & AIM:  BrandonNRoss
+1-404-635-6667ICQ:  2269442
 Skype:  brandonross
Schedule a meeting:  http://www.doodle.com/bross
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[sthaug]

> We've been asked to make a change the "clear bgp neighbor" command
> to make the neighbor or "all" argument mandatory.  The root cause
> is the severe impact of "clear bgp neighbor" and the increasing
> accidental use of this command without a specific neighbor.
> 
> In general, we avoid changing commands to add mandatory arguments,
> but my feeling is that the impact and severity of this specific
> command makes this an acceptable occasion for such a change.
> 
> I'm looking for feedback about this change.  My working assumption
> is that "clear bgp neighbor" is a sufficiently rare command and
> would not be used in automation/scripts, so the impact of making
> the neighbor/all argument mandatory would be minimal.  Is this
> assumption accurate?

For us, yes. Fully support the idea of requiring an "all" argument.

Steinar Haug, AS 2116
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Jonas Frey (Probe Networks)]

+1 for the "all" requirement

Am Mittwoch, den 26.02.2014, 10:36 -0500 schrieb Phil Shafer:
> Juniper users,
> 
> We've been asked to make a change the "clear bgp neighbor" command
> to make the neighbor or "all" argument mandatory.  The root cause
> is the severe impact of "clear bgp neighbor" and the increasing
> accidental use of this command without a specific neighbor.
> 
> In general, we avoid changing commands to add mandatory arguments,
> but my feeling is that the impact and severity of this specific
> command makes this an acceptable occasion for such a change.
> 
> I'm looking for feedback about this change.  My working assumption
> is that "clear bgp neighbor" is a sufficiently rare command and
> would not be used in automation/scripts, so the impact of making
> the neighbor/all argument mandatory would be minimal.  Is this
> assumption accurate?
> 
> Thanks,
>  Phil
> 
> [I've set reply-to to myself to avoid impacting the list]
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


signature.asc
Description: This is a digitally signed message part
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[ryanL]

yeah, i'm not slagging. just seems like poor training for newbie noc
engineers or something. this is a pretty rookie error, in my view, but i've
been around almost as long as you have ;-)


On Wed, Feb 26, 2014 at 1:44 PM, Phil Shafer  wrote:

> ryanL writes:
> >it's a nice-to-have, maybe? but this sounds more like an opportunity for
> >you to sell some JNCIA courses. i mean, how long has junos been around
> now?
>
> Not selling anything; just trying to solve a problem multiple
> customers have reported and escalated.  I'm a software developer,
> working on the UI code (CLI, MGD, configuration, XML API, scripting)
> for 17+ years.
>
> JUNOS 3.0 (the first release with the ui code) shipped during the
> summer of 1998, IIRC.
>
> Thanks,
>  Phil
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Fernando Garcia Fernandez]

+1 to include the “all” option.

In fact, coming from the IOS world, it amused me when I discovered that there 
was no “*” or “all” option to clear all neighbors.


El 26/02/2014, a las 20:24, Eric Van Tol  escribió:

>> it's a nice-to-have, maybe? but this sounds more like an opportunity for
>> you to sell some JNCIA courses. i mean, how long has junos been around
>> now?
> 
> Confusing comment, since this enhancement isn't about CLI inexperience.  It 
> doesn't matter how long Junos has been around or how experienced someone is, 
> it's still too incredibly easy to hit 'Enter' too soon and clear all your BGP 
> neighbors by accident.
> 
> I don't see a problem with adding the requirement 'all'.
> 
> -evt
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Brent Sweeny]

Phil, I think what you propose sounds like a reasonable and
appropriately-scoped response to a real problem.
  Brent Sweeny
  Indiana University

On 2/26/2014 7:36 AM, Phil Shafer wrote:
> Juniper users,
> 
> We've been asked to make a change the "clear bgp neighbor" command
> to make the neighbor or "all" argument mandatory.  The root cause
> is the severe impact of "clear bgp neighbor" and the increasing
> accidental use of this command without a specific neighbor.
> 
> In general, we avoid changing commands to add mandatory arguments,
> but my feeling is that the impact and severity of this specific
> command makes this an acceptable occasion for such a change.
> 
> I'm looking for feedback about this change.  My working assumption
> is that "clear bgp neighbor" is a sufficiently rare command and
> would not be used in automation/scripts, so the impact of making
> the neighbor/all argument mandatory would be minimal.  Is this
> assumption accurate?
> 
> Thanks,
>  Phil
> 
> [I've set reply-to to myself to avoid impacting the list]
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Eric Van Tol]

> it's a nice-to-have, maybe? but this sounds more like an opportunity for
> you to sell some JNCIA courses. i mean, how long has junos been around
> now?

Confusing comment, since this enhancement isn't about CLI inexperience.  It 
doesn't matter how long Junos has been around or how experienced someone is, 
it's still too incredibly easy to hit 'Enter' too soon and clear all your BGP 
neighbors by accident.

I don't see a problem with adding the requirement 'all'.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Jerry Dent]

Just add a line "Reset all bgp sessions? [Y/N]" for confirmation.


On Wed, Feb 26, 2014 at 1:24 PM, Eric Van Tol  wrote:

> > it's a nice-to-have, maybe? but this sounds more like an opportunity for
> > you to sell some JNCIA courses. i mean, how long has junos been around
> > now?
>
> Confusing comment, since this enhancement isn't about CLI inexperience.
>  It doesn't matter how long Junos has been around or how experienced
> someone is, it's still too incredibly easy to hit 'Enter' too soon and
> clear all your BGP neighbors by accident.
>
> I don't see a problem with adding the requirement 'all'.
>
> -evt
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Phil Shafer]

ryanL writes:
>it's a nice-to-have, maybe? but this sounds more like an opportunity for
>you to sell some JNCIA courses. i mean, how long has junos been around now?

Not selling anything; just trying to solve a problem multiple
customers have reported and escalated.  I'm a software developer,
working on the UI code (CLI, MGD, configuration, XML API, scripting)
for 17+ years.

JUNOS 3.0 (the first release with the ui code) shipped during the
summer of 1998, IIRC.

Thanks,
 Phil

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[ryanL]

it's a nice-to-have, maybe? but this sounds more like an opportunity for
you to sell some JNCIA courses. i mean, how long has junos been around now?


On Wed, Feb 26, 2014 at 10:36 AM, Phil Shafer  wrote:

> Juniper users,
>
> We've been asked to make a change the "clear bgp neighbor" command
> to make the neighbor or "all" argument mandatory.  The root cause
> is the severe impact of "clear bgp neighbor" and the increasing
> accidental use of this command without a specific neighbor.
>
> In general, we avoid changing commands to add mandatory arguments,
> but my feeling is that the impact and severity of this specific
> command makes this an acceptable occasion for such a change.
>
> I'm looking for feedback about this change.  My working assumption
> is that "clear bgp neighbor" is a sufficiently rare command and
> would not be used in automation/scripts, so the impact of making
> the neighbor/all argument mandatory would be minimal.  Is this
> assumption accurate?
>
> Thanks,
>  Phil
>
> [I've set reply-to to myself to avoid impacting the list]
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Phil Shafer]

Jerzy Pawlus writes:
>  1. Would it be possible to "clear bgp neighbor" command do nothing?
> after applying above change.

We could have it say something like "Oh no you didn't!", but
I'd rather use the CLI completion to get users to see that
something more is needed.

>  2. You can add an option under "protocol bgp" allowing to choose
> the syntax of the "clear bgp neighbor" command

Sure, but I'm trying to avoid the scenario when the user has to
turn on a config knob to get us to do the obviously right thing.

Thanks,
 Phil

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to "clear bgp neighbor"

[Jerzy Pawlus]

Hi,

> 
> We've been asked to make a change the "clear bgp neighbor" command
> to make the neighbor or "all" argument mandatory.  The root cause
> is the severe impact of "clear bgp neighbor" and the increasing
> accidental use of this command without a specific neighbor.
> 
  
  1. Would it be possible to "clear bgp neighbor" command do nothing?
 after applying above change.

  2. You can add an option under "protocol bgp" allowing to choose
 the syntax of the "clear bgp neighbor" command

Kind regards,

Jurek

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] proposed changes to "clear bgp neighbor"

[Phil Shafer]

Juniper users,

We've been asked to make a change the "clear bgp neighbor" command
to make the neighbor or "all" argument mandatory.  The root cause
is the severe impact of "clear bgp neighbor" and the increasing
accidental use of this command without a specific neighbor.

In general, we avoid changing commands to add mandatory arguments,
but my feeling is that the impact and severity of this specific
command makes this an acceptable occasion for such a change.

I'm looking for feedback about this change.  My working assumption
is that "clear bgp neighbor" is a sufficiently rare command and
would not be used in automation/scripts, so the impact of making
the neighbor/all argument mandatory would be minimal.  Is this
assumption accurate?

Thanks,
 Phil

[I've set reply-to to myself to avoid impacting the list]

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp