5.2.4 release date

[Peter L]

Hi

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

Regards Peter

[smilstea · Accepted solution]

Hi Peter,

5.2.4 is planned for mid to late April.

If you are considering this release please send me an email so I can see if we can get you in the EFT to test before release / your deployment.

Thanks,

Sam

[Florian Frotzler]

Hi,

Is 5.2.3 still the extended maintenance release for A9K?I assume 5.2.4 is for CRS?

Florian

[Peter L]

Hi Florian

5.2.4 is the EMR for ASR9K. For some reason .5.2.3 isn't EMR in the 5.2.x train.

http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ios-xr-software/product_bulletin_c25-478699.html

/Peter

[smilstea]

As Peter mentioned there will be no 5.2.3 for CRS or ASR9K.

5.2.4 will be the EMR for 9K and NCS6K, along with the GA for NCS4K.

CRS should be having a 5.2.4 release, no word yet on if it will be an EMR or not.

Sam

[Mark Pace Balzan]

Hi Sam 

hoping you can help clarify. I got hold of 5.2.4 for asr9k and have done some lab tests with the intention of looking at deployment later on since this was the targetted emr release.

i now see that in http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ios-xr-software/product_bulletin_c25-478699.html it mentions 5.2.4 as SMR 

can an you kindly let me know if there will be a 5.2.5 as emr for asr9k, and also what the emr target is for crs ?

thanks

Mark

[Bryan Garland]

524 is still a hardened release for the ASR9k.  It's not technically an EMR because other features did go in but for the CRS-X and NCS platforms.  

Thanks,

Bryan

[Florian Frotzler]

Hi Bryan,

Nevertheless I assume that there is 36 months extended support for 5.2.4?

Florian

[Aleksandar Vidakovic]

Hi Florian,

XR release 5.2.4 is an SMR release from release lifecycle perspective, for all platforms.

On asr9k, it's an EMR equivalent from quality perspective:

• no new features or HW support were allowed
• it was subject to the EMR hardening cycle, with special attention to BNG. 

Regards,

Aleksandar

[Florian Frotzler]

Hi Aleksandar,

This is absolutely catastrophic, we need to have a 36 months supported release in each train, how do I explain the customer that the platform is not ISSU capable but they need to change software once a year (24 months is only theoretical, as there is testing effort, maintenance window planning, waiting for SMU to get ist stable, etc)? Also this release was defenitely planned to be EMR at some point in the past, so changing release strategy without notice and suddenly is also totally unacceptable to partners and customers.

Florian

[Aleksandar Vidakovic]

Hi Florian,

the exception was made on 5.2.4 for various reasons, one of them being that an FCS of 5.3.3, which will be a true EMR, is planned for the end of 2015. This way we will be providing one EMR per calendar year.

If there are some special considerations for 5.2.4 deployment in your network, please do reach out to your Cisco account team. Let's see what migration strategy can we work out together.

Regards,

Aleksandar

[Mark Pace Balzan]

Hi Aleksandar,

so will there not be an EMR for the 5.2 train at all ?

realistically, 5.3.3 will be deployable for production some time late next year.

thanks

Mark

[Aleksandar Vidakovic]

From release lifecycle perspective, there won't be an EMR for ASR9000 in the 5.2 version. 5.2.4 is the last 5.2 release for the ASR9000.

We can get ahead of the deployment curve by engaging in early field testing or 5.3.3. If you would be interested, please reach out to your account team. We'll be happy to work with you on this.

Regards,

Aleksandar

[evan.r.moore]

Xander, Aleks, etc. :

I think the point that Mark, Florian, and others are trying to make, at least in part, is that some shops cannot, for matters not related to engineering, run code officially labelled SMR.  If you combine the legitimate engineering delays in putting code into field production with the hole that now exists in the ASR9k code series (EMR only), some shops are going to have problems.  Some shops may also have policy problems with going from 5.1 to 5.3 in a single step.

In other words, shifting from the documented pattern of EMRs creates management headaches.

ERM

[xthuijs]

hey evan,

discussions like this is what I so much value as it helps us understand also what possible ramifications are when such decisions are made!

although this was a decision made by the release operations group, outside my primary view, I honestly didnt think it was "such a big deal", considering that we have an EMR coming this year, albeit it being 53x.

based on the interaction here, I see some very valid points being brought up that make me believe we should look closer at this and "be more considerate" when making deviations from "standard policies" previously communicated.

I hope you know that when we see certain comments, like on this discussion that this WILL receive follow up! I will definitely use you all's valid points to release ops so that we can make everyone's life easier!! :)

To give a fine example: in the past we put features in smu's because some people needed it. but that affected stability for others. then we decided not to do features anymore in maintenance releases and smu's and that disappointed some others again that needed it and willing to take the risk. End result, we made feature packs that allow you to have the baseline (EMR) stability AND have the ability to run a feature that helps you differentiate and grow your business.

What I mean to share with that story is that we do (try to:) listen, taking comments like this very seriously and it is only because of transparent discussions like we have here that we can learn what to do better so that we come to the best middle ground for all parties involved.

anyways :) hope you didnt mind reading this little novel :)

cheers!

xander