[c-nsp] REP

[Rubens Kuhl Jr.]

On Wed, Jul 23, 2008 at 11:54 AM, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
>> <list of points why STP shouldn't interact>
>
> ...the key thing being "should not", rather than "will not". Using an
> entirely different protocol protects to a degree against human or machine
> error e.g. forgetting the bpduguard config.

I agree. It's an extra protection that doesn't hurt... but I prefer to
do bpudfilter, as the customer won't interfere with our STP and
vice-versa. spanning-tree portfast bpdufilter default (or something
like that) is a good tool do impose that beyond normal human error
(forgetting to insert a command) but not advanced human error
(configuring a customer interface as a backbone interface, for
instance).


>> I have never seen the point in more STP-like protocols when you can
>> configure 802.1w or 1s w/ 1w to converge just as quickly with uniform
>> support on all platforms to boot.  EAPS does not offer any benefits and in
>> fact it offer serious limitations thanks to its infancy.  Every vendor has
>> interpreted RFC 3619 differently since it was published nearly 5 years ago.
>>  For example Pannaway supports EAPS but their implementation is limited to
>> not allowing EAPS rings to cross VLANs. That's a serious design limitation.
>
> We've tuned metro rings for 100ms convergence. I've *never* seen STP come
> anywhere even close to that, and I frankly doubt it has the capability.

It hasn't, and we discovered that the bad way, with a loop that took
us a painful downtime.  And that's why we are looking at non-standard
ring protocols, not because our customers also use STP.

One point that could be argued, is what would be the performance of
Rapid PVST+ or their IEEE counterparts on a ring-only topology.

> 802.1s is (IMNSHO) a bad joke. There are topologies where it's not just
> worse than PVST, it's actively harmful. This would be significantly
> alleviated if:


>  * Cisco could run >1 MST "process"
>  * 802.1s had some way of versioning the config, as opposed to breaking the
> 802.1s domain into pieces every time you update the config (or mandating you
> decide on vlan->instance mappings on day 0 and never change it - yeah,
> right...)

We tried to migrate to MST, but just couldn't find a way to migrate
gradually from Rapid PVST+.


> EAPS (and Foundry MRP) aren't universal solutions, but correctly applied
> they bring significant benefits in my experience.

Also in the market, Allied Telesis has EPSR or something like that. It
would be a Good Thing if all those Ethernet ring protocols were
replaced by a standard one, but that doesn't prevent a network from
running different rings with different vendors, as they all provide
similar performance.

> When you say L2VPN, you mean point-to-point? What about multipoint e.g.
> VPLS? It's difficult to see how you could avoid MAC learning in a multipoint
> case.
>
> ...which is one reason I prefer L3VPNs, but there's a market for L2VPN.

I second that.

Rubens