Excerpts from Saku Ytti's message of 2016-06-06 20:06:01 +0300: > On 6 June 2016 at 19:01, Allan Eising <eis...@nordu.net> wrote: > > Hey Eising, > > > The ASR9000V-setup gave us the possibility of having inexpensive remote > > line-cards on small pops. These 9kV devices were cheaper than normal line > > cards > > and acted completely like normal router ports, ie. unique VLANs per port, > > direct termination in L3VPNs, queuing, and all that. Furthermore, the nV > > technology enabled us to create rings of satellites between two PEs, so > > customers could be served in an active/standby fashion by two routers. > > I think only benefit to regular switch here is unique VLAN and even > that is not true, if switch knows VLAN rewrite. It'll also decouple > the devices, so you don't have to upgrade them at the same time. And > certainly will expose you to fewer issues. > > It does not act like normal router port the more deeply you review > them. For example LPTS is way too aggressive for satellite, as all the > ports are just single port to LPTS. QoS also is not at all the same. > > > This reduced the number of PE routes in our network drastically, and > > allowed us > > to quickly roll out new POPs, and easily add more ports when necessary. > > I see this is same for Switch. > > > Also, provisioning was simplified, as the number of platforms could be > > reduced; > > old legacy 7600-routers were replaced by satellite devices on already > > existing > > PE-routers. > > This is benefit, but only if you're provisioning by CLI jockey. >
Okay, with apologies to the list, but this conversation is now officially derailed. I think our difference in perspective here is a lot about difference in market and business. The before mentioned satellite deployment were targeting business customers and only business customers. If your user base includes residential customers, you will gain very little from this, and would be much better off with a switch, I agree. With this, versus having the customers on switch ports, you avoided annoying spanning-tree half-rings, BFD on your BGP sessions, sub-optimal backup xconnects for old-school EoMPLS, and much more. I'd love to elaborate more off-list, but I'm unsure whether the rest of the list will find these things interesting - especially juniper-nsp, since my experiences were with cisco. Best, Allan _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
