As a co-author of draft-medved-alto-svr-apis-00, I have some responses to this thread in line below.
Thanks, Dave On Friday4/15/11 1:40 PM, "Woundy, Richard" <[email protected]> wrote: >> 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. I think the following summary is more accurate than the above: Note that section 4.1.1 is requirements, and states all of them as "should" (I.e., SHOULD) and are not mandatory. Section 4.1.2 describes A solution that meets many of the desirable requirements. > >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. I agree with Rich that the use case/ requirements is separable from the protocol specifics. Ben, would separating these address what appears to be one of your major comments? I suggest that we first focus on the requirements and where that work is best chartered. > >-- 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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
