Friday, April 3, 2009

What is a PER (Product Enhancement Request)?

According to your votes in the recent poll, i ended up having some interesting results.



1) only 1 person has been successful in his/her PER (i would really like to know the company he/she works for and what the PER was about)
2) 8 people have submitted a PER, but it wasn't implemented (i'm one of them)
4) 83% do not know what a PER is

While some other companies have PER open for public with online forms, Cisco likes to keep it internal. Even worse, you cannot watch its progress, unless you manage to persuade TAC to open a bug (as enhancement) and then tell your account team to attach a PER to this bug.

So, what is it about?

Your Cisco account team has access to the Product Enhancement Request (PER) tool. With this tool, the Cisco account team can submit a PER on your behalf, always with a "good" business case behind it. Generally, Product Enhancement Requests are things that you'd like to have on your devices, but are not happening, because there isn't any need for them (due to various reasons).

According to Cisco procedures, your Sales/Account Team needs to open and follow up on the PER request. It then goes to the Business Unit (BU) and gets reviewed and if approved it is prioritized to be implemented.

Judging from my experience and your votes to the poll, you'd better have a very good business case if you want to see you request being implemented. i.e. if you work for NTT, DT, BT, AT&T, then this is by default a very good business case. Otherwise you'll have to try very hard to convince the BU to accept your request. Also, if you have (or intend to buy) hundreds or thousands of cisco boxes, then this is also a very good business case. If you don't belong to one of the above categories, then the BU might say that your request is a corner case; don't believe them. They usually mean that your business is a corner business.

To be honest, i have to somehow agree with the above concept. Companies that bring a lot of money to Cisco, should have their requests prioritized. After all, they are the most important customers.

BUT

I think there are some things that should be considered too instead of relaying solely on business needs brought onto surface by big customers. I don't know how many of the following cases refer to others too, but this is my just-before-opening-a-PER experience until now:

1) Redistribution of FHRP (First Hop Redundancy Protocol) IPs into routing protocols does not take into account the state of active/standby interfaces. That means you cannot (easily) influence the downstream direction of packets.

2) Although there have been at least 3 years since ethernet has replaced ATM in the broadband edge, Cisco's MIBs do not support counting of PPPoE sessions per ethernet subinterface.

3) There aren't any cvpdnTunnelBytes* 64bit counters (used in VPDN tunnels). When gigabit and tengigabit interfaces are becoming common in all broadband platforms, some counters insist on 32bit.

4) The PPP idle timer feature ("ip idle-group") which is supposed to be an enhancement made specifically for LAC/LNS scenarios, was working fine in 12.3x, but got removed in the broadband 12.2SB release (on 7200 & c10k platforms). Even the new broadband platform (ASR1000) doesn't have it.

5) There is a hardcoded limit (for no apparent reason) of 8 UNI ports that can use community vlans on the ME-3400G-12CS. If you need more, you have to turn them into NNI.

6) If you're using an aaa server for system accounting, then in case of a problem on your aaa server, you'll have to wait for 2-3 mins to login into your routers, regardless of the aaa method used for your login.

7) "Configuration Change Notification and Logging" keeps a record of all per-user configurations applied through radius (i.e. ACLs) under a subscriber vtemplate.

All of the above cases got pwned by Cisco with the excuse "a PER must be submitted in order to be implemented". Of course, on some of them this is true, because they are new things and a lot of work needs to be done. Some others seem more like a misbehavior that needs to be fixed. According to Cisco, everything that adheres to the documentation cannot be considered a bug. So, keep that in mind.

I understand that my current needs are different from many others, but the possibility of someone else having the same needs can't always be zero.

I would like very much to see all submitted PERs in a poll by Cisco, so other customers could choose what they would like too. I'm sure that there are many good and simple ideas submitted as PERs that can be useful to everyone, but they are hidden somewhere away from the public.


PS: Since i don't have any actual internal info, a lot of my talk about the PER process might not be accurate. Please feel free to correct me.

No comments:

Post a Comment

 
Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.
Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Greece License.