On Wed, Apr 13, 2011 at 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. > > I concur for now. It's not clear to me that we fully understand the network abstraction information to be gathered in the first place. Draft-sun has recommended to gather information at BAS granularity. Another draft was talking about inter-ISP network abstraction for better asyn transmission etc.Comcast has shown that coarse and fine network maps have the similar effect... Further, I think that the current ALTO WG scope is to define the mechanism to bind application and network, not the actual network abstraction. Correct me if I am wrong. Regards, Ping > 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
