As a co-author of draft-medved-alto-svr-apis-00, let me explain my motivations for interest in this subject.
My primary motivation is to have *some* scalable means to populate (my) ALTO servers with current network information. Note that I don't think there needs to be only ONE way to populate ALTO servers. Certainly it needs to be possible to use manual configuration as well. Maybe there is room for proprietary mechanisms as well -- perhaps ALTO server vendor-driven (eg unique routing ingest mechanisms and algorithms), perhaps ALTO server purchaser-driven (eg via open/proprietary APIs to the ALTO server). 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. That's why the use of a common protocol (BGP) is of interest, because it is commonly implemented by router vendors and commonly deployed by service providers. We had talked a long time ago in ALTO about using "looking glass servers" as a potential network information source, and usually looking glass servers are based on BGP routes. That's why I am interested in an open specification for an ALTO server to network API. -- Rich P.S. I don't think ALTO servers need to listen to BGP *and* the IGP. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Benjamin Niven-Jenkins Sent: Thursday, April 14, 2011 6:16 PM To: Jan Medved Cc: [email protected] Subject: Re: [alto] Do we need to standardise an ALTO Server to Network API? Jan, On 14 Apr 2011, at 00:54, Jan Medved wrote: > On 4/13/11 4:32 AM, "Ben Niven-Jenkins" <[email protected]> wrote: >> * Extracting network topology is not an interoperability issue between >> ALTO servers. Each ALTO server can extract the network topology >> independently and if the topology needs to be distributed between ALTO >> servers then it is an ALTO Server-Server API that needs standardising >> *not* an ALTO Server-Network API. > > Actually, extracting network topology and generating the abstracted > network topology (maps) is an interoperability issue between ALTO Servers, > and it can not be completely separated from the exchange of topology > between ALTO servers. For ALTO Servers to be able to exchange (and > reconcile) their respective abstracted topologies (maps) with each other, > the topologies need to be equivalent. This then drives the need for a > common set of data from which the topology is created and a normalized way > to generate the topology from the data (which we mentioned in the draft, > but did not attempt to specify). I think this is the crucial bit for me. If you want two ALTO servers to produce the same result you need to identify the key bits of information they need to obtain from the network and how they will translate that into a ALTO representation of the network. How they extract that information from the network is an orthogonal problem. Throwing the entire IGP into BGP (or for that matter specifying that an ALTO server must listen to both BGP and the IGP) doesn't help you with interoperability as you haven't specified what information the ALTO server needs know and what it needs to do with that data to generate the network and cost maps, you've just specified one possible way to import the raw data into the ALTO server. <snip> > Standardizing the way to get network topology through ALTO will extend > ALTO's applicability rather than limit it. If ALTO does not define a > standardized way to generate maps from topology data, people will simply > use BGP (eventually with extensions that will convey the TE / IGP topology > information), and bypass an ALTO Service that a provider may offer. But your draft (and any ALTO Server - Network API) doesn't address how to standardise the way to get topology through ALTO. It just proposes one possible way to get topology *into* an ALTO server. Ben _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
