On Jan 19, 2011, at 5:16 AM, Tim Franklin wrote: > > ----- "Gert Doering" <g...@greenie.muc.de> wrote: > >> This sounds like a very very stupid design in the FTTH gear. > > But either not unique, or on some popular gear. > > I've recently reviewed the spec for a wholesale FTTH offering from a certain > incumbent which contains exactly the same caveats. > > In my particular case, I'd be sticking a managed Cisco on the end of the > service generating (and receiving) IPSLA probes if nothing else, so there > should never be silence long enough for the MAC learning to time out. It was > a bit of a "WTF?" moment, though...
I've been continuing research on doing a small FTTH deployment, and my general consensus/balancing point starts to look somewhere between: 1) Put everyone on a large(r) broadcast domain with bidi sfps (something that would be nice if cisco would support more natively) 2) use a variety of kludges such as occam or other ftth gear to actually terminate and possibly vlan/qos for voip, iptv, etc to make it happen. Having not asked Frank what hardware he is using, it seems like "It's a bug" that should be addressed. The security model is intending to block some activity but is actually creating greater problems. Either the gear should act more like a true bridge, or support the features necessary to terminate the customers without trouble (and do things like IPv6 and other modern tech). Divorcing price from the equation entirely, I'd love to take something like Nexus and use it for massive FTTH termination with vlans, pvlans, and other capabilities supported in the Earl8. - Jared _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
