[c-nsp] REP

[Justin Shore]

sthaug at nethelp.no wrote:
> The fact that REP and EAPS are explicitly *not* compatible with regular
> IEEE spanning tree is one of the great attractions of these protocols.
> This means that a customer who sends STP traffic into your network can
> *not* influence your ring topology/failover.

Honestly this is a moot point anyway because only a mis-configured 
network would ever allow a customer to interact with the SP's STP.  If a 
SP is dropping MetroE at the edge without bpdufilter enabled then 
something is seriously wrong.  If the SP is doing L2VPN then 
dot1g-tunnel and L2PT take care of inhibiting interaction between the CE 
and PE with STP.  Otherwise in all other cases the SP should explicitly 
enabled bpdufilter on all Ethernet CE-facing interfaces as part of the 
standard template that a SP deploys.

> Additionally, REP and EAPS are explicitly made for a ring architecture,
> and can therefore be made simpler and/or converge more rapidly.

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 have lots of EAPS rings. It works for us. We might be interested in
> using ME3400 with REP for the same type of rings if it had decent CAM
> size.  Unfortunately, it doesn't - 8K MAC addresses is uncomfortably
> close to the number of MAC addresses we already have in many of our
> rings.

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.

Justin