x
<<   <   Page 7 / 13   >   >>
routethus 12/5/2012 | 3:22:38 AM
re: Foundry Strikes at the Core dljvjbsl,

thanks - interesting view point. I am not sure that the fact that XML-based routing becomes important is synonymous with the decline in the amount of money spent on routers, but none the less, I think I understand where you are coming from.

would be possible to give some examples of application spaces where XML routing is being used in the way you describe (example VoIP, data center to data center computer applications,...)?

thx,
-r
dljvjbsl 12/5/2012 | 3:22:37 AM
re: Foundry Strikes at the Core
would be possible to give some examples of application spaces where XML routing is being used in the way you describe (example VoIP, data center to data center computer applications,...)?


There is a massive shift going on in the enterprise software space to what they call "service-oriented architectures" or "event-drive applications". These are all XML based. These are applications where the results of ubiquitous computing, autonomic computing, pervasive computing ... are all used to create applications that are aware of their own goals and capabilities (otherwise known as reflection). VoIP is an adjunct of this new market. The architectures make extensive use of policy to adapt to user preference and needs as well as network contingencies. It is my opinion (after much study) that these new technologies are going to change the way networks are operated. Anyway IBM, Oracle, Microsoft, BEA etc are all making very large investments in this area. A Google search on the acronym SOA will find a great many developments

Cisco and the other communication companies are going to find that the types of messaging required by these new applications is quite different from that which they are used to. SOAP message routing will be much more important than IP. IP routing will be an essential infrastructure element. However it will no longer offer a strategic advantage to the using company. It will be a commodity element and the strategy in using it will not to quickly adapt new capabilities. Rather the strategy in buying and using IP technology will be to reduce risk and cost. Strategic spending will be on higher-level enterprise services which offer the possibility of differentiation from competitors. It will be at this level that a strategy of investing heavily in new technologies will take place.

Communication companies that understand these new architectures will find a large profitable market. Those that donGÇÖt will have problems. IP will an essential infrastructure component. However products will have to emphasize cost reduction, reliability, controllability over any new capabilities. Routers will be pure commodity items with those from one manufacturer valued because they are interchangeable with those from other manufacturers.
dljvjbsl 12/5/2012 | 3:22:34 AM
re: Foundry Strikes at the Core
What you are talking about is an OSS function more than a routing function. If you look at "XML" you get a lot of the typical database stuff, but it does not, in and of itself, solve any problems

XML does a lot more than that now and is being prepared to do vastly more than that. I'm not saying that XML will replace BGP. What I am saying is that XML will supplant BGP. The exciting non-commodity applications will be occuring at the XML level
spelurker 12/5/2012 | 3:22:34 AM
re: Foundry Strikes at the Core > my point is that the important policy decisions
> that directly affect application utility and
> performance are being made at the XML level.
> Decisions being made at the BGP, VPN GǪ levels are
> going to rapidly become commodity. An XML
> application will decide that a VPN link is needed
> between two organizations. It will be set up and
> then the interesting things will happen at much
> higher application levels.

What you are talking about is an OSS function more than a routing function. If you look at "XML" you get a lot of the typical database stuff, but it does not, in and of itself, solve any problems. If one were to define an appropriate set of schemas, one could transport BGP-equivalent data (see IPDR.org) but this does NOT make it a replacement. It's like saying you've made an electric car by simply duplicating the dashboard lights of a plymouth -- you can see what's going on, but that does not make it do anything.

The problems with BGP lie largely with the "business logic" which is associated with it -- when you get an update, do you trust it? Do you propigate it? When you have input from different sources, how do you arbitrate between them? How much data are you prepared to handle? Can you mask failures? These problems do not go away just because the protocol changes.

I'm willing to believe that there is new technology around the corner to replace that which exixts now, but I've never seen any actual evidence to that effect.
alchemy 12/5/2012 | 3:22:33 AM
re: Foundry Strikes at the Core materialgirl writes:
Separation of logic and transport, isn't that what the "/" in TCP/IP all about? While XML will someday be powerful, how could it possibly manage network affairs over which it is not informed. Commoditize, yes. Replace, how can it?

XML is a programming/protocol definition language, not a protocol. It's easier to think of it as the IETF version of ASN.1 for those who never learned that type-length-value protocols are the robust way to build things. XML is typically used at the application layer but that doesn't mean you couldn't use it to define a Network or Transport layer. (Not that anyone would be stooopid enough to do this.)

There are all kinds of examples of application layer protocols that manage network affairs. The most recent is the BFD (Bidirectional Forwarding Detection) work being done in the IETF. BFD lets you run a lightweight heartbeat between elements in the network. You can use BFD as a control input to things like MPLS or OSPF but an application could very well use it to pick between two different static routes in a redundancy scheme.
materialgirl 12/5/2012 | 3:22:33 AM
re: Foundry Strikes at the Core Separation of logic and transport, isn't that what the "/" in TCP/IP all about? While XML will someday be powerful, how could it possibly manage network affairs over which it is not informed. Commoditize, yes. Replace, how can it?
rjmcmahon 12/5/2012 | 3:22:32 AM
re: Foundry Strikes at the Core There are all kinds of examples of application layer protocols that manage network affairs.

Application protocols managing network routes seems like poor design. Defining the abstraction layers properly is a critical component in building complex systems. Of course, nothing makes an application writer adhere to proper abstractions. I'd guess that the solutions that survive the test of time, will.

As far as XML supplanting BGP seems analagous to saying that the C programming language supplanted the Fast Fourier Transform. It doesn't make any sense to me. (But then I'm no expert in any of the above.)
dljvjbsl 12/5/2012 | 3:22:31 AM
re: Foundry Strikes at the Core
Separation of logic and transport, isn't that what the "/" in TCP/IP all about? While XML will someday be powerful, how could it possibly manage network affairs over which it is not informed. Commoditize, yes. Replace, how can it?


Commoditize is exactly what I meant. BGP will exist in some form as part of a commodity product. XML-based protocols working at higher levels will be making the interesting decisions on who and what to connect to. It will be routing higher-level data structres that are relevant ot the business or user application.

IP routing including BGP will become uninteresting commodities in the same way that the power supplies for network elements are uninteresting commodities. They are vital highly engineered components whose failures can cause serious problems. On the other hand, they cannot offer any beneftis beyond routine error-free operation. Higher level services based on XML will be manageing business processes, ensuring data privacy, routing information autonomously ...

TCP/IP, BGP, routers are all becming commodities and will be subject to commodity economics. In otehr words, all prodcuts are the same and teh only differentiator is price.
paolo.franzoi 12/5/2012 | 3:22:31 AM
re: Foundry Strikes at the Core
rj,

Is it fair to say that there may be multiple levels of protocols that manage network affairs, these each do so with a different time horizon and network scope.

Let me use two extreme examples to show what I mean.

An IMA group of T-1s between two nodes. The IMA group management deals with the real time considerations of the IMA link. This should occur inside the re-routing time of the IP protocols and has limited scope.

Carrier customers feel obligated to "tune" router queues and queue weights. This is done at a much longer time than IP protocols and has limited scope as well.

Carrier customers perform network engineering functions due to traffic management surveys (which in some ways lead to the queue optimization noted above). Again, the longer than IP protocol times and a scope that encompasses the entire network and more.

So, what we are talking about is building boxes that create connectivity management on the order of millions of connections. There are two examples I know of: the PSTN and the Public Internet. We are taking apart the PSTN today and replacing it with technology that has existed for less time than the PSTN but is not exactly rocket science anymore. Someday the same will be true for the Internet. For the PSTN, the SS7 network and its attachment to Class 4 and Class 5 switches represents the network controll plane.

I do find it interesting that this thread included statements that only companies like Cisco and Juniper could make viable BGP routers. Yet, dozens of companies made class 4 and 5 switches and they all interoperated. And the IETF is the open environment? Hmmmm

seven
rjmcmahon 12/5/2012 | 3:22:29 AM
re: Foundry Strikes at the Core Is it fair to say that there may be multiple levels of protocols that manage network affairs, these each do so with a different time horizon and network scope.

I think that is more than fair to say. Network protocols are quite complex and run at multiple levels. There is a lot more to a good packet system than getting BGP right.

I think the difference may be in what we are calling an application. I see a network protocol like BFD and an application like Apache as two different things. I don't see a reason why one would expose things like route redundancy to Apache. Did I confuse things?
<<   <   Page 7 / 13   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE