[c-nsp] SPA Module compatibility

[Christian Kratzer]

Hi,

On Tue, 25 Feb 2014, Gert Doering wrote:
> Hi,
>
> On Tue, Feb 25, 2014 at 11:29:35AM +0200, Mark Tinka wrote:
>> But by and large, modern routing equipment does policing and
>> shaping really well for this to no longer be an issue.
>
> Well.  My problem is, I can't always forklift to the "latest and greatest"
> in routing equipment - while our 7200s will shape just fine, they won't
> go much faster than maybe 50 mbit/s with shaping.  OTOH our 6500s will
> handle any bandwidth you throw at them, but will just not shape, period.
>
> ... and when I have to decide whether to get a 200 Mbit/s-on-GE line plus
> an ASR1k or ME3xxx to do shaping, or maybe get 2x100 Mbit/s line rate
> (or full GE) and plug into the already-there-6500...  the decision isn't
> always easy.

as shaping is expensive and not always available in both directions most people seem to resort to policing which simply drops packets.

Even when shaping is available queue sizes might not always match line speed.

Shaping/policing with a large difference between line speed and shaped/policed rate for the service is also quite problematic.

I remember an issue where a customer was doing nfs over ipsec over the wan and the providers equipment consistently dropped a single packet out of an nfs windows sized burt.

All this seems to work far too well these days and the expectation seems to be that you can define products at any bandwidth and the the right thing (tm) will just happen.

The other can of worms is of course link state detection as you also mentioned.

Greetings
Christian

-- 
Christian Kratzer                   CK Software GmbH
Email:   ck at cksoft.de               Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0       D-71126 Gaeufelden
Fax:     +49 7032 893 997 - 9       HRB 245288, Amtsgericht Stuttgart
Mobile:  +49 171 1947 843           Geschaeftsfuehrer: Christian Kratzer
Web:     http://www.cksoft.de/