Rich, On 15 Apr 2011, at 15:31, Woundy, Richard wrote:
> 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). The reason I do not think an ALTO Server - Network API needs to be specified in ALTO is not because I think ALTO servers do not need to extract topology from the network in a scalable way but because I see no Standards Track work for the ALTO WG to do to achieve that aim. I could paraphrase the contents of draft-medved-alto-svr-apis-00 as "Go implement draft-gredler-bgp-te-00 and here are some reasons why BGP is good". Therefore the solution proposed is not really draft-medved-alto-svr-apis-00 it is draft-gredler-bgp-te-00. As someone with a background in routing draft-medved-alto-svr-apis-00 adds nothing to draft-gredler-bgp-te-00 and certainly nothing that warrants the status of a Standards Track document. Now, I guess given ALTO is not in the Routing Area there may be folks in ALTO who are not routing experts and some level of informational material explaining how routing can be used to obtain topology may be useful, but that's an Informational document at best (it could be a BCP once there's some real world experience of doing it). > 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. No objection there. ISIS and OSPF are also commonly implemented by router vendors and commonly deployed by service providers :-) In my mind a Standards Track document coming out of ALTO that says "The answer is to load everything in BGP" sets the precedent that the IETF 'mandated' way to do it loading your IGP into BGP, when IMO that is one possible way that is likely to suit some but not all service providers. > That's why I am interested in an open specification for an ALTO server to > network API. IMO those open specifications exist in the form of the RFCs that describe existing (and future) routing protocols and extensions. To summarise my position: - I believe that passively listening to routing is a reasonable approach. - I do not believe there is Standards Track work for the ALTO WG to do to describe how to passively listen to a routing protocol. If ALTO generates additional requirements that cannot be met by existing roputing protocols ALTO could specify those and take them to the appropriate Routing Area WG to produce a solution. I think draft-medved-alto-svr-apis-00 clearly demonstrates that as it contains no protocol specification at all and leaves all that to draft-gredler-bgp-te-00 which can be taken up with the IDR WG. > -- Rich > > P.S. I don't think ALTO servers need to listen to BGP *and* the IGP. I think this really depends on the particular service provider's network. When I look at how service providers are requesting automatic topology import into our CDN product some are requesting ALTO, some are requesting just BGP and some are certainly requesting that we listen to both BGP and the IGP. Ben _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
