x
Page 1 / 5   >   >>
skeptic 12/4/2012 | 9:12:15 PM
re: Avici's Incredible Shrinking Router Cisco and Juniper offer a similar feature they call nonstop forwarding.
------------------

Thats not correct. Cisco and Juniper are offering
a feature that is meant to confuse service
providers into thinking they have similar
functionality, but they are offering something
quite different.

Cisco and Juniper are offering a solution where
the router essentially restarts/reloads.
Thats a very different solution from what
Avici/Alcatel/others say they have.

And the rumor now is that cisco/juniper know
that what they have isn't good enough at least
internally.
gigeguy 12/4/2012 | 9:12:13 PM
re: Avici's Incredible Shrinking Router It's great to see that they're willing to use some of that cash they stockpiled in the good old days to support ongoing R&D. That's exceptional in today's climate. I wish them success with their new products, so they can keep on spending on R&D! :-)
turing 12/4/2012 | 9:12:13 PM
re: Avici's Incredible Shrinking Router The guy says "Right now everyone has their own approach, but IGÇÖm sure it will be standardized so that routers from different vendors can talk to one another.GÇ¥ confuses me. I thought Avici and Alacatel's version doesn't require any standards - it's all internal.
(I know Cisco is pushing more RFCs on us, as usual)
digerato 12/4/2012 | 9:12:13 PM
re: Avici's Incredible Shrinking Router "I thought Avici and Alacatel's version doesn't require any standards - it's all internal.
(I know Cisco is pushing more RFCs on us, as usual)"

The idea is that if your router crashes and loses some or all of its BGP state, a "standby" route processor should be able to come up and acquire the necessary state without causing all of its adjacencies to flap. That requires cooperation from BGP neighbors -- hence changes to BGP.

One might suggest a form of redundancy where BGP state is never lost...

Cheers,

Digerato
jamesbond 12/4/2012 | 9:12:12 PM
re: Avici's Incredible Shrinking Router The idea is that if your router crashes and loses some or all of its BGP state, a "standby" route processor should be able to come up and acquire the necessary state without causing all of its adjacencies to flap. That requires cooperation from BGP neighbors -- hence changes to BGP.
-------------------

No that does not require cooperation from BGP
neighbors. As long as they have figured out
a way to keep TCP on two boards in sync,
neighbors will not even notice. There are a
number of ways to do this.

skeptic 12/4/2012 | 9:12:12 PM
re: Avici's Incredible Shrinking Router The guy says "Right now everyone has their own approach, but IGÇÖm sure it will be standardized so that routers from different vendors can talk to one another.GÇ¥ confuses me. I thought Avici and Alacatel's version doesn't require any standards - it's all internal.
(I know Cisco is pushing more RFCs on us, as usual)
-------------------------

Cisco marketing has a very deliberate strategy
to use "standardization" to confuse the
marketplace. And as you can see from the light
reading article, its working rather well.

Before people started demonstrating these
technologies, the standard answer from cisco
was that any solution but theirs was "impossible".

Now, even solutions that are contained within
a single router and involve no standards changes
at all are attacked by cisco and juniper for
not having the IETF seal of approval.

beltway_light 12/4/2012 | 9:12:10 PM
re: Avici's Incredible Shrinking Router it's all great if someone figured out
all the corner cases, handles this this
large number of bgp peers and heavy updates.
also it it willing to pay the price of
updating the other "RP" constantly with
the current state. all the power for them.
but i am just wondering isn't it great if
you don't need to keep all those states,
just let the neighbors to tell you after
you restart, what's wrong with that? even
it sometimes needs a couple of IETF documents.
beetlejuice 12/4/2012 | 9:12:10 PM
re: Avici's Incredible Shrinking Router Jesus Christ ! Sounds like Avici marketing team here putting the air fresheners around the corpse.

<1% market share, Kick Ass !
cc_junk 12/4/2012 | 9:12:05 PM
re: Avici's Incredible Shrinking Router Reply to beltway_light post#7:

"but i am just wondering isn't it great if
you don't need to keep all those states,
just let the neighbors to tell you after
you restart, what's wrong with that? even
it sometimes needs a couple of IETF documents."

Then all your neighbors must support and be interoperable for these extensions. That may be fine in the core of your network where you control what is deployed (and ironically, that is where Avici is mostly). But at the edge, are you going to require your customer base to upgrade their CPE routers so you can provide them high-availability? Isn't that the carrier's responsibility?

With the approach of Avici and Alcatel, your customers don't have to do anything for you to provide non-service affecting upgrades, failovers, maintenance. Sounds like a very worthwhile invention to me.

I recall that Amber networks was the first to have this high availability capability without changing protocols. Indeed, I believe that was Nokia's primary motivation for purchasning Amber - to obtain that high availability technology. Don't know whatever Nokia produced from that purchase.

High-availability for IP routing protocols has been demonstrated without changing the protocols. So why change them? Just so that we can accommodate the incumbents (Cisco and Juniper) who did not design for this to begin with and have to resort to unsatisfactory kluge to get some form of high-availability?

Shouldn't change protocols just because of some vendors development weaknesses. But their marketing machinery wants you to believe that their protocol changes have nothing to do with their weakness. To me their spinning and rationalizations are hollow.
capolite 12/4/2012 | 9:12:04 PM
re: Avici's Incredible Shrinking Router Don't be so fast. Level 3 is about to make a serious commitment to the new Avici router. Marcy, care to comment?
Page 1 / 5   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE