[c-nsp] REP

[Phil Mayers]

> <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 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.

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...)

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

In addition, there are cases where might want STP to pass through a ring 
topology without being either tunnelled or blocked. We're running an 
architecture like that in our datacentre, where the two DC routers with 
ACE modules see:

  r1 -- p2p -- r1
   |           |
   \-- CLOUD --/

...but the "cloud" is actually a ring of 5 (soon to be 6) Foundry 
switches, protected with an MRP ring.

If you don't need such, then all fine and well, but other people do find 
uses for non-STP protocols, and vendors sell boxes on the back of that - 
so there is clearly market demand.

> Are you learning customer MACs for the service you're offering?  That 
> would be the case if you're simply transporting PtP VLANs.  However if 
> you're doing L2VPN or dot1q-tunnels then you shouldn't be learning MACs.

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.