Hi Ben, > Regarding whether we need to standardise the Network-to-server "API" > for ALTO, my opinion is that we do not.
I highly agree with that opinion. Any attempt to standardize ALTO server API to network is a clear attempt to limit it's range of functionality.
Number of reasons: - Attaching an ALTO server as passive IGP node is not an issue. Using BGP to propagate local IGP area topology to ALTO server attached to such area is really highly questionable improvement - Using BGP to propagate remote IGP topologies is just a way .. clearly there are other ways to propagate IGP topologies from remote areas - As defined today draft-gredler-bgp-te-00 is very selective in what information is propagted from LSDB or TEDB. Each addition of such information would require a new BGP extension definition. This will block ALTO innovation. There were already proposals stated during the last IETF to carry entire LSDB in BGP as opaque information however those are beyond the scope of this WG discussion. - ALTO servers even today can benefit from other ways to get network information which would not have to be carried in BGP. Many thx, R.
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. 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. 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. * 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. 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
