x
Optical/IP

Sprint Spurns MPLS for Global VPNs

Sprint Corp. (NYSE: FON) doesn’t believe in MPLS, no matter what language the engineering manuals are written in.

The carrier is not only shunning the labeling protocol in its American network, but also on its growing international backbone. Sprint has quietly been expanding its IP VPN service offering in Europe and several locations in Asia for more than a year now, and it plans to make several announcements about its progress early next year.

At a time when carrier after carrier is coming out beating the MPLS drum, choosing not to use the protocol is a bold move. MPLS is considered by many to be a unifying technology with the ability to tie together separate data and ATM voice networks on the telecommunications backbone. Instead of following the herd, Sprint has elected to run its IP VPNs over a straight IP network, using a stateless protocol called L2TPv3 (which stands for Layer 2 Tunneling Protocol, version 3).

Sprint’s decision not to join the MPLS party has many industry observers scratching their heads and wondering if the move will cost the carrier customers.

"From what we’ve seen with MPLS, it’s definitely a checklist item." says Erin Dunne, an analyst with the Vertical Systems Group. However, she continues, "Sprint comes in and can usually explain their way out of it."

The checklist could pose more of a problem for Sprint now, as it attempts to gain market share in the IP VPN market outside the states. "MPLS has been adopted more readily in Europe than in the U.S.," says Infonetics Research Inc. analyst Richard Webb. "[Sprint] is going against the grain."

"I think it’s going to be more challenging," admits Barry Tishgart, Sprint’s director of data product management, talking of gaining market share in the European market. "Everything that we’ve found suggests that [the notion that MPLS is the only technology worth having] is stronger in Europe."

He insists, however, these preconceived ideas will not pose a problem to Sprint’s service offering. "We have not had a single door shut on us because of this issue," he says.

Sprint also isn't alone in believing that MPLS may not be all it's cracked up to be, particularly when it's used in very large scale carrier networks. Siemens AG (NYSE: SI; Frankfurt: SIE) is leading a study in Germany, called the KING Project, which is investigating alternatives to the protocol (see MPLS: King for a Day?).

If customers absolutely insist, Sprint says it will offer them MPLS -- from the edge of its network. The core of the Sprint network, however, will remain MPLS-free, according to Peter Lothberg, an independent technology consultant working for Sprint. "There is no network that can offer MPLS in the core at Sprint," he says, "but we can offer MPLS over the IP network."

But why not just go all the way and bring it into the core? The main issue is keeping it simple, according to Kathy Walker, senior vice president of network services in Sprint's Global Markets Group. "We think building off of our native IP network is the way to go," she says. "We want to go with simplicity." The idea, she says, is to "extend globally and make it look just like it looks domestically."

And domestically, the company has decided that MPLS just isn’t worth the bother.

Sprint has long professed its skepticism to using the protocol, insisting that rather than simplifying the network, it actually makes it more complex. Using L2TPv3 over a straight IP network, the company says it can offer all of the features available with MPLS, and then some. Among other things, Sprint says its IP VPN service allows for secure remote access, extranet capabilities, and data encryption -- none of which, it claims, are possible with MPLS.

"From the customer side, you can’t tell the difference, except that our performance is better," says Lothberg.

Since it is a new technology, MPLS is constantly changing and does have its disadvantages, says Geoff Bennett, director of Light Reading's Training Division. However, he says, a lot of the problems have begun to be rectified. "It also seems to be the direction the industry is moving in," he observes.

— Eugénie Larson, Reporter, Light Reading
teng100 12/4/2012 | 9:05:37 PM
re: Sprint Spurns MPLS for Global VPNs "Teng,

just curious since L2 and L3 VPNs are expected to bring service providers increased revenue in the next few years how do would they be implemented with an ATM only implementation?

How would the implementation support L2 tunneling of FR, Ethernet, PPP, HDLC?

How do they support VPNs without having without having to setup N*N VCs?

How would you expect to support advanced Metro Ethernet services such as VPLS?"

Only thing in the above nails down to N*N VCS,
that I have explained before.
QoS traffic you have to use the bandwith and isolated connection for each customer, New ATM
has the capability to scale the total number of the connections up as capacity/bamdwidth grows.
that is more ports more connections in the system,
they scale linearly.

teng100 12/4/2012 | 9:05:37 PM
re: Sprint Spurns MPLS for Global VPNs "Hi Teng100,
Cell tax is not a problem even at high speed..
POS and MPLS over POS has a packet queuing problem that limit trunk utlization to below 40%. That is a 60% tax which is higher than ATM cell tax.
It is just that in OC-48 and above, you do not need ATM cell to control jitter..
"

I do not know what is your conclusion????
Mark Seery 12/4/2012 | 9:05:38 PM
re: Sprint Spurns MPLS for Global VPNs Security
========

It is possible to build closed IP/MPLS networks. This is mostly an operations/architecture issue more than a technology issue

QoS
===

Common belief is that because MPLS does not define any new PHB, queuing, policing, shaping etc., it does not add anything to QoS. I believe this is an OK understanding for many data services, operating within the context of many business models. Not sure it meets all cases, but most especially transport/wholesale services. But not every one sees data protocols being used in this way, anyway.

IP Community
============

Any one brave enough to define what this is ;-) Some elements of the "IP community" are having trouble embracing some elements of the "carrier" community. This will be an interesting issue over the coming years.

Beefed up ATM
=============

Router vendors have had to support ATM for a number of reasons, for a number of years. New drivers are emerging as some carriers talk about the need for a universal edge (see LR articles on MSEs). Not sure that we can, at this stage, infer that this means MPLS interfaces on routers will have the same capabilities. Will be interesting to see if/how this all plays out.

-mark
AAL5 12/4/2012 | 9:05:38 PM
re: Sprint Spurns MPLS for Global VPNs Teng,

just curious since L2 and L3 VPNs are expected to bring service providers increased revenue in the next few years how do would they be implemented with an ATM only implementation?

How would the implementation support L2 tunneling of FR, Ethernet, PPP, HDLC?

How do they support VPNs without having without having to setup N*N VCs?

How would you expect to support advanced Metro Ethernet services such as VPLS?

Thanks,

AAL5
netskeptic 12/4/2012 | 9:05:39 PM
re: Sprint Spurns MPLS for Global VPNs > The IP community generally has the following
> set of opinions:
>
> 1) QoS isn't necessary, we just won't ever drop
> traffic. We'll overengineer our networks.

Apparently, this part of IP community never heard about WRED.

Thanks,

Netskeptic
sgan201 12/4/2012 | 9:05:39 PM
re: Sprint Spurns MPLS for Global VPNs Hi Teng100,
Cell tax is not a problem even at high speed..
POS and MPLS over POS has a packet queuing problem that limit trunk utlization to below 40%. That is a 60% tax which is higher than ATM cell tax.
It is just that in OC-48 and above, you do not need ATM cell to control jitter..
teng100 12/4/2012 | 9:05:39 PM
re: Sprint Spurns MPLS for Global VPNs "It is a business. Do what make money and make sense.. IP over ATM is a good choice for link of OC12/OC-3 and below. Do IP over MPLS or POS native for link greater than OC-12."

Even you have to argue the cell tax is not good
for high speed, The new ATM can also do frame interface in high speed, why need IP/MPLS?????
Tony Li 12/4/2012 | 9:05:40 PM
re: Sprint Spurns MPLS for Global VPNs How many good ISPs are actually making money??

------------------

That also depends on your definition of 'good'. ;-)

------------------

IP over ATM is a good choice for link of OC12/OC-3 and below. Do IP over MPLS or POS native for link greater than OC-12.

------------------

The number of facilities based providers that are using OC-12 in their backbones today is not huge. Most are on OC-48 and OC-192 already. The folks who are not facilities based are more likely to be at OC-12 and are most likely looking for the cheapest bandwidth that they can get. Sometimes this might be leasing dark fiber, sometimes it may be on someone else's ATM service. I don't think you can make a broad generalization here.

--------------------------

How many router vendors had recently release new ATM I/O modules for their router. Action speak loader than words..

--------------------------

I think you should be careful about the conclusions that are drawn from this. You can pretty safely draw the conclusion that the vendors feel that they can make money by doing this. You can pretty safely assume that someone is paying for ATM interfaces. There are a number of legacy ATM networks out there that are continuing to grow. I don't believe that you've presented the data that would allow us to conclude that they feel that ATM is the one true way.

--------------------------

This is one of the major problem with MPLS. It does not fit anywhere in the network.

---------------------------

Like I was trying to say: MPLS is not a QoS solution. Its benefits are for VPNs and TE. It _has_ QoS hooks, but they are a subset of what's available for DiffServ.

Tony
Tony Li 12/4/2012 | 9:05:40 PM
re: Sprint Spurns MPLS for Global VPNs
A friend of mine likes to point out that the only system that is fully secure is one that moves no bits. Most ISPs don't want that. Their customers certainly don't.

The cost of the ATM switch is not the issue. ISPs must have routers. The question is whether the routers are directly connected or whether they connect to ATM switches. Direct connection may be cheaper. A lot of it depends on whether the provider is facilities based and what they use for a transport network.

One thing I think that we can agree on tho: rational ISPs will only deploy ATM or MPLS if they have a clear business case associated with it.

Tony
Tony Li 12/4/2012 | 9:05:41 PM
re: Sprint Spurns MPLS for Global VPNs IP community with MPLS had pretty much agreed with ATM folks that the only way to deliver QOS is via connection. If you follow this argument, the correct comparison should be IP over ATM versus IP over MPLS. Which one is more scalable and deliver better QOS for IP??

However, if you assume IP should never have QOS, then you do not need either MPLS or ATM.

----------------------------------

I think that the IP community would violently disagree with this. The IP community generally has the following set of opinions:

1) QoS isn't necessary, we just won't ever drop traffic. We'll overengineer our networks.
2) You only need QoS for certain applications and DiffServ suffices. MPLS is not necessary for QoS reasons. [There may be other reasons, but QoS is NOT one of them.]

In any case, there is pretty clear consensus in the IP community that they don't like ATM. Some have deployed it out of necessity, but none of them are enamored with it and even those who have deployed it would be happy with a simpler alternative.

Tony

sgan201 12/4/2012 | 9:05:41 PM
re: Sprint Spurns MPLS for Global VPNs Hi Tony Li,
How many good ISPs are actually making money??
Genuity -> chapter 11
PSINet --> Ditto
UUNet --> hidden under WCOM balance sheet..
AOL --> Advertising contribute 50% of the revenue. With the drop of advertising revenue, not making much money either..

Equant -> The IP is running over FR and ATM access network..

It is a business. Do what make money and make sense.. IP over ATM is a good choice for link of OC12/OC-3 and below. Do IP over MPLS or POS native for link greater than OC-12.

If this is not the truth why both Cisco and Juniper are releasing new ATM interface with real ATM Traffic Management for their routers. Ditto for Riverstone. How many router vendors had recently release new ATM I/O modules for their router. Action speak loader than words..

Fundamentally, I do not disagree with you that only DiffServe is required if you have a backbone with a lot of bandwidth. In fact, you can send each class of traffic on a separate wavelength if you own the fiber. The issue come when you have OC-12/Oc-3 or less bandwidth.

This is one of the major problem with MPLS. It does not fit anywhere in the network.
A) If you do not have enough bandwidth (OC-12 or less), you need to run IP over ATM or IP over MPLS over ATM. If so, why not only do IP over ATM and do not add the MPLS overhead.

B) If you have OC-48 and above, you can do DiffServe and IP over POS native and it will be fine. You do not need the complexity of MPLS.
teng100 12/4/2012 | 9:05:41 PM
re: Sprint Spurns MPLS for Global VPNs You will need absolute security, QoS, then it will be based on the price and easy management for making the choice. Do whatever you think is right, but end of day, customer will tell you who is right. and New ATM switch will be much cheaper
then Router, I guarantee you.
teng100 12/4/2012 | 9:05:41 PM
re: Sprint Spurns MPLS for Global VPNs "I think that the IP community would violently disagree with this. The IP community generally has the following set of opinions:

1) QoS isn't necessary, we just won't ever drop traffic. We'll overengineer our networks.
2) You only need QoS for certain applications and DiffServ suffices. MPLS is not necessary for QoS reasons. [There may be other reasons, but QoS is NOT one of them.]

In any case, there is pretty clear consensus in the IP community that they don't like ATM. Some have deployed it out of necessity, but none of them are enamored with it and even those who have deployed it would be happy with a simpler alternative."

You will need absolute security, QoS, then it will be based on the price and easy management for making the choice. Do whatever you think is right, but end of day, customer will tell you who is right.





teng100 12/4/2012 | 9:05:42 PM
re: Sprint Spurns MPLS for Global VPNs dreamer101,
"The question is do SP need to sell IP with QOS in order to survive?? IP with best effort and connectionless had been proven as a disaster as far as business model is concerned. All the ISPs are not making money.

IP community with MPLS had pretty much agreed with ATM folks that the only way to deliver QOS is via connection. If you follow this argument, the correct comparison should be IP over ATM versus IP over MPLS. Which one is more scalable and deliver better QOS for IP??

However, if you assume IP should never have QOS, then you do not need either MPLS or ATM.."


That is you need a backbone that can sell QoS while use the rest of the bandwidth for IP internet traffic.
But Security in ATM is proven, MPLS is not.


teng100 12/4/2012 | 9:05:42 PM
re: Sprint Spurns MPLS for Global VPNs beowulf888:

It is a standard inside you will find
Hierarchical PNNI description.
sgan201 12/4/2012 | 9:05:42 PM
re: Sprint Spurns MPLS for Global VPNs Hi beowulf and teng100,
The question is do SP need to sell IP with QOS in order to survive?? IP with best effort and connectionless had been proven as a disaster as far as business model is concerned. All the ISPs are not making money.

IP community with MPLS had pretty much agreed with ATM folks that the only way to deliver QOS is via connection. If you follow this argument, the correct comparison should be IP over ATM versus IP over MPLS. Which one is more scalable and deliver better QOS for IP??

However, if you assume IP should never have QOS, then you do not need either MPLS or ATM..
beowulf888 12/4/2012 | 9:05:43 PM
re: Sprint Spurns MPLS for Global VPNs teng:
Thanks for the URL! I was searching for H-PNNI not AF-PNNI.

HNY!
--Beo

teng100 in msg 192 wrote:
I hope we can talk after you have some
reading done, plaese check this out.

ftp://ftp.atmforum.com/pub/app...


teng100 12/4/2012 | 9:05:44 PM
re: Sprint Spurns MPLS for Global VPNs beowulf888:

I hope we can talk after you have some
reading done, plaese check this out.

ftp://ftp.atmforum.com/pub/app...
beowulf888 12/4/2012 | 9:05:46 PM
re: Sprint Spurns MPLS for Global VPNs Teng:
Sorry, I'm afraid your ATM-is-the-future talk is nothing but dream-ware (no offense to dreamer101 intended). And it's OK to dream the impossible dream. But making dreams a reality is another matter. Here is what I believe/know:

1. The scalability of routing protocol has very little to do with the size of the address space. Yes, at some point every routing protocol will choke if the number of route prefixes (i.e. the "visible" address space) gets too large. And you need a large enough address space to build a really big netowrk. But the size of the protocol's address space does not -- repeat does not -- determine the scalability of a routing protocol. A perfect example is link state protocols like IS-IS and OSPF vs. a path vector protocol like BGP. All three can be used to route IP, but they have very different scalabilities. 'nuf said.

2. H-PNNI still looks like a link state protocol to me (even though it's hierarchical). But I haven't been able to find the specs for it on the ATM Forum pages, so I won't go out on a limb and say that it doesn't have some bells and whistles that will let it scale beyond a standard link-state protocol. However, I very much doubt if you're going to network every computer and coke machine in the world using ATM and H-PNNI (let alone every light bulb ;-).

3. Even if H-PNNI is scalable as you believe, you'll still need to translate those pesky "legacy" IP services into ATM -- either that or run IP over ATM -- if only make sure everybody can use your ATM mother-of-all-networks. Perfect example is DNS. Oh, I know the ENUM people want to translate all those hard to remember URLs (like atmforum.org) into easy to remember phone numbers (like 1.314.447.2537). But all the services of IP is what makes IP so usable (and scalable).

4. Finally, I haven't heard of any inter-SP ATM networks (but I'm willing to be corrected if you can provide me with an example). And why not? Because from a practical standpoint, (A) IP is cheaper and easier to internetwork, and (B) it's a defacto standard for internetworking (and a very flexible and open standard, at that thankyouverymuch).

In conclusion I got sucked into the ATM-Is-the-Future and the Internet-Is-a-Toy marketing hoopla back in '93, and I refuse be sucked into a revival of that crap again. Go pray in the church of ATM, but don't expect us IPers to nod our heads and say amen when you come prosletizing.

Please don't take my post as a personal attack on you. ATM has a place, and it will be around for many years to come. But you've offered me no convincing arguments that it is The Future of Networking.

best regards and HNY,
--Beo

Teng100 (msg 190) wrote:
>Routing scalability for a particular
>network relates to its addressing
>hierarchical or not, and out of band
>control is nothing to do with the
>routing scalability, it will take
>some form of an UNI interface for
>the user who needs to access the
>network, otherwise mixing with too
>many protocols which allow non-UNI
>access will not have security."



teng100 12/4/2012 | 9:06:00 PM
re: Sprint Spurns MPLS for Global VPNs dream101:

"My point is since you need something out of band to do signalling and notification to the application, you could use this for routing the connection. Hence, it is irrelevant whether MPLS or ATM routing is scalable"

Dreamer101,

Routing scalability for a particular network
relates to its addressing hierarchical or not,
and out of band control is nothing to do with
the routing scalability, it will take some form
of an UNI interface for the user who needs to
access the network, otherwise mixing with too
many protocols which allow non-UNI access will
not have security.


netskeptic 12/4/2012 | 9:06:01 PM
re: Sprint Spurns MPLS for Global VPNs > I can see Michael Powell laughing all the way
> into a CEO job with SBC or Verizon when the
> current administration is booted out of office.

This is how things should be done, e.g. W.Daley already landed at SBC and nobody had any problems with that, so there will be no problems with M.Powell either.

Again, if have to choose between monopolistic ILECs with pump-and-dump CLECs, I would choose ILECs.


Thanks,

Netskeptic
sgan201 12/4/2012 | 9:06:03 PM
re: Sprint Spurns MPLS for Global VPNs Hi beowulf888,
My point is since you need something out of band to do signalling and notification to the application, you could use this for routing the connection. Hence, it is irrelevant whether MPLS or ATM routing is scalable.. In fact, you could use this out of band thing to route a connection from MPLS to ATM to Sonet to DWDWM to TDM or whatever.. You might run PVC and static LSP throughout your network. Or you could do a hyrid, the out of band thing do inter-domain routing and within domain you do MPLS or ATM or G-MPLS..
willywilson 12/4/2012 | 9:06:04 PM
re: Sprint Spurns MPLS for Global VPNs I can see Michael Powell laughing all the way into a CEO job with SBC or Verizon when the current administration is booted out of office.

------

It's widely believed that Powell wants to run for a U.S. Senate seat from Virginia. He will need political allies and money. 'Nuff said?
sgan201 12/4/2012 | 9:06:04 PM
re: Sprint Spurns MPLS for Global VPNs Hi Teng100,
I would have to argue with you on this..
Technically to be accurate, ATM has 20 bytes of address. VPI/VCI is not the total ATM address. It is not used globally for routing.
To do an apple to apple comparison, you should say IPV4 has 32 bit address and ATM has 20 byte = 20 X 8 = 160 bits of address. For SVC calls, normally 19 bytes is used to refer to an ATM interface and you can specified VPI and VCI in that interface.. So total ATM address is 19 bytes plus VPI and VCI..

Now, with 19 bytes and H-PNNI supporting N-level address aggregation, only IPV6 with 128 bit of address can try to match the ATM addressing scalability..

ATM addressing is designed to be able to support every single phone number on the planet..


teng100 12/4/2012 | 9:06:04 PM
re: Sprint Spurns MPLS for Global VPNs dreamer said:
"Hi Teng100,
I would have to argue with you on this..
Technically to be accurate, ATM has 20 bytes of address. VPI/VCI is not the total ATM address. It is not used globally for routing.
To do an apple to apple comparison, you should say IPV4 has 32 bit address and ATM has 20 byte = 20 X 8 = 160 bits of address. For SVC calls, normally 19 bytes is used to refer to an ATM interface and you can specified VPI and VCI in that interface.. So total ATM address is 19 bytes plus VPI and VCI..

Now, with 19 bytes and H-PNNI supporting N-level address aggregation, only IPV6 with 128 bit of address can try to match the ATM addressing scalability..

ATM addressing is designed to be able to support every single phone number on the planet.."

I was using VPI/VCI to elaborate the possible path
to any IP destination even we we have to consider
using a single interface to send out the IP traffic to the core, of cource, we could use many
outgoing interfaces as well.
VPI/VCI is different than the ATM address since
we are not putting 20 bytes address in the actual data packet for the switching since ATM is connection oriented.
teng100 12/4/2012 | 9:06:05 PM
re: Sprint Spurns MPLS for Global VPNs beowulf888 wrote:
"
Teng:
I asked you this on another thread (and you probably haven't had time to respond), but for the benefit all who are lurking on this thread...

How do propose to scale this massive ATM network? PNNI? AINI? These are link state protocols. There's only so far you can scale them."

++++++++

There are two major applications which can be deliverd by ATM network, one is using PVC for connecting all the IP sebnets for internet related traffic and the others are End to End QoS traffic such as VPN (which might as well use IP address), Voice and other similar applications.

The PVC is the one that most of the so called "scalabilty issue of N2" comes from,
and of course old ATM was designed with limitations in total connections in this PVC support, hence has the issue.

The Key is in Hardware not in Software,
The HPNNI (Hierarchical PNNI) can do the job to aggragate the addresses so that it will be scalable.

The Hardware/Platform will need to have VP trucking and some merging capability for the best effort traffic at the Edge to make this possible.
since we now have 28 bits in the VPI/VCI space
and IP has 32bit, through some merging, it will be resonable to achieve this.


beowulf888 12/4/2012 | 9:06:05 PM
re: Sprint Spurns MPLS for Global VPNs dreamer:
I guess I've lost track of all the different sub-threads in this thread. But I'll try to respond to your response to something I must have posted but forget what it was.

dreamer101 (msg 161) wrote:
"1) Who say you cannot use SIP to setup a data call, Video on demand calls or whatever?? Why it must be voice?? MSF provide an architecture to separate signalling, control, data plane.. If you do the separation properly, you can let any kind of application to request any kind of connection to an MSF switch.."

I think my point was that the MSF guidelines are discussing voice systems. They don't really address MPLS issues, though. If I mispoke, I apologize. Disclaimer: I agree SIP is great. It's a heck of lot more flexible than H.323. I hope that SIP catches on. SIP builds strong VoIP networks twelve ways... ugghhh I'm getting punchy.

"2) Item 4 is billing and notification to the application. Please provide an example where it is in-band?? I cannot think of one.. Most is out of band for obvious reason.."

Agreed. But how does this apply to MPLS?

HNY,
--Beo
beowulf888 12/4/2012 | 9:06:06 PM
re: Sprint Spurns MPLS for Global VPNs Teng:
I asked you this on another thread (and you probably haven't had time to respond), but for the benefit all who are lurking on this thread...

How do propose to scale this massive ATM network? PNNI? AINI? These are link state protocols. There's only so far you can scale them.

TIA and HNY*
--Beo

*Happy New Year in TLA ;-)

Teng101 (msg 175) wrote:
"ATM VPI/VCI is big enough to scale to connect all
the networking and users together. Do not confuse
the Local Significance Channel number with the Total meshing connections needed within a network, that will be aligned to whatever the bandwidth you might have in this particular netwok."
beowulf888 12/4/2012 | 9:06:06 PM
re: Sprint Spurns MPLS for Global VPNs Willy:
I love your cynicism. No, wait, I shouldn't say cynicism. Because cynicism sounds like I'm dissing you, and I'm not. But your post was just *so* accurate that I had to laugh!

willywilson wrote (msg 166)
"Once the Broadband NPRM is approved by the corrupt FCC, and the RBOC monopolies are restored, there will indeed be a VoIP tsunami. It will appear in the form of press releases depicting the circuit network as a packet network, because only by doing this will the RBOCs be able to deny competitive access."

I can see Michael Powell laughing all the way into a CEO job with SBC or Verizon when the current administration is booted out of office.

--Beo
beowulf888 12/4/2012 | 9:06:06 PM
re: Sprint Spurns MPLS for Global VPNs In msg 162, Aleksy (netskeptic) wrote:
"No, I am simply saying that L3 would die under its own weight without a help of redundant/reliable L2 connections spanning the core."

Thanks for the clarification. I went back and re-read your posts, and I understand your arguments better now. I *do* agree with you that reliable L2 connections are highly important to keeping L3 protocols happy. I might not agree with you on some other things -- but never mind. Have a happy and prosperous new year!

--Beo



Mark Seery 12/4/2012 | 9:06:07 PM
re: Sprint Spurns MPLS for Global VPNs >> ATM already has two levels by using VP trucking. <<

Not enough for some people, your mileage may vary...
teng100 12/4/2012 | 9:06:08 PM
re: Sprint Spurns MPLS for Global VPNs "the many levels of stacking provided by MPLS is greater than what is offered by ATM. Whether that level of stacking is useful/needed is of course debatable. Some network architects clearly view that is, many do not.

not just a case of a big enough address space to cover number of users, but enough levels of stacking to create the architectural alternatives that some desire. with enough levels of stacking in use, then scalability benefits could be claimed as well."

ATM already has two levels by using VP trucking.
Mark Seery 12/4/2012 | 9:06:09 PM
re: Sprint Spurns MPLS for Global VPNs >> ATM VPI/VCI is big enough to scale to connect all the networking and users together <<

the many levels of stacking provided by MPLS is greater than what is offered by ATM. Whether that level of stacking is useful/needed is of course debatable. Some network architects clearly view that is, many do not.

not just a case of a big enough address space to cover number of users, but enough levels of stacking to create the architectural alternatives that some desire. with enough levels of stacking in use, then scalability benefits could be claimed as well.

-mark
Mark Seery 12/4/2012 | 9:06:10 PM
re: Sprint Spurns MPLS for Global VPNs >> yes, they have different control planes. <<

In the BGP case, that the same code and protocol are used for two different control planes is interesting (good/bad depending on point of view) as noted previously.

-mark
teng100 12/4/2012 | 9:06:14 PM
re: Sprint Spurns MPLS for Global VPNs "Estabilishing PE to PE reachability and setting up per-service connectivity are different tasks. By using different control planes (the former visible to the core, and the latter only at the edge), and by using a label stack in the forwarding plane (where the "service" label is unseen by the core), we get better scalability than with ATM VCs (he says, ducking)."

ATM VPI/VCI is big enough to scale to connect all
the networking and users together. Do not confuse
the Local Significance Channel number with the Total meshing connections needed within a network, that will be aligned to whatever the bandwidth you might have in this particular netwok.
giles0 12/4/2012 | 9:06:15 PM
re: Sprint Spurns MPLS for Global VPNs ------
>> neither control plane concerns itself with interior topology or PE reachability. <<

But some control plane does. So either they share/leverage elements of a different control plane, or we might conclude that the service layer and transport layers have different control planes?
------

yes, they have different control planes.

Estabilishing PE to PE reachability and setting up per-service connectivity are different tasks. By using different control planes (the former visible to the core, and the latter only at the edge), and by using a label stack in the forwarding plane (where the "service" label is unseen by the core), we get better scalability than with ATM VCs (he says, ducking).
teng100 12/4/2012 | 9:06:19 PM
re: Sprint Spurns MPLS for Global VPNs > ABR can be turn on as you wish.

I am wondering how one could benefit from turning on patently non-working feature ?

Thanks,

Netskeptic
++++++++++++++++

Who owns this non-working patent?
I am following the ATM ABR standard.
Thanks.


netskeptic 12/4/2012 | 9:06:20 PM
re: Sprint Spurns MPLS for Global VPNs > ABR can be turn on as you wish.

I am wondering how one could benefit from turning on patently non-working feature ?

Thanks,

Netskeptic

teng100 12/4/2012 | 9:06:21 PM
re: Sprint Spurns MPLS for Global VPNs Netskeptic wrote:
"First about ATM, it is far from dead, however, it is not going to explode either, because of its evident short-comings: no built-in redundancy, ridiculous cell size and no ABR. But it seem inevitable to me that some other L2 technology will emerge. "

The New breed of ATM equipment coming soon will have all the solutions for you, namely:

1. Security from top to bottom, edge to core.
2. Enable IP network to transparently communicate
through the ATM backbone facilitating easier
management, while open to any applications
that require End-to-End QoS.
3. VPI/VCI space fully used to scale the
connections and simplify the core.
4. High speed and Terabit capacity.
5. Cell or Frame as you wish.
6. ABR can be turn on as you wish.
7. Redundancy will be supported so no single point
of failure in terms of HW and SW.
8. ATM is a very well defined and proven standard
unlike IP. No ambiguities in ATM standards.

9. Merging the best effort and .....

wait and see.



netskeptic 12/4/2012 | 9:06:30 PM
re: Sprint Spurns MPLS for Global VPNs
First about ATM, it is far from dead, however, it is not going to explode either, because of its evident short-comings: no built-in redundancy, ridiculous cell size and no ABR. But it seem inevitable to me that some other L2 technology will emerge.

> Feel free to dispute these article, accuse the
> author of lying, or the CTO of being stupid.

I wondering what was these people's opinion in the mid 90s aboue rate-based flow control, I would not be surprised to find that they were as enthusiastic about it (if they are old enough to participate).

> I don't care. The IP tsunami is coming, you got
> your life raft?

Currently the Internet is a tiny network with less than 100K routes in DFZ, but the number of engineers who know how to write a scalable implementation of a routing protocol is already limited to 10-20 in the whole world.

Now, we will get this IP tsunami, Internet will explode and the number of engineers who know how to write a scalabale implementation of a routing protocol will pretty rapidly go to 0.

Thanks,

Netskeptic
teng100 12/4/2012 | 9:06:31 PM
re: Sprint Spurns MPLS for Global VPNs You think VOIP can do the job in terms of
Security and the Scalability to cover all the access side, So, I guess you will use IPv6 by then.

-------

How dense can you be? I am not a believer in VoIP. Do you have reading comprehension issues? Maybe English is your seventh language? Sheesh!

-------

Your opinion now is well taken,
but at least give me another chance to read before going very mad...

(and Yes, I will try to improve my English in the
mean time)

Thanks.
willywilson 12/4/2012 | 9:06:31 PM
re: Sprint Spurns MPLS for Global VPNs You think VOIP can do the job in terms of
Security and the Scalability to cover all the access side, So, I guess you will use IPv6 by then.

-------

How dense can you be? I am not a believer in VoIP. Do you have reading comprehension issues? Maybe English is your seventh language? Sheesh!
teng100 12/4/2012 | 9:06:31 PM
re: Sprint Spurns MPLS for Global VPNs "Once the Broadband NPRM is approved by the corrupt FCC, and the RBOC monopolies are restored, there will indeed be a VoIP tsunami. It will appear in the form of press releases depicting the circuit network as a packet network, because only by doing this will the RBOCs be able to deny competitive access."

You think VOIP can do the job in terms of
Security and the Scalability to cover all the access side, So, I guess you will use IPv6 by then.



teng100 12/4/2012 | 9:06:32 PM
re: Sprint Spurns MPLS for Global VPNs Firewall is only a temp solution since
firewall can not do anything but tell you
"YOUR ARE UNDER ATTCKING NOW, DO SOMETHING ABOUT IT" and then you can not find out who did it
waching all kinds of IP source address with the same destination IP address and all your communications get affected any way.

We need to plan a viable solution before it is too
late.
willywilson 12/4/2012 | 9:06:32 PM
re: Sprint Spurns MPLS for Global VPNs The IP tsunami is coming, you got your life raft?

-------

Once the Broadband NPRM is approved by the corrupt FCC, and the RBOC monopolies are restored, there will indeed be a VoIP tsunami. It will appear in the form of press releases depicting the circuit network as a packet network, because only by doing this will the RBOCs be able to deny competitive access.

The reality will be PCM tunneling through the lower frequencies of whatever DSL line code is chosen. The PCM will be separated at the CO (or maybe even the remote), and off loaded to the Class 5. This will be called "VoIP" and "convergence," and the press will go along with it because they're too dumb to know otherwise.
Packet Man 12/4/2012 | 9:06:33 PM
re: Sprint Spurns MPLS for Global VPNs Hi netskeptic:

http://www.riverstonenet.com/s...

http://www.tfi.com/pubs/2015.p...

http://www.newworldtel.com/2pr...

http://www.convergedigest.com/...

Feel free to dispute these article, accuse the author of lying, or the CTO of being stupid. I don't care. The IP tsunami is coming, you got your life raft?

PM
teng100 12/4/2012 | 9:06:33 PM
re: Sprint Spurns MPLS for Global VPNs
ATM will be alive and be strengthen soon
in the future and will see IP
stay in subnet/stub area, IP should not be in
the backbone since it is one of the application
to the backbone. The only companies that want
to see IP in the backbone are security
vendors....firewall makers....big router
company...not users need security from top to
bottom.
netskeptic 12/4/2012 | 9:06:37 PM
re: Sprint Spurns MPLS for Global VPNs > Are you saying that Layer 2 protocols are more
> scalable than L3 protocols?!? Could you explain
> why?

No, I am simply saying that L3 would die under its own weight without a help of redundant/reliable L2 connections spanning the core.


Thanks,

Netskeptic

sgan201 12/4/2012 | 9:06:38 PM
re: Sprint Spurns MPLS for Global VPNs Hi beowulf888,

1) Who say you cannot use SIP to setup a data call, Video on demand calls or whatever?? Why it must be voice?? MSF provide an architecture to separate signalling, control, data plane.. If you do the separation properly, you can let any kind of application to request any kind of connection to an MSF switch..

2) Item 4 is billing and notification to the application. Please provide an example where it is in-band?? I cannot think of one.. Most is out of band for obvious reason..
beowulf888 12/4/2012 | 9:06:40 PM
re: Sprint Spurns MPLS for Global VPNs Aleksey:
Are you saying that Layer 2 protocols are more scalable than L3 protocols?!? Could you explain why?

Thanks!
--Beo

netskeptic wrote:
"I expect that it will be a FEW orders of magnitude more decentralized than current Internet, but it will be MANY orders of magnitude more centralized than flat networks you are using as a strawman. Say, if we will have core with 16M routes (out 4G possible), it will be roughly 2 orders of magnitude more decentralized than the current internet, but it will be about roughly 2.5 orders of magnitude more centralized than flat network."

"However, I have very little doubt that this moderately decentralized core will be beyond the reach for routing protocols to handle L1 topologfy changes, hence the necessity of reliable L2 layer."

beowulf888 12/4/2012 | 9:06:40 PM
re: Sprint Spurns MPLS for Global VPNs Dreamer:
I've always respected the way you state your case although I might not always agree with your opinions. But in this case I need call you on a point...

you wrote:
"All 4 could be either logically or physically separated. But, unless you have unlimited bandwidth and you want to do anything more than best effort, you need item number 4. Item number 4 is always out of band like SS7 or ISDN D-channel to avoid DDOS attack."

Well, the MSForum guidelines apply to voice architectures -- not MPLS architectures. So it's not document that discusses MPLS signaling. Likewise, version 1 of their guidelines definitely does not express an opinion on out-of-band (voice) signaling one way or the other.

So, you have a perfect right to your opinion, but please don't insist that your opinion is based on the gospel as promulgated by the MSForum.

See...
http://www.msforum.org/techinf...

best regards,
--Beo
teng100 12/4/2012 | 9:06:44 PM
re: Sprint Spurns MPLS for Global VPNs Hi rtg_dude,

"Given this, martini-style VPNs are extremely
similar to those based on ATM or FR (and IMHO are
much healthier for the network), and 2547 ones
are extremely close to "gluing" the control
planes together."

However, there will be a security concern
if martini-style VPNs use any part of the network that are open to the DoS attacking,
and FR/ATM will be much more secured.
teng100 12/4/2012 | 9:06:47 PM
re: Sprint Spurns MPLS for Global VPNs Hi Mark,

"I can only assume I am missing something here. IP, ATM, and traditional voice networks all have a way of aggregating around some hierarchy. LNP complicates things I guess, but at least then you are going to some huge database (appropriately dimensioned) that (thankfully) is not present on each switch/router. Perhaps you could explain in more detail the scenario which you believe requires the control plane to carry information about every end user / application address."

I am not saying have to carry information about every end user / application address, but it can open such application to a user who happen to use
this native backbone address extention.
Mark Seery 12/4/2012 | 9:06:47 PM
re: Sprint Spurns MPLS for Global VPNs Hi Teng100,

>> In case you are talking about linking IP sebnet only. How about end to end voice call or any other
Non IP applications. <<

I can only assume I am missing something here. IP, ATM, and traditional voice networks all have a way of aggregating around some hierarchy. LNP complicates things I guess, but at least then you are going to some huge database (appropriately dimensioned) that (thankfully) is not present on each switch/router. Perhaps you could explain in more detail the scenario which you believe requires the control plane to carry information about every end user / application address.

Thanks,
Mark
teng100 12/4/2012 | 9:06:49 PM
re: Sprint Spurns MPLS for Global VPNs "Perhaps we're confusing things here. This isn't about topology, it's about addressing. Specifically, if you have a core without topology changes, but you have to inject routing (address) information that does not aggregate, then you force your IGP to carry information that is linear in the number of systems that you support. This eventually breaks down."

So, we need a core/backbone that have stable hierarchical address bigger enough to cover all
the user applications and down to each user eventually.
teng100 12/4/2012 | 9:06:49 PM
re: Sprint Spurns MPLS for Global VPNs "big enough to cover all the aggregated network (prefixes) not addresses. Even assuming the Internet is unable to get better at aggregating (networks), we are still talking networks and not addresses (uses and applications)."

In case you are talking about linking IP sebnet only. How about end to end voice call or any other
Non IP applications.

Mark Seery 12/4/2012 | 9:06:49 PM
re: Sprint Spurns MPLS for Global VPNs >> So, we need a core/backbone that have stable hierarchical address bigger enough to cover all
the user applications and down to each user eventually. <<

big enough to cover all the aggregated network (prefixes) not addresses. Even assuming the Internet is unable to get better at aggregating (networks), we are still talking networks and not addresses (uses and applications).

-mark
teng100 12/4/2012 | 9:06:51 PM
re: Sprint Spurns MPLS for Global VPNs dreamer101:

Now I understand what you are trying to say,
However, I am trying to say is that the
backbone should be isolated from
the applications so that the backbone and
users both will be secured.

And this security issue is not exactly the
issue regarding the bandwidth issue you are
talking about, although, it may have similar
approach in some way.

as softswitch for VOIP, you have to make
sure that VOIP control protocols and any
devices doing that will not be subjected to
DoS attacking.



netskeptic 12/4/2012 | 9:06:53 PM
re: Sprint Spurns MPLS for Global VPNs > The "core" of the Internet today is quite
> large ...

It seems to that this is the root of reasoning tree which leads me to a different conclusions from practically everybody else in this discussion. IMHO, if we are making comparisions with the grand unified network of the future, the core of today Intenet should be considered tiny.

> Just decentralizing without any aggregation
> gives you a flat L2 network, which doesn't
> scale well for L2 or L3

Look, I am talking about decentralization of the core only, so there still be substantial aggregation of periferal addresses. I expect that it will be a FEW orders of magnitude more decentralized than current Internet, but it will be MANY orders of magnitude more centralized than flat networks you are using as a strawman. Say, if we will have core with 16M routes (out 4G possible), it will be roughly 2 orders of magnitude more decentralized than the current internet, but it will be about roughly 2.5 orders of magnitude more centralized than flat network.


However, I have very little doubt that this moderately decentralized core will be beyond the reach for routing protocols to handle L1 topologfy changes, hence the necessity of reliable L2 layer.

> Perhaps we're confusing things here. This isn't
> about topology, it's about addressing.
> Specifically, if you have a core without
> topology changes, but you have to inject
> routing > (address) information that does not
> aggregate, then you force your IGP to carry
> information that is linear in the number of
> systems that you support. This eventually
> breaks down.

It is true for flat L2 network, however, I was not talking about it. I was talking that the level of aggregation sufficient for current routing protocols to work effectively is not going to be practically achievable in the nearest future.

Thanks,

Aleksey

sgan201 12/4/2012 | 9:06:54 PM
re: Sprint Spurns MPLS for Global VPNs Hi teng100,
1) You have a data path that forward packet..

2) You have a control/routing layer that update routing table for both connection oriented and connectionless table

3) You have a signalling layer that allow a switch to setup connections between themselves

4) You have a signalling layer that allow application to request service from the switch - SIP, H.248, Megaco. This layer also interface with billing..

All 4 could be either logically or physically separated. But, unless you have unlimited bandwidth and you want to do anything more than best effort, you need item number 4. Item number 4 is always out of band like SS7 or ISDN D-channel to avoid DDOS attack.
You should look at the work done by MSF Forum.
http://www.msforum.org/
Tony Li 12/4/2012 | 9:06:56 PM
re: Sprint Spurns MPLS for Global VPNs Pardon my ignorance Tony but I noticed a few posts about you being "theee" Tony Li. I suspect you are probably some genius that works for one of the bigger router/switch vendors but I really don't know. Can ya throw me a bone?
--------------------

Ok, but no meat.

http://www.procket.com/comp_le...

Tony
Tony Li 12/4/2012 | 9:06:56 PM
re: Sprint Spurns MPLS for Global VPNs > If there is aggregation, then a hierarchical
> link state protocol will work just fine.

If you need aggregation you have to keep the core very small/centralized and hence it has to be super-fast/super-expensive and it would not scale up well anyway. I would even say that a normal path of technological evolution is decentralization, decentralization,, decentralization. It may happen that global networking technology would buck this trend, but I doubt it.

----------------------

You're assuming that the core needs to be "very small". This is not the case. The "core" of the Internet today is quite large. Admittedly it's patched together with more than link state protocols, but those techniques could be applied intra-domain as well.

Just decentralizing without any aggregation gives you a flat L2 network, which doesn't scale well for L2 or L3.

-------------------

> If there is no aggregation, then you will
> eventually overburden your intra-domain
> protocol.

If there are practically no changes in the core topology it would not happen.

------------------

Perhaps we're confusing things here. This isn't about topology, it's about addressing. Specifically, if you have a core without topology changes, but you have to inject routing (address) information that does not aggregate, then you force your IGP to carry information that is linear in the number of systems that you support. This eventually breaks down.

Tony



> If there is no aggregation, then you will
> eventually overburden your intra-domain
> protocol.

If there are practically no changes in the core topology it would not happen.
sgan201 12/4/2012 | 9:06:59 PM
re: Sprint Spurns MPLS for Global VPNs Hi teng100,
Either case, you still need an out of band method to tell/reject application that the limit had been reached aka busy signal..
teng100 12/4/2012 | 9:06:59 PM
re: Sprint Spurns MPLS for Global VPNs "Hi teng100,
Either case, you still need an out of band method to tell/reject application that the limit had been reached aka busy signal.."

are you saying separate the data path and control path into two physical wires? or logically separated within a wire?
teng100 12/4/2012 | 9:07:00 PM
re: Sprint Spurns MPLS for Global VPNs "Hi Teng100,
If you provide enough bandwidth for maximum number of connection, you waste so much bandwidth that you go into chapter 11... This is what happening to all those ISPs..
Over-provisioning is not the answer.."

I have no Over-provisioning saying, all I said is that the maximum number of the connections you can support will be aligned to whatever the bandwith you have today. How you can use the bandwidth more efficiently from technology point of view, you always want to sell as much as you can if technology permits.
sgan201 12/4/2012 | 9:07:01 PM
re: Sprint Spurns MPLS for Global VPNs Hi Teng100,
If you provide enough bandwidth for maximum number of connection, you waste so much bandwidth that you go into chapter 11... This is what happening to all those ISPs..
Over-provisioning is not the answer..
rtg_dude 12/4/2012 | 9:07:02 PM
re: Sprint Spurns MPLS for Global VPNs Giles,

> Martini and 2547 have different control planes
> (martini uses targetted LDP, 2547 uses MP-BGP),
> however neither control plane concerns itself
> with interior topology or PE reachability.

There's one fundamental difference between the
martini-style VPNs and the 2547 ones. The former
keeps the customer's control plane separate from
the SP's one (as in ATM or FR based VPNs), while
the latter requires the SP to have an internal
infrastructure to distribute all routes from all
customers (granted that not all PEs will participate
in all VPNs.) In the 2547 case this infrastructure
is a set of MP-BGP routers (including PEs and RRs)
that can be either a completely separate set of
routers than those running BGP for the Internet
service, or the same ones. In the former case, the
SP saves its part of the Internet BGP system from
being affected by the VPN BGP, but has to essentially
run two BGP networks, in the latter case there is
only one BGP network, but there is a high risk of
that SP's Internet BGP destabilized because of the
VPN service. Note that in both cases the SP's network
is exposed to the control plane details of all
VPN customers, which also calls for RRs inside the
SP's network to help scaling distribution of this
information, while in martini-style VPNs the SP
gets no visibility of customer's routing.

Given this, martini-style VPNs are extremely
similar to those based on ATM or FR (and IMHO are
much healthier for the network), and 2547 ones
are extremely close to "gluing" the control
planes together.

rtg_dude
teng100 12/4/2012 | 9:07:02 PM
re: Sprint Spurns MPLS for Global VPNs Hi dreamer101:

Yes, if the bandwidth is limited anyway then
the number of the connections will be limited
for end to end QoS applications. We just
have to make sure we have enough resources
to cover the possible maximum call at the same
time.


I am not sure this is the answer you want.





Mark Seery 12/4/2012 | 9:07:02 PM
re: Sprint Spurns MPLS for Global VPNs Thanks Giles, good post. I walked in to that one, especially given recent debates.

>> neither control plane concerns itself with interior topology or PE reachability. <<

But some control plane does. So either they share/leverage elements of a different control plane, or we might conclude that the service layer and transport layers have different control planes?


-mark
sgan201 12/4/2012 | 9:07:04 PM
re: Sprint Spurns MPLS for Global VPNs Hi Teng100,
In my opinion, it is really irrelevant whether routing is scalable or not. In either case, you need some kind of out of band signalling.
The reason is billing and busy signal..
Since we do not have unlimited bandwidth, when a user/application ask for some bandwidth (assuming by SIP), there will reach a point that the network do not have the bandwidth to satify the request. The switch/router has to tell the SIP server and the SIP server has to tell the SIP client that it request for service is rejected..
If you do not do this, the first time it happen, you will get a law suit..
It is okay to give a user a busy signal but it is not okay to connect a user's call and then send the traffic to a black hole..
teng100 12/4/2012 | 9:07:08 PM
re: Sprint Spurns MPLS for Global VPNs beowulf888 wrote:
"Can you list some of the vulnerabilities that you perceive with routing (which *is* the signaling on a TCP/IP network)? I can think of a few, but they're probably as remote as an SS7 network getting subverted."

Control protocols in an IP network are just too many now including Topology, routing, MPLS, VOIP,
and more....

Certainly, everything can be "fixed" in one way or the another, however, I can see IP will be always vulnerable due to the complexity in management and very high cost associated with this
kind of networking architecture from security point of view. The backbone has to be isolated from the user application and have a logic way to
handle the security concern. Even put all the patches you can think of today, it will take a long time to fixed all the holes existing today, before then, it will be replaced with other viable solutiuon soon in the future.

Having a piece of mind and focusing only on generating true profit are very important for carrier or ISP, and customer will always be attracted to a secured netwok for long term business safety.
beowulf888 12/4/2012 | 9:07:08 PM
re: Sprint Spurns MPLS for Global VPNs Teng:
Sorry I didn't see your most recent post when I composed my last post (I guess I should refresh my browser more often).

Anyway, you wrote:
"First the speed is kind of low and was designed for end user application. Furthermore, How often we need to change the key before it can be penetrated by the DoS attacking from time to time.
it seems adding a big cost to the routers though."

Well, I don't really think that BGP over IPsec is all that necessary (see my previous post). And yes, that sort of security would still be vulnerable to DoS attacks. But DoS vulnerabilities are not really a protocol issue -- they're a resource and filtering issue. However, I think that most every router vendor has implemented techniques to mitigate syn flood attacks.

cheers,
--Beo
beowulf888 12/4/2012 | 9:07:09 PM
re: Sprint Spurns MPLS for Global VPNs teng100 wrote:
>Current IP network ties the application
>layer with the routing layer and it will
>cause serious security issues that need to
>be addressed in a logic way for the long
>term viability.

Are you saying that the Internet needs some sort of out-of-band signaling system like SS7?

Can you list some of the vulnerabilities that you perceive with routing (which *is* the signaling on a TCP/IP network)? I can think of a few, but they're probably as remote as an SS7 network getting subverted.

For instance, one of the commonly perceived buggaboos of a BGP network is that it's possible to forge a TCP RST and drop the BGP session. Frankly, it would take a very sophisticated attacker to do so, because the spoofed RST would have to match a real RST in some very fundamental ways: i.e. the source address, source port, destination address, destination port, the TTL value. Any super-script-kiddy or techno-terrorist would need direct access to the Layer 1 and Layer 2 network (and if they had that, heck, they could also subvert an SS7 network!).

I'm not saying it can't be done -- just that it's very highly unlikely.

A more likely vulnerability is DoS/DDoS Attacks directly against the BGP protocol port (port 179). TCP syn flood attacks against port 179 attempt to force the routerG«÷s processors to work overtime, triggering a route flap. All the proposed security bells and whistle add-ons for BGP: BGP over IPsec, BGP with MD5, etc. face the same syn flood vulnerability, though.

Probably the best way to mitigate the risk of DoS attacks is to increase the input queue depth to
the point where router has enough room to drop the syn connections and still have room to keep
the control plane traffic flowing.

I suppose SS7 isn't really vulnerable to DoS attacks (I only know a limited amount about the protocol's internals), but certainly the carrier network is -- look what happens when everyone tries to phone home after a major disaster. ;-)

cheers,
--Beo
giles0 12/4/2012 | 9:07:10 PM
re: Sprint Spurns MPLS for Global VPNs ------
If a single MPLS network is offering Martini and 2547 is that a multi-layer network with the same problems as IP over ATM (forgetting n2 control plane - no need to go there), or is it different because one control plane can be used for both?
------

Martini and 2547 have different control planes (martini uses targetted LDP, 2547 uses MP-BGP), however neither control plane concerns itself with interior topology or PE reachability.

Both Martini and 2547 make the assumption that there is an underlying mesh of tunnel LSPs providing connectivity from PE to PE. The same mesh of LSPs can be used for both martini and 2547 (and for Internet, VoIP, VPLS, etc.)

Giles
netskeptic 12/4/2012 | 9:07:11 PM
re: Sprint Spurns MPLS for Global VPNs > If there is aggregation, then a hierarchical
> link state protocol will work just fine.

If you need aggregation you have to keep the core very small/centralized and hence it has to be super-fast/super-expensive and it would not scale up well anyway. I would even say that a normal path of technological evolution is decentralization, decentralization,, decentralization. It may happen that global networking technology would buck this trend, but I doubt it.


> If there is no aggregation, then you will
> eventually overburden your intra-domain
> protocol.

If there are practically no changes in the core topology it would not happen.


Thanks,

Netskeptic
netskeptic 12/4/2012 | 9:07:11 PM
re: Sprint Spurns MPLS for Global VPNs
> Gee touchy.....most Layer 2 fans seem to
> detonate easier. Why is that?

You call my mild sarcasm a detonation, wow, yet anoher scaling problem :).

> Anyway back to the original intent of this
> post....discussion on how often can KISS
> networks be better than layers/layers/layers
> architecturing.

I am 100% agree and in the long run the most trivial solution would win. I would like just to point out that modern routing networks are anything but KISS and they are already at the limit of their ability to scale up.

Thanks,

Netskeptic
teng100 12/4/2012 | 9:07:11 PM
re: Sprint Spurns MPLS for Global VPNs "You might also look around and find several folks who have implemented IPSEC or other authentication mechanisms in hardware already. Some examples:

http://www.hifn.com/products/P...
http://www.asicint.com/cores/c...

So... this could be as easy as writing a check"


First the speed is kind of low and was designed for end user application. Furthermore, How often we need to change the key before it can be penetrated by the DoS attacking from time to time.
it seems adding a big cost to the routers though.
Mark Seery 12/4/2012 | 9:07:12 PM
re: Sprint Spurns MPLS for Global VPNs That there will be multiple layers in public networks seems inevitable (IMO), for a variety of functional and organizational issues. Seems like the key discussion point should be the issue of whether dynamic routing protocols can operate at multiple layers, or not, in the same network.

Some have said no - a commonly held view. Other opinions would be interesting to hear. For example, if the IP domain is usin a UNI in to the optical domain, can they both run routing procotols internal to their domains without any problems?

What happens when a wholesale transport network is offering services to a retail packet network. Should the transport network not use routing protocols?

Is it only when multiple layers share similar topology information that it is a problem? Is it restoration that becomes the problem, or just simple routing?

If a single MPLS network is offering Martini and 2547 is that a multi-layer network with the same problems as IP over ATM (forgetting n2 control plane - no need to go there), or is it different because one control plane can be used for both?

-mark
Packet Man 12/4/2012 | 9:07:12 PM
re: Sprint Spurns MPLS for Global VPNs If you simply want to feel good by being right about an important issue, be my guest: Packet Man is the greatest specialist in routing and network infrastructure known to the humanity. If we want network nirvana for us and food on the table for our families we have to follow his views without asking any questions.
-----
Gee touchy.....most Layer 2 fans seem to detonate easier. Why is that?

Anyway back to the original intent of this post....discussion on how often can KISS networks be better than layers/layers/layers architecturing.

PM
netskeptic 12/4/2012 | 9:07:12 PM
re: Sprint Spurns MPLS for Global VPNs > There was no mention of recalculating shortest
> paths. You kept changing your mind from very
> large networks to POP networks, and I threw in
> a bone that a couple of static routes could do > the trick. You then said in MSG112 you cannot
> use static routes because links go down. I
> mearly said you can use floating static routes
> to overcome that. Now you say something about
> me believing static routes prevents routers
> from calculating shortest paths. I never once
> made a remark that would imply something like
> that. I mearly challeged your remark that
> static routes cannot be used.

I am/was talking about simple central topic: whether or not routing protocols would scale to handle a very large network (say one with 16M routes in DFZ). Naturally, the core of this network consists of interconnected POPs, I suppose it is time to stop wondering about it. The central issue for the routing protocols scalability is handling core topology changes - it seems to me that both you and I were in agreement here.

Then you threw in your bone that did not make any sense in this context and now you are offended that I pointed it out. If you are interested in checking the validity of your views stop throwing in nonsense.

If you simply want to feel good by being right about an important issue, be my guest: Packet Man is the greatest specialist in routing and network infrastructure known to the humanity. If we want network nirvana for us and food on the table for our families we have to follow his views without asking any questions.



> In
> reality, "most" of us know that you can set it
> up so that certain ways of populating a routing
> table can have more "weight" than other ways. I
> can make iBGP have more importance than EIGRP,
> I can make OSPF can have more importance than
> Static.

Yep, your bone did not make any sense wrt preventing core topology changes. We are back to the beginning of your story.

Thanks,

Netskeptic


Packet Man 12/4/2012 | 9:07:13 PM
re: Sprint Spurns MPLS for Global VPNs Tony_Li wrote in MSG118:
First, if you consider the context of only a single network, it does not much matter if the internals are run by L2 or L3. You do need some dynamic toplogy discovery and route computation at some level. You can do this at L2 and have a full mesh of VCs, or you can do this at L3. Just don't do it at both levels, please

My comment:
I agree. I've always been of the opinion that doing it at both levels is no good. It's obivious I'm a L3 fan and other are L2 fans but at the end of the day it really should be one of the other, but not both.

-----------------------
you at the very least need to run an inter-domain L3 protocol (i.e., BGP).

Yup, I never contested that.
-----------------------------

The rational decision criteria for whether or not to deploy MPLS in your network is truly simple: do you need the features that it provides?

Yup again, I wish I was better at putting thoughts into words.
---------------
Pardon my ignorance Tony but I noticed a few posts about you being "theee" Tony Li. I suspect you are probably some genius that works for one of the bigger router/switch vendors but I really don't know. Can ya throw me a bone?

PM
Packet Man 12/4/2012 | 9:07:13 PM
re: Sprint Spurns MPLS for Global VPNs netskeptic wrote in MSG112
"(b)You cannot use static routes, because your links can go up and down"
netskeptic then wrote in MSG116:
"It seems that you truly believe that this trick would prevent connected routers from recalculating shortest paths."

My comment:
There was no mention of recalculating shortest paths. You kept changing your mind from very large networks to POP networks, and I threw in a bone that a couple of static routes could do the trick. You then said in MSG112 you cannot use static routes because links go down. I mearly said you can use floating static routes to overcome that. Now you say something about me believing static routes prevents routers from calculating shortest paths. I never once made a remark that would imply something like that. I mearly challeged your remark that static routes cannot be used. In reality, "most" of us know that you can set it up so that certain ways of populating a routing table can have more "weight" than other ways. I can make iBGP have more importance than EIGRP, I can make OSPF can have more importance than Static.


rtg_dude wrote in MSG124:
"while this works for extremely simple
topologies, this won't help when it gets
even slightly more complex. Local interface
state knowledge is not enough to calculate
loop free routes in a network, that's why
IS-IS and OSPF have complete topology maps
(within the limits of an area, of course.)
"

My comment:
Absolutly. I seldom use static routes in real life. On occasion a static route here or there works but its OSPF 95% of the time for me. I knew I should clarified this earlier. :o)

PM
Mark Seery 12/4/2012 | 9:07:14 PM
re: Sprint Spurns MPLS for Global VPNs >> I am trying to sense how complicated the hardware will be if we have a complete well defined document for this algorithm. <<

There are a number of companies working on TCP offload engines (TOEs). If they don't find a big market in ISCSI land, then I am sure they will be only too happy to work with router vendors (if not already by the sounds of it) to adapt what they have already done, to the types of things Tony is talking about.

I would suggest a chat to these vendors might give you some idea of what can be done in TCP-land, in silicon.

-mark
rtg_dude 12/4/2012 | 9:07:14 PM
re: Sprint Spurns MPLS for Global VPNs jamesbond,

>OSPF is more complex and consumes
>more memory/cpu cycles per node.

Complexity-wise, OSPF and BGP are
compareable. As for mem/cpu, do a
"show proc cpu" one day, you'll find
it really interesting ;)

rtg_dude
Tony Li 12/4/2012 | 9:07:14 PM
re: Sprint Spurns MPLS for Global VPNs You might also look around and find several folks who have implemented IPSEC or other authentication mechanisms in hardware already. Some examples:

http://www.hifn.com/products/P...
http://www.asicint.com/cores/c...

So... this could be as easy as writing a check. ;-)

Tony
rtg_dude 12/4/2012 | 9:07:15 PM
re: Sprint Spurns MPLS for Global VPNs PM,

> Since you would love to see my right
> I'll give you a clue.....floating static
> routes via tweaking the administrative
> distance.

while this works for extremely simple
topologies, this won't help when it gets
even slightly more complex. Local interface
state knowledge is not enough to calculate
loop free routes in a network, that's why
IS-IS and OSPF have complete topology maps
(within the limits of an area, of course.)

rtg_dude
rtg_dude 12/4/2012 | 9:07:15 PM
re: Sprint Spurns MPLS for Global VPNs itisi,

> Thanks kindly for cohering! :-)

you're quite welcome.

> As to OSPF, - I would think
> physical adjacencies could be
> handled similarly as in the BGP
> case.

agreed, TTL 255 would work.

> For virtual links, you
> probably should be configuring
> (and filtering) for specific
> remotes anyway.

VLs are "nasty". What you normally configure
is not the IP address of the other ABR,
but its Router ID. The local ABR then
dynamically calculates based on the area
topology the src and dst addresses to be
used for encapsulation of packets sent
over the VLs, so the addresses are not stable.
One could, however, have the OSPF code
dynamically update the filters. The problem
with this though is the local decision and
the one performed at the remote ABR are
not synchronized, i.e., you might believe
the src address for the packets you should
be receiving on that VL is X, while the other
ABR still uses Y based on his (not yet up-to-
date, or more up-to-date) topology.

> Worst case, seems to me you should
> be filtering for non-local-AS at your
> boundaries, and accepting only local-AS
> source addresses to OSPF. No?

Yes, this should work (in fact it is possible
to limit the set of addresses to those configured
on the remote ABR), provided that you filter
out OSPF packets at your edges AND use the strict
RPF check at your eBGP speakers to make sure you
don't allow spoofed packets from other ISPs.

rtg_dude
teng100 12/4/2012 | 9:07:16 PM
re: Sprint Spurns MPLS for Global VPNs "Hardware should not be standardized. Algorithms should be. And are."

I am trying to sense how complicated the hardware will be if we have a complete well defined document for this algorithm.


DoTheMath 12/4/2012 | 9:07:17 PM
re: Sprint Spurns MPLS for Global VPNs Tony Li wrote:
The rational decision criteria for whether or not
to deploy MPLS in your network is truly simple: do
you need the features that it provides? If no, then
stop here. If yes, then proceed. When you're
contemplating this question, in addition to the
goals for simplicity that many people have expounded
and that I agree with, you must also consider your
own profitability. Many ISPs have followed some of
the suggested ways of building their networks as
described here. Yes, they were simpler, but the
net costs were higher and they in turn ended up
in Chapter 11. [To be fair, some of the MPLS folks
have also ended up in Chapter 11. Profibility is
clearly hard.]

-----------------------------------------------

Profitability, or the lack of it, in the 1996-2000 era was
driven not by technology but by fashion. It didn't
matter if it was stupid network or smart network, they didn't
make money, because they bloated themselves, on
borrowed money. That's two strikes, and the recession
added the third strike.

Why on earth does a service providers needs to keep
his HQ in fancy San Francisco, paying $4/sqft/month (even
$10 per month at the peak) rent, having to pay their
staff twice the going rate of, say, Kansas City? The
only reason I could think of is Corporate Hubris.

It is possible to make money as a service provider. It
just requires fundamentally different set of people
(businessmen who know business is about MAKING money,
not spending OTHER PEOPLE's money).

Just as a point of comparison, compare Exodus (HQ,
fancy office complex in Santa Clara now empty) vs Rackspace
Managed Hosting (HQ in earthquake-free, cheap, San Antionio, TX).
Guess which one is making money and thriving?


Tony Li 12/4/2012 | 9:07:17 PM
re: Sprint Spurns MPLS for Global VPNs Hardware should not be standardized. Algorithms should be. And are.

Tony
teng100 12/4/2012 | 9:07:17 PM
re: Sprint Spurns MPLS for Global VPNs " You're again assuming that the authentication is done in the CPU. In the fullness of time, you'll see the authentication checks implemented in line rate hardware. "

I am wondering do we have a standard for this
kind of hardware authentication so that we can make some sense of it, or how complicated the hardware will be.




Tony Li 12/4/2012 | 9:07:18 PM
re: Sprint Spurns MPLS for Global VPNs
I have a slightly different perspective that I would like to share with you.

First, if you consider the context of only a single network, it does not much matter if the internals are run by L2 or L3. You do need some dynamic toplogy discovery and route computation at some level. You can do this at L2 and have a full mesh of VCs, or you can do this at L3. Just don't do it at both levels, please.

Since a network that is not connected to other networks is a very restricted case, and if you want to interconnect you need L3, you at the very least need to run an inter-domain L3 protocol (i.e., BGP).

For your intra-domain protocol, what you run must scale to the size of network that you want to build. The scalability of this protocol is, in part, limited by the addressing scheme used within the domain. It doesn't matter if it's at L2 or L3. If there is aggregation, then a hierarchical link state protocol will work just fine. If there is no aggregation, then you will eventually overburden your intra-domain protocol.

The rational decision criteria for whether or not to deploy MPLS in your network is truly simple: do you need the features that it provides? If no, then stop here. If yes, then proceed. When you're contemplating this question, in addition to the goals for simplicity that many people have expounded and that I agree with, you must also consider your own profitability. Many ISPs have followed some of the suggested ways of building their networks as described here. Yes, they were simpler, but the net costs were higher and they in turn ended up in Chapter 11. [To be fair, some of the MPLS folks have also ended up in Chapter 11. Profibility is clearly hard.]

The net question then becomes: what works for you?

Tony
Tony Li 12/4/2012 | 9:07:18 PM
re: Sprint Spurns MPLS for Global VPNs This will cause DoS attack already through malicious DDoS packets that passed the hardware to the CPU.

--------------

You're again assuming that the authentication is done in the CPU. In the fullness of time, you'll see the authentication checks implemented in line rate hardware.

Tony
netskeptic 12/4/2012 | 9:07:19 PM
re: Sprint Spurns MPLS for Global VPNs > Since you would love to see my right I'll give
> you a clue.....floating static routes via
> tweaking the administrative distance.

It seems that you truly believe that this trick would prevent connected routers from recalculating shortest paths. Wow, the depth of your wisdom is truly frightening.



Thanks,

Netskeptic

netskeptic 12/4/2012 | 9:07:20 PM
re: Sprint Spurns MPLS for Global VPNs > Man you are so wrong. I not even going to
> debate the rest with you.

I would love to see you being right at the end (I have two kids to put through college and I am writing router code for living), but so far my track record on detecting technology duds was pretty good - and I see DUD written all over MPLS/IP-based-converged-network.

Thanks,

Netskeptic

Packet Man 12/4/2012 | 9:07:20 PM
re: Sprint Spurns MPLS for Global VPNs netskeptic wrote:
(b)You cannot use static routes, because your links can go up and down and hence you have core topology changes and hence you have to have dynamic routing and you are back to the beginning of your story.

My comment:
Man you are so wrong. I not even going to debate the rest with you.

PM
Packet Man 12/4/2012 | 9:07:20 PM
re: Sprint Spurns MPLS for Global VPNs netskeptic wrote:
I would love to see you being right at the end (I have two kids to put through college and I am writing router code for living), but so far my track record on detecting technology duds was pretty good - and I see DUD written all over MPLS/IP-based-converged-network.

My comment:
You write router code and you are telling us that we can't use static routes because of link failures?? Tell me you don't work for Nortel cause I got shares there man.
Since you would love to see my right I'll give you a clue.....floating static routes via tweaking the administrative distance.

I'm off to see a movie....Merry Christmas.

PM
teng100 12/4/2012 | 9:07:21 PM
re: Sprint Spurns MPLS for Global VPNs "However I will say this. As technology evolves to allow better scaling, a L3 network will scale many folds larger than a L2 network. L2 technology fundamentally allows for conversation and logic between two boxes. 'Awareness' of the total network and end-to-end conversation/logic can only occur at L3. Any attempts to ignore that fundamental law of device scaling will result in in a technology that scales worse the L3 technology it is trying to beat."



Security concerns will be very important for critical voice and VPN applications.

Network needs to have enough addresses for each device attached to the network for the ultimate security control, and separate the application from the network control will be also very essential for security.

Current IP netwok fails to provide all these requirements.

What will be the right technology will be
based on the security to begin with, otherwise,
the customer will tell you soon.

netskeptic 12/4/2012 | 9:07:21 PM
re: Sprint Spurns MPLS for Global VPNs > Make up your mind. Since you now wanna talk
> about POP-to-POP instead of very large scale
> networks I would say instead of using some
> complex L2 technology I would simply use static
> routes. If MPLS is already enabled then I
> suppose you could use traffic flow engineering
> if needed.

(a)I am talking about a core of a very large network which is a POP-to-POP network, what is so hard to grasp here ?

(b)You cannot use static routes, because your links can go up and down and hence you have core topology changes and hence you have to have dynamic routing and you are back to the beginning of your story.

(c) Theoretically you can use MPLS to insulate your L3 networks from L1 topology changes, but it is practically unusable because MPLS learns topology changes from the same protocols we are trying to eliminate and as redundant PVC protocol it offers very little bang for a huge buck.

> Again if one is expected to scale a very large
> network you have to break it down into
> sections. If you don't do that any protocol at
> any layer will evenutually break. Why have
> topology changes in the North-East section be
> announced to the Southern sections, assuming
> your network is designed right?

Yeap, as long as there are no topology changes in the core itself, one can partition network into a set of peripheral areas (and/or a set of private L3 overlay networks) where it will be quite possible to handle topology changes. But again, as long as you have topology changes in the core you cannot effectively partition large network.

> As for QoS I can't see how any protocol can
> provide any meaningful QoS during topology
> changes, espically during link flaps.

Again, this why we have to have a layer eliminating topology changes in the core (natural requirement here that this layer has to effectively reuse spare bandwidth for lower traffic classes).

Look, any talk about QoS over links which could go down is simply meaningless: first one has provide for links to stay up no matter what and only after that we can talk about how much would it cost to have W Gbps average with X Gbps peak with Y ms of delay and Z ms of jitter.

> MPLS I can see having an advantage if pre-
> defined traffic flow engineering has been pre-
> defined. However ATM-PNNI, IP-OSPF, etc, etc
> will all have problems during congestion cause
> by outages in a network. If one of these
> protocols did this job without introducing new
> major issues to a network you and me would all
> be out of a job.

Yep, none of them is suitable, I would even venture to say that no protocol based solution is suitable. I think that we will simply have a mesh of redundant POP-to-POP PVCs. Transmission plant is already in the ground, the only problem is to make simple/fast/dense switches, I would call it an ultimate KISS solution.


> Don't kid yourself, L2 has its limits, and so
> does L3.

That is why we have to use them both, it is time for you to stop kidding yourself that L3 alone will do the job.


Thanks,

Netskeptic

Packet Man 12/4/2012 | 9:07:22 PM
re: Sprint Spurns MPLS for Global VPNs jamesbond wrote in MSG107:
What are "Autonomous tools" that come with OSPF?
Dividing Network into sections is by means of
Areas not Autonomous systems in OSPF context.
FYI, BGP is meant to scale better than OSPF.
OSPF is more complex and consumes more memory/
cpu cycles per node.

My comment:
I agree 100% with you. While OSPF does not do AS like BGP, it does have some basic AS tools to it. The ASBR function can let you summarize routes from one section to another section, in the very large scale networks. Internally you use the Areas as you said. I acknowledge that OSPF is CPU intensive, but by using that ASBR you can curve this significantly. Again the assumption is made that the network is designed and implemented in an hierarchally fashion the way networks should be. BGP is so far the ultimate way of scaling when used with an IGP like OSPF or ISIS. By itself (eBGP and iBGP) BGP can also get hard to manage.

PM

Packet Man 12/4/2012 | 9:07:22 PM
re: Sprint Spurns MPLS for Global VPNs netskeptic first wrote in MSG103:
"The key question is whether routing protocols would scale up to handle a really big network? I doubt it."

Then after my comments netskeptic then writes in MSG106:
"there is no point to bring it up because we are discussing a different matter: L2 network I am talking about is POP-to-POP net and L2 will scale perfectly well in the case."

My comment:
Make up your mind. Since you now wanna talk about POP-to-POP instead of very large scale networks I would say instead of using some complex L2 technology I would simply use static routes. If MPLS is already enabled then I suppose you could use traffic flow engineering if needed.

Your comment:
We have a nice scalable end-to-end protocol with only two problems: (1)it cannot reflect on its core topology changes fast enough to handle REALLY big network, (2)it is uncapable of providing meaningful QoS in the core especially when its topology is changing and the utilization is high.

My comment:
Oh now we are back to very large networks, I thought you had changed your mind to POP-to-POP flows. Again if one is expected to scale a very large network you have to break it down into sections. If you don't do that any protocol at any layer will evenutually break. Why have topology changes in the North-East section be announced to the Southern sections, assuming your network is designed right? However as I said earlier L3 protocols will scale larger before 'protocol unstability' occurs than a L2 protocol, espescially if the L2 protocol is a connections based protocol. As for QoS I can't see how any protocol can provide any meaningful QoS during topology changes, espically during link flaps. MPLS I can see having an advantage if pre-defined traffic flow engineering has been pre-defined. However ATM-PNNI, IP-OSPF, etc, etc will all have problems during congestion cause by outages in a network. If one of these protocols did this job without introducing new major issues to a network you and me would all be out of a job. Don't kid yourself, L2 has its limits, and so does L3.


netskeptic also wrote:
So, routing protocols would not scale, but you are just unable to spell it.

My comment:
I have no idea what you just said there. :o)

PM
teng100 12/4/2012 | 9:07:22 PM
re: Sprint Spurns MPLS for Global VPNs "However I will say this. As technology evolves to allow better scaling, a L3 network will scale many folds larger than a L2 network. L2 technology fundamentally allows for conversation and logic between two boxes. 'Awareness' of the total network and end-to-end conversation/logic can only occur at L3. Any attempts to ignore that fundamental law of device scaling will result in in a technology that scales worse the L3 technology it is trying to beat."

Current IP network ties the application layer with the routing layer and it will cause serious security issues that need to be addressed in a logic way for the long term viability.

IP address space needs to cover all the end users
in order to serve all the applications in a secured way.









jamesbond 12/4/2012 | 9:07:23 PM
re: Sprint Spurns MPLS for Global VPNs Why not set up your network into sections and use the Autonomous tools that come with OSPF or example? (Many players are obeying these rules of thumb and seem to be having good success)

--------------------------

What are "Autonomous tools" that come with OSPF?
Dividing Network into sections is by means of
Areas not Autonomous systems in OSPF context.
FYI, BGP is meant to scale better than OSPF.
OSPF is more complex and consumes more memory/
cpu cycles per node.

Packet Man 12/4/2012 | 9:07:23 PM
re: Sprint Spurns MPLS for Global VPNs netskeptic wrote in MSG103:
The key question is whether routing protocols would scale up to handle a really big network? I doubt it.

My comment:
Why do we have to have a routing protocol that can handle a really big network? (I am assuming you mean the Internet). I had a discussion one time when an engineer from a Nortel vendor, and the topic was actually OSPF. He told me if you follow the OSPF rules of thumb you will have a very powerful capable network that is "sweet". However if you try to 'bend' the rules you network will be a living hell.

So my question is do we need a single protocol to scale to a million routers or switches? Why not set up your network into sections and use the Autonomous tools that come with OSPF or example? (Many players are obeying these rules of thumb and seem to be having good success) Most large carriers have their operations organized into the Western Operations, Eastern Operations etc. Don't get me wrong, if a protocol comes along that can scale to a million boxes hey great. As for BGP I think the biggest problem is not its scaling capabilities (its scales great), but how us humans use it. The golden rule of route summarization and network hierarchy is not being implemented as much as it should be. If that were the case we could probably shrink the Internet BGP routing table by 25%.

However I will say this. As technology evolves to allow better scaling, a L3 network will scale many folds larger than a L2 network. L2 technology fundamentally allows for conversation and logic between two boxes. 'Awareness' of the total network and end-to-end conversation/logic can only occur at L3. Any attempts to ignore that fundamental law of device scaling will result in in a technology that scales worse the L3 technology it is trying to beat.

PM
netskeptic 12/4/2012 | 9:07:23 PM
re: Sprint Spurns MPLS for Global VPNs > So my question is do we need a single protocol
> to scale to a million routers or switches? Why
> not set up your network into sections and use
> the Autonomous tools that come with OSPF or
> example?

So, routing protocols would not scale, but you are just unable to spell it.

> However I will say this. As technology evolves
> to allow better scaling, a L3 network will
> scale many folds larger than a L2 network. L2
> technology fundamentally allows for
> conversation and logic between two
> boxes. 'Awareness' of the total network and end-
> to-end conversation/logic can only occur at L3.
> Any attempts to ignore that fundamental law of
> device scaling will result in in a technology
> that scales worse the L3 technology it is
> trying to beat.

I would say it is a well established fact since at least 1996, and there is no point to bring it up because we are discussing a different matter: L2 network I am talking about is POP-to-POP net and L2 will scale perfectly well in the case.

Let us look at what we have:

We have a nice scalable end-to-end protocol with only two problems: (1)it cannot reflect on its core topology changes fast enough to handle REALLY big network, (2)it is uncapable of providing meaningful QoS in the core especially when its topology is changing and the utilization is high.

Do you like it or not there is no way around these problems. So, the only way up is to eliminate topology changes and provide QoS in underlying L2 network, this is it.

Thanks,

Netskeptic

netskeptic 12/4/2012 | 9:07:24 PM
re: Sprint Spurns MPLS for Global VPNs > *IP everywhere with OSPF (or ISIS) in a POS
> core and BGP only at the edge where needed.

The key question is whether routing protocols would scale up to handle a really big network? I doubt it.

IMHO, the inevitable future is a universal redundant QoS-capable L2 network, with statically routed IP core and VPNs over it for data, and with virtual TDM over it for voice.


> *Less than 80% utilized.
> *IP DiffServ (DSCP) QoS to enforce QoS should
> congestion occur.
> *CPE VPN solutions to create the necessary
> tunnels for the customers.
> * A small yet highly 'tuned' IP staff.
> * A sales team who understands IP and IP
> solutions

Again, if routing protocols could handle a really big network, everything else will fall right in.

Thanks,

Netskeptic
teng100 12/4/2012 | 9:07:24 PM
re: Sprint Spurns MPLS for Global VPNs "The key question is whether routing protocols would scale up to handle a really big network? I doubt it.

IMHO, the inevitable future is a universal redundant QoS-capable L2 network, with statically routed IP core and VPNs over it for data, and with virtual TDM over it for voice."

I agree, but with statically IP route over
such QoS-capable L2 network. and IP should be
kept in region or stub area.
teng100 12/4/2012 | 9:07:25 PM
re: Sprint Spurns MPLS for Global VPNs "Once the limited set of protocols are let through to the processor, you would still need to worry about attacks on those protocols. As Tony pointed out in an earlier message, this would be limited to how fast the central proccessor could authenticate those protocol packets. "Authentication" could take the form of the TTL counter that was mentioned in a previous message."

This will cause DoS attack already through malicious DDoS packets that passed the hardware to the CPU.
fiber_r_us 12/4/2012 | 9:07:25 PM
re: Sprint Spurns MPLS for Global VPNs Tony said:

>Again, you don't need to define the garbage. We
>need to define the 'non-garbage'. The set of
>things that are actually necessary to keep the
>network up and running is relatively small. And
>of course, some flexibility in your hardware is
>very helpful.

Exactly. This is what I was trying to say in message 77 where I pointed out:

"Usually, you would only allow OSPF, ISIS, BGP, LDP, RSVP, SSH, and some ICMP"

Are there other protocols you would allow? Maybe a few. But it would be a very limited set. You can also filter based on which port a packet was received from. For example, you might only want to let ssh sessions in from a port that was physicaly attached to the provider's internal management network (an out-of-band network with no outside connections). Or, you might not want to let control packets in from any customer-connected ports. As I and others have pointed out, this filtering is easily accomplished in hardware.

Once the limited set of protocols are let through to the processor, you would still need to worry about attacks on those protocols. As Tony pointed out in an earlier message, this would be limited to how fast the central proccessor could authenticate those protocol packets. "Authentication" could take the form of the TTL counter that was mentioned in a previous message.
Tony Li 12/4/2012 | 9:07:26 PM
re: Sprint Spurns MPLS for Global VPNs "Try the reverse algorithm: everything is garbage until proven otherwise."

And how we define what garbage is from time to time while adding more and more proven items will be a on going modification nightmare????

---------------------

Again, you don't need to define the garbage. We need to define the 'non-garbage'. The set of things that are actually necessary to keep the network up and running is relatively small. And of course, some flexibility in your hardware is very helpful.

Tony
teng100 12/4/2012 | 9:07:27 PM
re: Sprint Spurns MPLS for Global VPNs "Security is incremental: hard, continual work.

As a hacker, nothing I like better than a target that thinks it's got the magic bullet. Liable to be like the telcos, - _they've_ got isolated control planes. All you have to do is get access (via social engineering or Joe Layoff) and you own them, lock, stock, barrel, and every ratty little misimplemented RTOS stack and shell in their net. Yum."

I think this will be different than what we are
talking about DoS attacking. Thanks.
Packet Man 12/4/2012 | 9:07:29 PM
re: Sprint Spurns MPLS for Global VPNs jepovic wrote in MSG18:
The IP/MPLS/SDH network is similar to the IP/ATM/SDH network, and we all know where that went. MPLS doesn't add any new boxes, but it adds complexity. It makes the network harder to manage, makes the software less stable etc. It's just not worth the hassle.

hey_tedd wrote in MSG22:
The MPLS developer community has to stop blaming others for their shortcomings and work humbly to produce the needed solutions, here are some of the things that folks should keep moving on:
-also wrote:
Revenue generating applications need to start using MPLS!!! How to add VoIP that is secure and redundant for clients that use MPLS VPN backbones.

sid wrote a great post in MSG23.

OptiFuture wrote in MSG31:
The future is not MPLS, nor ATM, but IP+OPTICAL. ATM was a necessary evil (because of low speed links) but is soon going to fade away towards the access and edge. MPLS - too late, too complicated. Here's how the network will look like (you don't have to agree :-) but this is how it's going to be):
(Read all of his post, I think its good)

My comments:
With respect to what jepovic wrote, some of my thoughts 'align' with him. I believe in the KISS (keep it simple silly) rule. While I am a big fan of most forms of stat-muxing/packet-switching, I was never a fan of overlaying layers of packet-switching on each other. That's why I am often quoted to say get that ATM out of the network. Maybe I should of said "get that L2 packet-switching technology out of there", to be more accurate. I truly believe adding layers into a network, whether it be hardware/software adds significant capitol and operational costs to a company, and the gains may not pay for the associated costs. OptiFuture wrote a post (MSG31) that I believe is a very good and accurate prediction of the way it will be. In MSG22 hey_tedd made a comment of MPLS blaming. I have read a lot of the posts in here and read articles on the Internet and frankly I see the same thing starting all over again. ATM while an excellent compromise of a technology had/has an awful lot of finger pointing and bad mouthing in every way possible. 5 or so years of mass deployment and many service providers are simply confused. Shall I continue to invest in ATM, or shall I rip it out? Frankly I see MPLS heading down the same road. In MSG23 Sid wrote some great stuff too. As for all that signaling plane stuff I simply can't comment, I have no idea. I have noticed one trend though. A lot of the ATM flag wavers are the ones that are quick to shoot down MPLS. Maybe because they see IP+MPLS as a threat to their very existence. If MPLS+IP+IP-QOS will eliminate most of the need for ATM why use it? We just can't everytime add/maintain another technology layer in a network because it solves 10% of our problems. A few years ago transport circuit (T1 to OCwhatever) costs were a lot more and advanced traffic engineering was worth it. Today however with pricing being only a few % points above costs most players can afford a network that is not 95% utilized. While this was happening, staffing costs have gone up not down. To me the solution is almost blaring in your face. Why use ATM or MPLS or what-ever and a larger staff to have a network run 95% on a cheap transport network, when you can have a 'KISS' network running at 80% minus all that hardware and software and staff baggage. I have been at this racket for 12 years, in telcos (both privately and public held) and in military environments and I have seen time n time over......8 times out of 10, the simple solution is cheaper in the long term than the complex solution. The complex solution seems to be the winner in the short term but after you add on all of the issues it creates, the solutions to those issues, and all those mini-costs, you lose more in the long run.

My choice:
*IP everywhere with OSPF (or ISIS) in a POS core and BGP only at the edge where needed.
*Less than 80% utilized.
*IP DiffServ (DSCP) QoS to enforce QoS should congestion occur.
*CPE VPN solutions to create the necessary tunnels for the customers.
* A small yet highly 'tuned' IP staff.
* A sales team who understands IP and IP solutions, and doesn't have to understand FR, ATM, IP, MPLS, etc, etc, etc. (There is nothing worse than a sales guy who will sell anything to make that sale happen, often at a big "whoops" to the carrier.) If he has a smaller portfolio of solutions then he has less chance of getting it wrong. At the end of the day there is nothing wrong with saying "No" to a customer, if you can't provide them a solution and make a profit at it.
*From a marketing point of view, customers like to choose players who are playing with the "hot trendy" items of the day. However at the end of the day they will continue to do business with you if the solution you give them works.

Many of todayG«÷s multi-service multi-capable multi-layer-network players are in trouble financially due to large costs, while many of the niche players with KISS networks are doing all right for themselves.

PM
itisi 12/4/2012 | 9:07:29 PM
re: Sprint Spurns MPLS for Global VPNs Security is incremental: hard, continual work.

As a hacker, nothing I like better than a target that thinks it's got the magic bullet. Liable to be like the telcos, - _they've_ got isolated control planes. All you have to do is get access (via social engineering or Joe Layoff) and you own them, lock, stock, barrel, and every ratty little misimplemented RTOS stack and shell in their net. Yum.

>>"Try the reverse algorithm: everything is garbage until proven otherwise."

>And how we define what garbage is from time to time while adding more and more proven items will be a on going modification nightmare????
teng100 12/4/2012 | 9:07:29 PM
re: Sprint Spurns MPLS for Global VPNs "Try the reverse algorithm: everything is garbage until proven otherwise."

And how we define what garbage is from time to time while adding more and more proven items will be a on going modification nightmare????
Tony Li 12/4/2012 | 9:07:31 PM
re: Sprint Spurns MPLS for Global VPNs It seems impossible implemented in ASIC or NPU
due to no well defined algorithm to cover all
possible cases seen today and more in the future.
Even CPU program has no algorithm to cover all the
case without going into halt state.

-------------------------

Try the reverse algorithm: everything is garbage until proven otherwise.

Tony
teng100 12/4/2012 | 9:07:35 PM
re: Sprint Spurns MPLS for Global VPNs "also, need to make sure your router does
not choke when someone blasts to your router
eigrp packets, use you as an email server,
web-cache rediretor, Lotus Notes registration
server, X11 display redirect, postscript
printer spooler server, cisco gateway discovery
protocol packets, etc. btw, you need to
make sure the data forwarding is still doing
line-rate."

It seems impossible implemented in ASIC or NPU
due to no well defined algorithm to cover all
possible cases seen today and more in the future.
Even CPU program has no algorithm to cover all the
case without going into halt state.
beltway_light 12/4/2012 | 9:07:35 PM
re: Sprint Spurns MPLS for Global VPNs also, need to make sure your router does
not choke when someone blasts to your router
eigrp packets, use you as an email server,
web-cache rediretor, Lotus Notes registration
server, X11 display redirect, postscript
printer spooler server, cisco gateway discovery
protocol packets, etc. btw, you need to
make sure the data forwarding is still doing
line-rate.
itisi 12/4/2012 | 9:07:36 PM
re: Sprint Spurns MPLS for Global VPNs Thanks kindly for cohering! :-) Also see discussion in IDR WG in the last IETF proceedings. This has been kicked around in the operations community for a while.

As to OSPF, - I would think physical adjacencies could be handled similarly as in the BGP case. For virtual links, you probably should be configuring (and filtering) for specific remotes anyway. Worst case, seems to me you should be filtering for non-local-AS at your boundaries, and accepting only local-AS source addresses to OSPF. No?


fiber_r_us wrote:

> itisi,
> please restate your idea in a coherent way.

itisi meant the idea described in draft-gill-btsh.
Mark Seery 12/4/2012 | 9:07:37 PM
re: Sprint Spurns MPLS for Global VPNs >> itisi meant the idea described in draft-gill-btsh <<

seems like a good idea. the basic notion that it would be hard to spoof TTL 255/254 seems sound as well. i guess the only question is what if the adjacent router was compromised, but of course if it was, then it can do even uglier things anyway ....

it does raise the philisophical question of whether a network should be based on an architecture that is inherently secure, or where you reverse engineer in security every time another whole in the dyke springs a leak. I guess if the preservation of a certain paradigm is the high-order bit, then the answer to that question is obvious; and the fix is certainly quicker to implement than waiting for a new architecture to go through the sausage machine.

if not for the companies represented by the authors (AOL, Sprint, Verio) I would tend to be a bit skeptical about the assumption of common filtering they make in the draft, but if all three do it, then that's some good coverage for sure. certainly the filtering suggested is common sense and if the industry consolidates, the chances of BCPs being implemented certainly goes up. additionally as peering routers get refreshed with GSR-class products, then there will be less excuses for not doing filtering.

-mark
rtg_dude 12/4/2012 | 9:07:38 PM
re: Sprint Spurns MPLS for Global VPNs fiber_r_us wrote:

> itisi,
> please restate your idea in a coherent way.

itisi meant the idea described in draft-gill-btsh.
The idea is to solve the problem of DoS attacks
still possible with rate limiting of control
traffic (because the attacker eats up all BW and
valid traffic can't get through) by restricting
incoming BGP/TCP segments to have TTL==255 or 254
in the IP header, and rejecting those with other
TTLs. Since it is impossible for an outsider
to send a packet with such TTL, it is easy to identify
valid packets and not necessary to spend too
many cycles (to check TCP-MD5, for example) on
those from attackers (one could implement them
in the line cards). The same trick was used in
IPv6 ND.

itisi wrote:

> OSPF and ISIS, - not an issue.

ISIS is not an issue, indeed; OSPF is, see my
post 79. Using the TTL trick in OSPF networks
might be possible (in fact I remember a
discussion on this in the OSPF WG a while ago),
but not in all situations, because once you
have virtual links (if you have them, of course),
you'd need to allow non-255 TTLs.

rtg_dude
Mark Seery 12/4/2012 | 9:07:38 PM
re: Sprint Spurns MPLS for Global VPNs Tony,

You wrote:

>> static routing. I believe that has proven to be both labor intensive and have high latency. <<

there are large networks providing premium services based on OSS provisioning. neither labor intensive or high latency (either with respect to service activation or forwarding performance). these networks are profitable as well as having very low defects.

which is not to suggest that is the only way, or the right way for every application. but it is simply to suggest that an operator may choose to invest in one plane (control, management, data,..) over the other based on a whole range of issues. it would appear that SPs are not a homogenous group with almost as many different views as a lightreading message board ;-)

>> My understanding is that the SONET layer is routed manually and that provisioning is a significant issue. <<

Not all operators (around the globe) have invested the same amount of time and effort into reducing the provisioning overhead of the transport layer. It is not a technical issue, it is an investment issue. The SONET approach shifts the heavy lifting from the control plane to either the management plane or the people plane. The management plane has been shown to be very effective in some networks when invested in, while reducing the complexity of the network elements. It is **a** approach, not necessarily **the** approach. Once again it comes to a network operator preference of where they want to feel the pain: in the control plane, or in the management plane. You've already argued that traffic engineering is amenable to offline optimization so that would seem to infer that you are open to the idea that management systems can play constructive roles in networks; and that doing everything through the control plane is not the only viable option.

>> I'm also told that routing for the voice network is done statically in the switches and that the signaling leaves state in the switches that the calls transit. <<

Yes, but the state is bounded by the upper limit of how many circuits can be supported. So a non-complex engineering issue. In other paradigms, the engineer has to guess what the bounds of the state might be. Sometimes they guess right, sometimes they guess wrong, and sometimes multipling this guess over n line cards and n route processors leads to an aggregate engineering problem.

I am not trying to argue in favor of another paradigm, just trying to suggest that choke points can be moved around from one plane to another. All approaches have vices, virtues, and the vices of their virtues when pushed to the limits of their design considerations.

>> For the phone network, at least, the routing is somewhat scalable because we've installed a hierarchical addressing scheme that allows aggregation and abstraction of end points. This is also the same thing that we try to do with IP addresses in the Internet. <<

Good point, and understood.

>> phone users want global roaming, IP users want Provider Independent address space. <<

Both of which are available on some portions of the voice network (particularly cell); though achieved through network-based databases and a signiling network that has a different topology than the user plane. Not necessarily **the** only approach, but **a** approach which is known to work and which has a different set of issues and attributes than the way we use directories in the Internet today.

-mark
Tony Li 12/4/2012 | 9:07:39 PM
re: Sprint Spurns MPLS for Global VPNs SAR's still have to deal with VCs. So if the VCs
were fine grainularity, there STILL would be a
serious scalability problem.

-------------------------

True enough. So the best option is to do away with fine grained VCs. Seems like a fine idea.

Tony
fiber_r_us 12/4/2012 | 9:07:40 PM
re: Sprint Spurns MPLS for Global VPNs itisi,

please restate your idea in a coherent way.
lob 12/4/2012 | 9:07:41 PM
re: Sprint Spurns MPLS for Global VPNs signmeup wrote:

> But the basic premise of MPLS was to solve some
> nasty little quirks associated with traffic
> forwarding like recursive lookups. Instead of
> having to build faster lookup asics, MPLS
> allowed existing architectures to scale by
> removing the complexity associated with packet
> lookup for each and every packet onto the
> control plane.

Actually, from a systems engineering point of view, this is an extremely bad tradeoff - control plane is distributed, open to injection of bad information, and its configuration is not controlled by the router desiger; conversely, forwarding engines are local and completely parameter-controlled.

In other words, this approach compromises the global system robustness for the sake of slight optimization of a single, relatively uncomplicated part of it. (After all, doing second routing table lookup is not something hard to implement; there are no hard limits for packet forwarding latencies, and there's no dependency between packets, so simple duplication of that step in the forwarding pipeline will suffice).

Besides the obvious fact that MPLS does not improve forwarding scaling much (the hardest parts are packet classification and queue scheduling, _not_ route lookup), the whole issue of forwarding engine scaling became moot years before MPLS, when i invented the parallel routing trick.

> Yes, the tradeoff is that there is a more
> complex control plane, but this was being
> called for anyway by the SP's who wanted to
> take advantage of differentiated service
> offerings.

Yep. Those are the same SP's who still don't have any differentiated offerings... simply because their "regular" service is good enough for practically all users, so rolling out really differentiated service simply won't generate any profits. Service _reliability_ is the real problem, not the packet loss or jitter.

> With MPLS, you could achieve
> line-rate forwarding with older hardware.

Yep, this is pretty much the root of the problem: a vendor with the broken-as-designed hardware is screwing up everyone by forcing bad control plane design to cover up its hardware problems.

Line rate forwarding is not that hard to do... if you design hardware for real traffic, not for the artificial line-rate Christmas-tree streams, or for doing per-packet ACLs at OC-192c rate (nobody invented any use for those super-fast ACLs yet).

> There are other inherent benefits to running
> "pure" MPLS - let's forget about TE and VPN for > the moment.

Let's forget about them permanently, because, provably, there aren't any. Any benefit from MPLS in those fields can be achieved just as well with trivial improvements to plain IP router design. This was already discussed.

> With MPLS I can remove iBGP from the core of
> my network.

Sure, dude. Instead you have to drag the iBGP mesh to all edge boxes, which makes it very very scalable <heavy irony="">.

In fact, even with flows or source routing as modus operandi, core boxes still need to have full routing table (need to send those pesky ICMPs somewhere, right?).

> However, from an operational perspective, I
> would much rather beef up the edge in order to
> simplify the core.

This makes little sense from economic perspective; core boxes are few and are a minor component in the capex and opex structures. It makes a lot of sense to confine routing to core routers, and make edge boxes to do aggregation and filtering - cheaply. Making all those itty-bitty edge boxes (which are typicaly constantly tweaked by junior engineers on the customer installation mill) to uncontrollably participate in signaling is rather reckless.

> however I sometimes feel that we lose sight of
> the WHY things were designed. MPLS was designed > to solve some very real problems,

... of the OFRV, _not_ providers, who had that "solution" pretty much forced on them, despite the fact that there were more palatable design alternatives.

> and to meet the needs of providers who want to
> generate additional revenue.

That's apparently why the core of the anti-MPLS "sect" are people with real-life backbone engineering and management background (as opposed to academia, marketing, journalism, or router design).
</heavy>
fiber_r_us 12/4/2012 | 9:07:41 PM
re: Sprint Spurns MPLS for Global VPNs >Well of course, but the point is that if after
>applying filters and rate limiting you end up
>dropping legitimate packets and then impacting
>sessions between routers, you may not have
>brought down the control processor, but there
>has been an impact to the network.

Applying filters should only deny non-useful packets (protocols that are not being "listened" for on the control processor). Otherwise, the filters are wrong. I agree that rate-limiting could have a negative impact. But, the kinds of things that should be rate-limited are:

- ICMP packets
- TCP Syn packets, for BGP, SSH, or any other TCP-based attacks

This type of rate-limiting is unlikely to affect the basic operation of the network. Of course, if you rate-limit all packet types you are going to run this risk of affecting the proper operation of the network. But, I am not suggesting that such a broad-brush approach be used.
Tony Li 12/4/2012 | 9:07:41 PM
re: Sprint Spurns MPLS for Global VPNs Mark,

You wrote:

Well yes, but not all paradigms pass that state around via a control plane.

------------------

That's true, but the only paradigms that I know of that don't pass state around the control plane is the paradigm of static routing. I believe that has proven to be both labor intensive and have high latency.

---------------------

In addition, there are examples of paradigms where nodes in the network do not have knowledge of the domain-wide topology. We can argue those paradigms have some number of problems, but they do not have the same state issues. In some cases all they know is the nodes that attached to them and the links that get them there. A very bounded amount of state. Examples of this are SONET networks, and a significant part of the voice network.

--------------------------

My understanding is that the SONET layer is routed manually and that provisioning is a significant issue. Further, the SONET device has no idea about end nodes, so everything must be manually engineered, end to end. I'm also told that routing for the voice network is done statically in the switches and that the signaling leaves state in the switches that the calls transit.

For the phone network, at least, the routing is somewhat scalable because we've installed a hierarchical addressing scheme that allows aggregation and abstraction of end points. This is also the same thing that we try to do with IP addresses in the Internet. Not everyone likes either of these: phone users want global roaming, IP users want Provider Independent address space.

Tony
Tony Li 12/4/2012 | 9:07:42 PM
re: Sprint Spurns MPLS for Global VPNs How much more resource do you need to defend
the DoS attack? The distributive DoS attacking can be so malicious so that your limited resource
will get burned out quickly and normal packets can not get normal services in the attacking
and repairing time window.

The question is not DoS attack happened
before or not, but when that will happen if possible.
-----------------------------

In the limit, you need enough processing power to
authenticate all of the packets that are arriving
at the switch. This is not impossible, just more expensive than folks would like to pay for.

In any case, the only real way of avoiding a DoS attack on the infrastructure elements is to move routing and signalling to an out of band control plane. This is certainly possible, but the originators of the Internet architecture felt that it was preferable to have fate sharing between the control plane and the data plane. IMHO, this was and still is the right call.

Note that regardless of the control plane, anyone can still attack the data plane through pointless bandwidth consumption. So DoS attacks can't ever completely go away.

Tony
itisi 12/4/2012 | 9:07:42 PM
re: Sprint Spurns MPLS for Global VPNs For BGP, one thing being done is dropping TCP to the BGP port with TTL > 1; effect is to filter DOSlings from the wide world. Bump TTL a little if you multihop. OSPF and ISIS, - not an issue.

>There are routers that have logic that allows them to rate limit traffic to the control processor. The problem with this approach is that it does not discrominate between DoS traffic and legitimate traffic.
itisi 12/4/2012 | 9:07:42 PM
re: Sprint Spurns MPLS for Global VPNs <blush> Should have been, "TTL < 255". Neighbor obviously needs to cooperate.

>For BGP, one thing being done is dropping TCP to the BGP port with TTL > 1; effect is to filter DOSlings from the wide world. Bump TTL a little if you multihop. OSPF and ISIS, - not an issue.

>>There are routers that have logic that allows them to rate limit traffic to the control processor. The problem with this approach is that it does not discrominate between DoS traffic and legitimate traffic.</blush>
teng100 12/4/2012 | 9:07:43 PM
re: Sprint Spurns MPLS for Global VPNs "Rate-limiting packets to the control processor is *part* of the solution that is offered"

How much more resource do you need to defend
the DoS attack? The distributive DoS attacking can be so malicious so that your limited resource
will get burned out quickly and normal packets can not get normal services in the attacking
and repairing time window.

The question is not DoS attack happened
before or not, but when that will happen if possible.
rtg_dude 12/4/2012 | 9:07:43 PM
re: Sprint Spurns MPLS for Global VPNs fiber_r_us,

> Neither can a MPLS Martini or 2547 client.

You're assuming a very specific deployment
scenario where the client is not attached
to the Internet by any means. The security
model cannot be based on this assumption,
neither can it ignore the presence of the
rest of the Internet.

From your other post:

> When running the Internet over MPLS

from the one to me:

> If you are running the Internet on top of
> your MPLS backbone

To make sure someone suddenly doesn't
read this as if one could run the whole
Internet over MPLS, let me clarify that
we're talking about a single SP running
the Internet service using an MPLS-enabled
core :)

> in addition to offering the MPLS VPN services,
> then an Internet client could send packets
> to the IP address of the edge routers running
> BGP. But, it is not neccessary that any of
> the core routers have IP addresses that are
> routeable to the Internet (see previous post).

You are assuming a specific scenario again.
The reality is not all SPs that have MPLS
in their backbone have 2547 in it, some are
using it just for TE, some just for FRR.
In these cases renumbering would be a huge
event that most people are trying to avoid,
besides there are still admins out there who
prefer to have routeable addresses on their
router interfaces :)

> OSPF and ISIS packets are multicast in
> nature. There is no way to *forward* them
> through a router via the forwarding plane.

This is technically incorrect. While IS-IS
packets cannot be routed since they are sent
over L2 (that's why I didn't use IS-IS as
an example), OSPF packets can be. And no,
not all of them are multicast. The are sent
using only multicast on p2p links only.
On other links it's either a mixture of
multicast and unicast (on multiaccess once
the OSPF neighbor FSM reaches the Exchange
state, they're sent unicast) or only unicast
(virtual links and manually configured
neighbors.)

> The worst
> you could do with OSPF or ISIS is to send
> a stream of packets from a client device
> to the provider's router port (to which
> the client would have to be *directly*
> attached).

See above

> The provider's router would
> promptly discard such packets as the router
> would not be running OSPF or ISIS on a
> customer facing interface.

It is potentially possible to "promptly"
discard such packets from the attacker if
the MD5 check is implemented in the data plane.
However, the current installed base does this
in the control plane only, which means that
a large stream of OSPF packets from an attacker
can do some harm...

rtg_dude
Mark Seery 12/4/2012 | 9:07:43 PM
re: Sprint Spurns MPLS for Global VPNs >> But first, one filters all packets but those that might be destined to the processor ....<<

Well of course, but the point is that if after applying filters and rate limiting you end up dropping legitimate packets and then impacting sessions between routers, you may not have brought down the control processor, but there has been an impact to the network.

Obviosuly it is a trivial exercise to prevent a control processor from being overloaded. It is a non-trivial exercise to differentiate between valid and non-valid (by what ever definition you choose to make) packets; especially when the differentiation needs to be done dynamically.

-mark
fiber_r_us 12/4/2012 | 9:07:43 PM
re: Sprint Spurns MPLS for Global VPNs Rate-limiting packets to the control processor is *part* of the solution that is offered. But first, one filters all packets but those that might be destined to the processor (no point in allowing HTTP for example). Usually, you would only allow OSPF, ISIS, BGP, LDP, RSVP, SSH, and some ICMP. Then, you prioritize the basic control protocols (OSPF and ISIS) above all others for example. Then you allow BGP, LDP, or RSVP sessions in only at controlled session establishment rates (you might do this with TCP in general). SSH is only alowed in from authorized physical ports. Essentially, you are building a wirespeed firewall between the potentially hostile entities and the control processor. Several vendors offer this functionality.

Again, even without the "firewall" in place, I know of no sucessful DOS attacks on the control processors in a major provider's networks.
teng100 12/4/2012 | 9:07:44 PM
re: Sprint Spurns MPLS for Global VPNs "
There are routers that have logic that allows them to rate limit traffic to the control processor. The problem with this approach is that it does not discrominate between DoS traffic and legitimate traffic."

That is true, and rate limit will never bring
things in control due to the nature of overloading
the pipe through DoS attack.
Mark Seery 12/4/2012 | 9:07:44 PM
re: Sprint Spurns MPLS for Global VPNs Tony,

>> All paradigms put state in the network. <<

Well yes, but not all paradigms pass that state around via a control plane. That is the point I was making. Different stress points are created by trying to use one approach for state representation for *** all *** the state required (routing, QoS, ...). We have a rich set of options including control plane, management databases, and in the forwarding plane itself.

In addition, there are examples of paradigms where nodes in the network do not have knowledge of the domain-wide topology. We can argue those paradigms have some number of problems, but they do not have the same state issues. In some cases all they know is the nodes that attached to them and the links that get them there. A very bounded amount of state. Examples of this are SONET networks, and a significant part of the voice network.

-mark
Mark Seery 12/4/2012 | 9:07:45 PM
re: Sprint Spurns MPLS for Global VPNs >> How do you filter the packets into control processors? there is no way to filter it,
since filter may get burned out a big time. <<

There are routers that have logic that allows them to rate limit traffic to the control processor. The problem with this approach is that it does not discrominate between DoS traffic and legitimate traffic.

-mark
teng100 12/4/2012 | 9:07:46 PM
re: Sprint Spurns MPLS for Global VPNs fiber_r_us said

"I could envision attempting to attack control processors on the edge routers through the IP addresses that are exposed to the Internet (for those edge boxes that are supporting the Internet). But, most vendors have provided excellent controls to filter what gets to the control processor. In the Internet, I am unaware of any successful (ones that have caused serious damage) attacks on the control processors of provider's edge or core boxes. I am aware of attempts, just no major successes."

How do you filter the packets into control processors? there is no way to filter it,
since filter may get burned out a big time.
Mark Seery 12/4/2012 | 9:07:46 PM
re: Sprint Spurns MPLS for Global VPNs Mark Seery wrote:

>> You are saying that some provider is extending their core OSPF, ISIS, LDP, or RSVP instance into customer controlled boxes??? <<

Some providers offer RIP or OSPF between CE and PE for Internet access applications. This has been criticized by some operators as being a bad thing, but it happens none the less. Didn't mean to imply anyone has extended RSVP.

>> If this is true, they they will get what they deserve! <<

The more interesting question is what do the rest of us get ;-)

>> In this edge router, the customer's control plane instance is heavily filtered before the dynamic information is passed to any other control protocol (if it is dynamically passed at all). <<

If this worked all seamlessly and perfectly, there probably would not be so much garbage in the global routing tables.

>> Please tell me *why* someone would consider extending a backbone control protocol beyond their own domain? <<

Because their customer does not want to futz with BGP. Note: I am **not** defending the practice, just explaining it.

>> When running the Internet over MPLS, only the routers at the edge need run BGP. <<

And yet there are few examples of this **today**

>> The traceroute would merely show the two edges (one on the way "in" and one on the way "out" of the provider's network). <<

Agreed. Level(3) hides a lot of internal addresses by virtue of the MPLS mesh they have. My point was not to say that it couldn't be done, just that doing it is unpopular with some people.

-mark
fiber_r_us 12/4/2012 | 9:07:47 PM
re: Sprint Spurns MPLS for Global VPNs Teng 100 said:

>The problem is that when all such BGP running
>"Edge Routers" are under attcck, it is still
>make MPLS unsecure in the customer's view.

For such a BGP-running edge router, what form of attack do you envison that would affect the MPLS backbone in such a way that it would be unable to service MPLS VPNs? Give an example. Just saying it is "unsecure" without examples is purely rhetoric and not very helpful.

For the Internet "VPN" running over the MPLS backbone, it would have the same vulnerabilties that the present Internet boxes have, except that exposure would be limited only to edge boxes running the Internet VPN. On the Internet, most DOS attacks are against customer hosts or links to customers (by overloading the customer link). I know of no instances of attacking ISIS or OSPF that have occured (and don't really see how they could occur).

I could envision attempting to attack control processors on the edge routers through the IP addresses that are exposed to the Internet (for those edge boxes that are supporting the Internet). But, most vendors have provided excellent controls to filter what gets to the control processor. In the Internet, I am unaware of any successful (ones that have caused serious damage) attacks on the control processors of provider's edge or core boxes. I am aware of attempts, just no major successes.
teng100 12/4/2012 | 9:07:48 PM
re: Sprint Spurns MPLS for Global VPNs "When running the Internet over MPLS, only the routers at the edge need run BGP. Only their IP addresses would be exposed. Those IP addresses are part of the Internet and are routeable. The control plane addresses inside of the MPLS backbone do not (and should not) be exposed to the Internet"

The problem is that when all such BGP running
"Edge Routers" are under attcck, it is still
make MPLS unsecure in the customer's view.
fiber_r_us 12/4/2012 | 9:07:50 PM
re: Sprint Spurns MPLS for Global VPNs Mark Seery wrote:

>well actually this does happen believe it or
>not, but more importantly, the control plane
>extension you refer to is not the only issue.

Can't say that I believe it. You are saying that some provider is extending their core OSPF, ISIS, LDP, or RSVP instance into customer controlled boxes??? If this is true, they they will get what they deserve! While I know of numerous cases where a provider runs *a* control protocol with a customer, these control protocol instances are not the same as the provider's backbone control protocols. That is, the control protocol instance that is shared with the customer ends on the very first provider edge router that the customer's link touches. In this edge router, the customer's control plane instance is heavily filtered before the dynamic information is passed to any other control protocol (if it is dynamically passed at all).

Please tell me *why* someone would consider extending a backbone control protocol beyond their own domain?

>While the control plane extension problem can
>easily be solved by moving to static routes or
>BGP, the harder cultural issue to solve is the
>one of allowing pings and traceroutes to expose
>the internals of a network, and the interface
>addresses used (which many times have registered
>DNS names). Technically this is not necessary,
>but it happens by tradition.

When running the Internet over MPLS, only the routers at the edge need run BGP. Only their IP addresses would be exposed. Those IP addresses are part of the Internet and are routeable. The control plane addresses inside of the MPLS backbone do not (and should not) be exposed to the Internet. The backbone MPLS IP addresses could be network 10 for example. Appropriately configured, there is no way to send IP packets to the control plane within the MPLS backbone. In this mode, there is no way to "ping" or "traceroute" *through* a providers MPLS backbone. The traceroute would merely show the two edges (one on the way "in" and one on the way "out" of the provider's network).

While not fully migrated to this model yet, many providers are heading this direction.
fiber_r_us 12/4/2012 | 9:07:50 PM
re: Sprint Spurns MPLS for Global VPNs rtg_dude said:

>An ATM or FR client cannot send a control-plane
>packet directly to a switch in the middle of the network.

Neither can a MPLS Martini or 2547 client.

>In the MPLS case (especially in the MPLS TE
>case), the SP's MPLS cloud is the IP cloud
>as well and those IP addresses are
>routable, so the MPLS control plane (as well
>as IP control plane for that matter) is exposed
>to every script kido in the Net, who can start
>sending you spoofed OSPF packets.

If you are running the Internet on top of your MPLS backbone in addition to offering the MPLS VPN services, then an Internet client could send packets to the IP address of the edge routers running BGP. But, it is not neccessary that any of the core routers have IP addresses that are routeable to the Internet (see previous post).

OSPF and ISIS packets are multicast in nature. There is no way to *forward* them through a router via the forwarding plane. The worst you could do with OSPF or ISIS is to send a stream of packets from a client device to the provider's router port (to which the client would have to be *directly* attached). The provider's router would promptly discard such packets as the router would not be running OSPF or ISIS on a customer facing interface.

I agree that vendors must write solid code to ensure that things are scaleable and not vulnerable to attacks. This is particularly true about 2547. A vendor's code should include configureable limits on how many routes that can belong to a 2547 VPN and should include controls on how often that information can dynamically be changed (flapping). The last RFP I wrote requested such features. But what is new about that?
jamesbond 12/4/2012 | 9:07:51 PM
re: Sprint Spurns MPLS for Global VPNs By not doing the SAR, you're forced into keeping the switch at the L2 level, where it has to keep state for each VC. If these VCs are at a fine granularity, then you quickly have a serious scalability problem.

------------------------------

SAR's still have to deal with VCs. So if the VCs
were fine grainularity, there STILL would be a
serious scalability problem.
signmeup 12/4/2012 | 9:07:51 PM
re: Sprint Spurns MPLS for Global VPNs MPLS was originally designed to solve some very fundamental issues surrounding L3 scalability in routers. Unfortunately it has become a melting pot for many to push some really off-the-wall solutions.

But the basic premise of MPLS was to solve some nasty little quirks associated with traffic forwarding like recursive lookups. Instead of having to build faster lookup asics, MPLS allowed existing architectures to scale by removing the complexity associated with packet lookup for each and every packet onto the control plane. Yes, the tradeoff is that there is a more complex control plane, but this was being called for anyway by the SP's who wanted to take advantage of differentiated service offerings. With MPLS, you could achieve line-rate forwarding with older hardware.

There are other inherent benefits to running "pure" MPLS - let's forget about TE and VPN for the moment. With MPLS I can remove iBGP from the core of my network. I don't need it anymore since MPLS will identify the exit point for all eBGP-learned routes. This means that my core routers no longer need to worry about the complexities of an iBGP mesh or RR or confederations to ensure that my routes are propagated from edge to edge.

Unfortunately this presents somewhat of a paradigm shift as it is the edge that must handle more functions. Traditionally, most providers overbuilt the core; now with MPLS it is the edge that controls the path across the core. However, from an operational perspective, I would much rather beef up the edge in order to simplify the core.

As far as TE and VPN is concerned, both of these are a direct result of provider's input. And in each case, there is a defined business case that requires these technologies that has substantial revenues attached. The argument to just throw bandwidth at the problem has been around for ever; but the reality is that there has always been a need for bandwidth management.

I know that much of my post was a history lession that most of you already know by heart; however I sometimes feel that we lose sight of the WHY things were designed. MPLS was designed to solve some very real problems, and to meet the needs of providers who want to generate additional revenue.

Merry Christmas to all (or at least to those that celebrate it! To the rest - I wish you the best no matter what holidays you celebrate!)

signmeup
DoTheMath 12/4/2012 | 9:07:54 PM
re: Sprint Spurns MPLS for Global VPNs Tony wrote:
All paradigms put state in the network. Be it
routing tables or VC information, it is state and
it must be in the network to get bits from point
A to point B. The real question is about the
scalability of that state. If we're talking
individual routes, we've learned that you cannot
put state into the network for each individual
computer and even for each individual site.
Similarly, in a connection oriented network, you
cannot put state into the network for each
host-pair connection. Instead, you must scale
the architecture so that a given amount of state
can be used for a large traffic aggregate. If that
aggregate is large enough, then you can achieve
a workable amount of scalability.

--------------------------------------------------
Excellent point, fully granted. The question is "Is
MPLS the best way to solve the routing scalability
problem". Secondary question is
"What is the real magnitude of the scalability
problem, assuming, say, <10 billion> (use your
imagination) IP nodes in a universal all IP
network of the future".

My gut feel is that cheaper solutions (from an operational
labor standpoint, not bandwidth/CPU/memory standpoint)
are possible. Labor vs bandwidth/CPU/memory
equation only gets worse every year, unless operators
find some way to move much of their operations
offshore to cheaper locations, which will buy them
a couple of decades (that is not trivial!) until
those locations "catch up" in terms of costs.

As an engineer, I love solving complex technical
problems. I am just not sure there is an economic
return for solving such problems vs applying
cheap, inelegant, brute-force architectural
approaches that save labor.
rtg_dude 12/4/2012 | 9:07:55 PM
re: Sprint Spurns MPLS for Global VPNs Tony,

> I agree with all of your points,
> but I'll also point out that these costs are all
> either one-time costs or the result of poor
> implementations.

Some of them are one-time costs, some are recurring
(such as more frequent upgrades) or impose a permanent
increase (such as changed network maintenance). In
fact I think I grouped them so that the one-time costs
go first.

Regarding poor implementations - we all know that
all implementations have bugs, we can't eliminate
them. One could argue that most vendors have their
MPLS code stabilized enough to be at least as mature
as pure IP (which I don't necessarily agree with),
but it's as simple as having to deal with more code,
which means more bugs and increased probability of
network failure. Yes, the "keep the network stupid"
argument has been proven to be wrong, the network
is complex, but increasing its complexity even more
doesn't seem to help...

> If, in exchange for these costs, you were able to
> shave 10% off of circuit costs, would you break even
> or better? If you're not facilities based, I bet
> the answer is 'yes.'

I donno, maybe you're right... Nobody I asked could
tell me for sure... I'll keep asking :-)

> Correct, it was dkatz. Sorry, I don't recall if it
> was the New York Times or the Wall Street Journal.
> One of the two. ;-)

You're right, I think it was the Wall Street Journal ;)

Kicking my anti-mpls twin away from the keyboard
and treating MPLS as yet another rope^H^H^H^Htool
in the SP's hands again ;)

rtg_dude
rtg_dude 12/4/2012 | 9:07:56 PM
re: Sprint Spurns MPLS for Global VPNs fiber_r_us,

Starting with your last point:


> There is little different in the security
> models between ATM, FR, and MPLS.


In fact there is, and a big one. An ATM or FR
client cannot send a control-plane packet
directly to a switch in the middle of the
network.

In the MPLS case (especially in the MPLS TE
case), the SP's MPLS cloud is the IP cloud
as well and those IP addresses are
routable, so the MPLS control plane (as well
as IP control plane for that matter) is exposed
to every script kido in the Net, who can start
sending you spoofed OSPF packets.


> For converged MPLS backbones that wish to
> support the Internet along with the various
> MPLS VPN services, the Internet is essentially
> just another service. In this case, the
> provider's edge box must take measures to
> ensure that the control processor's resources
> can not be abused by packets from the Internet.


You can (and should in fact) filter at your
edges. You can't be sure your peer ISP or
his peer does the same though.

Regarding your other point:


> For MPLS applications that require control
> protocols between the provider's MPLS edge
> and the customer's edge (such as 2547), the
> provider's edge is responsible for keeping
> the customer's routing information in a
> contained environment (through VRFs or virtual
> routers).


The reality is that in 2547 the customer's
routing information is not supposed
to be contained just with the VRFs of that
PE. Instead it is supposed to be disseminated
among other PEs through MP-BGP. Now, in order
to scale your iBGP mesh for 2547, you're going
to use RRs, so we eventually have a BGP network
that accumulates all customer routes...
and route flaps :) It takes a good SW architecture
to get the PE side right. I really hope vendors
still have required clue to make 2547 safer...


> If a vendor's product does not
> adequately perform this task, then the vendor's
> product is *broken*. This is analogous to
> ATM's UNI interface; any ATM switch that did
> not protect the network from a customer's UNI
> interface is simply *broken*.


The analogy with ATM UNI is half-valid. With UNI,
the client is not "connecting" its network's control
plane with the service provider's one; it is also not
injecting in the provider's control plane information
about all its routes. What you're right about is
that it is potentially possible to drive an PNNI
inside an ATM network crazy with a malicious UNI
client (that's probably why some people prefer S-PVCs
to SVCs), as well as it is potentially possible to
drive a SP's backbone crazy with a malicious CE.

rtg_dude
Tony Li 12/4/2012 | 9:07:56 PM
re: Sprint Spurns MPLS for Global VPNs It makes sense to leave the traffic in cells (humor me on the terminonlogy) rather than SAR at each switch.

---------------------

In fact, this turns out not to be true. Keeping the data in cells on the wide area links turns out to create a considerable amount of overhead. You end up paying for this for each and every link until the packet is reassembled. The lost bandwidth is (was?) expensive enough that the cost of the SARs in each router blade are quickly paid off.

Also, there's another hidden cost. By not doing the SAR, you're forced into keeping the switch at the L2 level, where it has to keep state for each VC. If these VCs are at a fine granularity, then you quickly have a serious scalability problem.

Tony
Tony Li 12/4/2012 | 9:07:56 PM
re: Sprint Spurns MPLS for Global VPNs It is indeed. Note though, that 'labor costs' in
the MPLS TE context does not mean a bunch of college
grads reading traffic matrices, calculating LSP
paths, and punching them in. Instead those would be:

....


---------------------

I agree with all of your points, but I'll also
point out that these costs are all either one-time costs or the result of poor implementations. If, in exchange for these costs, you were able to shave 10% off of circuit costs, would you break even or better? If you're not facilities based, I bet the answer is 'yes.'

----------------------

o fixing the network brought down by the bugs
that my lab staging didn't detect (add "reading
the front page of The New York Times" here [(c)
dkatz, I think])

------------------------

Correct, it was dkatz. Sorry, I don't recall if it was the New York Times or the Wall Street Journal. One of the two. ;-)

-------------------------

Blood sucking as Randy puts it :)

-------------------------

Rhetorical question: What doesn't Randy describe as blood sucking?

Tony
Tony Li 12/4/2012 | 9:07:56 PM
re: Sprint Spurns MPLS for Global VPNs Any paradigm that espouses putting state/attributes in the control plane is eventually going to become complex, it is human nature, if all you have is a hammer....... People perhaps might consider embracing the philisopher's axiom that there is no such thing as truth, but just optimization for a result. All paradigms lead to complexity over time, it is just a matter of on what axis - that's why occassionally a clean sheet of paper might be required / or a pragmatic approach to using multiple approaches to solving a problem and not always over one plane (user/data, control, management,.....)

-------------------


All paradigms put state in the network. Be it routing tables or VC information, it is state and it must be in the network to get bits from point A to point B. The real question is about the scalability of that state. If we're talking individual routes, we've learned that you cannot put state into the network for each individual computer and even for each individual site. Similarly, in a connection oriented network, you cannot put state into the network for each host-pair connection. Instead, you must scale the architecture so that a given amount of state can be used for a large traffic aggregate. If that aggregate is large enough, then you can achieve a workable amount of scalability.

Tony
rtg_dude 12/4/2012 | 9:07:57 PM
re: Sprint Spurns MPLS for Global VPNs Tony,

Releasing my anti-mpls evil twin ;)

> You are correct in that if this resulted in
> increased labor costs, this would not be a net win.
> However, it turns out that TE is particularly
> ameanable to offline automation and optimization.

It is indeed. Note though, that 'labor costs' in
the MPLS TE context does not mean a bunch of college
grads reading traffic matrices, calculating LSP
paths, and punching them in. Instead those would be:

o time to learn and get some lab experience
with the technology,

o staging the config in the lab

o chasing new bugs and getting my vendor(s)
fix them in the code I am running just so
I'm able to start using new technology

o rolling MPLS out in the network

o fixing the network brought down by the bugs
that my lab staging didn't detect (add "reading
the front page of The New York Times" here [(c)
dkatz, I think])

o changing my service procedures

o changing my provisioning procedures (now I have
to deal with logical circuits in addition to
the physical ones)

o supporting yet another stack of protocols
in my network, with their own bugs

o dealing with new bugs introduced into
the regular IP code in the name of MPLS

o upgrading my routers more often (more code, more
state, more memory and cpu cycles needed...)

o etc., etc...

o hiring more people to do all this...

Blood sucking as Randy puts it :)

rtg_dude
Mark Seery 12/4/2012 | 9:07:57 PM
re: Sprint Spurns MPLS for Global VPNs >> However, I am unaware of any provider even considering extending the provider's network's control protocol instances (OSPF-TE, ISIS-TE, RSVP, or LDP) into a customer's link <<

well actually this does happen believe it or not, but more importantly, the control plane extension you refer to is not the only issue. While the control plane extension problem can easily be solved by moving to static routes or BGP, the harder cultural issue to solve is the one of allowing pings and traceroutes to expose the internals of a network, and the interface addresses used (which many times have registered DNS names). Technically this is not necessary, but it happens by tradition.

These interface addresses are exposed for a variety of reasons, of course the most interesting one I have heard is the insistence by some that they need this information to diagnose problems that supposed "clueless" operators can not solve themselves. Once again a people/operational/cultural/BCP issue, not a technology issue.

-mark
fiber_r_us 12/4/2012 | 9:07:58 PM
re: Sprint Spurns MPLS for Global VPNs >If (now it is) MPLS control protocols are still
>based upon IP control protocols then MPLS is
>also subject to DoS attack.

>DoS attack will be always there in the IP/MPLS
>backbone since any hijacker can send spoofing
>IPpackets to the IP/MPLS routers to launch DoS attack

Having IP control protocols within an MPLS network does *not* imply that customer interfaces have a path to those control protocols. This is like saying since I have an ATM interface connected to a provider's ATM switch, then I must be able to attack the PNNI control plane!

If a provider extends their MPLS network's control plane (or address space) to a customer device, then that provider exposes their network to DOS attacks. However, I am unaware of any provider even considering extending the provider's network's control protocol instances (OSPF-TE, ISIS-TE, RSVP, or LDP) into a customer's link. No provider would do this any more than they would extend their ATM network's PNNI into a customer's ATM switch.

For MPLS applications that require control protocols between the provider's MPLS edge and the customer's edge (such as 2547), the provider's edge is responsible for keeping the customer's routing information in a contained environment (through VRFs or virtual routers). If a vendor's product does not adequately perform this task, then the vendor's product is *broken*. This is analogous to ATM's UNI interface; any ATM switch that did not protect the network from a customer's UNI interface is simply *broken*.

For converged MPLS backbones that wish to support the Internet along with the various MPLS VPN services, the Internet is essentially just another service. In this case, the provider's edge box must take measures to ensure that the control processor's resources can not be abused by packets from the Internet.

There is little different in the security models between ATM, FR, and MPLS.
rtg_dude 12/4/2012 | 9:07:58 PM
re: Sprint Spurns MPLS for Global VPNs lightmaster,

> I sort of agree, sort of disagree. In order
> for the frame switches to continue to scale,
> they had to go to a cell architecture internally.

<snip>

> It makes sense to leave the traffic in cells (humor
> me on the terminonlogy) rather than SAR at each switch.

It is a bit more complex than that. Quite a few high-
performance IP routers (just pure IP, not ATM/FR
boxes with an IP topping) use cell-based switching
inside to ensure high-speed non-blocking communication
among the interfaces. We're still running IP in the
Internet though :)

rtg_dude</snip>
lightmaster 12/4/2012 | 9:07:59 PM
re: Sprint Spurns MPLS for Global VPNs broadbandboy said: "ATM might have been stopped dead in its tracks."

I sort of agree, sort of disagree. In order for the frame switches to continue to scale, they had to go to a cell architecture internally. Recall that Stratacom had already gone to a cell architecture internally prior to ATM. If it violates your religion to call them cells, just call them small, fixed sized packets.

It makes sense to leave the traffic in cells (humor me on the terminonlogy) rather than SAR at each switch. On the other hand, one would have expected the architecture to be built more friendly to data traffic (i.e. no 53 byte cells, etc.).




teng100 12/4/2012 | 9:08:00 PM
re: Sprint Spurns MPLS for Global VPNs BBboy wrote:

" could ATM or MPLS devices ever be subject to DOS attacks? Can address spoofing be used against ATM or MPLS networks? Or are they inherently more secure than IP devices."

Fot DoS attack, ATM is secure since the
ATM switch does not listen to IP control protocols, it uses PNNI for the routing control.

If (now it is) MPLS control protocols are still based upon IP control protocols then MPLS is also subject to DoS attack.

DoS attack will be always there in the IP/MPLS
backbone since any hijacker can send spoofing IP
packets to the IP/MPLS routers to launch DoS attack.




broadbandboy 12/4/2012 | 9:08:01 PM
re: Sprint Spurns MPLS for Global VPNs Teng100 wrote: "can you tell me how you protect all the IP routers from DOS attack, Thanks."

Teng, could ATM or MPLS devices ever be subject to DOS attacks? Can address spoofing be used against ATM or MPLS networks? Or are they inherently more secure than IP devices.

BBboy
broadbandboy 12/4/2012 | 9:08:02 PM
re: Sprint Spurns MPLS for Global VPNs Packet Man wrote: "So are you saying X.25 is better than FR, and FR is better than ATM? :o)"

No, but those are good points. Actually, I think of FR as a streamlined version of X.25 (sans error checking at every node). So one could say X.25 got better?

Certain aspects of FR did not get better, and so it was replaced by ATM in certain applications. ATM switches replaced Frame Relay switches in the backbone of frame relay networks. ATM switches replaced frame relay switches in the Internet core.

But what if the vendors had improved FR's speeds and feeds? What if Cascade had delivered OC-3 and OC-12 frame interfaces to uunet in the 90s? ATM might have been stopped dead in its tracks. Who knows, they might not have felt the need to push MPLS standardization, and today we might be arguing about fast reroute for frame relay!

BBboy
Mark Seery 12/4/2012 | 9:08:07 PM
re: Sprint Spurns MPLS for Global VPNs Tony,

>> TE is particularly ameanable to offline automation and optimization <<

Which of course just raises another religious issue in the constant struggle between control planes and management planes (distributed vs centralized, .....) - though I do agree with the statement you made.

All,

There are far more people issues than technical issues involved in this debate.

a) fight for control of technology / standards
b) resistance to learning something new (this happens with all technology - even happened when IP was introduced)
c) a lack of understanding about other people's concept of network architecture
d) the desire to fullfill the requirements of multiple markets with one technology / code base / product line ......
e) a lack of understanding about value chains
f) focus on one's own problems without understanding or caring about some one eleses
g) ...................

MPLS represents a framework for pursuing different architectural approaches to building a network. All efforts of this magnitude are overly complex - IPv6 is as well.

Any paradigm that espouses putting state/attributes in the control plane is eventually going to become complex, it is human nature, if all you have is a hammer....... People perhaps might consider embracing the philisopher's axiom that there is no such thing as truth, but just optimization for a result. All paradigms lead to complexity over time, it is just a matter of on what axis - that's why occassionally a clean sheet of paper might be required / or a pragmatic approach to using multiple approaches to solving a problem and not always over one plane (user/data, control, management,.....)

Lastly, let not a particular implementation guide all your thoughts on an approach.

---------------------

On the issue of economics, someone made the statement that voice links are only 7% utilized on average. I very much doubt this is true. It may be true for private lines (in fact it probably is) but that is different a) the transport network is not the same as the voice network - they are two architecturally distinct networks and b) enterprise is paying a market price for a fixed amount of bandwidth and they can use it how they like. TE has to do with optimizing the internal cost structure of a network, a totally different issue.

To those that think it is a labor vs bandwidth issue: Service providers clearly want to reduce the cost of both, and they see automation as one avenue to get there - there may be others.

-mark
Tony Li 12/4/2012 | 9:08:19 PM
re: Sprint Spurns MPLS for Global VPNs
DTTM,

I think that it has been proven repeatedly that ISPs need to do a better job of managing both CapEx and OpEx. Wasting bandwidth or labor are both unacceptable today.

The theory behind MPLS/TE is that by giving the carrier the ability to engineer the traffic load on his network, he can decrease the wasted bandwidth. This is a common enough notion and is accepted practice for voice and FR networks. Certain ISPs were engaging in such practices with their L2 switching fabrics long before MPLS came along.

You are correct in that if this resulted in increased labor costs, this would not be a net win. However, it turns out that TE is particularly ameanable to offline automation and optimization. And we have to automate. As you correctly point out, the most scarce resource is networking talent. Anything that can be left to a mere computer should be.

Regards,
Tony
DoTheMath 12/4/2012 | 9:08:20 PM
re: Sprint Spurns MPLS for Global VPNs lob wrote:
In other words, a real CM of those boxes is a
truly formidable task, and to my knowledge nobody
ever managed to get it right.

....
In other words, someone designing a network like
that puts his backbone at the mercy of an army of boxes
and untrusted people.
...
Networks are built for _peak_ capacity, and at
least for a single-fault survival w/o degradation
(building networks otherwise would effectively
prevent any maintenance activities - you want to
be able to turn off a piece of backbone or
transmission equipment w/o disconnecting a major
portion of your subscribers). This is why talking
about underutilization "on average" is rather
meaningless.

------------------------------------------------
Thanks for a beautiful post, lob. It seems to me that
MPLS us predicated on the philosophy: "bandwidth is
scarce, so QoS requires careful rationing and
complex coordination that arise from such rationing".
This is a proven loser argument in history. Human
mind is the only scarce resource, so anything that
taxes human mind more will end up being a very
expensive technology in the long run.

In the software industry, almost every new productivity
idea has been met with "It is too slow, it wastes CPU/memory/disk,
it will never succeed. Yet, those things never slowed down
the march of the ideas. Wasting bandwidth is a far more
viable business propsosition, if it results in increased
human productivity. Operators that optimize their networks
to conserve bandwidth rather than minimize their use of
labor will lose big time.
Tony Li 12/4/2012 | 9:08:20 PM
re: Sprint Spurns MPLS for Global VPNs
In other words, unlike MPLS-based VPN backbones, tunnel-based VPN backbones are not fragile.

-------------------


I think that you're over generalizing. You seem
to be arguing against 2547 VPNs, when that's not nearly the only way.

Another way would be an L2 MPLS service that would work exactly as FR does: statically configured LSPs at the PE box, interconnected with traffic engineered LSPs.

This has the great advantage of not burdening the ISPs forwarding tables with an unscalable number of routes.

Tony
rtg_dude 12/4/2012 | 9:08:22 PM
re: Sprint Spurns MPLS for Global VPNs andropat,

> 1. so you are saying that a gre tunnel can be used
> between 2 PE routers to exchange 2547 vpn
> information.

To make sure we're on the same page here: we're
talking about encapsulating VPN traffic, not about
exchanging VPN routes, which 2547 uses MP-BGP for.

> If one PE has multiple vrf's each with
> say the same 10.x net space then gre "key" fields
> can be used to differentiate the traffic on the far
> end PE? I have heard of running 2547 over GRE but
> not using gre itself. I would have to know more about
> this to agree.

There was a draft from Yakov and Eric (if memory serves)
on this. They recently switched to a more generic
method of encapsulating MPLS into GRE by putting the
MPLS shim header with the whole label stack inside...

> 2. My point exactly. You may be able to use IGP
> based TE and provide SLAs but not nearly as efficiently
> as using a "control" based mechanism like MPLS which
> was my point from the start. There are alot of "knobs"
> in MPLS today which allow MPLS paths to switch over
> to links with lower metrics, more available rsvp b/w,
> etc.,

They way I look at it is what you pay vs what you get.
You pay a lot for MPLS (maintenance, bugs,
staff education, blah, blah), what you get is delayed
BW provisioning, that is you will need to add more BW
sooner or later anyways, TE gives you some time to
delay this. Is it worth it? Donno, time will show.

> 3. I am not confusing anything with convergence.
> The fact is that with a gre tunnel if a link
> downstream from the tunnel starting point fails
> the tunnel still shows up. You will then be
> blackholing traffic. so a hack is to run a routing
> protocol over the tunnel and use its keepalive as
> a failure detection mechanism. this is why I
> suggested that mpls FRR using rsvp hellos or the
> "soft" state built-in to rsvp to detect link
> failures with path-tear and so forth would be
> faster.

So, we have two potential situations here: 1) link
failure with a reroute available, and 2) link
failure with complete loss of connectivity. In the
former scenario FRR is indeed better at the moment,
because we do not have fast IGP convergence yet
(when we have it, difference will be much less
noticeable.) In the latter case, FRR gives faster
notification, agreed. Advantage of IGP reconvergence
against FRR though is that an IGP will find you
a path if there's at least some way to get to
the destination, while when you use a backup LSP,
you may have a scenario where both primary and
backup are affected.

rtg_dude
rtg_dude 12/4/2012 | 9:08:22 PM
re: Sprint Spurns MPLS for Global VPNs bsd_devil,

> Please don't hide behind Tony.
> He's been gracious enough to
> explain and clarify his points.
> Feel free to correct whatever
> mistakes you have noticed in
> my previous messages.

Sure thing. See below.

> most of the TE computation happens
> within ISIS/OSPF for MPLS

Strictly speaking, no TE "computation" happens
with IGPs. LSP path computation (CSPF) is
independent from the IGP you're using.

> CSPF extensions to ISIS and OSPF are useless
> CSPF in the IGP

Strictly speaking, there's no such thing as
a "CSPF extensions to ISIS and OSPF", CSPF
does the path calculation and generally doesn't
care which IGP was used to distribute additional
link info OSPF or ISIS. Now, those mechanisms
in IGPs to provide CSPF with enough link info
are called TE extensions.

> You guys can't make a simple decision: RSVP or LDP

You're probably confusing LDP with CR-LDP here
and those are used for different purposes. We have
LDP to establish label mapping for IGP-derived
LSPs and we have RSVP-TE and CR-LDP to establish
explicitly routed (traffic engineering) LSPs.
So, RSVP-TE and LDP are not directly comparable;
RSVP-TE and CR-LDP are, but if you are confused why
and whether we need two, look at draft-andersson-
mpls-sig-decision-03.txt

> As well augment the IGPs so that apart from doing
> ECMP, they would also do tunnel-setup (just the
> way they do with MPLS)

As Tony pointed out already, IGPs do not perform
any tunnel-setup in MPLS. Putting ECMP and tunnel-
setup on the same plate is also "interesting"...

Again, I'm not a big MPLS lover, but you gotta be
careful and precise when you argue against a
technology.

rtg_dude
lob 12/4/2012 | 9:08:23 PM
re: Sprint Spurns MPLS for Global VPNs I hope folks here followed discussion between me and Tony Li, regarding merits of MPLS "fast rerouting" and TE; if not, please take a look, because I'll be skipping many points which were already discussed (i.e. the proof that properly-implemented IGPs always perform better than "fast rerouting", etc).

Today's topic is why MPLS VPNs are silly.

For anyone living in a real world, one of the most obvious facts is that things break. And in the network world most things break because people mess with them. A majority of backbone problems can be traced to configuration errors.

The change management in backbones is a major issue because any real network is always in a flux, customers coming, customers going, customers asking for new tricks.

With MPLS what you get is that backbone boxes carry virtual circuits routing information originated by edge boxes (typically, by customer premise boxes). There are tens of thousands of those boxes, and a lot of customers prefer to have some control over those, even if their own network admins do not have the right paranoid mindset or understanding necessary to keep going safely on the minefield created by the happy feature-marketing machine of OFRVs.

In other words, a real CM of those boxes is a truly formidable task, and to my knowledge nobody ever managed to get it right.

Besides CM issues, the more boxes are involved in the production of dynamic routing information, the higher chances are that one of them goes banana. Alpha particles, rodent droppings, prehistoric alpha version of IOS, whatever.

In other words, someone designing a network like that puts his backbone at the mercy of an army of boxes and untrusted people.

On the other hand, tunnel-based VPNs (be it L2TP or GRE, or SSH, or whatever) do not inject any additional routing information into the backbone, therefore limiting damage caused by problems at the periphery.

In other words, unlike MPLS-based VPN backbones, tunnel-based VPN backbones are not fragile.

The second most common source of network troubles is bugs in router software. It is painfully obvious that plain IP routing software is much simpler than MPLS+IP routing software. It also has known failure modes, and decades of experience dealing with those failures. The only place where MPLS can be as stable as plain IP routing is the fantasy world of marketroids.

Given that customers do not really care about what techie gimmicks providers use to drag bits from point A to point B, if probability of bits being delivered is acceptable and the price is right, the "customers want MPLS" argument is pretty much bogus. Customers, however, do care about network availability and reliability. So do the backbone engineers who like to have peaceful nights.

So, the only conclusion a rational person can draw is that Sprint engineering and management should be applauded for the sanity and healthy scepticism they have demonstrated by refusing to yield to the hype of the day. I believe their customers will benefit as well, from the dependable and predictable behaviour of their network services.

PS. Regarding "underutilization" argument in IP backbone networks - the voice networks with the same protection level and overload capacity as IP backbones are on average loaded to about 7% - if protection capacity and transmission of silence are factored in. For some reason nobody cries that they are "massively overbuilt".

Networks are built for _peak_ capacity, and at least for a single-fault survival w/o degradation
(building networks otherwise would effectively prevent any maintenance activities - you want to be able to turn off a piece of backbone or transmission equipment w/o disconnecting a major portion of your subscribers). This is why talking about underutilization "on average" is rather meaningless.
andropat 12/4/2012 | 9:08:24 PM
re: Sprint Spurns MPLS for Global VPNs Beltway light,

We are saying the same thing then with re: to gre vs. mpls 2547. route differentiation happends via labels and so you are saying running 2547 (mpls labels) over gre is the way it works. that I have heard of. the bottom line is that l3 vpns cannot be delivered strictly based on a gre tunnel between 2 PEs.

your point about 2547 over ldp is very accurate. however, more and more people want "constraints" so running an rsvp core with ldp at the edge for PE - PE connectivity will get more common. The will allow a TE-based core with the simplicity of loopback reachability via ldp tunnels between PE devices.

You lost me on the GRE thing. of course if you remove a destination PE from the scenario then reachability to the CEs off that PE goes away. Thanks for clearing that up for me. My point was losing a link or node "along the way". GRE tunnesl will NOT detect this failure unless a protocol is running over the tunnel. The only way to detect this failure is if the immediate node or link (if its pos) that the tunnel is created over goes down. Running a protocol over GRE is absolutely fine and many, many do this for varying reasons. The key is never to resolve your tunnel destination through the tunnel itself. the point about not being able to reduce the hello-timer of the protocol is confusing. I would rather have "hello timer" then none at all. Any what I have done in the past is simply reduced my protocol hello timer to the typical timer of a HDLC hello like 10 seconds.

Lastly, why does everyone think that MPLS must be deployed in the "thousands" of tunnels. And with RSVP hellos set too low it is a bad idea. No one I know running mpls has thousands of tunnels built and they still accomplish very good TE, offer a l2/l3 vpn service, et., The cpu speeds appearing in next-gen routers coupled with Xnix-based or "real-time OSes" can more than handle this stuff. Look at the latest test with redback and Laurel. They had no problem handling 10s of thousands of tunnels.

beltway_light 12/4/2012 | 9:08:29 PM
re: Sprint Spurns MPLS for Global VPNs >1. so you are saying that a gre tunnel can
>be used between 2 PE routers to exchange
>2547 vpn information. If one PE has multiple
>vrf's each with say the same 10.x net space
>then gre "key" fields can be used to
>differentiate the traffic on the far end PE?
>I have heard of running 2547 over GRE but not
>using gre itself. I would have to know more
>about this to agree.

don't think it should use the gre "key", the
gre "key" is mainly used for tunnel security
reasons. also, 2547 should work over IP, which
does not have a "key". Just use the mpls labels
for the VPN information, the GRE or IP is only
used to replace the transport label of MPLS.
there is no reason to change both labels,
especially a PE can have some remote PEs using
MPLS, but others using GRE/IP tunnels.

>2. My point exactly. You may be able to use IGP
>based TE and provide SLAs but not nearly as
>efficiently as using a "control" based
>mechanism like MPLS which was my point from the
>start. There are alot of "knobs" in MPLS today
>which allow MPLS paths to switch over to links
>with lower metrics, more available rsvp b/w,
>etc.,

first of all, 2547 is not mainly run over MPLS TE,
most people will run it over LDP based network,
which has the same convergence level as the IGP
based if not worse. then, if b/w is a problem
in the network, mpls TE does give more control
over the native IP "TE", but there is no free
lunch. one has to ask the question that how
to manage thousands of mpls TE tunnels, and
keep the tunnel attributes updated as the
traffic pattern changes in the network.

>3. I am not confusing anything with convergence.
>The fact is that with a gre tunnel if a link
>downstream from the tunnel starting point fails
>the tunnel still shows up. You will then be
>blackholing traffic.

in 2547, if the tunnel end is gone(e.g. the
remote PE is down), then there is no other way
to deliver this traffic to the remote CEs anyway,
so there is no need to worry about tunnel seems
to be up. IGP will finally inform the destination
of the tunnel is lost. if IGP fast convergence
is done properly, this blackholing would only
last for half a second to a second.

>so a hack is to run a
>routing protocol over the tunnel and use
>its keepalive as a failure detection mechanism.

it's always a bad idea to run dynamic routing
protocol over a gre tunnel. even if you do, you
can not set the hello holdtime too low, so the
detection of the tunnel failure will take a
long time anyway.

>this is why I suggested that mpls FRR using rsvp
>hellos or the "soft" state built-in to rsvp to
>detect link failures with path-tear and so forth
>would be faster.

well, the FRR mainly rely on the point-to-point
link signal loss detection to do the FRR locally.
use rsvp hellos too fast is not safe, and it
will not likely get down to <60ms response level.
even though the FRR for TE tunnels does give
<60ms switch-over, but it's a mess if the
network has lots of tunnels, and if the tunnel
attributes change often, it's a hell to manage
them(either manually, offline or build the
intelligence into the LSRs)

andropat 12/4/2012 | 9:08:31 PM
re: Sprint Spurns MPLS for Global VPNs routing dude...

1. so you are saying that a gre tunnel can be used between 2 PE routers to exchange 2547 vpn information. If one PE has multiple vrf's each with say the same 10.x net space then gre "key" fields can be used to differentiate the traffic on the far end PE? I have heard of running 2547 over GRE but not using gre itself. I would have to know more about this to agree.

2. My point exactly. You may be able to use IGP based TE and provide SLAs but not nearly as efficiently as using a "control" based mechanism like MPLS which was my point from the start. There are alot of "knobs" in MPLS today which allow MPLS paths to switch over to links with lower metrics, more available rsvp b/w, etc.,

3. I am not confusing anything with convergence. The fact is that with a gre tunnel if a link downstream from the tunnel starting point fails the tunnel still shows up. You will then be blackholing traffic. so a hack is to run a routing protocol over the tunnel and use its keepalive as a failure detection mechanism. this is why I suggested that mpls FRR using rsvp hellos or the "soft" state built-in to rsvp to detect link failures with path-tear and so forth would be faster.

hope this helps you clarify things!
bsd_devil 12/4/2012 | 9:08:33 PM
re: Sprint Spurns MPLS for Global VPNs Dude,

Please don't hide behind Tony. He's been gracious enough to explain and clarify his points. Feel free to correct whatever mistakes you have noticed in my previous messages. I wouldn't mind that. One of the best things about human-interaction is learning-from-your-mistakes. Hopefully, your extensive knowledge of whatever you claim it to be would enlighten not just me, but maybe others who care to read these messages.

Or is it that to avoid showing how little you know you just allude to things and not really talk about them? Thats good strategy too. If thats the case, do not embarass yourself by opening your trap, or well, typing away to glory! :)

Have fun!
Packet Man 12/4/2012 | 9:08:34 PM
re: Sprint Spurns MPLS for Global VPNs While we all share our opinions, our views, our knowledge both technical and political, lets all remember we have one common goal.....to help mankind 'talk'. I wish you all the best, have a great Christmas, and lets hope for a better telecom new year.

On the first day of Christmas,
my CEO said to me
Get that MPLS running..

On the second day of Christmas,
my CEO said to me
Do your BER,
And get that MPLS running..

On the third day of Christmas,
my CEO said to me
We need it to do GR303
Do your BER,
And get that MPLS running..

...Buy optical stock...
...Get more traffic...
...Use BGP...
...What happened to Pluris...
...They all want VPNs...
...Who made this gateway...
...Freaken board of directors...
...Whats wrong with this soft-switch...
...No Aaaaaa Teeee Mmmmmmm.
...Will it to do GR303...
...Do your BER...
...And get that MPLS running.

PM :o)++++<
Packet Man 12/4/2012 | 9:08:36 PM
re: Sprint Spurns MPLS for Global VPNs your comment:
So, whats wrong with that? Those "old dogs" account for most of the revenues and probably all of the profits in data networking. One thing I have learned in the past 14 years is that everytime something new comes along, the old stuff gets better. Remember optical vs. magnetic disk drives, 10 Mbps shared media ethernet vs. ATM LANs, etc.

My comment:
So are you saying X.25 is better than FR, and FR is better than ATM? :o)

PM
Packet Man 12/4/2012 | 9:08:37 PM
re: Sprint Spurns MPLS for Global VPNs It would concern me, however, if they are saying that Sprint's core IP network is a *routed* POS network. YUCK!
-------
Can you further example why you have these concerns?

Darnnnn, its explain, not example. Man I think I forgetting what words mean what now, :o)

PM
Packet Man 12/4/2012 | 9:08:37 PM
re: Sprint Spurns MPLS for Global VPNs It would concern me, however, if they are saying that Sprint's core IP network is a *routed* POS network. YUCK!
-------
Can you further example why you have these concerns?

PM
rtg_dude 12/4/2012 | 9:08:38 PM
re: Sprint Spurns MPLS for Global VPNs andropat,

> I need some clarification:
>
> 1. with 2547bis atleast there is a requirement
> for label stacking. one label for transport, one
> label for bgp route distinguisher, etc., how then
> will gre tunnels solve this problem? how can 2547bis
> run over gre?

you don't need the transport label since
you send a normal IP packet, and you can use
the key field in GRE for the same purpose
as the second-level label in MPLS stack (it
doesn't really encode the RD, btw)

> 2. if gre tunnels or l2tp tunnels are used and
> they always follow the igp shortest path given
> there is no TE then how can I offload or "control"
> cpe traffic or vpn traffic, etc., ?? I know there
> are overprovisioned networks but it seems crazy
> that all traffic entering a given PE will follow
> the same tunnel to the same destination. seems it
> would be nice to be able to atleast influence this
> traffic decision either per customer (src address),
> per vpn, etc.,

without mpls in your network, you do not have
explicit control over the path VPN traffic takes,
so it is indeed the igp shortest path. however,
as the article suggests, people actually manage
to run their networks without MPLS TE and still
provide required SLAs.


> 3. what about failover? gre tunnels atleast not
> until very recently or ever do not support a
> keepalive. so it is very difficult to discover
> link failures downstream. most isps that use
> tunneling run an igp or bgp over the tunnel and
> use it as a keepalive. does l2tp change this?
> with mpls you have a bevy of failover techniques
> that are automatic and quick. some quick enough
> to support voice gateway signalling.

don't remember what l2tp does.

notice that you're confusing two things: reconvergence
at the customer's level (e.g. IGP reacting to tunnel
state changes) and reconvergence within the SP's
cloud (which is what your comment on MPS FRR
alludes to.) If the cloud can quickly reconverge
it is undesirable for the tunnel to go down as
this will cause unnecessary activity at the customer's
routing level; and it doesn't really matter how
the cloud reconverges--using MPLS FRR or fast
IGP convergence (which people are already working
on.)
Tony Li 12/4/2012 | 9:08:38 PM
re: Sprint Spurns MPLS for Global VPNs Tony (if you are really "the" Tony Li)
-----------------------------------

I am, in fact. :-)

-----------------------------------

RSVP and LDP, your signalling protocols, are the classic examples of excess baggage wrought on us by MPLS. (You guys can't make a simple decision: RSVP or LDP??!!)

------------------------------------

Perhaps you weren't watching the politics and evolution of the standards. It took very little time for almost everyone to converge on RSVP. There was one holdout who didn't realize when it was time to fold.

Oh, and by the way, I never "tell" ISPs how to run their networks. They tell me what problems need to be solved and I try to figure out how to solve them. Unlike many others, I have no religion about technology other than growing the Internet.

---------------------

So, please explain where the "most of the work happens in forwarding plane" thingie comes into picture!!

------------------------

Well, that all depends on how you define "work", which is how you originally described things. My thinking was that in terms of net cycles, the forwarding plane is certainly going to require more resources than anything in the control plane. Now, another way of thinking about things is complexity. I would agree that CSPF and/or RSVP are probably the complex parts of MPLS/TE.

------------------------

I think pushing MPLS onto the world that considered GRE too heavy is the worst "revenge" anyone can take. You could have definitely designed GRE-2.

--------------------------

Well, sorry. It wasn't meant to be "revenge". The suggestion from all folks who thought GRE was too "heavy" was that we should do a connection oriented tunnel so that the expense of a source route could be amortized over many packets.

--------------------------

BTW, again, if you are the real Tony, don't forget that we are scheduled for a meeting over coffee soon after new-years.

----------------------------

Well, I just checked my schedule and I don't see you there, so you'd best send me a reminder, please.

Tony
cc_junk 12/4/2012 | 9:08:38 PM
re: Sprint Spurns MPLS for Global VPNs Reply to trouble_man, post #26.

His comments are the most important. Market and selling are what matters. Whether you think MPLS is awful or not. The number one application driving MPLS dollars right now is 2547 VPNs and not TE.

Many large enterprises are moving to 2547 VPNs from their private line or PVC based networks. This is where Sprint will have to compete. Their network based VPN offer needs to be able to compete with the other carriers like AT&T.

Problem is that most entprises are caught up with the MPLS hype. Even though they don't see MPLS, they only see a private network based IP network, they think that what makes it all possible is MPLS. MPLS has the marketing and mindshare of the enterprise customer because they equate the network based VPNs with MPLS.

Sure, 2547 or other network based VPNs could be done with other types of tunneling PE-to-PE (GRE, IP, L2TP) but marketing advantage belongs to the MPLS implementations. Sprint will have to constantly be defending their version in the market. It is not good to have to always be in a defensive position and have to constantly be explaining and justifying yourself. Sprint has a large marketing/selling challenge.

Will it be worth that challenge? The network based VPNs service from the different carriers will act the same from the enterprise point of view. But Sprint is going to be at a disadvantage from a marketing perspective, irrespective if they or others think they could possibly have the technological high ground. I have not met a single networking organization from a large enterprise that thinks MPLS is a negative.

They are and will lose a lot of their private line and FR/ATM enterprise base to the other carrier network based VPN offer. This is where the positive margins are and where the big bucks are in the carrier business (not in the Internet services).



Separately, I don't think that Sprint has the technological high ground with L2TP over MPLS. The number one drawback with L2TP for the interior tunneling to create either 2547 or Virtual router VPNs is that the carrier must create the PE-PE (or even PE-P in some VR models) connections. The carrier shouldn't have to create these full mesh topologies (much less manage a backbone topology per customer as in the VR model - just give the customer PVC service instead). To existing 200 PEs in the network add another one and you will have to create 200 new internal tunnel connections. While there is a internet draft about automatically tunneling instead of creating these tunnel interfaces, only the 2547 implementation using MPLS does it automatically. Once the edge router vendors offer another tunneling technology that is automatic and does not require the provisioning of tunnel interfaces, then those alternatives can be better than the MPLS versions (assuming the carrier chooses other ways to accomplish TE and fast reroute).
OptiFuture 12/4/2012 | 9:08:39 PM
re: Sprint Spurns MPLS for Global VPNs Dream on, folks....

The future is not MPLS, nor ATM, but IP+OPTICAL.

ATM was a necessary evil (because of low speed links) but is soon going to fade away towards the access and edge.
MPLS - too late, too complicated.

Here's how the network will look like (you don't have to agree :-) but this is how it's going to be):

- Edge multiservice routers will aggregate traffic to IP and feed it to core IP routers.
- core IP routers will be interconnected by an automated lambda switching and transport optical network (dwdm)
- the core IP routers will have multiple dwdm interfaces equipped with tunable lasers feeding into the core optical network.
- the core optical network will provide signalized uni (non-ch at the beginning) services to the core IP routers, automating the setup of the mesh.

*QoS: light up another lambda, you have 100 of them on each fiber. Cheaper and less risky than hiring PhDs to throw queuing theory at you and mess up with your network.

*TE: same answer: add a lambda. Bw is cheap. It's quick and easy. No more load balancing crap. If traffic wants to go that way, allow it, don't fight with it.

*Availability: acheived at the optical layer (APS etc).

*Risk when you mess up with the network: minimal

*Scalability: acheived using dwdm, channelized SONET and IP tunnels.


If you don't see this coming, you are living in the past.


Nostradamus





teng100 12/4/2012 | 9:08:39 PM
re: Sprint Spurns MPLS for Global VPNs "The future is not MPLS, nor ATM, but IP+OPTICAL."

if above is true, can you tell me how you protect
all the IP routers from DOS attack, Thanks.


rtg_dude 12/4/2012 | 9:08:39 PM
re: Sprint Spurns MPLS for Global VPNs bsd_devil,

I don't like MPLS more than you do, but I believe
that if you decide to argue against a technology,
you should at least know it well enough to not
sound mmmm.... not-exactly-fluent. In your case,
you've made enough mistakes in your two messages
to make you look ridiculous regardless of how
strong your real arguments are. I could've shown
you those myself, but I'll leave this to Tony.

rtg_dude

P.S. That joker's name is Yakov and yes he's doing
whatever he wants with BGP... first 2547 now L2
VPN signaling... oh, boy, don't get me started
on this.
EdmundFitzgerald 12/4/2012 | 9:08:42 PM
re: Sprint Spurns MPLS for Global VPNs Check out this book. Its full of cheap shots taken on telecom geeks and their wall-street pals. Pretty funny stuff.

My friend at Sprint says its all true or closer to the truth than you would think.

http://www.iuniverse.com/books...

Its from that tech humor web site valley of the geeks

www.valleyofthegeeks.com
bsd_devil 12/4/2012 | 9:08:43 PM
re: Sprint Spurns MPLS for Global VPNs Tony (if you are really "the" Tony Li)

First off, I appreciate your answers/explanations.

Second off, I completely realize the distinction between the signalling protocols and augmented-routing protocols. So, I am hard-pressed to disagree with you: most of the TE computation happens within ISIS/OSPF for MPLS. (Or you would have to tell us all that CSPF extensions to ISIS and OSPF are useless). RSVP and LDP, your signalling protocols, are the classic examples of excess baggage wrought on us by MPLS. (You guys can't make a simple decision: RSVP or LDP??!! And you wish to tell the ISPs how to run their networks!! Wow! Thats way too much self confidence.) (And then again, wasn't there some joker suggesting use of BGP as a signalling protocol? Of course, if you wish to insist that BGP, your own baby, is not a routing protocol, I would have nothing further to say! ;-)

I also disagree that the forwarding plane does anything significant. Its no more IP's forwarding plane, as I am sure you realize. CSPF in the IGP does the computation. RSVP does the signalling. MPLS Tunnel Manager (software) sets up the tunnels. Now all the forwarding plane has to do is lookup the top-most label, and (if its not to be popped) lookup a simple table and forward out another interface! Or tunnel for the MPLS purist. If you wish to say this isn't the MPLS forwarding plane, man, I would start having serious doubts about you being the real Tony Li. So, please explain where the "most of the work happens in forwarding plane" thingie comes into picture!!

I think pushing MPLS onto the world that considered GRE too heavy is the worst "revenge" anyone can take. You could have definitely designed GRE-2. Or GMAT maybe! ;-)

The bottom line is extremely simple. MPLS is just another tunneling technology with TOO many concepts "stolen" out of ATM. Or maybe I should say, MPLS = FR-NextGen with concepts stolen from ATM. I think the world would have been a much better place if we had augmented ATM by overcoming a few of its limitations.

I do not believe that I am leading the world towards MPLS in disguise. Heck! I would never do that mistake. I think the "mistakes" have happened because people tried to pull technologies from ATM (QoS, TE, etc) into the IP world. It was a fun experiment, but I think someday we have to conciously pull the plug on this experiment (MPLS). Its taken too much time, moeny and resources. And we are going nowhere real fast. We cannot let this experiment run amock.

BTW, again, if you are the real Tony, don't forget that we are scheduled for a meeting over coffee soon after new-years.

teng100 12/4/2012 | 9:08:44 PM
re: Sprint Spurns MPLS for Global VPNs "
Overall, I completely agree that this MPLS sh*t is taking up too much of the industry's time. I think we need to focus on really solving the problems that exist with our customers (the ISPs) rather than inventing new problems (such as MPLS) so a few can publish papers and RFCs that restate what the ATM forum did gracefully years back."

Hi bsd_devil,

I agree, and here are some news you can use.
Thanks.

http://www.lightreading.com/do...
doc_id=26075&site=lightreading
Tony Li 12/4/2012 | 9:08:45 PM
re: Sprint Spurns MPLS for Global VPNs if you really want to move traffic around dynamically, realize that MPLS cannot do it.

------------------------

As long as your MPLS implementation does "make before break", you can, in fact do this. Yes, there is a one-time issue about packet ordering right at the point of cutover.

------------------------

Hell, write your own tunneling protocol and use it.

------------------------

Did that. It got dissed because it (GRE) was too 'heavy', especially when source routing was invoked.

------------------------

If you are using dynamic traffic engineering, then most of the work is being done by the IGP anyway.

------------------------

I would argue that most of the work is in the forwarding plane. And that the signaling protocol should not (architecturally) be tied to the routing protocol.

------------------------

As well augment the IGPs so that apart from doing ECMP, they would also do tunnel-setup (just the way they do with MPLS).

------------------------

The IGPs do NOT do tunnel-setup for MPLS. That's what RSVP or LDP is for.

------------------------

I think you would be much better off focusing on IGPs, diffserv and such techniques. Scr#w MPLS.

------------------------

So far, your recommendations would lead us to reinventing something that looked almost identical to MPLS.

Tony
bsd_devil 12/4/2012 | 9:08:47 PM
re: Sprint Spurns MPLS for Global VPNs Two things:

1. if you really want to move traffic around dynamically, realize that MPLS cannot do it.

The point is MPLS is just a stupid tunneling technology with too much hype and no real value. If you achieve your traffic engineering manually, then you should be able to use absolutely any tunneling technology. Hell, write your own tunneling protocol and use it.

If you are using dynamic traffic engineering, then most of the work is being done by the IGP anyway. As well augment the IGPs so that apart from doing ECMP, they would also do tunnel-setup (just the way they do with MPLS). And again, you could use any tunneling technology. THere's no need to waste your time, effort or money with MPLS just because a bunch of jokers tell you so.

Overall, I completely agree that this MPLS sh*t is taking up too much of the industry's time. I think we need to focus on really solving the problems that exist with our customers (the ISPs) rather than inventing new problems (such as MPLS) so a few can publish papers and RFCs that restate what the ATM forum did gracefully years back.

I think you would be much better off focusing on IGPs, diffserv and such techniques. Scr#w MPLS.
troubled_man 12/4/2012 | 9:08:47 PM
re: Sprint Spurns MPLS for Global VPNs After reading the many posts two things are clear:

1.) There are many pros and cons of each technology. I think we can all agree to disagree?

2.) The greatest sales organizations within Sprint are not its customer facing sales force but its engineering departments (GMG,PCS,LTD,etc..). Let's not forget ION. They convinced upper management to throw billions of dollars at something that was supposed to be "vastly technically superior" and this product never seen the light of day. If I sound like a disgruntled shareholder, it's because I am.

The real questions Sprint should be asking itself:

Can we sell This?

It's no secret, Sprint has been losing deals left and right at home and abroad with multi-national companies strictly because of the lack of MPLS in their network portfolio. The sales force has been handicapped by this decision from day one. Think about it, a Sprint rep is going to call on a current MPLS/MPLS-VPN customer and say what? We have a MPLS-like solution? MPLS is not what it is cracked up to be? Our backbone is #1?(5 nines of reliability, .5% dropped packets etc...which is easy to achieve with 10-15% utilization--go figure) I just refuse to believe that this is the strategy!! To add insult to injury, Sprint with the exception to Sprintlink is just now making the transition to IP and IP related services, so overall their sales force(Hell, the company) is still behind the power curve as it relates to IP education. Don't believe me, call your local Sprint account rep( I just did 20 minutes ago) and ask him or her to explain the pros and cons of MPLS, even better, ask them to explain L2TPv3. As a shareholder, I'm wondering if this is just Sprint's poor attempt to save face because they missed out on about 2-3 years of "MPLS-derived" revenue. Can Barry/Kathy tell us how much that engineering decision cost Sprint? Again, cudos to engineering! Hmmmmmmm. Maybe Peter L. will start making sales calls?(I doubt it) I'm sure Equant, ATT, and Verizon, just to name a few are shaking in their boots with Sprint's latest decision.

Can the Pros to L2TPv3 outweigh the mass marketing and popularity of MPLS?

This is my greatest area of concern. In order for Sprint to overcome this obstacle they need a boat load of support from its vendors that are currently making hundreds of millions of dollars selling both MPLS solutions and capable networking gear. Do you think Nortel, Juniper and the biggest MPLS proponent of them all, Cisco are going to denounce MPLS? Don't hold your breath. In reality, that's what it's going to take and I'm confident that's not going to happen. The point I'm trying to make is how can a company of this size with so many smart people (questionable) hedge a bet on something that is literally out of their control.

To Sum things up I leave you with this:

As a company would you rather have a million-plus subscribers on your network and then explain the engineering merits for the network migration at a later date.

-or

As a company, get your ducks in a row, quadruple your marketing budget in hopes to educate the masses that your equivalent offering is vastly superior to the world's current offering(which is up for serious debate), wait for planet alignment, buy a boat load of vendor gear in hopes they'll join you in this crusade, and most importantly pray.

what's next Peter, Gigabit-token ring solutions!
-The name of the game is MARKET SHARE
-The wrong people at SPRINT seem to get laid off!






broadbandboy 12/4/2012 | 9:08:50 PM
re: Sprint Spurns MPLS for Global VPNs dsmathews wrote: "MPLS as used in #2 for corporate entities or enterprise customers (not Star Trek) as a "VPN" has marginal benifits, at best. It is simply a way for carriers to dress up an old dog (FR/ATM) and fight off cannibalization of FR/ATM networks to IPVPN."

So, whats wrong with that? Those "old dogs" account for most of the revenues and probably all of the profits in data networking. One thing I have learned in the past 14 years is that everytime something new comes along, the old stuff gets better. Remember optical vs. magnetic disk drives, 10 Mbps shared media ethernet vs. ATM LANs, etc.

My hat goes off to whoever at ATT thought up the idea for "IP-enabled" services (good marketing term, no?). Simply brilliant. It effectively eliminated the most serious limitation of Frame/ATM which was PVC scalability in large networks. It also probably pushed back mass migration of large enterprises to "pure" IP-VPNs by at least several years.

-----------------------------------

"Funny how most carriers name their products to respond to this (IP enabled FR, etc.) - as if corporate customers weren't adding their own layer 3 addressing to FR/ATM circuits in the first place."

-------------------------------

Yes, but the key is you can make all your changes at L3 without having to touch your PVCs. So now we are back to the old paradigm of dynamic routing over static links. Not having to make changes at both L2 & L3 means less chance of screwing something up.

BBboy

sid1138 12/4/2012 | 9:08:51 PM
re: Sprint Spurns MPLS for Global VPNs All of this discussion about MPLS, Sprint, and what not is interesting and informative. However, let's get to what really matters - real requirements.

For years now we have been hearing about a converged network. "Everything over one network!" In order to get that to work, that network needs to provide the following features:

1) High utilization. Over provisioning will not cut it in a converged network because then services will be too expensive. The network will need to be able to run at 80% utilization for long periods of time (hours).

2) Multi-pathing/traffic engineering. The network owner will need to be able to quickly and easily move traffic around the network. This is to reduce congestion while maintaining high utilization across the network.

3) Guaranteed bandwidth VPN. If I am paying for 25 megabits per second bandwidth I want 25 megabits per second - always. Not some nominal, long term average.

4) Real time traffic that is real time. This means that the traffic is flowing across a network with constant delay, little (less than 50 microseconds) jitter and no queuing packet loss - ever. I want my real time voice, video, medical data, game data, scientific data, or any other real time data to have no network induced jitter, unusal delays, or other artifacts. The packet switched environment must meet or exceed the circuit switch environment.

5) I want the ability to add redundancy to my traffic to be able to get 99.999% or better availability. If I am running a remote surgical procedure using streaming video and data controls, interruptions are life threatening and will not be tolorated

6) And, I want all of this at a cost that I can afford. This means the equipment needs to be cheap and off the shelf, the network needs to be relatively easy to manage and control, utilization needs to be high, and protocols need to be simple. In short, I want all of this using IP, preferable over Ethernet but also over DS-1, DS-3, Sonet and OC3/12 links.

I can tell you right now with 100% surety that MPLS will never meet these requirements. ATM does not meet these requirements. There is no publicly available network system that meets these requirements. Until there is, Convergence remains a pipe dream and a lab experiment. It will not become a reality until these requirements can be met.
hey_tedd 12/4/2012 | 9:08:53 PM
re: Sprint Spurns MPLS for Global VPNs Interesting decision from Sprint, but not that surprising.
A lot of the high level R&D work and stance that Sprint has is related to just plain IP traffic marking or reacting in the core to the different TOS labels of standard IP flows, which in the core may be all that is needed, similar to the C&W strategy in their core. The other strategy is related to Ipv6 and the view that this is the true next generation protocol for the backbone. I can understand their view and strategy, especially under the pressures of the current economic environment, any strategy that conserves cash and uses G«£safe technologiesG«• is more in character of a large carrier, which will take its time in deciding what the long-term technology investments should be. At the present time it is politically correct to save your job at all costs! Minimizing any dangerous technological investments is the safe bet for folks that do not want to lose their job.

The MPLS developer community has to stop blaming others for their shortcomings and work humbly to produce the needed solutions, here are some of the things that folks should keep moving on:

Low cost MPLS architectures to provide aggregation and fast recovery from the edge and the core.

End-to-end encryption and security as part of the MPLS VPN architecture needs to be added.

Authentication needs to be added as part of the structure for generating client access and revenue. It would be great if a low cost MPLS UNI existed that could glue the CPE automatically to the carrierG«÷s network. All is needed is an e-mail to the user with some PKI parameters, add SSL or PKI like features to the MPLS-UNI!

Billing and mediation services as part of the overall carrier MPLS backbone, so carriers can mix and share traffic dynamically, this will allow carriers to create global networks quickly and be billed for it!!!

Revenue generating applications need to start using MPLS!!! How to add VoIP that is secure and redundant for clients that use MPLS VPN backbones.

SIP and other signaling protocols need to be added as part of OAM and recovery procedures for CR-LDP.

LSP recovery procedures have to prove they have the needed OAM features, from the edge to the core.
dsmathews 12/4/2012 | 9:08:54 PM
re: Sprint Spurns MPLS for Global VPNs Let's try to think of 2 ways to use MPLS -

1) as a traffic mgmt/core network mechanism for carrier networks

2) as a consumable "VPN-like" technology for corporate users

MPLS as used in #1 for carriers is a good thing, given you have a redundant/diverse network and potential need for congestion management in various locations of your network.

MPLS as used in #2 for corporate entities or enterprise customers (not Star Trek) as a "VPN" has marginal benifits, at best. It is simply a way for carriers to dress up an old dog (FR/ATM) and fight off cannibalization of FR/ATM networks to IPVPN.

Funny how most carriers name their products to respond to this (IP enabled FR, etc.) - as if corporate customers weren't adding their own layer 3 addressing to FR/ATM circuits in the first place.

So - try to focus on one of these scenarios when giving your perspective of the MPLS marketspace, as they are VASTLY different.

Sprint may choose to use MPLS in it's core IP network as a traffic engineering mechanism, but end consumers would never see this.

It would concern me, however, if they are saying that Sprint's core IP network is a *routed* POS network. YUCK!

It seems obvious by the article that Sprint has elected to NOT use MPLS as a customer facing "VPN" product.

beetlejuice 12/4/2012 | 9:08:55 PM
re: Sprint Spurns MPLS for Global VPNs They have L2TP wrapped under FAST MIM. In such a case, L2TP is far exceeds MPLS.
andropat 12/4/2012 | 9:09:00 PM
re: Sprint Spurns MPLS for Global VPNs I need some clarification:

1. with 2547bis atleast there is a requirement for label stacking. one label for transport, one label for bgp route distinguisher, etc., how then will gre tunnels solve this problem? how can 2547bis run over gre?

2. if gre tunnels or l2tp tunnels are used and they always follow the igp shortest path given there is no TE then how can I offload or "control" cpe traffic or vpn traffic, etc., ?? I know there are overprovisioned networks but it seems crazy that all traffic entering a given PE will follow the same tunnel to the same destination. seems it would be nice to be able to atleast influence this traffic decision either per customer (src address), per vpn, etc.,

3. what about failover? gre tunnels atleast not until very recently or ever do not support a keepalive. so it is very difficult to discover link failures downstream. most isps that use tunneling run an igp or bgp over the tunnel and use it as a keepalive. does l2tp change this? with mpls you have a bevy of failover techniques that are automatic and quick. some quick enough to support voice gateway signalling.

thx for the input.
jepovic 12/4/2012 | 9:09:03 PM
re: Sprint Spurns MPLS for Global VPNs Let's take the MPLS arguments one by one:
* Layer 2 VPNs. Sure, it works with MPLS, but it works just as well over IP as Sprint argues.
* QoS. That's DiffServ, and has nothing to do with MPLS
* Traffic Engineering: Only useful when you have trouble with load balancing on expensive links. In most cases, it's useless.
* MPLS VPNs: Could be, and will be, done just as easily with GRE tunnels.

The IP/MPLS/SDH network is similar to the IP/ATM/SDH network, and we all know where that went. MPLS doesn't add any new boxes, but it adds complexity. It makes the network harder to manage, makes the software less stable etc. It's just not worth the hassle.

MPLS will keep growing a while, and then the hype will disappear. In 2-3 years, operators will look at their networks: MPLS, couldn't we get rid of that?
BobbyMax 12/4/2012 | 9:09:07 PM
re: Sprint Spurns MPLS for Global VPNs MPLS has not been tested in large networks. Its usefulness is questionable. At the best it can be tried at the edge. If congestion is an issue for a provider, it can be tried within a portion of the network, If there is enough bandwidth, that is utilization is no more than 60%, MPLS need not be deployed. The Sprint experience provides enough experience about MPLS.
AliasCC 12/4/2012 | 9:09:07 PM
re: Sprint Spurns MPLS for Global VPNs bbboy,

Your descriptions of Sprint's various IP-VPN offers are correct - and it's nice to see you got the naming correct on the FR network IP-VPN: "IP Intelligent FR" as opposed to "IP enabled FR" which is the name of the comparable service offered by AT&T.

fiber_r_us and netgenius,

You both had incorrect or only partially correct descriptions of the services & networks. And your comments on scalability are not worth debating - the VR-based service does scale quite well - and there are plenty examples of carriers having scaling issues with 2547. Vendors always make claims of scalability and performance with "marketing numbers" - Cisco is usually the best at this. Regardless, both technologies and vendor implementations will scale well enough for deployments and the numbers will always be improved upon over time.

Sprint is not considering MPLS in either the Frame/ATM network or SprintLink - and for you to suggest that adding MPLS to the FR/ATM network would provide a more reliable IP service (or better QoS) is ludicrous. This is what FR & ATM excel at, with 10+ years of live deployments to help improve it. Adding another control plane that is not even finalized in the standards to attempt to replace what is proven to work and make money for the service provider to gain the exact same service offering, but with lower reliability and CoS instead of Qos??

ACC
netgenius 12/4/2012 | 9:09:09 PM
re: Sprint Spurns MPLS for Global VPNs digerato: Sprint has more than 1 type of IP VPN. Most are offered over SprintLink. IP enabled Frame ,which is another type of VPN, is not offered over SprintLink. It is offered over Frame/ATM network and it does not use Cisco but Nortel/Marconi/NEC.

This ATM edge/core network is where Sprint is looking at MPLS as a way of offering additional highly reliable connection based IP VPN services (over Frame, ATM or Pos).

I concur with your view of SprintLink.
netgenius 12/4/2012 | 9:09:09 PM
re: Sprint Spurns MPLS for Global VPNs Interesting. The below description is correct except it doesn't mention that this service runs over ATM.

"a. IP Intelligent Frame - an IP-enabled Frame Relay service apparently designed to prevent mass defection of customers to AT&T's IPFR service. Sprint claims it has "all the customer facing benefits" as AT&T, except that instead of MPLS Sprint's is based on the "virtual router" concept. The platform is Passport, 7480 & 15K. Access is frame, core is IP routing protocols."
broadbandboy 12/4/2012 | 9:09:10 PM
re: Sprint Spurns MPLS for Global VPNs Hold your flames, I know its spelled Cosine, not cosign.

B
broadbandboy 12/4/2012 | 9:09:10 PM
re: Sprint Spurns MPLS for Global VPNs I am seeing a lot of posts that are only partially correct, kind of like a bunch of blind men trying to describe an elephant. You all have a piece of it, but nobody has the complete picture.

I can add another blind guy's point of view:

According to an article in "Network Technology Report," Sprint has a number of VPN offers, none of which use MPLS.

a. IP Intelligent Frame - an IP-enabled Frame Relay service apparently designed to prevent mass defection of customers to AT&T's IPFR service. Sprint claims it has "all the customer facing benefits" as AT&T, except that instead of MPLS Sprint's is based on the "virtual router" concept. The platform is Passport, 7480 & 15K. Access is frame, core is IP routing protocols.

b. Sprint also offers "managed premise-based (CPE) VPNs which run over the Sprintlink IP backbone.

c. Sprint has a network-based VPN service running over Sprintlink but using Cosign boxes for tunneling and security (IPsec).

d. Sprint also has an offer called Sprintlink Frame Relay, which transports Frame or ATM encapsulated over IP.

------------------------------

Sprint keep referring to the Virtual Router concept, which is outlined in a recent IETF draft to which Sprint is the main contributor:

draft-ietf-ppvpn-as-vr-01.txt

Allow me to paste a few lines from the applicability statements that sheds some light on what Sprint is doing:

"VR-based PPVPNs are used in the following situations:

- The customer wishes to outsource the maintenance and management of inter-site VPN connectivity to the Service Provider (SP).

- The SP desires to provide VPN service without upgrading its core network to support any specific technology (e.g., MPLS), i.e., the SP wants to provide a Layer 3 VPN service over a range of core network technologies, including existing IP routed or Layer 2 switched core networks, MPLS, or a combination of these technologies."

I think that about sums it up.

Any thoughts?

BBboy

digerato 12/4/2012 | 9:09:13 PM
re: Sprint Spurns MPLS for Global VPNs Sprint's IP VPN service is running over the Sprintlink backbone. The backbone is based on Cisco GSRs with POS. There is no ATM or frame relay involved (whichever Nortel cheerleader that was posting earlier, trying to grab some of the credit -- good effort, but no cigar)

To allow Sprint's customer base to use whatever IP addressing they like, Sprint is using L2TPv3 as the tunneling technology. This encapsulates the frame containing the customer's traffic inside an IP packet. This packet is routed across the Sprintlink core just like any other packet and finds its way to the destination router (an L2TPv3 "LNS") via the usual IP forwarding mechanisms. There, the LNS strips off the IP wapper and delivers the frame safely into the destination customer network.

As someone else pointed out earier, Sprintlink's backbone is massively overbuilt (as most IP backbones tend to be). A feature that MPLS offers that L2TPv3 does not is the ability to control the path of the traffic across the network. That's why MPLS bothers with the label switched path concept. If your IP backbone is largely empty, you don't need that path control because you don't have to care about carefully controlling the traffic paths (i.e. traffic engineering) for the purposes of maximising network utilization and avoiding congestion. So, this is why they didn't use MPL -- they don't need it with this kind of network design.

Whether this is financially viable long term is another matter entirely. Judging by the conversations I've had with people at different levels in carriers regarding the utilization of their IP backbones, there seems to be a major disconnect between the CFO's office and the IP ops / IP engineering teams. The CFO's office wants to minimize overprovisioning to reduce costs, but the IP eng/ops teams are used to desingning networks to be mostly empty most of the time. That's how they're able to offer their service guarantees.

Digerato
fiber_r_us 12/4/2012 | 9:09:13 PM
re: Sprint Spurns MPLS for Global VPNs good description digerato.

So, where is the L2TPv3 tunnel terminated? At the customer CPE? Or is there some new edge device that offers the encapsulation?
FatherConfessor 12/4/2012 | 9:09:15 PM
re: Sprint Spurns MPLS for Global VPNs If their engineers think L2TP is a better technology than MPLS, they are idiots!
andropat 12/4/2012 | 9:09:15 PM
re: Sprint Spurns MPLS for Global VPNs isn't he done yet... retired or something. what does he mean by "all customers will see is better performance". I can't believe sprint still pays this fool. geeee peter I wonder who is pushing l2tpv3 these days... maybe CISCO. retire already.. you are annoying.
fiber_r_us 12/4/2012 | 9:09:17 PM
re: Sprint Spurns MPLS for Global VPNs Thanks netgenius, you beat me to it. I was having a hard time understanding what exactly changed in Sprints offering here:

1) Sprint already has a FR offering with QOS over traditional FR and ATM switches. To call this "IP enabled" seems simply like a marketing term. There is nothing "IP" or MPLS about it. And yes, it makes them money and they are not in a hurry to replace it... yet.

2) Sprint has a separate Internet backbone that uses POS via GSRs. I don't think they offer VPNs directly on this structure. They may offer CPE-based "managed VPN" service where a CPE box does IP tunneling over their Internet backbone.

3) The article mentions that they are using L2TPv3 over a "strait IP network". Over their Internet backbone? Or is this some new IP network?

4) If it is a new network, how is this moving them towards a converged network? Sounds like one more overlay network.

5) "Sprint says its IP VPN service allows for secure remote access, extranet capabilities, and data encryption -- none of which, it claims, are possible with MPLS." Huh?? Secure remote access? Are we talking about dial-up L2VPNs here? Extranet capabilities? What does that mean? Data encryption? Other than IPSEC (which can be done over MPLS or any other technology that IP runs over) how does this get them encryption?
gigeguy 12/4/2012 | 9:09:17 PM
re: Sprint Spurns MPLS for Global VPNs "It is good to see that the voice of reason, as embodied by Peter L, still holds sway at Sprint."

Yeah, right! The only reason that they don't need MPLS traffic engineering on Sprintlink is that they they run it at about 5% utilization. You don't have to worry about congestion or traffic engineering when the router queues are always empty. Peter's answer is to throw money at the problem by running a very inefficient network. Hey, it works if you've got money to burn!
netgenius 12/4/2012 | 9:09:18 PM
re: Sprint Spurns MPLS for Global VPNs 2bits. Partly right, mostly wrong.

Right: Sprint is offering IP enabled Frame relay VPNs over the ATM/Frame network. (the frame edge is Nortel Frame and the ATM core is Marconi/NEC). This passport 7k solution does not scale and will need to be replaced soon. I agree, it is clever and more importantly relatively inexpensive for Sprint to deploy.

Wrong: The IP enabled Frame VPN is a small part of the Sprint IP VPN offering. Sprint offers a wide array of IP based VPNs provided over their SprintLink network (a seperate network from the ATM/Frame network). This article ambiguosly only discusses the SprintLink IP network and I see where you could get confused. The Sprint ATM network is an entirely different story.

The Sprint ATM network is a seperate network from SprintLink (both are part of GMG) that IS being considerd for an MPLS overlay in order to appease customers that insist on IP-VPNs with ATM grade QoS (you would be suprised at how many there are). This would provide Sprint with a scaleable frame and ATM IP-VPN solution with 2547Bis. The author of this article either does not know the Sprint network structure very well or must have thought the title Sprint Spurns MPLS was more catchy than the truth.
bsd_devil 12/4/2012 | 9:09:24 PM
re: Sprint Spurns MPLS for Global VPNs SUPERB MOVE. FINALLY THERE ARE SOME TECHIES WHO REALIZE THAT MPLS IS ALL BS. WAY TO GO! LETS ROUT MPLS OUT OF THE NETWORK. ITS USELESS PIECE OF JUNK THAT DOESN'T AND CANNOT WORK. JUST A FEW DAYS BACK I GAVE THE MPLS GROUP AT MY PLACE AN OPTION: SWITCH TO SOME OTHER PROJECT OR LEAVE! EVERYONE SWITCHED HAPPILY AND EAGERLY! ;-)

OK! GOTTA GO INVEST IN SPRINT.
2bits 12/4/2012 | 9:09:25 PM
re: Sprint Spurns MPLS for Global VPNs Sprint has a clever way of doing IP-VPN that a few carriers have taken advantage of. They're running IP-VPN over their existing ATM network, which I believe is Nortel based. This gives them ATM-grade QoS and CoS without having to chase MPLS standards or 'evolve' the network.
x-man 12/4/2012 | 9:09:28 PM
re: Sprint Spurns MPLS for Global VPNs It is good to see that the voice of reason, as embodied by Peter L, still holds sway at Sprint while the other sheep talk of 'checkbox items'. It is overly complex, brings very little of value to the table, and makes my network less stable, but I have to have it because it is a checkbox item. This kind of thinking clearly evinces the progress of the stupidity epidemic. For those who weren't there, cisco created 'tag switching' to counter Ipsilon. This turned out to be unnecessary as Ipsilon died the death deserved by overhyped and poorly thought out technologies. At that point cisco should have said 'we were only kidding, we're not really going to implement this crap', but some marketing wonk got ahold of it and now you have this pervasive mythology.
ATM is dead, long live ATM.
boozoo 12/4/2012 | 9:09:31 PM
re: Sprint Spurns MPLS for Global VPNs I'm sure the folks at Sprint are not stupid.
I'm wondering whether their decision is based on a very healthy, easy-to-manage and reliable optical transport layer that would render MPLS deployment useless.

Boozoo
muttsnuts 12/5/2012 | 12:53:37 AM
re: Sprint Spurns MPLS for Global VPNs Snip

Separately, I don't think that Sprint has the technological high ground with L2TP over MPLS. The number one drawback with L2TP for the interior tunneling to create either 2547 or Virtual router VPNs is that the carrier must create the PE-PE (or even PE-P in some VR models) connections. The carrier shouldn't have to create these full mesh topologies (much less manage a backbone topology per customer as in the VR model - just give the customer PVC service instead). To existing 200 PEs in the network add another one and you will have to create 200 new internal tunnel connections.

This full mesh creation theoretically could be a problem however I know this is at least addressed by Cosine's provisioning system. I'd guess any one else opting for these tunneling methods would do the same.
cc_junk 12/5/2012 | 12:55:09 AM
re: Sprint Spurns MPLS for Global VPNs dreamer101:
"I was right about Qwest but wrong about BellSouth being Cosine's customer..

http://www.cosinecom.com/about..."

Thanks. But specifically you said Qwest (and originally Bellsouth) were using the VR ability of Cosine. No mention of that at your url above. I am very interested in what the LECs are thinking/planning for their network based VPNs.
beltway_light 12/5/2012 | 12:55:21 AM
re: Sprint Spurns MPLS for Global VPNs >This is to say, currently MPLS do not have end to
>end coverage for most part of the customers,
>using IPsec to reach remote site instead.
>if that is the case, why just use Ipsec all the
>way? unless IP addresses is running out soon?

you are talking about cpe based vpn, we were
talking about ISP-based L3 vpn. Let's assume
some customers do want use ISP-based L3 vpn
service, than there is no need for CEs or even
PEs to have full-meshed IPSec tunnels. The
whole idea of rfc2547 is to get rid of full
meshed tunnels to the edge or cpe routers.
but there is some cases, "dialup" users do
want to access their internal network, now
that internal network is part of the provider's
"vpn". so the provider may offer some kind
of IPSec termination device to bring those
dialup users into their associated vpns(through
the provider's backbone). but this particular
funtionality has nothing to do with VR based
or "vrf" based ISP-serviced vpn.

teng100 12/5/2012 | 12:55:22 AM
re: Sprint Spurns MPLS for Global VPNs dreamer101,

How do you think VR bring the value to
a customer, interested to know your opinion.

Thanks
Teng100
sgan201 12/5/2012 | 12:55:22 AM
re: Sprint Spurns MPLS for Global VPNs Hi cc_junk,
I was right about Qwest but wrong about BellSouth being Cosine's customer..

http://www.cosinecom.com/about...
teng100 12/5/2012 | 12:55:23 AM
re: Sprint Spurns MPLS for Global VPNs "if you think people will exclusively use cosine
and shasta for vpn, then you must be dreaming.
even the people work for cosine or shasta won't
dare have such a dream. the only thing the
cosine box add to the picture is it has some
kind of IPSec card in the box, so it does
add some IPSec remote VPN access into the
network. but not many ISPs have such a
requirement."

This is to say, currently MPLS do not have end to end coverage for most part of the customers, using
IPsec to reach remote site instead.
if that is the case, why just use Ipsec all the way? unless IP addresses is running out soon?
beltway_light 12/5/2012 | 12:55:23 AM
re: Sprint Spurns MPLS for Global VPNs >4) If you have a Cosine only or Shasta only
>network, why the hell do you want to run
>RFC 2547?? It adds overhead and provide with no
>additional functionality to your VR solution..

if you think people will exclusively use cosine
and shasta for vpn, then you must be dreaming.
even the people work for cosine or shasta won't
dare have such a dream. the only thing the
cosine box add to the picture is it has some
kind of IPSec card in the box, so it does
add some IPSec remote VPN access into the
network. but not many ISPs have such a
requirement.
sgan201 12/5/2012 | 12:55:25 AM
re: Sprint Spurns MPLS for Global VPNs Hi beltway_light,

1) "If implemented correctly" is the key phrase

2) VR based IP VPN do not need RFC 2547 to work. It can be deployed without RFC 2547 if it turns out that RFC 2547 is flawed. Implementation without VR do not have this choice.

3) VR based IP VPN can always do its proprietary things and only do RFC 2547 at the gateway box to some stupid boxes..

4) If you have a Cosine only or Shasta only network, why the hell do you want to run RFC 2547?? It adds overhead and provide with no additional functionality to your VR solution..
beltway_light 12/5/2012 | 12:55:28 AM
re: Sprint Spurns MPLS for Global VPNs >A) RFC 2547 is widely deployed and market
>leader -> wrong
>
>B) RFC 2547 implementation is working -->
>questionable"

this Virtual Router MPLS VPN vs RFC 2547
discussion is rather silly. this is because
there is no technical significant difference
between the two if implemented correctly.
Both the VR and "vrf" implementation has a
VPN-based routing table/forwarding table for
each MPLS vpn. VPN customer's routes are
imported into this "vpn" RIB, further
being redistributed into mbgp to be used as
the signalling for mpls labels. It does not
matter the implementation is a VR based or
a "vrf" based, the mechanism is EXACTLY the
same. The only big difference between these
two(not really has anything to do with rfc2547)
are admin and network management issues. for
a VR based VPN, a user can "physically"
telnet/ssh into that VR, ping/traceroute from
that VR(even though for the "vrf", one can
ping/traceroute by specifying which vrf table
to use); it's a little cleaner for the
vpn configurations, since there is a VR block
instead of configuring everything reference to
the "vrf" name. But my guess is that the VR
carries a little more overhead than the "vrf"
implementation. so to claim that the VR is
more scalable than "vrf" for rfc2547 is probably
a propaganda.
cc_junk 12/5/2012 | 12:55:29 AM
re: Sprint Spurns MPLS for Global VPNs dreamer101:
"As per Cosine, you can check out their announcement, I think Bellsouth and Qwest is using it for VR based IP VPNs.."

I would definitely be very interested in any announcements about this, in particular for Bellsouth. Can you point me to such?
sgan201 12/5/2012 | 12:55:30 AM
re: Sprint Spurns MPLS for Global VPNs Check out Savvis and a few other SPs..
Probably including Sprint..
They are using Shasta for VR based IP VPN..

As per Cosine, you can check out their announcement, I think Bellsouth and Qwest is using it for VR based IP VPNs..

Hi Folks,
Both NT and Cosine are being politically correct talking about RFC 2547... It is the same thing like NT selling VoATM but claiming in future it will be VoIP. This is the same old trick..
cc_junk 12/5/2012 | 12:55:30 AM
re: Sprint Spurns MPLS for Global VPNs reply to dreamer101 post#289:

"The last time I look, the top two equipment vendors in L3 Network based VPN are:

1) Cosine

2) NT's Shasta.

They are both Virtual Router based. By the way, even Equant (supposedly the strongest RFC 2547 supporter) is starting to buy Cosine box in 7/2002.

So, your argument about

A) RFC 2547 is widely deployed and market leader -> wrong

B) RFC 2547 implementation is working --> questionable"

------------



I didn't say anything in my post about market leadership. My post was in response to an earlier claim that there are no services that justify MPLS use.

But since you bring it up, I do not know of any significant market presence of virtual router based VPNs (ala RFC2764 VPRN model as in ppvpn-vpn-vr draft). Sprint's is a very recent pre-announcement with incomplete details. Can you point to any others?

A market research firm touts Equant's MPLS IP VPN service as the leading IP VPN service in Europe
http://www.equant.com/content/...

Note that CPE based, enterprise managed tunneling IP VPNs has a larger market share currently than the provider IP VPN services. But the discussion here is about provider service markets. And I don't deny that Cosine and Shasta lead the remote access and tunnel termination market, but that application is not network-based enterprise VPNs.

I notice that both Cosine and Nortel this past year are now pitching their virtual router technology for 2547 VPNs. Seems to me they are following the 2547 market rather than leading with VR. In fact Cosine is pitching their VR version of 2547 as a being a superior scaling approach to other vendors 2547 implementation.

Also, just Equant using Cosine means you can jump to the conclusion that Equant is going to VRPN? Can you show any evidence that Equant is planning to use Cosine's aggregation box for the purpose of VRPN? I think you miconstrued the announcement. Quoting from Equant in the Cosine press release "By deploying CoSine's equipment ... Equant will be able to provide access to its Virtual Private Network (VPN) services via broadband DSL. ... We were looking for an intelligent carrier edge device that would allow us to leverage diverse access methods such as DSL, cable modems and others while moving customer premise functionality into the backbone..." Didn't see anything in the release other than traditional remote access use of Cosine so that Equants customers can access Equant's network based VPN service (which is 2547).

Your other comment:
"L2 VPN
A) Just because SP can sell inferior FR/ATM services via MPLS box, it does not mean enterprise will buy it."

---

I agree with you. I don't know that L2 VPN will allow these new entrants to compete successfully in the traditional enterprise FR/ATM service market (in spite of announcements like Level 3 of service for Cox, which is really a com provider itself). If after time it matures and is no longer "inferior" it could just inject more competition into what has been a very profitble decent margin business. My point in my post was that L2 VPN is a service justifying MPLS deployment for certain providers when the assertion was there were no services being enabled by MPLS.
Mark Seery 12/5/2012 | 12:55:33 AM
re: Sprint Spurns MPLS for Global VPNs >> In this case, why the FR/ATM customers want to buy into this gateway/medition services that will cut down the fine ATM QoS and feel less secure. I believe, it will be hard to convince the FR/ATM customers. <<

I have no great insight into what % of enterprise customers will buy into layer 2 services over an MPLS core, so I won't get in to an argument about that. Your opinion is your opinion, and you have a right to that.

But let me throw some other thoughts at you.

If IP/MPLS routers evolve to have fine-grain QoS, then it is a mute point. So I'll let you look in to your own crystal ball and determine for yourself what might happen there.

If IP/MPLS routers do not evole to have fine-grain QoS then the issue becomes how many Frame customers really a) benefit from this with the applications they are using and b) value it. Once again, I have no great insight and I won't try to make an argument one way or the other. Customers that really need the high-end features in ATM are obviously going to be the ones most reluctant to move.

At any rate, what we are talking about is cap and grow strategies and a transition that will take many years. The real issue is how are the questions posed answered for *new* customers/incremental business (cap-and-grow), and could objections to moving to a new technology base be overcome through incentives (such as lower pricing which has been tried for IP VPNs) and for what % of the business. Also, could new market opportunities open up that would provide growth for these new networks/technologies (for example Cable subscribers, wireless data,.....)

There is nothing easy about this scenario for SPs with existing large Frame/ATM bases (for ones without it, the decision tree is much simpler IMO), and there are way more questions than answers, but none the less, the world goes forward and SPs will need to as well - especially those with a vision of how new architectures can bring them significant benefits.

The comment made by netskeptic about how SPs should just do maintenance spending feels a little bit like what is going on, but of course few vendors want to see this scenario exist for much longer. In the end, the decision is made by the existing FR/ATM vendors. What they are able to do, or not, has a large bearing on the rate of change here, and if their business leads determine that the FR/ATM market is not worth investing in, then of course SPs have no choice but to move on. Once again, you can't always put two protocols side by side on a piece of paper and determine, with any certainty, which one is going to win.

-mark
teng100 12/5/2012 | 12:55:40 AM
re: Sprint Spurns MPLS for Global VPNs Mark:
"With out going in to details, I think ships in the night is only a scenario if MPLS fails to meet the requirements of some services. If MPLS can do it, then I think the most likely scenario is gateway/medition functionality in the edge for both data/user plane and control plane."

In this case, why the FR/ATM customers want to buy
into this gateway/medition services that will cut down the fine ATM QoS and feel less secure. I believe, it will be hard to convince the FR/ATM customers.
sgan201 12/5/2012 | 12:55:46 AM
re: Sprint Spurns MPLS for Global VPNs Hi cc_junk,
The last time I look, the top two equipment vendors in L3 Network based VPN are:

1) Cosine

2) NT's Shasta.

They are both Virtual Router based. By the way, even Equant (supposedly the strongest RFC 2547 supporter) is starting to buy Cosine box in 7/2002.

So, your argument about

A) RFC 2547 is widely deployed and market leader -> wrong

B) RFC 2547 implementation is working --> questionable

L2 VPN
A) Just because SP can sell inferior FR/ATM services via MPLS box, it does not mean enterprise will buy it.

B) Before Fiber_r_us start flaming me, I check that Level 3 only sell bandwidth in chunk of DS3 and above. It is wholesale.

C) I used to be an enterprise network engineer. Buying unproven FR service is a lose-lose proposition for us..
i) If it works, the management will say this is just the way it is.. - No gain for me.

ii) If it failed, I will be fired since I made the recommendation..
cc_junk 12/5/2012 | 12:55:49 AM
re: Sprint Spurns MPLS for Global VPNs reply to optical_fan post#278:
"...MPLS does not have much to add. It was believed -few years back- that MPLS will allow the design and implementation of high speed networks that offer QoS services, but we already have high-speed IP routers so why do we need to introduce new protocols that does not offer much services!"

There are two services:

1) RFC2547 VPNs. this is a fundamentally different way for a carrier to build the enteprise WAN. It is not private lines, FR/ATM PVC/SVCs, IP tunneling. It is a new service with distinct value adds (and cons) over the other approaches to enterprise WANS.

2) Layer 2 VPNs. This is not a new service for the enterprise. But it does allow providers who only built an IP router network and never built a FR/ATM network to get into the larger enterprise WAN business by offering FR/ATM/Ethernet service on their existing router network.

Clearly, this offers a lot.

You could theoretically or in a demonstration create these services without MPLS. But the first implementations to market were with MPLS and they are what are being deployed. The alternatives using GRE or L2TP are just coming out and in the case of 2547 do not have the auto-creation and discovery of PE-to-PE connectivity. When they do have the automation of the MPLS implementations will they be too late to get deployed by carriers already far down the path with the MPLS version?

Unless the MPLS implementation of these services completely fail they are not likely to be replaced by an alternative implementation late to the market that brings no service value add to play.

If TE was the only reason for being for MPLS then it would likely not last long since it is not a directly customer facing service. But if the above two services succeed then MPLS will likely be with us for some time.

Mark Seery 12/5/2012 | 12:55:51 AM
re: Sprint Spurns MPLS for Global VPNs Teng,

>> The migration from ATM to MPLS will be a very complicated task, ship in the night will be a nightmare <<

With out going in to details, I think ships in the night is only a scenario if MPLS fails to meet the requirements of some services. If MPLS can do it, then I think the most likely scenario is gateway/medition functionality in the edge for both data/user plane and control plane.

-mark
Mark Seery 12/5/2012 | 12:55:51 AM
re: Sprint Spurns MPLS for Global VPNs Hi BBoy,

>> So if Sprint data can provide a comparable level of service without the added cost and complexity of MPLS, and they are able to post good numbers on both the top and bottom lines, I think the analysts will reward them no matter what technology they chose to implement. <<

Fundamentally I agree with you, but the c-levels still have to field the annoying questions (from their customers as well) and its like anything in politics, its not usually the thing that people are upset at you about that you get beaten over the head about, i.e. in a competitive world, handing people invitations to beat your brains out is not a survival strategy.

>> Again, anyone who bases fundamental technology decisions on extraneous factors like public opinion is a fool. <<

you are correct, but it does influence the picture that is painted to the outside world, and if caught between two choices, unless one choice has overwhelming advantage (not just little technical nits) then the path of least resistance is the one that raises the fewest questions.

>> But what the time line will be, and what type of platform will be required <<

and what pltaforms will be available

>> are multi-billion dollar questions that are far from being decided. <<

agreed.

-mark
teng100 12/5/2012 | 12:55:51 AM
re: Sprint Spurns MPLS for Global VPNs BBboy said:
"Bottom line, I believe that most of the major data service providers are considering migration of legacy services to MPLS backbones. But what the time line will be, and what type of platform will be required, are multi-billion dollar questions that are far from being decided.
"

This is interesting especially in
"what type of platform will be required"

The migration from ATM to MPLS will be a very complicated task, ship in the night will be a nightmare, you must have a platform that can do both ATM and MPLS in the core and you know what
when a error occurs, you do not know where is the problem. you always have two big networks logically running side by side and they will be sharing all the complexity and unsecurity, then the ATM customer will slowly get away from you and you will be looking at your protocols machine running everyday with no value customers in the end.
broadbandboy 12/5/2012 | 12:55:52 AM
re: Sprint Spurns MPLS for Global VPNs Mark,

You make many good points in your reply. I am going to pick out a few to comment on.

On OC-192 you wrote: "clearly it can be done, unfortunately (for confidence in the ATM market) not all ATM switch vendors have committed to it; and specifically some important ones including the incumbent at some of the RBOCs."

I agree. And lets get it out into the open here--you are talking about LUCENT. They are the incumbent ATM/Frame switch provider to the RBOCs. And they have said "no way" to OC-192 ATM.

Other than Marconi (which has it today), incumbent vendors who say they will support 10 gig ATM include Alcatel and Cisco. Not sure about Nortel.

But any SP who sticks with Lucent has no choice. They will have to go to an IP/MPLS backbone whether they want to or not. With Lucent, ATM is a dead-end (unless they change their minds again).

----------------------------------

"I'm really a bit reluctant to launch off the deep end on this subject (NDA), but I will at least throw the following bone at you: did incumbent ATM switch vendors do enough to give the RBOCs confidence that they would have the solutions they would need for a converged IP/layer 2 network? If you answer this with no, then u might see how the door was opened up to look at other alternatives - indeed perhaps even the necessity."

My answer, if the incumbent is Alcatel (Newbridge), then yeah, I'd say they did a pretty good job, if the LR multiservice tests are any indication. If its Cisco, well, consider that AT&T's successful IPFR is based on the MGX 8850 ATM switch which has a built-in router. And some very large service providers, like Sprint, base their IP-VPN offers on Nortel Passports.

But aain, if you mean Lucent, then I'd say the confidence level is less than zero.

---------------------------------------

"Should CEOs care about the investment power of institutional investors? The selling of shares is a market, just like any other market. Lastly, if the opinion of analysts was truly so irrelevant (I am not saying accurate,just perception of influence) to executives, then executives wouldn't get so bent out of shape when ever an analyst look at their company sideways."

---------------------------------

I agree that C-level executives worry excessively about what a Grubmann would say about their stock at the end of every quarter. But at the end of the day, isn't it mainly about financial performance, not arcane distinctions between protocols, packets and cells, switches and routers? I get all kinds of analyst reports, and the bottom line seems to be things like ROI, cash flow, operating margins, etc.

Example: I saw a big "sell" warning this morning for Sprint PCS. Why? Not because they chose CDMA over GSM or whatever, but because 4Q sales at Radioshack outlets went down the toilet.

So if Sprint data can provide a comparable level of service without the added cost and complexity of MPLS, and they are able to post good numbers on both the top and bottom lines, I think the analysts will reward them no matter what technology they chose to implement.

---------------------------------

"So you are saying that you acknowledge that carriers are afraid to say ATM in a press release, but you still don't believe they are influenced by other people's opinions. Can you please explain the logic?"

Sure. ATM has been politically incorrect for as many years as I can remember (yet it keeps on going and has attracted many imitators). Companies long ago learned that if they did not want to get bashed by nitwit trade press reporters and opinionated columnists in places like BCR or Network World, they had better call it IP (as dreamer has already pointed out). Have you ever read an article titled "Why IP Must Die?" I don't think so.

Again, anyone who bases fundamental technology decisions on extraneous factors like public opinion is a fool.

--------------------------------------------

"In the last half of 2002, SBC and Bell South made MPLS announcements (lets not start a flame on whether BLS did or not) and many on this thread seem to be speculating (by inference) that VZ is about to do the same. Seems they have no problem saying the "MPLS" word (not a criticism, just an observation)."

I agree. Bell South is the most aggressive RBOC in planning an MPLS based network architecture. And they don't mind jawboning about it, becuase the head of their data group is all for it.

I say more power to'em if they can make it work.

But I have also heard the head of SBC network engineering say that, as far has he was concerned, MPLS would not be implementable until it was fully interoperable, which would take several more years.

Bottom line, I believe that most of the major data service providers are considering migration of legacy services to MPLS backbones. But what the time line will be, and what type of platform will be required, are multi-billion dollar questions that are far from being decided.

BBboy
teng100 12/5/2012 | 12:56:12 AM
re: Sprint Spurns MPLS for Global VPNs Mark Seery said:
"
I don't know how you define "tremendously" but I think ATM is about as dead as SONET for some network functions in some RBOC organizations."

Mark, would you elaborate the "some network functions" in more details, kind of interested
to know in this areas.
Thanks.
teng100
Mark Seery 12/5/2012 | 12:56:13 AM
re: Sprint Spurns MPLS for Global VPNs >> Hi Mark,
RBOC is not buying much.. If you want growth, you need to go somewhere else.. <<

fair enough. then think of it as a % of capex issue.

-mark
sgan201 12/5/2012 | 12:56:15 AM
re: Sprint Spurns MPLS for Global VPNs Hi Mark,
RBOC is not buying much.. If you want growth, you need to go somewhere else...
Mark Seery 12/5/2012 | 12:56:22 AM
re: Sprint Spurns MPLS for Global VPNs >> How about this. Due to political correctness, SP still buy ATM but dare not mention this in the press. Given this, eventhough ATM market might be growing but you will never hear about this. <<

A reasonable discussion could be had around this thought. I would add the following:

a) for some parts of the network, ATM is the incumbent, the switch over costs would be hard to justify at the moment
b) there are some applications where some people will still feel only ATM can get the job done today.

>> This is the same thing like NT selling VoATM to Sprint Local Service via the VP of Marketing of VoIP.. And, never clearly state that it is VoATM.. <<

Where NT is the incumbent in a voice application, the tendency is going to be to go with ATM because a) that's the solution NT offers and b) the switch over costs and risks to another vendor may be perceived as too high.

>> At this rate, ATM might be growing tremendously but nobody knows.. <<

I don't know how you define "tremendously" but I think ATM is about as dead as SONET for some network functions in some RBOC organizations.

-mark
teng100 12/5/2012 | 12:56:22 AM
re: Sprint Spurns MPLS for Global VPNs Hi all,


MPLS has been a hot topic, but it is just way
too complex now and even more when the OAM and
multicast are brought to the table.

You can not build
connection based model on connectionless
model, it violate the networking fundamental
guideline; You can not build a network
which has L3 in the core but L2 at the Edge,
it violate another fundamental networking
priciple. Tell me how you can build
everything on IP when the IPv4 has only 32
bits for the total addresses and how do you
expand? where is the addressing hierarchy?
it ties application layer to backbone
routing(control)layer,and this is also the
root of the security problems.

Get real now.







sgan201 12/5/2012 | 12:56:29 AM
re: Sprint Spurns MPLS for Global VPNs Hi Mark,
How about this. Due to political correctness, SP still buy ATM but dare not mention this in the press. Given this, eventhough ATM market might be growing but you will never hear about this.

As equipment provider, do you prefer PO or good press??

This is the same thing like NT selling VoATM to Sprint Local Service via the VP of Marketing of VoIP.. And, never clearly state that it is VoATM..

At this rate, ATM might be growing tremendously but nobody knows..
optical_fan 12/5/2012 | 12:56:29 AM
re: Sprint Spurns MPLS for Global VPNs There is no incentive for companies to spend money especially under the current economic pressures to upgrade their networks from ATM or IP to MPLS. Even without the current economic pressures, MPLS does not offer much to the existing ATM and IP infrastructure. With the current high density and high capacity ATM switches and IP routers, MPLS does not have much to add. It was believed -few years back- that MPLS will allow the design and implementation of high speed networks that offer QoS services, but we already have high-speed IP routers so why do we need to introduce new protocols that does not offer much services!

It is really surprising that some customers will still choose to deploy MPLS networks! Sprint should set a model for other companies follow by its decision to neglect MPLS.

sgan201 12/5/2012 | 12:56:30 AM
re: Sprint Spurns MPLS for Global VPNs Hi Beltway_light,
1) My statement only apply to SP that own fiber.

2) Most ISPs especially the smaller one only peered at limited locations - less than 10.

3) If you own fiber, you could probably get away with doing Ethernet and using Sonet APS doing protection. By the way, that protection is more reliable and way faster..

4) Complexity is not scalable. KISS..
teng100 12/5/2012 | 12:56:32 AM
re: Sprint Spurns MPLS for Global VPNs BBboy wrote:
" Again, I would be very interested in learning more about those ATM-related events that have caused a change of heart among certain un-named RBOCs."

BBboy and other interested professional:
if you would like to receive the white paper
in new ATM capabity, please send hello email
to [email protected] This will be kept
confidential of course.

Thanks.
Teng100
Mark Seery 12/5/2012 | 12:56:32 AM
re: Sprint Spurns MPLS for Global VPNs BBoy,

>> Mark, most of your posts on this thread have been excellent, but I've got to question a few of your latest comments. <<

Thanks, and no problem.

OC-192 ATM
==========
-clearly it can be done, unfortunately (for confidence in the ATM market) not all ATM switch vendors have committed to it; and specifically some important ones including the incumbent at some of the RBOCs.
-scaling is a larger issue than just the highest port speed. If you matched the requirements some carriers have against the ATM switches announced this year, with some exceptions, you wouldn't even meet the (perceived) edge requirements of some next-gen IP/MPLS networks.
-The issue is not whether ATM works, the issue is what does the road map look like. I am interested to learn more about some of the things Teng has said.

On what happened to ATM this year
=================================

-I'm really a bit reluctant to launch off the deep end on this subject(NDA), but I will at least throw the following bone at you: did incumbent ATM switch vendors do enough to give the RBOCs confidence that they would have the solutions they would need for a converged IP/layer 2 network? If you answer this with no, then u might see how the door was opened up to look at other alternatives - indeed perhaps even the necessity.

>> Well, I think that is just silly. Anyone who would take advice from Wall St. analysts on network architecture is an ass. <<

Wall St analysts look at the high order bit - where is the general investment trend headed. As technologists, we might think they should know a little more than this, but many "business" people would side with this logic. Should CEOs care about the investment power of institutional investors? The selling of shares is a market, just like any other market. Lastly, if the opinion of analysts was truly so irrelevant(I am not saying accurate,just perception of influence) to executives, then executives wouldn't get so bent out of shape when ever an analyst look at their company sideways.

>> "IP/MPLS+guaranteed-QoS" platform. In other words, an ATM switch with an MPLS upgrade path for political cover. <<

So you are saying that you acknowledge that carriers are afraid to say ATM in a press release, but you still don't believe they are influenced by other people's opinions. Can you please explain the logic?

In the last half of 2002 SBC and Bell South made MPLS announcements (lets not start a flame on whether BLS did or not) and many on this thread seem to be speculating (by inference) that VZ is about to do the same. Seems they have no problem saying the "MPLS" word (not a criticism, just an observation).

-mark

beltway_light 12/5/2012 | 12:56:32 AM
re: Sprint Spurns MPLS for Global VPNs >3 pairs of fibers can satisfy the total bandwidth
>of whole USA. If you own fiber and you have
>essentially have more bandwidths than anyone can
>use in the core, what do you do??
>You buy the cheapest equipments possible for you
>to utilize the bandwidth. No intelligence. Pure
>layer 1 box - DWDWM or TDM.

you massively underestimated the complexity of
the Internet. If the Internet only consisted of
a couple of pairs of point-to-point connections,
then you were right. But the Internet has more
than 100 million users, 10s of thousands of ISPs
inter-connected together to offer them the
any-to-any IP services, this is why it has been so
successful. If an ISP has many inter-connected
AS-neighbors, how to "intelligently" hand off
the traffic to them can save money and bandwidth.
Many ISPs can not just settle for edge routers
because, first of all, they don't want to
pay all the money to their upstream providers;
second, they want to control the traffic with
complex policies to miximize the bandwidth
utilization; third, many edge services require
backbone routing/service support. They can
buy the raw bandwidth, but they usually want
to control either l2 or l3 portions, thus they
do need some core routers(even though not as
many as the number of edge routers).

teng100 12/5/2012 | 12:56:33 AM
re: Sprint Spurns MPLS for Global VPNs dreamer101 said
"""
3 pairs of fibers can satisfy the total bandwidth of whole USA. If you own fiber and you have essentially have more bandwidths than anyone can use in the core, what do you do??
You buy the cheapest equipments possible for you to utilize the bandwidth. No intelligence. Pure layer 1 box - DWDWM or TDM. """"

I have another thought, use whatever L2 technology in switching layer(Service level layer) that can fill the pipe of the current Layer1 media such as OC192c, you should use that switching Layer technology throughout without introducing another layer of switching for simplicity, statistical L2 muxing gain and lower cost due to less adaptations and easy management.
Mark Seery 12/5/2012 | 12:56:33 AM
re: Sprint Spurns MPLS for Global VPNs >> Everything that you said is conventional wisdom .... <<

Oh well, I try to be different ;-) I guess we are all individuals after all.

>> Let me throw this curve ball to you. <<

catcher's mit on.

>> How about core network does not matter?? <<

Whose - yours our mine?

>> No Layer 2 or 3 switching. It might even be just stupid 10GigE switch with minimal intelligence.. <<

OK, if I stop being flipant (sp?) I think you might be asking the question: do you need some really expensive, really complicated, silicon and software nightmare, every time you want to move a bit from point A to point b? (was I close?)

If that was the question, then this is my answer: no. But that does not obviate the need to understand architecture, and how it relates to the value chain of the organization/SP in question.

For example does Savvis have a core network? Did UUNET have a core before they were part of MFS/WOrldcom? In my opinion, the answer is yes. Why is this important? Because what you might consider the edge (from where ever you are standing) some one else might consider the core.

>> 3 pairs of fibers can satisfy the total bandwidth of whole USA <<

There are more than three places in the world where people live, and in many of these places there will be equipment for quickly punting express/transit bits, there will be equipment for switching and grooming, equipment for adding value beyond moving bits, and equipment for getting bits to all those places that do not have fiber.

There is a role for a transport layer that provides a reliable platform for cost effectively and reliably moving bits around the place - I think we agree on this point? What that technology is, and whether one technology should try to perform every bit of function in a network is at the core of this thread. Break down a network into its architectural components(from an organizational, value chain, and functional perspective) and a lot of these protocol wars would have a lot more clarity (IMO).

-mark
teng100 12/5/2012 | 12:56:34 AM
re: Sprint Spurns MPLS for Global VPNs Hi Mark Seery:

Thanks for your suggestion, in order to
communicate more freely, I would like to
establish a private channel with you,
you can start to send me a Hello email at
[email protected], this will be kept
confidential of coures, how do you think.

Thanks,
Teng100
broadbandboy 12/5/2012 | 12:56:34 AM
re: Sprint Spurns MPLS for Global VPNs Mark Seery wrote: "SPs installing new IP cores are asking themselves the question: is the majority of future R&D likely to be in MPLS or in ATM. Certain things on the ATM front this year caused them to take that question very seriously."

--------------------------------------

Mark, most of your posts on this thread have been excellent, but I've got to question a few of your latest comments.

First, what has happend this past year "on the ATM front" that was so bad? The only thing I can think of is the advent of the first 10 Gbps ATM interfaces. This technology has been delivered by a vendor (Marconi) to a customer (fed. govt.) and demonstrated in public by that customer. Sure its bleeding edge, but it does invalidate the assumption that ATM can't scale to very high speed backbones. That was a major concern for operators of legacy ATM networks.

I'd say that was a good thing, not a bad thing.

------------------------------------
Your other point:
"So the major barrier for ATM at this point is not even technical: it is the perceptions of network
architects and the investment community (carriers are concerned that if they do ATM announcements the investment community will beat them up for investing in obsolete technology)."


Well, I think that is just silly. Anyone who would take advice from Wall St. analysts on network architecture is an ass. A lot of CLECs did that back in the 1990s, and it was like Toonces at the wheel; those know-it-all investment analysts with their grow-now-pay-later models drove a whole industry right off a cliff.

While you do have a very good point about not making ATM announcements, that would never happen anyway. SPs and ATM vendors are savvy enough to have rebranded the technology under the "multiservice" moniker. You will see press releases about service provider X's "next-generation revenue-enhancing multiservice network" based on vendor Y's advanced "IP/MPLS+guaranteed-QoS" platform. In other words, an ATM switch with an MPLS upgrade path for political cover.

Again, I would be very interested in learning more about those ATM-related events that have caused a change of heart among certain un-named RBOCs.

BBboy
sgan201 12/5/2012 | 12:56:35 AM
re: Sprint Spurns MPLS for Global VPNs Hi Mark,
Everything that you said is conventional wisdom held by a lot of people. But, historically, in data comm world, conventional wisdom is always wrong.

Let me throw this curve ball to you.
How about core network does not matter??
In fact, in my way of thinking, the Core is either going to be dumb DWDWM or TDM. No Layer 2 or 3 switching. It might even be just stupid 10GigE switch with minimal intelligence..

The total bandwidth requirement for USA is around 7 terabits = 7,000,000Mbps give or take 50%..

A pair of fiber can have 320 X 10 Gbps = 3.2 Tbps

3 pairs of fibers can satisfy the total bandwidth of whole USA. If you own fiber and you have essentially have more bandwidths than anyone can use in the core, what do you do??
You buy the cheapest equipments possible for you to utilize the bandwidth. No intelligence. Pure layer 1 box - DWDWM or TDM.

It is only at the edge that you need any intelligence..
Mark Seery 12/5/2012 | 12:56:37 AM
re: Sprint Spurns MPLS for Global VPNs [sorry - cut and paste error on last post - disregard]

>> dreamer101,

If I have a white paper, are you willing to
read and give me some comment? <<

Teng, I certainly would (seriously).

On other issues,

SPs installing new IP cores are asking themselves the question: is the majority of future R&D likely to be in MPLS or in ATM. Certain things on the ATM front this year caused them to take that question very seriously. So the major barrier for ATM at this point is not even technical: it is the perceptions of network architects and the investment community (carriers are concerned that if they do ATM announcements the investment community will beat them up for investing in obsolete technology). So the message about the "new ATM" has to be received by a very broad audience.

RFPs: not always the first one that is the biggie. Carriers, RBOCs in particular as well as some PTTs, have to learn how to support MPLS at scale (i.e. do a lot of internal training) before they can go there (at least for premium services which will impact what those networks may be used for).

On the issue of RFPs, it is not always the first one that leads to the biggest deployment. RBOCs may be articulating a strong interest in MPLS, but at the end of the day, they have to be able to support it - at scale = lots of training and/or lots of equipment vendor hand holding = advantage to a very small circle of vendors.

There are places where ATM still makes sense (to carriers), but there are places where it is going to be a real uphill battle; and the vendors that pick their fights with this in mind can still prosper. Start by thinking about network architecture, and go from there (my opinion).

-mark
Mark Seery 12/5/2012 | 12:56:38 AM
re: Sprint Spurns MPLS for Global VPNs >> dreamer101,

If I have a white paper, are you willing to
read and give me some comment? <<

Teng, I certainly would (seriously).

On other issues,

SPs installing new IP cores are asking themselves the question: is the majority of future R&D likely to be in MPLS or in ATM. Certain things on the ATM front this year caused them to take that question very seriously. So the major barrier for ATM at this point is not even technical: it is the perceptions of network architects and the investment community (carriers are concerned that if they do ATM announcements the investment community will beat them up for investing in obsolete technology). So the message about the "new ATM" has to be received by a very broad audience.

RFPs: not always the first one that is the biggie. Carriers, RBOCs in particular as well as some PTTs, have to learn how to support MPLS at scale (i.e. do a lot of internal training) before they can go there (at least for premium services which will impact what those networks may be used for).

But before you send it my way, I think you should know that I am not sure it is a technology issue at this point. Various things occurred this year that gave RBOCs uncertainty about their incumbent ATM vendors, which led to them saying, well if we can't be sure about x then maybe we should take a look at y (MPLS and the vendors there of).

RBOCs feel that multiple vendors will continue to evolve MPLS, whereas they are not so sure about what the future of ATM R&D looks like. This is a sentiment issue which over hangs all the other technical debates. In addition to this concern, carriers have to worry about how the investment community will react if they come out with a press release along the lines of "Carrier A announces next gen IP network based on ATM switches from vendor y". The investment community may never get to read your white paper, and even if they did....So the sell job for the "new ATM" has to be very broad and very well articulated. It is a lot easier for carriers to please the investment community by doing an MPLS announcement, than it is to fight well-entrenched perceptions about ATM.

On the issue of RFPs, it is not always the first one that leads to the biggest deployment. RBOCs may be articulating a strong interest in MPLS, but at the end of the day, they have to be able to support it - at scale = lots of training and/or lots of equipment vendor hand holding = advantage to a very small circle of vendors.

There are places where ATM still makes sense (to carriers), but there are places where it is going to be a real uphill battle; and the vendors that pick their fights with this in mind can still prosper. Start by thinking about network architecture, and go from there (my opinion).

-mark
sgan201 12/5/2012 | 12:56:38 AM
re: Sprint Spurns MPLS for Global VPNs Hi Teng,
I might if you post it somewhere that I can download and upload my comment...
teng100 12/5/2012 | 12:56:40 AM
re: Sprint Spurns MPLS for Global VPNs dreamer101,

If I have a white paper, are you willing to
read and give me some comment?

Thanks.
Teng100


teng100 12/5/2012 | 12:56:44 AM
re: Sprint Spurns MPLS for Global VPNs Beo Write:
""Teng:
We've been reading your posts for the past month, on this LR thread and others, in which you've critisiced IP and MPLS and praised the "new" ATM. And you've done well to generate a lot of really good issues and discussion.

Your persistence in sticking to your guns in the face of some very tough comments is admirable. But this makes us all the more curious about what your background is (because most of us have had to compromise on our technical beliefs at one point in or another in our careers ;-).

You may not want to identify the company you work for, but we'd love to know where you're coming from experience-wise. Are you a box-level engineer, a test engineer, an integrator, SE, or what?

I think most of the people on this thread have plenty of experience in the trenches. I may not agree with all their opinions, but (with the exception of BobbyMax ;-)I respect their opinions and experience. And I've certainly learned quite a bit reading the LR threads.

I myself have over a dozen years' experience designing and building big networks (as a consultant and in a professional svcs capacity), and I have my opinions as to what the best technology is given the circumstances. I've worked for half-dozen companies over the years -- including Cisco -- but I try not to be too attached to any single technology or vendor.

Anyway, that's my background. What's yours? I can't help but be curious.

Best Regards,
--Beo"""


Beo:

It has been a great pleasure for me in this
meaasge board, and I have learned a
lot of things from all you guys, it
certainly will help us to communicate and
understand each other more.

I have more than 20 years experience
in many areas such as ATM, IP/MPLS
design especially I want to get all the
merits and foundation of each technology
understood very well .

It is also very important for me to
present my view so that you guys can make
your judgement based on some information
which happen to be new to you at this time.
Some good brainstorm can help us to
build strength.

Thanks.

AAL5 12/5/2012 | 12:56:45 AM
re: Sprint Spurns MPLS for Global VPNs
I have to agree with beowulf, I respect Teng for being so polite when I've tried to get a flame war going with him.

Congrats, you're one cool guy :)

AAL5

beowulf888 12/5/2012 | 12:56:46 AM
re: Sprint Spurns MPLS for Global VPNs Beetlejuice:
At the risk of displaying my ignorance before the gurus of the LightReading lists, what does the MIM in Fast MIM stand for?

TIA,
--Beo
beowulf888 12/5/2012 | 12:56:47 AM
re: Sprint Spurns MPLS for Global VPNs Teng:
We've been reading your posts for the past month, on this LR thread and others, in which you've critisiced IP and MPLS and praised the "new" ATM. And you've done well to generate a lot of really good issues and discussion.

Your persistence in sticking to your guns in the face of some very tough comments is admirable. But this makes us all the more curious about what your background is (because most of us have had to compromise on our technical beliefs at one point in or another in our careers ;-).

You may not want to identify the company you work for, but we'd love to know where you're coming from experience-wise. Are you a box-level engineer, a test engineer, an integrator, SE, or what?

I think most of the people on this thread have plenty of experience in the trenches. I may not agree with all their opinions, but (with the exception of BobbyMax ;-)I respect their opinions and experience. And I've certainly learned quite a bit reading the LR threads.

I myself have over a dozen years' experience designing and building big networks (as a consultant and in a professional svcs capacity), and I have my opinions as to what the best technology is given the circumstances. I've worked for half-dozen companies over the years -- including Cisco -- but I try not to be too attached to any single technology or vendor.

Anyway, that's my background. What's yours? I can't help but be curious.

Best Regards,
--Beo
sgan201 12/5/2012 | 12:56:48 AM
re: Sprint Spurns MPLS for Global VPNs Hi Teng100,
Cannot tell..
Pssst....
sgan201 12/5/2012 | 12:56:49 AM
re: Sprint Spurns MPLS for Global VPNs It is not IP..
teng100 12/5/2012 | 12:56:49 AM
re: Sprint Spurns MPLS for Global VPNs optical wavelength, DWDM, TDM, SOnet ????
teng100 12/5/2012 | 12:56:49 AM
re: Sprint Spurns MPLS for Global VPNs AAl5:
""""To make things simpler for you IG«÷ll ask again one question, G«£What product by which company does not have all the disadvantages of G«ˇold ATMG«÷?G«•"""

I intend to discuss in this message board for
reasoning instead of specifying the details of X company for now. I hope you can understand.
Thanks.
teng100 12/5/2012 | 12:56:50 AM
re: Sprint Spurns MPLS for Global VPNs dreamer101"

""3) There are some new and very big networks are being built right now. PO is now. Every single one of them is bigger than the RFP that you had seen that promised to buy some time in the future. Laurel, Juniper were not invited period."""

Dreamer101, can you elaborate this technology?
Thanks.
AAL5 12/5/2012 | 12:56:50 AM
re: Sprint Spurns MPLS for Global VPNs Teng,

Everything I said had meaning; do you have problems with comprehension?

To make things simpler for you IG«÷ll ask again one question, G«£What product by which company does not have all the disadvantages of G«ˇold ATMG«÷?G«•

AAL5
sgan201 12/5/2012 | 12:56:50 AM
re: Sprint Spurns MPLS for Global VPNs Hi All,
This is my opinion.

1) The edge network if you have to deploy now, the only answer is ATM if you run anything more than IP on your edge.

2) Both ATM and MPLS are the wrong answers for the new core network. They are wrong for different reasons.

3) There are some new and very big networks are being built right now. PO is now. Every single one of them is bigger than the RFP that you had seen that promised to buy some time in the future. Laurel, Juniper were not invited period.
AAL5 12/5/2012 | 12:56:51 AM
re: Sprint Spurns MPLS for Global VPNs Teng,

as you suggested I went back through all of your posts to find some concrete information regarding "new ATM". All I found was a litany of promises that "new ATM" will solve all problems. What product by which company does not have all the disadvantages of "old ATM"?

By the way "new MPLS" is just around the corner and it fixes all the problems of "old MPLS" and is 2^100 times better. This sort of argument is ridiculous.

What I have been trying to convey is that you should be a technology atheist if you wish to survive. ATM bigeots such as yourself have been promising everything for too many years now. ATMs chance to be all things to all men is over, Service Providers have woken up to the fact that they can use their switches and routers to provide new services and generate revenue now with lower capex and opex.

Try using your "new ATM" message to the service providers, I bet some in your company have, problem is no-one believes it any more, hence RFPs are coming out that are replacing ATM in their network.

Time to wake up and smell the coffee, no never mind please work away developing ATM based solutions, can I ask what company you work for so I can short their stock?

AAL5
teng100 12/5/2012 | 12:56:51 AM
re: Sprint Spurns MPLS for Global VPNs AAL5,

Please ask something you do not understand
instead of saying something with no meaning.
Thanks.
teng100 12/5/2012 | 12:56:51 AM
re: Sprint Spurns MPLS for Global VPNs AAL5 wrote:
"""No, they would put out an RFP of the technology they are interested in, pick a couple of couple of suppliers for trials, test the equipment to see how it performs. If successful they would slowly integrate the equipment into their existing network, and then add new revenue generating services. They will make some money, then buy some more equipment.""""

We all need to think about all the solutions from the root of its merits, not simply based on few RFPs which might get changed in the future soon.



"""
teng100 12/5/2012 | 12:56:52 AM
re: Sprint Spurns MPLS for Global VPNs AAL5 wrote:
"""Presumably you work for a company that provides mainly an ATM solution in this market space, so are you saying that customer X does not understand what they want?"""

I am not saying any capability issues in terms of
networking architects in the industry, however,
you have the wrong impression that ATM is ATM,
the New ATM is also capable to manage the IP as I said in the previous posts.

AAL5 12/5/2012 | 12:56:52 AM
re: Sprint Spurns MPLS for Global VPNs Netskeptic wrote:
"Look, carriers are under immense pricing pressure and if there is some technology out there, which would allow them either saving or making NOTICEABLE money they would be buying it in volume."

No, they would put out an RFP of the technology they are interested in, pick a couple of couple of suppliers for trials, test the equipment to see how it performs. If successful they would slowly integrate the equipment into their existing network, and then add new revenue generating services. They will make some money, then buy some more equipment.

Its a slowly-slowly game, as many people have pointed out this is why the telecos are still in buisness.

A considerable number of telecos have privately stated that they will not be extending their existing ATM networks and will be buying MPLS core and edge boxes in the near future. A few RFPs are out, and I can assure you that next generation ATM boxes are not on the list of requirements.

AAL5
AAL5 12/5/2012 | 12:56:52 AM
re: Sprint Spurns MPLS for Global VPNs Teng,

so you are telling me that company X in question is basing their requirements on incorrect information about ATM capabilities?

Wow, as this is not the only telco I am aware of that does not plan to extend there ATM network there must be a lot of network architects at these companies that have got it wrong.

Presumably you work for a company that provides mainly an ATM solution in this market space, so are you saying that customer X does not understand what they want?

Is this because the customer is not intelligent enough to make the correct decision or because your marketing/sales guys haven't done their job properly in educating the customer about what they really need?

Here's a useful buisness tip, provide customers want they want do not force a solution on them. If Sprint don't want MPLS in their network, provide a non-MPLS solution to them to suit their buisness requirements. If another company wants an MPLS core and MPLS enabled services at the edge provide them what they want.

If you don't follow this simple rule you're company is not going to play in this space.

AAL5
teng100 12/5/2012 | 12:56:53 AM
re: Sprint Spurns MPLS for Global VPNs Netskeptic wote:""IMHO, the core issue of the day is that ALL sides are wrong, be it ATM, MPLS or pure-IP-over-L1. And any provider who would move decisively one way or another will suffer, so that is why most of them limit their expenses to patching existing networks and limited real life trials.

Look, carriers are under immense pricing pressure and if there is some technology out there, which would allow them either saving or making NOTICEABLE money they would be buying it in volume.""""

It make sense. All of us are trying to find a total solution for the networking, we certainly do
not want to make some quick-fix solution that eventually will be broken and give the providers and all of the users (including you and me) more problems down the road.
teng100 12/5/2012 | 12:56:55 AM
re: Sprint Spurns MPLS for Global VPNs AAL5:

I know your knowledge in terms of currnt RFPs
but if you are the CEO of this provider, what
you need to do if the RFP content was based on
some earlier information about ATM.
beetlejuice 12/5/2012 | 12:56:55 AM
re: Sprint Spurns MPLS for Global VPNs They don't need MPLS when they are built on using Fast MIM.
AAL5 12/5/2012 | 12:56:56 AM
re: Sprint Spurns MPLS for Global VPNs
The RFP by a major SP is at the edge but it specifies a non-ATM core. This is not the only one I am aware of at the moment. Many service providers in North America and Europe have stated that going forward they wish to transition their networks to an MPLS core so they can add more edge services at reduced Capex and Opex.

This will not happen overnight as it obviously makes sense to use existing equipment as much as possible and slowly transition to a different network architecture. Sprint is the exception to "the rule", but I can assure you that many telecos are currently examining how to make this transition, some are a lot further ahead than you would think.

Like many others on this board I'm under NDA and will not give details of customer's requirements etc., but if you work for Juniper, Cisco or Laurel I am sure you will be familar with what I am referring to.

AAL5
teng100 12/5/2012 | 12:56:56 AM
re: Sprint Spurns MPLS for Global VPNs dreamer101:
""Equipment revenue at the edge is at least 2 times against the core. This is the same for IP and ATM. Who is building a new big core network anyhow?? RFP does not qualify as real PO. Now, all the POs are at the edge..""

That is the reality now. And to think about it in the near furure, Core and Edge are looking like each other in a mirror, they will be growing equally for QoS selling, that is why we need to have a solid planning now for the whole picture. Providers now can have more options now in terms of new ATM solution.
sgan201 12/5/2012 | 12:57:03 AM
re: Sprint Spurns MPLS for Global VPNs Hi All,
Equipment revenue at the edge is at least 2 times against the core. This is the same for IP and ATM. Who is building a new big core network anyhow?? RFP does not qualify as real PO. Now, all the POs are at the edge..
netskeptic 12/5/2012 | 12:57:04 AM
re: Sprint Spurns MPLS for Global VPNs > The market will ultimately decide who is right
> and who is wrong, and from what many Service
> Providers are asking at the moment ATM in the
> core is going to be replaced in the near
> future.

IMHO, the core issue of the day is that ALL sides are wrong, be it ATM, MPLS or pure-IP-over-L1. And any provider who would move decisively one way or another will suffer, so that is why most of them limit their expenses to patching existing networks and limited real life trials.

Look, carriers are under immense pricing pressure and if there is some technology out there, which would allow them either saving or making NOTICEABLE money they would be buying it in volume.

Thanks,

Netskeptic
teng100 12/5/2012 | 12:57:05 AM
re: Sprint Spurns MPLS for Global VPNs Tony Li wrote:
In any case, there is pretty clear consensus in the IP community that they don't like ATM. Some have deployed it out of necessity, but none of them are enamored with it and even those who have deployed it would be happy with a simpler alternative."

Beo wrote:
Yes. ATM networks are definitely labor intensive!

=======
Teng100: That is the limitation in the past,
new ATM has the capability to manage the Edge IP
network transparently through software without
manual provisioning or very minimum human instruction needed for authorization.
teng100 12/5/2012 | 12:57:05 AM
re: Sprint Spurns MPLS for Global VPNs AAL5 wrote:


AAL5:
It just makes it so much easier for those of us that wish to provide non-ATM solutions to those providers that see the benefits of MPLS.

If you were aware of any of the major RFPs that are out at the moment you may have a different view.
================================
Teng100: I know the current RFPs, but this RFPs can be enhanced with this new ATM view now.

AAL5:
The market will ultimately decide who is right and who is wrong, and from what many Service Providers are asking at the moment ATM in the core is going to be replaced in the near future.

Teng100: I hope everyone can look at ATM more
closely when searching for a viable and secured network solution. And of course, market is inherently dynamic and should align to whatever
the technology coming along that make sense in the long term.
teng100 12/5/2012 | 12:57:06 AM
re: Sprint Spurns MPLS for Global VPNs mark Seery wrote:
As Vint Cerf has been known to say: the great thing about the Internet is that every one is connected. The bad thing about the Internet is that every one is connected.
---------
Teng100: fair enough.

Mark:
Seems to me all technologies struggle to deal with this issue. In a public network where we all have access to everything else, how is this problem solved by using SVCs? A SVC-based DoS attack is as easily conceivable as a packet-based attack. As for protecting the internals of a network, that the addresses are exposed to day is largely an ISP cultural issue, not a technical issue. You have to change the culture, not the technology.
------------
Teng100: I would rather say how we provide a better solution for the future.
Eventually, all the important data communications
can be based on SVC like telephone call to cut down the DoS attack, and SVC will get the attacker
location in record if DoS indeed happened. This will dramatically put DoS attack under control for those who prefer more security such as banking, medical or Government.
if you do not like SVC, you get easy access and
you will be responsible for the result any way.
But use ATM as backbone, the backbone will be secured once for all.

Mark:
If you think that a layer 2 or a multi layer for that matter approach is the only solution, then this can be achieved with MPLS, in theory, over time as implementations mature.
----------------------
Teng100: I would rather say which technology will
be long term viable, IP network will be only one of the application, not all of them certainly. ATM can provide a secured solution including QoS selling and transporting internet traffic with easy management. As today, ATM will be the foundation and only viable solution for those carrier who prefer a piece of mind and make real money today and tomorrow.
AAL5 12/5/2012 | 12:57:06 AM
re: Sprint Spurns MPLS for Global VPNs
Teng,

I'm really glad there are people around with your point of view regarding ATMs future prospects in regards to providing a core network for service providers to run revenue generating services on, with reduced Capex and Opex.

It just makes it so much easier for those of us that wish to provide non-ATM solutions to those providers that see the benefits of MPLS.

If you were aware of any of the major RFPs that are out at the moment you may have a different view.

The market will ultimately decide who is right and who is wrong, and from what many Service Providers are asking at the moment ATM in the core is going to be replaced in the near future.

AAL5
sgan201 12/5/2012 | 12:57:15 AM
re: Sprint Spurns MPLS for Global VPNs Hi Mark,
Now, we understand each other perfectly..
Mark Seery 12/5/2012 | 12:57:15 AM
re: Sprint Spurns MPLS for Global VPNs >> Now, we understand each other perfectly.. <<

:-))
sgan201 12/5/2012 | 12:57:17 AM
re: Sprint Spurns MPLS for Global VPNs Hi Mark,
1) I hope your source is reliable and they are telling you the truth..

2) They are most probably not using a particular brand of router..
Mark Seery 12/5/2012 | 12:57:17 AM
re: Sprint Spurns MPLS for Global VPNs >> 2) They are most probably not using a particular brand of router.. <<

that is an astute observation, which should help you narrow down the potential SPs in question.

-mark
Mark Seery 12/5/2012 | 12:57:17 AM
re: Sprint Spurns MPLS for Global VPNs >> Most of the IP/MPLS networks that I am aware of run only LDP with no RSVP+TE enable <<

then clearly there are sone north american networks you are not familiar with.

-mark
Mark Seery 12/5/2012 | 12:57:18 AM
re: Sprint Spurns MPLS for Global VPNs Hi Dreamer,

I am not sure why you assume no RSVP-TE for 0 bandwidth LSPs, but that's not important in this discussion.

With normal IP+Diffserve there is not the equivalent traffic steering capabilities, so you can not leverage offline tools as well, especially in an environment where there is asymmetic dimensioning (i.e. where nice clean symmetric load balancing is not optimal).

I have spoken to sprint about their opinions about MPLS, and I want to be careful what I say, but IMO, the bottom line for sprint is that they feel MPLS is a whole lot more complexity for questionable, if any gains, in a network optimized for, and built with, IP technology. This is a big picture philisophical issue, and not related, as far as I could tell from my discussions, specifically with the issue you raise.

I personally believe, the overiding issue for Sprint is the desire to be sensitive to the wishes of their customer base, which is different to the ATT customer base (in terms of what types of customers dominate the customer base). Both companies are being customer-driven, but markets are not homogenous.

-mark

sgan201 12/5/2012 | 12:57:18 AM
re: Sprint Spurns MPLS for Global VPNs Hi Mark,
Most of the IP/MPLS networks that I am aware of run only LDP with no RSVP+TE enable. If you only run LDP, MPLS box is no better than IP router since you are not steering the traffic..
sgan201 12/5/2012 | 12:57:19 AM
re: Sprint Spurns MPLS for Global VPNs Hi Mark,
If MPLS is only DiffServe with E-LSP (aka LDP only with no RSVP+TE), what is the point doing MPLS?? You must as well using normal IP router with DiffServe with IP over POS.
This is why I say E-LSP is useless.
Unless, it is strictly marketing BS so that you can tell the user you use MPLS in your backbone.
I believe that is the conclusion that Sprint reached.
Mark Seery 12/5/2012 | 12:57:21 AM
re: Sprint Spurns MPLS for Global VPNs >> It is difficult for engineers writing this crap to get at the useage details. <<

Agreed, wish there was any easy answer to this problem. SPs should (IMO) see it as being to their benefit to talk openly and often about network internals (traffic, architecture,...). Some are better than others for a variety of reasons.

>> Can you shed some light on how TEs are actually being used? <<

Some SPs just want to use 0 bandwidth LSPs to steer the aggregate traffic, for all classes of service, along x path. In this case it would be, IMO, useful to have an E-LSP model, as a L-LSP model does not meet the SPs requirements. An L-LSP model requires additional management over head, complexity, and scaling requirements, and (I suspect) changes to offline TE software.

There are Network Architects who think this way who are involved in the IETF. If you make it your mission to go and talk to each one of them, you will eventually come across such people, though they sometimes shun the bright lights for fear of getting burned by religous debates (I suspect). That some companies see such information as proprietary is another issue, but I think such companies should consider getting past that for both their own benefit, and the benefit of the industry as a whole (may not be a decision that is in the hands of the engineers).

-mark

jamesbond 12/5/2012 | 12:57:21 AM
re: Sprint Spurns MPLS for Global VPNs I would suggest such people take a look at how TE is actually being used by some SPs at the core of IP networks.

-mark
------------------------

Mark,

It is difficult for engineers writing this crap to
get at the useage details. How do we get our
hands on this information? Can you shed some
light on how TEs are actually being used?

thanks
jamesbond 12/5/2012 | 12:57:22 AM
re: Sprint Spurns MPLS for Global VPNs Well, I don't know where you get those factoids that ISPs aren't making or can't make money. MFS, UUnet, CERFnet, were definitely all profitable before they got bought up by the telcos
-----------------------------------------

I don't think we should use 1997-1999 data as
a basis for saying they were profitable. I doubt
that they would be profitable in a **normal**
market like todays.
Mark Seery 12/5/2012 | 12:57:23 AM
re: Sprint Spurns MPLS for Global VPNs >> The only extra useless mode in MPLS is E-LSP which is not usable in the real world. <<

While a realize this is a commonly held belief, (especially with vendors of technology that can not support this mode), it would seem to me that E-LSP is much closer to the IP diffserv model than L-LSP is. I realize that some people believe that E-LSP is not practical for TE purposes, but then I would suggest such people take a look at how TE is actually being used by some SPs at the core of IP networks.

-mark
Mark Seery 12/5/2012 | 12:57:23 AM
re: Sprint Spurns MPLS for Global VPNs >> It may very well be that selling IP is not profitable if you have to support a bloated telco infrastructure. <<

it may well be that, in a highly competitive market, a single entity can not be all things to all people, and that this is another example of structural separation that may make sense. I personally think it is more of a value chain focus issue.

-mark

beowulf888 12/5/2012 | 12:57:23 AM
re: Sprint Spurns MPLS for Global VPNs second try, I left something out...

dreamer101 wrote (msg 195):
>The question is do SP need to sell IP with
>QOS in order to survive??

remove:
Yes, but it will be the layer 2 infrastructure that provides the QoS.

replace with:
Yes, but L2 and L3 will need to work together to provide the QoS.

ATM QoS isn't really compatible with IP QoS. But MPLS is. So for that reason and that reason only, I do think that MPLS has future in IPoMPLS networks or IPoMPLSoATM networks. Just my guess.

>IP with best effort and connectionless had
>been proven as a disaster as far as business
>model is concerned. All the ISPs are not
>making money.

Well, I don't know where you get those factoids that ISPs aren't making or can't make money. MFS, UUnet, CERFnet, were definitely all profitable before they got bought up by the telcos. It may very well be that selling IP is not profitable if you have to support a bloated telco infrastructure.

--Beo
sgan201 12/5/2012 | 12:57:24 AM
re: Sprint Spurns MPLS for Global VPNs Hi Beoulf888,
You are wrong in saying number of ATM ports sold is small.
Based on Infornetics Q3/2002 reports.
Total number of ATM ports sold in MS core switch is 20K..

Total number of ports sold by core router in the same quarter is 15K..

On the edge, it is 157K for ATM versus 142K for IP..

To be proper, you should say it is 50-50 now..

Mark Seery 12/5/2012 | 12:57:24 AM
re: Sprint Spurns MPLS for Global VPNs >> In the big switch and router markets the number of ATM ports sold are a relatively small percentage of total ports sold (I don't have the current numbers). But ATM has not acheived any overall market dominance. <<

That is **roughly** analagous to saying that OC-192 POS ports are a relatively small percentatge of ports sold and therefore core routers have not achieved any overall market dominance.

ATM switches are at the core of important, profitable networks. IP core routers are at the core of important, disruptive networks. Two different markets, and I think they should be viewed that way, at least over the next 2-5 years.

-mark
beowulf888 12/5/2012 | 12:57:25 AM
re: Sprint Spurns MPLS for Global VPNs teng101 wrote in msg 198:
"You will need absolute security, QoS, then it will be based on the price and easy management for making the choice. Do whatever you think is right, but end of day, customer will tell you who is right."

Bingo! In the big switch and router markets the number of ATM ports sold are a relatively small percentage of total ports sold (I don't have the current numbers). But ATM has not acheived any overall market dominance.
sgan201 12/5/2012 | 12:57:25 AM
re: Sprint Spurns MPLS for Global VPNs Hi beowulf,
Please explain why ATM QOS is not compatible with IP QOS. And, MPLS is more compatible with IP QOS than ATM.
In either case, you can mapped DiffServe into ATM VCC or MPLS LSP (L-LSP mode). The only extra useless mode in MPLS is E-LSP which is not usable in the real world.

Please qualify your statement..
beowulf888 12/5/2012 | 12:57:26 AM
re: Sprint Spurns MPLS for Global VPNs Tony Li in msg 197 wrote:
"In any case, there is pretty clear consensus in the IP community that they don't like ATM. Some have deployed it out of necessity, but none of them are enamored with it and even those who have deployed it would be happy with a simpler alternative."

Yes. ATM networks are definitely labor intensive!

--Beo
beowulf888 12/5/2012 | 12:57:26 AM
re: Sprint Spurns MPLS for Global VPNs dreamer101 wrote (msg 195):
>The question is do SP need to sell IP with
>QOS in order to survive??

Yes, but it will be the layer 2 infrastructure that provides the QoS. ATM QoS isn't really compatible with IP QoS. But MPLS is. So for that reason and that reason only, I do think that MPLS has future in IPoMPLS networks or IPoMPLSoATM networks. Just my guess.

>IP with best effort and connectionless had
>been proven as a disaster as far as business
>model is concerned. All the ISPs are not
>making money.

Well, I don't know where you get those factoids that ISPs aren't making or can't make money. MFS, UUnet, CERFnet, were definitely all profitable before they got bought up by the telcos. It may very well be that selling IP is not profitable if you have to support a bloated telco infrastructure.

--Beo
teng100 12/5/2012 | 12:57:27 AM
re: Sprint Spurns MPLS for Global VPNs dreamer101:
Hi Teng100,
"""My point is that even at high speed, ATM with cell tax is more bandwidth efficient than MPLS or IP over POS. Previously, it was not possible because of lack of ATM interface at OC-48c and OC-192c speed.

If majority of your traffic is in cell mode from the access side, it is more efficient to run it at cell mode at the backbone also...""""

Great points, ATM can do high speed
fundamentally cheaper & more robust
than IP packet switching, due to the
underterministic queuing, security
complication and jittering characteristic
in packet switching.

Thanks
Mark Seery 12/5/2012 | 12:57:27 AM
re: Sprint Spurns MPLS for Global VPNs [slight error in original post - sorry all]

Teng100,

As Vint Cerf has been known to say: the great thing about the Internet is that every one is connected. The bad thing about the Internet is that every one is connected.

Seems to me all technologies struggle to deal with this issue. In a public network where we all have access to everything else, how is this problem solved by using SVCs? A SVC-based DoS attack is as easily conceivable as a packet-based attack. As for protecting the internals of a network, that the addresses are exposed to day is largely an ISP cultural issue, not a technical issue. You have to change the culture, not the technology.

If you think that a layer 2 or a multi layer for that matter approach is the only solution, then this can be achieved with MPLS, in theory, over time as implementations mature.

-mark
Mark Seery 12/5/2012 | 12:57:28 AM
re: Sprint Spurns MPLS for Global VPNs Teng100,

As Vint Cerf has been known to say: the great thing about the Internet is that every one is connected. The bad thing about the Internet is that every one is connected.

Seems to me all technologies struggle to deal with this issue. In a public network where we all have access to everything else, how is this problem solved by using SVCs? A SVC-based DoS attack is as easily conceivable as a packet-based SVC attack. As for protecting the internals of a network, that the addresses are exposed to day is largely an ISP cultural issue, not a technical issue. You have to change the culture, not the technology.

-mark
sgan201 12/5/2012 | 12:57:30 AM
re: Sprint Spurns MPLS for Global VPNs Hi Teng100,
My point is that even at high speed, ATM with cell tax is more bandwidth efficient than MPLS or IP over POS. Previously, it was not possible because of lack of ATM interface at OC-48c and OC-192c speed.

If majority of your traffic is in cell mode from the access side, it is more efficient to run it at cell mode at the backbone also...

teng100 12/5/2012 | 12:57:32 AM
re: Sprint Spurns MPLS for Global VPNs "Security
========

It is possible to build closed IP/MPLS networks. This is mostly an operations/architecture issue more than a technology issue""

It will require lots of boundary defense/filtering work to protect such network if you want to connect to current internet at the same time, which is complicated. You will need a powerful L2 secured layer in the core to be long term viable.
teng100 12/5/2012 | 12:57:33 AM
re: Sprint Spurns MPLS for Global VPNs "Hi Teng100,
Cell tax is not a problem even at high speed..
POS and MPLS over POS has a packet queuing problem that limit trunk utlization to below 40%. That is a 60% tax which is higher than ATM cell tax.
It is just that in OC-48 and above, you do not need ATM cell to control jitter..
"

I do not know what is your conclusion????
I guess using ATM throughout will be the best
choice in the end
humphrn 12/5/2012 | 3:08:57 AM
re: Sprint Spurns MPLS for Global VPNs So how come everyone else is using, quite happily MPLS...A majority of carriers....lots of companies with great engineers all technically savy and they are ALL wrong. Yea get your head of the sand like Sprint had to do and grow up.

humphrn 12/5/2012 | 3:26:26 AM
re: Sprint Spurns MPLS for Global VPNs Can someone please explain the advantages and disadvantages of one Vs the other ? Also are there any white papers on the subject ?
humphrn 12/5/2012 | 3:26:26 AM
re: Sprint Spurns MPLS for Global VPNs Why do you think this ?
paolo.franzoi 12/5/2012 | 3:26:26 AM
re: Sprint Spurns MPLS for Global VPNs
Did you notice this topic was done 2 years ago?

Is there not some way you can move these questions and comments to someplace more relevant?

seven
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE