OK. So who other than Andrew was able to get this working (and keep it working) ? I'm about to place an order for slow-verse for my residence...
-Z- On Mon, Dec 9, 2013 at 12:20 AM, Nikolay Shopik <sho...@inblock.ru> wrote: > On 04/12/13 23:48, Owen DeLong wrote: > > Please tell me what provider is selling 100Mbit for $20-30 in the > 408-532-xxxx > > area of San Jose, California. > > > > Currently, the only provider capable of delivering more than 768k wired > > here is charging me $100+/month for 30-50Mbps maximum. > > > > I could get 100Mbps from them, but they want $250+/month for that. > > > > If I can get 100Mbps for $20-30, I'd jump at it. > > I know this is nanog, but i was talking about Russia, sorry for > confusion. You can get 350Mbps for 70$ via GPON here. but plain ethernet > dominates mostly here > > > > > Not entirely sure what you are saying here. In this day and age, I don't > see > > any reason that wireless providers should get a free pass or be able to > sustain > > significantly worse policies than wireline providers. Wireless bandwidth > is > > rapidly approaching parity with wired bandwidth pricing at consumer > levels. > > Sure but most cases you hit tower limit or frequency to crowded, since > its shared medium and you can't do anything about that. In wired you can > just drop another cable to your new client. > > > > >> Some even come up with idea two separate /64 make things easier :-D, > >> instead just put at least round /60 > > > > Actually, providing a separate /64 for the provider link makes a lot of > sense. > > It really is best to pull that out of a separate provider aggregate > across all > > the subscribers in the same aggregation group than to carve individual > > link prefixes out of each subscribers internal-use prefix. > > > > For example, if you get a tunnel from HE, then, by default, you get a > /64 > > from our link block for the tunnel broker to which you connect and an > additional > > /64 for your internal use by default. If you click the "please give me a > /48" checkbox, > > then you'll also get an additional /48. > > I was talking about /64 + /64 to client LANs and not counting another > /64 for WAN interface. I find this hard to manage at least on Cisco, > actually didn't find way to separate them at all, unless its make them > static > > > > > We do this because it makes our provisioning easier and allows us to > support > > users that want prefixes as well as users whose equipment (or brains) > can't > > handle more than a single /64 for their LAN. > > > > There's really NOTHING to be gained from providing anything in between a > /64 > > and a /48, so we don't do it. > > > > Owen > > > >