Contributors   |   Messages   |   Polls   |   Resources   |  
Comments
clrmoney
clrmoney
4/9/2016 1:15:27 PM
User Rank
Platinum
NFV
I think that this need to get this resolved relating to data management and virtualization tools for our computers and processors etc.

50%
50%
jbtombes
jbtombes
4/11/2016 3:45:29 PM
User Rank
Platinum
several minutes delay?
Absent Doctor, notification of failure to the app manager takes several minutes? Wow. It's good that someone - or some group of someones - got around to addresssing that delay. So now notification can occur within a second. How long before the repair takes effect?

50%
50%
Carlos Goncalves
Carlos Goncalves
4/18/2016 11:03:18 AM
User Rank
Author
Re: several minutes delay?
Yes, before notifications could take up to several minutes and it was not deterministic because of two stats pooling times in between.

The time for repairing can vary a lot depending on a number of factors that may be external to the virtual infrastructure management (VIM) platform, e.g. OpenStack. For instance, a recovery action could be, as presented in this article, switching to a standby VNF triggered by the upper layers (e.g. VNF, VNF Manager, NFV Orchestrator) and that takes milliseconds. We measured 103 milliseconds from active-standby switching action to recovery in an OpenStack testbed (Use Case #2 https://wiki.opnfv.org/download/attachments/5046291/20150730_doctor_demo_v6.pdf).

Another recovery action could involve actions to the VIM such as evacuation of the VNF/VM to another compute node – in this case, it could take up to seconds (we measured 58-second evacuation time in an OpenStack testbed; Use Case #1). However, for telco operation, switching to the standby VNF would be necessary before such evacuation actions.


50%
50%
JohnBarnes
JohnBarnes
4/13/2016 7:53:17 AM
User Rank
Platinum
Cool video from a business standpoint ...
... for those of us on the tech/biz interface, it would be great, though, to see some kind of packet simulation: error happens here, how does it become local message? How does local message transfer/convert upchain, and how does fix propagate downward?

I realize that our engineering writer here was probably already driven half-mad by all the cool things they didn't give him space to explain, but the right animation/simulation would help a great deal for those of us trying to follow (in a naive, semi-technical way).

 

50%
50%
Carlos Goncalves
Carlos Goncalves
4/18/2016 11:03:52 AM
User Rank
Author
Re: Cool video from a business standpoint ...
Hello, John. Thank you for your valuable comments. Please kindly refer to https://wiki.opnfv.org/download/attachments/5046291/20150730_doctor_demo_v6.pdf. I believe the slide deck can answer to your questions. The Doctor team will be talking about the project soon at the OpenStack Summit Austin. I invite you to join us and get a live demo :)


50%
50%
JohnBarnes
JohnBarnes
4/19/2016 7:27:58 AM
User Rank
Platinum
Re: Cool video from a business standpoint ...
Sadly, I won't be able to be there, and here's another reason to be sad about it.  But it sounds like you're already working on exactly the issue I asked about, so that better supporting explanation is already on the way.  Good going, again!

50%
50%
JohnBarnes
JohnBarnes
4/13/2016 7:56:34 AM
User Rank
Platinum
If I'm understanding this correctly the basic structure is hub and spoke ...
... with hubs defined at an arbitrary network/junction distance from the rim of applications. I'm just wondering if it would be possible to devolve more and more of the analysis/repair functions down into local processors and have them report back that they found a problem and fixed it rather than requiring the whole problem-identification-attempt-solution-evaluation cycle to pass through the upper reaches of the pyramid?

Or have I misunderstood the architecture?

50%
50%
Carlos Goncalves
Carlos Goncalves
4/18/2016 11:05:56 AM
User Rank
Author
Re: If I'm understanding this correctly the basic structure is hub and spoke ...
John, you made a very good point!

Not everything needs to be reported to upper layer management entities. What could be locally repaired (e.g. a fan or RAID disk failure) can be locally repaired. The objective is to reduce the service downtime to zero.  In the Doctor architecture, we have the Inspector module where an Operator can flexibly define what kind of fault it wants the VIM (e.g. OpenStack) to report to upper layer managements. It should be flexible and programmable to be able to reflect Operators policy.

We also need to consider the fact that in certain redundancy configurations, e.g. 1+1 ACT-SBY, local repairing may violate the ACT-SBY interdependency. Migration, re-instantiation, etc. type of recovery should not be performed without notifying the upper layer management. That's what Doctor tries to achieve. Based on the policy defined in the Inspector module, Doctor notifies the upper layer management about a fault so that the upper layer management can take necessary action, e.g., switch to the standby instance.

50%
50%
JohnBarnes
JohnBarnes
4/19/2016 7:24:47 AM
User Rank
Platinum
Re: If I'm understanding this correctly the basic structure is hub and spoke ...
Carlos, that's a great solution made much better by the ability of individual organizations to decide the exact structure of reporting and control they want at each level, rather than trying to write a "correct" version for them ahead of time (the bane of any software buyer: the supplier who decided what would be "right" and imposed it).  I assume it is also possible for users to change their minds more or less on the fly, so that if it becomes clear that higher levels don't need some information, or that they do, they can begin or stop recording data in those categories without having to redo the whole database?

50%
50%
Carlos Goncalves
Carlos Goncalves
4/20/2016 9:15:26 AM
User Rank
Author
Re: If I'm understanding this correctly the basic structure is hub and spoke ...
Yes, Doctor gives users the flexibility to dynamically reprogram policies. As for redoing the whole database, it is a scenario that is not applicable -- as the intent is to detect failures and notify fast, keeping monitoring data for long periods is not of essence. Thus, in this context, there's no need to depend on such database possibly holding millions of past records for later use.

50%
50%
FrancisLiu
FrancisLiu
4/14/2016 10:00:41 PM
User Rank
Steel
1 whole second
Is that good enough?

What's the current detection and failover time for VoLTE or even older spec voice ?

While the article doesn't explicitly state it, I expect that Doctor can handle n+1. Is that correct, or does it only do Active/Standy, ie 1+1.

Thanks for bringing this effort to light. If you hadn't pointed it out, we'd still be thinking that NFV had sub-second response times like people expect from transport networks.

50%
50%
Carlos Goncalves
Carlos Goncalves
4/18/2016 11:07:41 AM
User Rank
Author
Re: 1 whole second
Theoretically and technically, n+1 is also possible. However, the fast notification feature in Doctor provides the upper layer management a mean to switch to a standby VNF as soon as it receives such fault notification. Now, a sub-second switchover is possible if the standby is a hot-standby. The upper layer management can then just switch to the hot-standby, and provided that Doctor sends a fast enough fault notification, the switchover can be completed in sub-second order. Assuming the standby in an n+1 redundancy scheme is a common standby node and not in hot-standby, fast notification from Doctor will not guarantee a sub-second level recovery. Well, that won't be Doctor's fault though :)


100%
0%
freehe
freehe
4/26/2016 9:06:04 PM
User Rank
Platinum
Users
"Users can also expect greater functional testing scenarios coverage, and improved installation support and documentation."

As a former software tester and developer this is great to hear. New technology is great but if it is not documented there will be a lag in troubleshooting user problems. Also, you can never test too much. I always got into arguments with management asking for more time to test products but they were more concerned with pushing products to market.

 

50%
50%
dlr5288
dlr5288
4/25/2016 8:21:50 PM
User Rank
Platinum
The Cloud
Every time the cloud is involved it makes me worried. The cloud has become such a huge thing in the past couple years and it's nice to know that cloud computing is being worked on. However, whenever dealing with the cloud you're also dealing with the risk of leaking information, just because the cloud can be somewhat easy to hack in to.

50%
50%
freehe
freehe
4/26/2016 9:04:09 PM
User Rank
Platinum
Re: The Cloud
@dlr5288, I agree. Companies expect the cloud to solve all their problems and it does not.

 

50%
50%
dlr5288
dlr5288
4/27/2016 8:33:42 PM
User Rank
Platinum
Re: The Cloud
Yes, exaclty!

For me personally, it just seems like such a big liability. I also feel like companies rely on it a little too much. When the security is as shaky as it is with the cloud, I don't think it's the best idea to fully count on it. 

50%
50%
batye
batye
5/9/2016 3:02:25 AM
User Rank
Platinum
Re: The Cloud
@dlr5288  as Co.  trying to relay on it with out anything else as back up in place as seconday system - try to overlook this problem, with hope to save money... but at the end they end paying one way or other...

50%
50%


Latest Articles
Italy's 5G auction could exceed a government target of raising €2.5 billion ($2.9 billion) after attracting interest from companies outside the mobile market.
The emerging-markets operator is focusing on the humdrum business of connectivity and keeping quiet about some of its ill-fated 'digitalization' efforts.
Three UK has picked Huawei over existing radio access network suppliers Nokia and Samsung to build its 5G network.
Vendor says that it's its biggest 5G deal to date.
Verizon skates where the puck is going by waiting for standards-based 5G devices to launch its mobile service in 2019.
On-the-Air Thursdays Digital Audio
Orange has been one of the leading proponents of SDN and NFV. In this Telco Transformation radio show, Orange's John Isch provides some perspective on his company's NFV/SDN journey.
Special Huawei Video
10/16/2017
Huawei Network Transformation Seminar
The adoption of virtualization technology and cloud architectures by telecom network operators is now well underway but there is still a long way to go before the transition to an era of Network Functions Cloudification (NFC) is complete.
Video
The Small Cell Forum's CEO Sue Monahan says that small cells will be crucial for indoor 5G coverage, but challenges around business models, siting ...
People, strategy, a strong technology roadmap and new business processes are the key underpinnings of Telstra's digital transformation, COO Robyn ...
Eric Bozich, vice president of products and marketing at CenturyLink, talks about the challenges and opportunities of integrating Level 3 into ...
Epsilon's Mark Daley, director of digital strategy and business development, talks about digital transformation from a wholesale service provider ...
Bill Walker, CenturyLink's director of network architecture, shares his insights on why training isn't enough for IT employees and traditional ...
All Videos
Telco Transformation
About Us     Contact Us     Help     Register     Twitter     Facebook     RSS
Copyright © 2024 Light Reading, part of Informa Tech,
a division of Informa PLC. All rights reserved. Privacy Policy | Cookie Policy | Terms of Use
in partnership with