[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