x
Optical/IP

Packet Design Intros BST

Packet Design LLC, the technology startup led by former Cisco Systems Inc. (Nasdaq: CSCO) CTO Judy Estrin, is introducing a new routing protocol that it says will help make Internet more reliable and secure. The new technology, called Border Gateway Protocol (BGP) Scalable Transport, is meant to simplify the way routers exchange BGP tables (see Packet Design Intros Routing Protocol).

A well documented Internet problem relates to Border Gateway Protocol (BGP) routing tables, the directories of where things are located on the Internet that enable big backbone routers to do their job (see Experts Sound Alarm on Internet Routing ). The Internet's growth -- and the millions of new devices with IP addresses -- has caused these BGP tables to grow to about the size of Anna Nicole Smith. Also, more enterprises and ISPs are using BGP to connect to multiple ISPs, which adds significantly to the number of BGP route table entries.

Though today's routers are extremely fast, a lot of their processor power and memory are consumed when the BGP-related information gets too big. "What's essentially happening with BGP is these massive address tables -- phone books, if you will -- are being moved from one ISP to another to another to another," says Richard Clarke, special advisor to the President for cyberspace security.

Packet Design's Estrin says BGP's problems can be addressed by changing the way BGP information is carried to the other routers in a network. Right now BGP tables are carried via TCP (Transmission Control Protocol), a protocol that makes a point-to-point connection between routers.

Enter BST, or BGP Scalable Transport, which Packet Design describes as an alternative transport protocol for BGP. TCP devotes memory to keeping track of the state of the TCP connection. But rather than keep a plethora of point-to-point links, BST works by using a technique known as "flooding" to send BGP tables only to a router's immediate neighbor routers. Those routers, in turn, send it to their neighbors, and so on. Theoretically, fewer resources are exhausted this way than keeping track of the state of so many TCP connections within a network.

BST comes as a reference source code module. The reference product contains all of the tools a router vendor would need to build and test BST in a FreeBSD (Unix) environment. BST doesn't change the BGP protocol, Packet Design says. But a router's BGP implementation would need some tinkering, so the router will use BST for message passing instead of TCP.

Estrin says there are also security benefits to this approach as well. In a BST-enabled cloud of routers, only one router at a time would have its IP address exposed to the outside world. When that one router fails, other routers would step up, one at a time, as designated by a network administrator, to take its place.

"There's a lot of focus in the Internet on making things faster," Estrin says. "What we're finding now is that we need to focus on the control plane, which allows you to make it better, not just faster."

Estrin says Packet Design aims to sell BST to router vendors and pricing starts at $100,000. This is the company's second commercial product since inception. The first was a router network troubleshooting system called Route Explorer (see Packet Design's Routing 'Spy' ).

Though the potential customer base is small, and it may be a tough sell, vendors might take solace in knowing that BST's creator is former Cisco chief scientist Van Jacobson. "As a person who has played a large role in the development of TCP over the years [Jacobson] is a credible person to address the problems of TCP," says Mark Seery, an analyst at RHK Inc.

Whether it’s a commercial success or not, the fact that someone is attempting to solve some of the problems surrounding BGP is getting some cheers. "Even if all [Packet Design] does is open up a conversation on the topic, I think [it] will have done the industry an incredible service," Seery says.

Other routing experts say BST is frivolous business. "BGP tables are big and TCP has high memory costs, but so what? Memory is cheap, and even newer edge routers are scaling to hold tables many times the size of today's full Internet table," says one routing wonk, who asked not to be named. "Also, the rate of BGP table growth is slowing." — Phil Harvey, Senior Editor, Light Reading
www.lightreading.com
Page 1 / 3   >   >>
beltway_light 12/4/2012 | 9:23:12 PM
re: Packet Design Intros BST
the idea sounds cool, why waste bandwidth
to update every router in the domain while
you can do "flooding" to cascade the updates?

If they think iBGP full-mesh problem can be
solved like IGP flooding, then they are
opening a can of worm here. In order to make
it really work, it probably can get even
worse than iBGP/TCP full-mesh problem.

Without TCP reliable transport, one has to
deal with ack and retransmit, one has to
keep all the packets around for long time
in order for retransmit. then to claim no
change to BGP protocol is a bogus claim.
how does BST flood over a LAN, do they need
to elect DR and BDR for that:-)

Just ask them a very simple operational
question: what if a router in the middle
of the backbone reboots, does the BST
neighbors suppose to keep millions of BGP
packets and reflood to this router? or does
every router in the domain suppose to
reflood every thing again?

sounds like a cool and broken idea to me.
skeptic 12/4/2012 | 9:23:35 PM
re: Packet Design Intros BST There is a disconnect here. Perhaps the wrong part of the technology was deescribed, or this technology does not hold a solution for the larger issues. Either way, any of this commentary / context is conspicuously absent. Perhaps PEBKAC?
--------------------
There is a data sheet at the packet design
website that is equally confusing.

mu-law 12/4/2012 | 9:23:40 PM
re: Packet Design Intros BST Surely Estrin, Van, Cengiz, all being quite smart, have read the current work on BGP (e.g. Gordon & Wilfong, et al) and its well documented issues.
What this article describes is a proprietary mechanism to address issues that have already been solved by open standards, like SCTP.

There is a disconnect here. Perhaps the wrong part of the technology was deescribed, or this technology does not hold a solution for the larger issues. Either way, any of this commentary / context is conspicuously absent. Perhaps PEBKAC?

Confused,
mu
skeptic 12/4/2012 | 9:23:43 PM
re: Packet Design Intros BST Think more of it, mulitcasting BGP updates to
all peers does not make sense. Each peer may
have different policies/filtering so that the routes you send to each peer may be different. You cannot just send all peers the same stuff.
----------------

The other thing to consider is that if you use
flooding for BGP routes, you are getting a similar
effect to redistributing all (external)
BGP routes into the IGP (OSPF/ISIS).
The historical problem with putting BGP
routes into the IGP is that the attributes are
lost. But if you flood BGP information, you
lose the attributes anyway. BGP can't do policy
modifications if you flood, so there are few
if any attributes to lose.




myresearch 12/4/2012 | 9:23:53 PM
re: Packet Design Intros BST Think more of it, mulitcasting BGP updates to
all peers does not make sense. Each peer may
have different policies/filtering so that the routes you send to each peer may be different. You cannot just send all peers the same stuff.
rainbowarrior 12/4/2012 | 9:24:01 PM
re: Packet Design Intros BST
Since when has the maintenance of TCP state machines been a gating factor in BGP scaleability?
The full mesh problem has more to do with processing sumultaneous updates from multiple peers.

I agree that Harvey must have missed the point. It sounds like Packet Design is proposing a multicast flooding technique to address the full-mesh problem.

Of course, until we see a draft on what they are proposing, we'll never know.
skeptic 12/4/2012 | 9:24:02 PM
re: Packet Design Intros BST Van has made amazing contributions... just saying that he has recently done some sloppy work and any of the "routing gods" can do bad work as well as good work.
-------------------
It wasn't just sloppy work. It was his attitude and
his unwillingness to listen to other people when
they questioned his conclusions. Sure, people
make mistakes. But when people point them out,
your supposed to acknowlege them rather than
treating the people who correct you as ignorant
or not worth of talking to.

achorale 12/4/2012 | 9:24:08 PM
re: Packet Design Intros BST Emirikol writes:

> Sorry... second sentence should have said:
>
> The world would be much easier to manage if
> people would spend more effort saying fewer
> things but saying them correctly.

this has to be the funniest post i've seen
in a long time. classic! thanks Emirikol ...

gardner 12/4/2012 | 9:24:09 PM
re: Packet Design Intros BST What is with the pentagrams around TCP? <\b>

Pentagrams? That's so cute! Evidently we have one of those guys right here in our midst who sees Anton LaVey under every bed. ;-) Pentagrams indeed. As a SONET guy I tend to think all IP heads are devil worshipers but I think those particular drawings might represent complete graphs with 5 vertices more than they represent Satan. I suppose that to the unwashed masses who were drunk that day in discrete math class they look suprisingly like an upside down pentagram contained in a pentagon but they aren't. Perhaps if you cut back on the Jack Daniels . . . ;-)
light-headed 12/4/2012 | 9:24:10 PM
re: Packet Design Intros BST Van has made amazing contributions... just saying that he has recently done some sloppy work and any of the "routing gods" can do bad work as well as good work. Time will tell with this one but i am suspicious of anything that is not pushed through the ietf standards process and subjected to peer review. This may well be a submitted draft but there is no mention in article.
Page 1 / 3   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE