On Thu, Jan 20, 2005 at 07:05:20AM -0500, Joe Maimon wrote:

A couple comments from my side...

That is something that you have the ability to decide becuase you are the case owner. The reason we don't have a hard line on that topic is becuase a lot of customers want the case closed especially if a workaround is in place. They put the bug on their watch list and upgrade when the fix comes. There are things in the works to make it easier for the customer to monitor say a specific train and be notified when that bug is integrated there.

We have other customers that say please keep the case open until a fix is delivered in a CCO released version of code /*plug: that is the way I like customers to handle it because that makes the case an accurate representation of how we do solving a customers problem fully*/

As you know there are different states a case can be in and one of them is DE-pending and that's when all the work has been done on the case and it's waiting on DE to fix the bug which is what your case should be in. DE-pend-workaround-provided.

Or do you keep them

I personally don't like thinking about it from "keep the pressure on". Although I realize sometimes a little pressure is needed hopefully if the TAC engineer understands the importance they can do that on your behalf as part of service to the customer. You should not be required to do that.

Just ask for the case to be put in a DE-end-workaround-provided state until you have a CCO image that fixes your bug. Until then the case is not resolved if that's what *you* as the customer determines to be closure for the case /*which is the way I would view it as a customer*/. However, we also have to handle the customer that wants the case closed because just like you said they have a workaround and don't want to worry about it anymore. Some want it that way for some reason.

I think the answer from the TAC engineer should be:

Mr. Customer,

Thanks for working with us to find this bug. Fortunately we have found a workaround that appears to be acceptable to you in the short term while we fix our bug. In the meantime, would you prefer to leave the case open and in a DE-pending status or would you rather I close it and you can monitor the state of the bug through the BugToolkit on CCO?

Thanks, TAC Engineer

We even have customers that sometimes are willing to verify the fix for us depending on what their network setup and IOS code change procedures are. Some can't due to policy. Some want to because they want to know if it's a problem they can reproduce also that it's the same problem and when the fix is delivered on CCO it will fix the problem they see. It's a customer decision.

It's actually still pretty common and used between PE-CE links of some MPLS/VPN providers. Mostly I think because it seems to be the most simple to operate /*from a configuration point of view*/.

Depends exactly what you are doing.

The overhead to switch a GRE packet in the CEF path is very small compared to normal packet switching. If you are talking about the additional GRE header size taking up bandwidth on the links which comes more significant when running small packets then yes that can be an issue. GREoIPSEC is very common through the internet today for VPN topologies.

In my eperience not very. Most ISP's I've seen, non MPLS-VPN, either do statics to leased line customers or BGP.

RIP is driven more as a requirement for some customers in the MPLS VPN context because that may be what the customer request.

Others can comment here. It's functionality that's built in IOS and it should work..always.

I can't think of a way to do this and I've never seen a customer request. If you can make sure I understand what you are asking for I'll run it by the coders and see if it's functionality we could add.

What you want is the ability to specify on a per interface basis the offset that gets added to a RIP route for VA interfaces.

There are two approaches I see:

a) make it where the offset-list command under router rip will accept a VA interface and then if possible have a per-user AAA command get loaded for each user to add the command under router rip

b) make it where under the VA interface you could apply the offset list command there and have it loaded from AAA on a per user basis

What is your deployment scenario that you are running RIP to customers? Usually I see it done as per user static routes because the provider doesn't want to add the complexity of a dynamic routing protocol to the user for various reasons.

Rodney