> I see no Standards Track work for the ALTO WG to do to achieve that aim.
My opinion: I do agree that this work is outside the scope of the current ALTO charter. I think the essential question is whether this effort should be captured in an ALTO re-charter. It seems we will have diverging opinions there. I'll defer to the WG chairs to figure out how to determine consensus or lack thereof. > 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. Well, I agree, sort of. draft-medved-* is just a motivation document at this time, eg why we want it, what we think are the requirements. draft-gredler-* defines the new BGP encodings but doesn't say much how an ALTO server would leverage that information. draft-gredler-* also is concerned with MPLS-TE, which is way outside the scope of ALTO. A third document is needed (or significant updates to the other two) to say how an ALTO server would consume and react to the BGP TE information. But right now there doesn't seem to be a forum for this discussion. It is not in scope for ALTO yet (my opinion), and it seems that IDR is not the ideal forum. > If ALTO generates additional requirements that cannot be met by existing > [routing] protocols ALTO could specify those and take them to the appropriate > Routing Area WG to produce a solution. That is a possible approach. > 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. Sigh. It might also clearly demonstrate that the protocol specification work to make BGP TE work specifically with ALTO servers hasn't started yet. And that draft-medved-alto-svr-apis-00 is written as a motivational (use case / requirements) document not as a standards track protocol document. I guess we might have to agree to disagree. -- Rich -----Original Message----- From: Ben Niven-Jenkins [mailto:[email protected]] Sent: Friday, April 15, 2011 1:11 PM To: Woundy, Richard Cc: Jan Medved; [email protected] Subject: Re: [alto] Do we need to standardise an ALTO Server to Network API? 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
