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