[c-nsp] NCS-5001 - MPLS L3VPN Issue

[Saku Ytti]

On 3 February 2016 at 15:29, Mikael Abrahamsson <swmike at swm.pp.se> wrote:
> I have spent a non-trivial amount of time going through SMUs and testing
> upgrades. Considering that Cisco do not do testing of SMUs in any-to-any
> configuration, I am a big proponent of SPs, where the SP is properly tested,
> and contains all rollup bug fixes.

+1, of course this essentially kills whole concept of in-service
upgrades, but they were never really true anyhow.

IMHO whole SMU issue is incorrectly presented, users are given
impression that there is single IOS-XR release and then there are
SMU's which solve exactly one DDTS. Which, if possible, would be
terrific.
But alas, that's not what SMUs are, they are really just newer version
(I'm guessing usually HEAD of that particular branch) of given binary.

So I think it would be healthier to present this without abstraction.
Say that this bug affects BGP component and you'll need BGP version K
or newer to solve it. It is really what it is doing already, just
presented as something else.
If it were presented like this, then it would be trivial to determine
if it's service impacting or not, of course restarting BGP is service
impacting. It would also be obvious that BGP version K+7 supersedes
K+6 and older.
Now as it's presented as magic sauce, determining these trivial issues
is complicated.


Is the magic sauce possible, even in theory? Could you really solve 1
single issue, in running system and control arbitrary combination of
fixes? Choosing another language than C would allow solving 1 single
issue run time, like in erlang/BEAM you could rewrite run time single
broken function to newer version. But even in that case, could you
possible manage arbitrary set of these? You probably could not, but
would it even be needed? If you can rewrite the function run-time,
then you can force linear progression so if you want given fix on
function Z, you also must walk all the earlier changes in order until
you're at that fix.

-- 
  ++ytti