Ben, Please see inline.
Thanks, Jan On 4/13/11 4:32 AM, "Ben Niven-Jenkins" <[email protected]> wrote: >Authors, Colleagues, > >The meeting minutes from IETF 80 record: > >"Jan Medved presents Network-to-server API. > > Jan Seedorf: scope of this work is explicitly excluded in RFC 5693 > ALTO WG scope description. Enrico: this is new work, currently not > in the charter. We should hear it. Jan S.: we need to discuss if we > need to standardized it. Eric: it does, but maybe not now." > >Regarding whether we need to standardise the Network-to-server "API" for >ALTO, my opinion is that we do not. > >Extracting network topology by passively listening to routing protocols >for various purposes including aiding with operations, diagnostics, root >cause analysis, management, capacity planning, traffic engineering, etc. >is not a new idea. There are multiple products on the market to enable >operators to do just that. Agreed that extracting network topology by passively listening to routing protocols is not a new idea. What is a new idea, though, is that it can be accomplished by listening to a single protocol (BGP with TE extensions), rather than listening to both BGP and IGPs. This significantly simplifies (even enables) the operation and deployment of an ALTO Server that wishes to listen routing protocol updates. Streamlining / simplifying the ALTO Server's operation is the primary motivation for this draft. > >An ALTO server that follows a similar approach as a mechanism to import >network topology into its network topology/map/cost database is a >reasonable proposition but in my opinion the ALTO WG should not attempt >to standardise how a ALTO server should perform such integration with an >operator's routing control plane(s), for example because: > >* 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). >Interoperation between an ALTO Server and the underlying network(s) is a >solved problem as is demonstrated by the numerous interoperable >implementations of routing protocols. Not really. First, the interoperable implementations of routing protocols are used to talk between routers themselves, not as a northbound API to the network. Now, we need to differentiate between BGP and IGPs. BGP can (and has been) used to get network topology to interested clients. IGPs are not, and it is highly unlikely that operators will let an ALTO Server to hook into their IGP (at least this has been my experience over the past several years...). Even if they do, there are a lot of issues with it - security, worries about network stability, multi-area deployment complexity, etc. (more listed in the draft). We need both BGP and IGP data to generate cost maps, and unfortunately today there is no practical way to get it. Today, the vast majority of clients that need network topology data simply hook into BGP. ALTO is much easier to use to get network topology than BGP. But for ALTO to be usable for this purpose, we need a deterministic way to generate ALTO maps from a well defined set of network data, so that clients know what they're getting. One part of this definition is the Network-Server API which defines the data set and the way to get it, another is a normalized way to generate the maps. > >* Attempting to standardise a single approach is likely to limit the >applicability of ALTO (or the relevancy of the ALTO Server-Network "API >standard") because it is unlikely we would be able to converge on a >single routing protocol that would satisfy the preferences of all >operators that are likely to deploy an ALTO server. I am not sure what you mean - there is a single routing protocol that operators have converged on - BGP. If you mean operators have not converged on a single IGP, I agree. But that is precisely one of the problems we are addressing with the draft. Operators can use a single protocol - BGP - that (with appropriate extensions) can convey all the information required to generate ALTO maps. Since BGP has the necessary security and policy knobs, and it is already being used to exchange information between different admin domains, it is definitely a good candidate for a northbound API to propagate topology information to interested clients. Some of the diagnostics, root cause analysis, management, capacity planning, traffic engineering etc. tools could also benefit from this API, since it will make life a lot easier for them. Or, better yet, they will be able to use the ALTO interface, which will make it even easier :-) 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. Now, I would like to point out that the draft is only focusing on ALTO maps that are generated from network topology data. There can be other maps, generated from other types of data (for example from RTD measurements, network probes, or from resource utilization measurements), which will require their own APIs. This "other data" and "other APIs" are not in the scope of the draft. > >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
