re: MPLS Gets the Management BluesThe FCC only has US jurisdiction. The Internet is a worldwide network. Why is it that Americans think they rule the world? Duh.
re: MPLS Gets the Management BluesThe fact is that OAM in a connectionless system is really hard to do, so it's not surprising that the IETF has essentially ignored it for so long. But MPLS changes all that except the IETF doesn't allow anything to be done with MPLS that can't be done with IP - hello!
The fact is that certain people want to apply connect-oriented OAM ideas to connectionless networks without understanding the implications or the difficulties in providing a useful end product.
The fact is that if you want to understand what happened with MPLS, you should take a look first at what happened in the ATM standards in this area. Years of effort were poured into ATM and at the end, for all the people with big ideas about fault diagnoses, all we got was a bloated mess for OAM that didn't solve the problems it was supposed to.
Part of the approach at IETF was to provide simple statistics and connectivity checking models that were obviously useful.
The problems with going beyond that have been discussed over and over again for years at IETF. And aside from a small set of people, nobody wants to re-make, change the layering of, or change the basic fundementals of IP and MPLS to solve OAM problems.
re: MPLS Gets the Management BluesI see lots of people using the word "carriers" in this discussion, but I would advise being careful about thinking that there is consensus in this area among the carriers.
Find me one carrier that does not use Sonet PM stats to generate tickets when failures happen.
What does this say about the IETF? Well, it says that one small set of people with ideas that not necessarily applicable to the majority of carriers are not going to get to set the standards for the entire industry.
What carrier does not want to automate the service provisioning process and have alarms that can segregate a network so as to pin point the failure and reduce down time?
Historically, overly complicated OAM models have ended up being implemented by everyone and used by no one anyway.
Your model would be static then? No ability to turn on/off features and no ability to supress alarms or set a threshold?
re: MPLS Gets the Management BluesPeople from BT and France Telecom have expressed the same interest to me and they are talking METRO not internet. The FCC has very little say in the internet and also only defines what carriers can do not how they do it
re: MPLS Gets the Management BluesWhat do you mean by 'propers' in the context of equipment providers vs. carriers?
Since I wasnGÇÖt discussing equipment providers vs carriers, I donGÇÖt mean anything by propers in that context.
Given that the IETF is now looking at OAM functionality might that not suggest that they were wrong the first time?
No. Maybe the IETF is just its doing due diligence to ensure what the ITU did does not conflict with what the IETF is doing or may do as the standards process is a moving target.
Were they perhaps a bit arrogant in their approach, forgetting where their bread is buttered or perhaps underestimating the resoursefulness of the carriers?
I donGÇÖt think the carriers butter the IETFGÇÖs bread. However, equipment providers are free to implement a carrierGÇÖs specific requirement if they want to. What we donGÇÖt need is for the IETF to go off half cock in how they handle this. Nor, the ITU for that matter.
In future MPLS RFPs which standard do you think will be asked for, IETF or ITU? If your company is only designing to IETF what are your odds of making the sale? Are they better or worse than if you designed to ITU? Standing in front of a PTT or an RBOC and telling them that they don't need what they say they need is an uncommon route to success. . . . If you were a carrier and asked for certain functionality in a standards body and were voted down because there are startups with the same voting power that you have, what would you do? . . . There is always the Golden Rule (He with the Gold Rules) and carriers know this extremely well. Why not let them make the major functionality decisions so everybody (ie: equipment providers) has an even playing field (on standards at least)?
-------------------------------
You ask a lot of questions Stephen! HereGÇÖs one right back at you. Why should the carriers be the ones to make the major functionality decisions? What about other IP equipment users like enterprises, small and medium size businesses, educational institutions, governments, research organizations, and non-profits?
re: MPLS Gets the Management BluesWhy should the carriers be the ones to make the major functionality decisions? What about other IP equipment users like enterprises, small and medium size businesses, educational institutions, governments, research organizations, and non-profits?
In my experience this is generally a business issue. If you, or any organization for that matter, have sufficient purchasing power to interest the standards bodies then by all means. Also, in general, the carriers are more technically inclined than the other organizations that you mention. Those other organizations will also benefit from that technical expertise and from the economies of scale of a product that is potentially popular with the carriers. As customers of those carriers, the organizations that you mention, if they banded together, would have significant market, and therefore standards (in the model that I suggested) clout.
re: MPLS Gets the Management Blues>Find me one carrier that does not use Sonet PM >stats to generate tickets when failures happen.
MPLS is not Sonet. If you want basic statistics like tunnel up/down, that doesn't require MPLS OAM.
>What carrier does not want to automate the >service provisioning process and have alarms >that can segregate a network so as to pin point >the failure and reduce down time?
What does MPLS OAM have to do with service provisioning?
As far as alarms, you have the media (sonet or whatever) state and you have the tunnel state to key off of.
The arguments for MPLS OAM, as far as I know, are mostly centered on reachability and detecting connectivity problems not associated with either the tunnel state or the media state.
But the question isn't with the goals of the people pushing these ideas, its what carriers are willing to give up to get there.
* Are you willing to adopt the architecture of one particular carrier as the preferred one for all carriers. And to change the MPLS standards to prefer that particular network model?
* Are you willing to give up PHP
* Do you want to force massive change on MPLS such as abandoning uni-directional tunnels, creating more layer-breaking coupling between IP and MPLS, or forcing IP into a more connection oriented direction?
Wasn't PHP just a hack that was bolted on to MPLS behaviour to cope with software-based edge routers that couldn't do 2 lookups per packet at wire speed?
Given that we throw routers away after 2 years on average, aren't those boxes either retired, or due for retirement now? In fact, is there even a significant installed base of those old designs? And isn't a minority of under-powered boxes threatening to hold back the majority?
If you are going to use MPLS to offer virtual private networks, then you have to have:
"the complete set of capabilities that the legacy transport mechanisms provide already. These include link protection and/or service restoration, assured QOS (i.e., Sonet/SDH and ATM), bandwidth priority (Frame Relay), and Operation and Management (OAM) capabilities"
If carriers want to use MPLS to emulate connection oriented services, then, yes, you are going to have to move IP into a more connection oriented direction. Isn't that the whole point?
Historically, overly complicated OAM models have ended up being implemented by everyone and used by no one anyway.
And historically I would have agreed with you. After all, we're talking about the ITU approach, right? But in the case of MPLS OAM the ITU approach is actually far simpler and easier to implement than the IETF approach. In fact it's so simple I'm worried it might not be effective enough. I actually prefer a lot of the ideas coming out of the IETF. But they are more complex, and they have to be implemented on LSRs as well as LERs. The ITU stuff only has to go on the LER.
The fact is that certain people want to apply
connect-oriented OAM ideas to connectionless
networks without understanding the implications
or the difficulties in providing a useful end
product.
The fact is that if you want to understand what
happened with MPLS, you should take a look first
at what happened in the ATM standards in this
area. Years of effort were poured into ATM
and at the end, for all the people with big
ideas about fault diagnoses, all we got was
a bloated mess for OAM that didn't solve the
problems it was supposed to.
Part of the approach at IETF was to provide
simple statistics and connectivity checking
models that were obviously useful.
The problems with going beyond that have been
discussed over and over again for years at IETF.
And aside from a small set of people, nobody
wants to re-make, change the layering of, or
change the basic fundementals of IP and MPLS to
solve OAM problems.
in this discussion, but I would advise being
careful about thinking that there is consensus
in this area among the carriers.
Find me one carrier that does not use Sonet PM stats to generate tickets when failures happen.
What does this say about the IETF? Well, it says
that one small set of people with ideas that
not necessarily applicable to the majority of
carriers are not going to get to set the standards
for the entire industry.
What carrier does not want to automate the service provisioning process and have alarms that can segregate a network so as to pin point the failure and reduce down time?
Historically, overly complicated OAM models have
ended up being implemented by everyone and used
by no one anyway.
Your model would be static then? No ability to turn on/off features and no ability to supress alarms or set a threshold?
Since I wasnGÇÖt discussing equipment providers vs carriers, I donGÇÖt mean anything by propers in that context.
Given that the IETF is now looking at OAM functionality might that not suggest that they were wrong the first time?
No. Maybe the IETF is just its doing due diligence to ensure what the ITU did does not conflict with what the IETF is doing or may do as the standards process is a moving target.
Were they perhaps a bit arrogant in their approach, forgetting where their bread is buttered or perhaps underestimating the resoursefulness of the carriers?
I donGÇÖt think the carriers butter the IETFGÇÖs bread. However, equipment providers are free to implement a carrierGÇÖs specific requirement if they want to. What we donGÇÖt need is for the IETF to go off half cock in how they handle this. Nor, the ITU for that matter.
In future MPLS RFPs which standard do you think will be asked for, IETF or ITU? If your company is only designing to IETF what are your odds of making the sale? Are they better or worse than if you designed to ITU? Standing in front of a PTT or an RBOC and telling them that they don't need what they say they need is an uncommon route to success.
.
.
.
If you were a carrier and asked for certain functionality in a standards body and were voted down because there are startups with the same voting power that you have, what would you do?
.
.
.
There is always the Golden Rule (He with the Gold Rules) and carriers know this extremely well. Why not let them make the major functionality decisions so everybody (ie: equipment providers) has an even playing field (on standards at least)?
-------------------------------
You ask a lot of questions Stephen! HereGÇÖs one right back at you. Why should the carriers be the ones to make the major functionality decisions? What about other IP equipment users like enterprises, small and medium size businesses, educational institutions, governments, research organizations, and non-profits?
In my experience this is generally a business issue. If you, or any organization for that matter, have sufficient purchasing power to interest the standards bodies then by all means. Also, in general, the carriers are more technically inclined than the other organizations that you mention. Those other organizations will also benefit from that technical expertise and from the economies of scale of a product that is potentially popular with the carriers. As customers of those carriers, the organizations that you mention, if they banded together, would have significant market, and therefore standards (in the model that I suggested) clout.
MPLS is not Sonet. If you want basic statistics
like tunnel up/down, that doesn't require MPLS
OAM.
>What carrier does not want to automate the >service provisioning process and have alarms >that can segregate a network so as to pin point >the failure and reduce down time?
What does MPLS OAM have to do with service
provisioning?
As far as alarms, you have the media (sonet or
whatever) state and you have the tunnel state
to key off of.
The arguments for MPLS OAM, as far as I know,
are mostly centered on reachability and
detecting connectivity problems not associated
with either the tunnel state or the media state.
But the question isn't with the goals of the
people pushing these ideas, its what carriers
are willing to give up to get there.
* Are you willing to adopt the architecture
of one particular carrier as the preferred one
for all carriers. And to change the MPLS
standards to prefer that particular network
model?
* Are you willing to give up PHP
* Do you want to force massive change on MPLS
such as abandoning uni-directional tunnels,
creating more layer-breaking coupling between
IP and MPLS, or forcing IP into a more connection
oriented direction?
* Are you willing to give up PHP
Wasn't PHP just a hack that was bolted on to MPLS behaviour to cope with software-based edge routers that couldn't do 2 lookups per packet at wire speed?
Given that we throw routers away after 2 years on average, aren't those boxes either retired, or due for retirement now? In fact, is there even a significant installed base of those old designs? And isn't a minority of under-powered boxes threatening to hold back the majority?
I'm open to persuasion on these questions.
Cheers,
Geoff
http://www.lightreading.com/do...
If you are going to use MPLS to offer virtual private networks, then you have to have:
"the complete set of capabilities that the legacy transport mechanisms provide already. These include link protection and/or service restoration, assured QOS (i.e., Sonet/SDH and ATM), bandwidth priority (Frame Relay), and Operation and Management (OAM) capabilities"
If carriers want to use MPLS to emulate connection oriented services, then, yes, you are going to have to move IP into a more connection oriented direction. Isn't that the whole point?
Historically, overly complicated OAM models have ended up being implemented by everyone and used by no one anyway.
And historically I would have agreed with you. After all, we're talking about the ITU approach, right? But in the case of MPLS OAM the ITU approach is actually far simpler and easier to implement than the IETF approach. In fact it's so simple I'm worried it might not be effective enough. I actually prefer a lot of the ideas coming out of the IETF. But they are more complex, and they have to be implemented on LSRs as well as LERs. The ITU stuff only has to go on the LER.
Cheers,
Geoff