Re: [c-nsp] Upgrading to 40G
On 28/02/2014 18:49, Mikael Abrahamsson wrote: Also I would say there is a fundamental lack of focus from operational people when it comes to progress in making the standards better and more efficient. Ops people are like any other recipient of developemnt, if you ask them, most of them just want the same, but more and cheaper. Doing leaps in efficiency isn't something they do, because that's not what they focus on, they focus on stability. My view is that the real problem is treating ops and development as two different things done by two separate groups of people - a pervasive attitude in the IT industry as a whole, that leads to un-operable crap being thrown over the wall from development, while at the same time development has no idea what ops needs. I think that siloing two groups of people with similar skillsets off from each other, making their communications go via some insipid bureaucratic process (ITIL! PRINCE2! Blah blah blah...), and then being surprised when each group doesn't understand the others needs is, frankly, idiotic. Ops and developement are the same thing, in my view. Ops must, surely, have a list of things they want to automate and/or architect out of existence, and you can't do truly useful development work without a visceral understanding of the operational needs of the network. That also happens to be a fundamentally more humanising and enjoyable way of working, in my experience. ___ 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/
Re: [c-nsp] Upgrading to 40G
On Saturday, March 01, 2014 02:39:07 PM Phil Mayers wrote: My view is that the real problem is treating ops and development as two different things done by two separate groups of people - a pervasive attitude in the IT industry as a whole, that leads to un-operable crap being thrown over the wall from development, while at the same time development has no idea what ops needs. And this creates a huge gap. Folk that translate RFC's into code may not necessarily understand how their choice of implementation affects network operation. Some vendors have BU's that monitor these lists, and when all the planets align, some actually go out and ask whether implementing a feature (a certain way) has operational value or not. This happens less often than it should, but it shows that there is a gap that needs filling.. Operators have, for years, tried to get their word into vendors. And the usual answer - Show me the money. One poster on a competing vendor's -nsp list suggested that requests for new features and capabilities should be posted via a web site, rather than trying to channel these through your AM, because more than likely, those go into /dev/null for the majority of operators. Are operators talking more to their vendors than they are the IETF? Yes. But some may argue that the IETF are mostly vendors, so... This is not an easy problem to solve - and if vendors continue to use the AM's-go-and-find-out-how-many-of-your- customers-have-requested-this-feature or how-large-is- your-customer's-deal approach, we'll never fix this problem. I appreciate that vendors have finite resources as to do other areas in life, but we also can't ignore the problem entirely. Mark. signature.asc Description: This is a digitally signed message part. ___ 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/
Re: [c-nsp] replace Huawei HG863 GPON terminal with Cisco gear
Tarko, when I reload my ONT and debug the OMCI messages exchanged between the ONT and OLT during and right after the bootup, then I see ONT-G, GEM Port Network CTP, GAL Ethernt Profile, MAC Bridge Port Configuration Data, Flow Mapping Mode, HW Extended Multicase Transfer Mode, VLAN Tagging Filter Data, etc messages. All those messages seem to be driven by OLT. I guess that those requests/instructions from OLT to ONT are defined in service profile in OLT? It is probably very difficult to make the SFP ONT represent itself exactly the way my HG863 G-PON terminal.. I guess it's not as simple as changing some values on non-volatile memory on SFP, because based on those debugged OMCI messages, there seems some serious interaction taking place and there will be compatibility hurdles sooner or later with the service profile defined in OLT. Last but not least, it would be difficult to debug if I'm not in control of OLT. regards, Martin On Fri, Feb 28, 2014 at 8:52 AM, Tarko Tikan ta...@lanparty.ee wrote: hey, So I guess this Huawei GPON ONT in SFP form-factor will be something like RAD MIRICi-155(http://www.radproductsonline.com/support/ cs11c01/radcnt/mediaserver/18805_MIRICI-155.pdf) which supports management over web-interface(or maybe even CLI is available) SFP form-factor is SFP :) one could change the serial-number of this ONT? Is the 16 Why do you insist changing this? If you have compatible ONT just let ISP change the serial in their end (*). hex characters some sort of industry-standard or is this vendor-specific as well? To my best knowledge, it's standard. (*) In real life, it's not that easy. ONT is provisioned using service profiles that are defined in OLT. Profile defines things like number of expected ethernet ports in ONT, number of POTS ports, IP/routing capabilities, vlan mappings from GEM to ONT ports etc. When you have mismatch between profile and real life (ie. you replace 4-port ONT with SFP that says 1 ethernet port in it's capabilities in OMCI), ONT will not be provisioned. (G)PON is not like DSL, don't expect to bring your own ONT. -- tarko ___ 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/
Re: [c-nsp] replace Huawei HG863 GPON terminal with Cisco gear
hey, All those messages seem to be driven by OLT. I guess that those requests/instructions from OLT to ONT are defined in service profile in OLT? Correct. -- tarko ___ 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/
Re: [c-nsp] replace Huawei HG863 GPON terminal with Cisco gear
Tarko, so even once Huawei releases its GPON ONT in SFP form-factor which is compatible with their GPON OLT in OMCI protocol wise, it wont help as long as service profile in OLT operated by ISP is not updated? I wish this isn't so strict and OLT could be able to adopt with different(at least to some extent) GPON terminals dynamically.. :P regards, Martin On Sat, Mar 1, 2014 at 7:37 PM, Tarko Tikan ta...@lanparty.ee wrote: hey, All those messages seem to be driven by OLT. I guess that those requests/instructions from OLT to ONT are defined in service profile in OLT? Correct. -- tarko ___ 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/
