Dave, Colleagues, Please see inline below.
Ben On 18 Apr 2011, at 15:20, Mcdysan, David E wrote: >>> 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? Yes. I would prefer ALTO WG to focus on: - What information an ALTO server needs from the network to do its job (which may differ by use case). - What an ALTO server may want (or be required) to do with that information > I suggest that we first focus on the requirements and where that work is > best chartered. > Did you mean to insert a 'not' to make 'and not where that work is chartered'? If so, then I'd say that is a fine suggestion and one I heartily agree with :-) Ben _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
