Hi Ben, A response to your question below. Dave
On Tuesday4/19/11 12:43 PM, "Ben Niven-Jenkins" <[email protected]> wrote: >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 :-) Sorry, the following is what I had in mind, with CHANGES IN ALL CAPS. I suggest that THE ALTO WG first focus on the requirements and THEN AS A NEXT STEP (E.G., A SEPARATE DRAFT) DETERMINE where ANY NEEDED INFORMATIONAL, BCP OR PROTOCOL work AS DETERMINED FROM THE REQUIREMENTS ANALYSIS WOULD best BE chartered. > >Ben > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
