To clarify .. I was not mixing two things. I was only referring to ALTO
server-to-network part in my last two posts.
So to conclude my opinion is:
- ALTO client to server protocol - required
- ALTO server to network protocol - not needed
- ALTO server to server spec - perhaps required, but only to define
server to server network map abstraction such that two ALTO servers from
different vendors could exchange/share their maps. Useful especially in
the inter-domain applications (example: CDNs).
Rgs,
R.
I think you are mixing two things together, that I see as
independent.
But do you need to have a RFC which mandates support of BGP-TE spec
by an ALTO server ? How about ALTO vendors which not have BGP code
at all today ?
There is a ALTO client-to-server protocol spec. There is a ALTO
server-to-network protocol spec. They should be independently
specified, and can be independently implemented.
If you want to build a ALTO server that follows only the
client-to-server protocol spec, go ahead. There is probably a market
for a product like this. This shouldn't be prohibited.
I think there are a number of parties that want an ALTO server that
would follow specifications for both client-to-server and
server-to-network protocols.
I could really easily imagine an ALTO vendor which does not support
BGP and collects network information (both routing and non-routing
related) via their own self discovering application modules running
on all or on subset of routers of given network.
So in other words, I need to deploy "application modules" on my
routers for your approach to work. And if your application modules
didn't run on my routers, I have to replace my routers to enable ALTO
support in my network. Hmmm.
And on the other hand if you want to choose a particular
deployment
model you can select ALTO server vendor which does support BGP-TE
RFC XYZ.
Yes we could. The question is what needs to be carried in BGP-TE to
be useful to ALTO servers. That's where the interoperability concerns
arise, and where an open specification is needed.
-- Rich
-----Original Message----- From: Robert Raszuk
[mailto:[email protected]] Sent: Friday, April 15, 2011 11:08 AM To:
Woundy, Richard Cc: Benjamin Niven-Jenkins; Jan Medved;
[email protected] Subject: Re: [alto] Do we need to standardise an ALTO
Server to Network API?
Hi Richard,
My secondary motivation is to ensure that, with respect to
automated population of network information into ALTO servers, I
could choose ALTO server vendors and router vendors fairly
independently.
But do you need to have a RFC which mandates support of BGP-TE spec
by an ALTO server ?
How about ALTO vendors which not have BGP code at all today ?
Are they out of luck to even propose ALTO servers ? I could really
easily imagine an ALTO vendor which does not support BGP and
collects network information (both routing and non-routing related)
via their own self discovering application modules running on all or
on subset of routers of given network. Result: no need to configure
and maintain dozens if not more of BGP sessions both on the ALTO
server as well as on the routers, no need to support BGP or IGP on
ALTO server side.
And on the other hand if you want to choose a particular deployment
model you can select ALTO server vendor which does support BGP-TE
RFC XYZ. Just like today when you are buying routers or other
network devices you just make sure they speak the same language as
described in the protocol RFC XYZ. No need for another API spec to
mandate support of RFC XYZ.
Cheers, R.
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
