5.2.4 release date

[Peter L]

Hi

Short question, when will IOS-XR 5.2.4 be released?

Regards Peter

[Florian Frotzler]

Hi,

In the early days of ASR9K it was planned to use X.Y.3 as the EMR, now with special CRS/A9K/NCS releases this changes obvisouly from train to train, now it seems not even this information is reliable. I only want to point out that YOUR partners are out there having to give customers software recommendations (e.g. when they buy a new ASR9K or use an old software version that needs to be upgraded for some reason). So at the end of the day I have to pick a software and I do that based on potential stability and life cycle, so changing the strategy without notice is not a funny thing for us.

Florian

[xthuijs]

Hi florian,

fair feedback. I had hoped with the info documented here: http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ios-xr-software/product_bulletin_c25-478699.html that documents the release strategy was crisp enough.

Because we target EMR's to have no new features, and while new hardware was introduced, it made more sense to the release team to not call this an EMR and focus that EMR (which requires a substantial amount of additional testing resources) for the XR 5.3 release to maintain the strategy of an EMR per calendar year as aleks suggested also.

Now the key and only difference between the EMR and SMR is the lifetime, which is 36 vs 24 months, but you have the same support etc. And for a9k specifically since no new features for a9k were introduced, you can consider this EMR in the realm of stability. In fact 524 is a very solid release for BNG deployments and provides new capabilities such as flowspec which is very hot at the moment.

regards

xander

[Florian Frotzler]

Hi Xander,

I appreciate your feedback. My criticism here is that if you have to regularly look up a document to determine the software strategy, then there is no real software strategy. When IOS-XR was born, I was glad that Cisco reworked and simplified the whole numbering concept compared to IOS. Now this falls apart. Also making platform specific releases part of the overall numbering (effectively skippig those releases for other platforms), my humble opinion is that this was not a good decision, but this is just my 0,02$. My point with 5.2.4 is not that it is SMR as such, the problem I have is that 5.2.4 was supposed to be EMR (I have slides that proof that) and there was a last minute decision to change it. Now this makes my business harder, as I have to give sw recommendations on almost a daily basis.

Florian

[xthuijs]

hey florian,

also please see my note to Evan just a bit earlier here:

https://supportforums.cisco.com/discussion/12396291/524-release-date#comment-10555381

Based on my research indeed it seemed that during the release process of XR524 the strategy was changed from EMR to SMR. And I very much understand now what the ramifications are for you having to deal with such changes. As I mentioned to Evan, I will definitely forward this discussion to the release group to make sure we do it differently next time (whether that be not happening, or communicated differently or something).

I can explain however the platform release specificness because there is a good business reason behind it:

For every release that is put out, there are dev-test (DT, component specific) and system integration test (SIT, topology, feature cross sections etc) testing coverage necessary.

sometimes lets say the CRS or NCS have an immediate need to push out a release, but let's say ASR9000 doesnt have its content ready, not all needed fixes are in there etc. The reduce the testing overhead from a non important release, it can be decided that in this case 523 is put out, but the a9k doesn't participate.

if it all it shoudl alleviate your release strategy decision not having to evaluate a release that doesnt make much sense or doesnt buy you much for that platform :)

So instead of calling it a 522-YZ bla release for that platform, like how it was in IOS to make platform specific trains suddenly that somehow somewhere ended back up in baseline :), it seems, to me at least, better to call 522-yz -> 523, but not every one needs it, and then continue with 524 "for the all of us".

What I do get out of your comment is that the release strategy is not clear, or the reasons and that is something we can fix very easily with better transparency and alerts/documentation!! And as you know I am a big fan of blogs and docus :)

Does this explanation jive with you at all? if not I'd love to hear what to be done to make it easier (knowing I have business needs to accommodate also :)

as always btw Florian, I really value the interaction and thanks for taking the time to share this so positively and constructively!

cheers!

xander

[Florian Frotzler]

Hi Xander,

Maybe there is simply not a 100% perfect solution to deal with the platform specific releases :) But thank you for clearing that up. Regarding the software strategy, more/better documentation/alerts sounds like a good deal...maybe spiced up with a little bit more consideration in the future regarding [last minute] strategy changes ;)

Florian

[xthuijs]

Very fair request Florian.

Aleks and I are having some conversations as we speak and hopefully in a week or so we can give some conclusions as to what we're doing about this. Standby (everyone) to hear more on this in say a week or so.

xander