Traffic engineering tools

You miss the point. As you well know, capacity is where it is, and not
where you need it. This is a pragmatic and practical problem that costs
people Real Money.

Tony, there's more fiber in the ground than all routers together can
fill up. And putting in fiber is not a highly skilled labour, quite
unlike getting tons of buggy software to work in a production network.

I know one very large backbone operator who says something like "We couldn't
even begin to build our network without TE. It works and we must have it."

Isn't it the same provider who's notorious for ATM-based network?
If we think of the same provider - i had a pleasure of being a customer.
Never again.

It's got nothing to do with latency and everything
to do with capacity. If you have the luxury of having fiber wherever and
whenever you want it, well, you're lucky. But not everyone is quite so
lucky.

Luck is 99% a foresight.

I would claim that those _ARE_ real benefits.

Numbers?

Perhaps it's not the elegant, desireable, or theoretically beautiful
solution. But it is a practical solution.

Yes, sure. As Milo used to say: "With enough thrust even pigs will fly" :slight_smile:

If you would like to wait for the elegant, desireable, and theoretically
beautiful solution, please be my guest. Those of us who engineer to reality
have more work to do. :wink: I'll simply remind you that there is also a
group of people waiting for the elegant, desireable, and theoretically
beautiful inter-domain routing protocol.

I found that one cannot do IDR protocols for a living. Maybe, Yakov :slight_smile:

Or..... it could be a requirement posed by the customer base that vendors
are trying to address.

Yeah, sure. Like the conFusion. Or 7000 series.

You may not share in the problem. That's fine, I don't think anyone would
(ethically) suggest that you use a tool that solves a problem you don't
have.

Unfortunately, the tool does not come free - any new code in a box makes the
box flakier. And costlier.

So what all these features do is shifting cost from those who screwed up
network planning to those who did it properly, but have to pay for all
bundled TE stuff and live with flaky complicated code.

My memories of being dragged out of bed nearly every night because of
router software being stuck in interesting ways are not particularly fond.
I'll exchange complicated ultra-smart hot stuff for a dumb box which
actually works - any time.

--vadim

Vadim,

You continue to dismiss concepts (traffic engineering) that have proven
themselves in practice in large networks. And they continued to prove
themselves long after you predicted they would not (years ago).

Stating the obvious, "there's more fiber in the ground than all routers
can fill up" is not the point. The point is could we have built the Internet
to its present point without traffic engineering? The answer to that is a
resounding NO!

The next question is whether traffic engineering is useful for the future.
Remember these practitioners do not build networks based upon theory, but on
practical implementations that prove themselves to work. Perhaps the
load-sharing mechanism you described for Pluris will work. Perhaps not.
But to promote what hasn't proven itself and dismiss what has sounds
suspicously like bad marketing dressed up in the language of mathematics.

Prabhu

Vadim Antonov wrote:

Stating the obvious, "there's more fiber in the ground than all routers
can fill up" is not the point. The point is could we have built the Internet
to its present point without traffic engineering? The answer to that is a
resounding NO!

May be, you first determine what exactly do you mean as the _traffic
engeneering_? OSPF, btw, is kind of TE too...

/I don't refuse your ideas, through.

The next question is whether traffic engineering is useful for the future.
Remember these practitioners do not build networks based upon theory, but on
practical implementations that prove themselves to work. Perhaps the
load-sharing mechanism you described for Pluris will work. Perhaps not.
But to promote what hasn't proven itself and dismiss what has sounds
suspicously like bad marketing dressed up in the language of mathematics.

Prabhu

Vadim Antonov wrote:
>
> > You miss the point. As you well know, capacity is where it is, and not
> > where you need it. This is a pragmatic and practical problem that costs
> > people Real Money.
>
> Tony, there's more fiber in the ground than all routers together can
> fill up. And putting in fiber is not a highly skilled labour, quite
> unlike getting tons of buggy software to work in a production network.
>
> > I know one very large backbone operator who says something like "We couldn't
> >even begin to build our network without TE. It works and we must have it."
>
> Isn't it the same provider who's notorious for ATM-based network?
> If we think of the same provider - i had a pleasure of being a customer.
> Never again.
>
> > It's got nothing to do with latency and everything
> > to do with capacity. If you have the luxury of having fiber wherever and
> > whenever you want it, well, you're lucky. But not everyone is quite so
> > lucky.
>
> Luck is 99% a foresight.
>
> > I would claim that those _ARE_ real benefits.
>
> Numbers?
>
> > Perhaps it's not the elegant, desireable, or theoretically beautiful
> > solution. But it is a practical solution.
>
> Yes, sure. As Milo used to say: "With enough thrust even pigs will fly" :slight_smile:
>
> > If you would like to wait for the elegant, desireable, and theoretically
> > beautiful solution, please be my guest. Those of us who engineer to reality
> > have more work to do. :wink: I'll simply remind you that there is also a
> > group of people waiting for the elegant, desireable, and theoretically
> > beautiful inter-domain routing protocol.
>
> I found that one cannot do IDR protocols for a living. Maybe, Yakov :slight_smile:
>
> > Or..... it could be a requirement posed by the customer base that vendors
> > are trying to address.
>
> Yeah, sure. Like the conFusion. Or 7000 series.
>
> > You may not share in the problem. That's fine, I don't think anyone would
> > (ethically) suggest that you use a tool that solves a problem you don't
> > have.
>
> Unfortunately, the tool does not come free - any new code in a box makes the
> box flakier. And costlier.
>
> So what all these features do is shifting cost from those who screwed up
> network planning to those who did it properly, but have to pay for all
> bundled TE stuff and live with flaky complicated code.
>
> My memories of being dragged out of bed nearly every night because of
> router software being stuck in interesting ways are not particularly fond.
> I'll exchange complicated ultra-smart hot stuff for a dumb box which
> actually works - any time.
>
> --vadim

--
----------------------------------------------------------------------
Prabhu Kavi Phone: 978-264-4900 x125
Director, Prod. Mgmt. FAX: 978-264-0671
Tenor Networks Email: prabhu_kavi@tenornetworks.com
50 Nagog Park WWW: www.tenornetworks.com
Acton, MA 01720
----------------------------------------------------------------------

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)