As not a co-author I support the adoption of this document. It is to be used as deployment guideline and contains very useful examples for ops and network engineering teams.
It has been discussed that IETF drafts should not be limited to protocol specifications. In general we publish a lot of dry documents which in number of cases lack of comprehensive operational guidelines. It is however to the working group and area director to categorize such document as informational RFC or make it a BCP. Useful work ! As to one comment made: > But one certainly couldn't hand this draft to a vendor and say "this is what I want"; > there isn't nearly enough content in the draft for it to be used that way. I must say that this really depends on the vendor. If I have internal development teams or external vendor developing controller such document is a very good reference to base customized details on. And those would normally be given SP or Enterprise "secret sauce". Kind regards, Robert. On Fri, Aug 5, 2016 at 10:31 PM, Eric C Rosen <[email protected]> wrote: > I'm afraid I really don't understand just what the point of adopting this > document would be. > > All the document really says is that one can improve scale by using > hierarchy. That is certainly true, but hardly a new result. The document > gives two examples of hierarchical structure: a two-level hierarchy and an > "optional" three-level hierarchy. I'm not sure why the three-level > hierarchy is any more or less optional than the two-level hierarchy or any > other form of hierarchy. > > The document goes on to sketch an application that could be run over the > hierarchy, the application of setting up pseudowires with SLA. Then it > gives an example of how one might (or might not) set up a control plane to > run the example application over the example hierarchy. But one certainly > couldn't hand this draft to a vendor and say "this is what I want"; there > isn't nearly enough content in the draft for it to be used that way. > > The document doesn't seem to rule out any alternatives, or even give > considerations that could be used to rule out alternatives. > > The document doesn't require anything, doesn't prohibit anything, doesn't > provide any kind of comprehensive analysis, doesn't really address any > protocol issues. While it does present some interesting thoughts about the > use of hieararchy in a spring-based network, I don't think it makes any > sense for the working group to adopt the document in its present form. > > It is possible that the document is intended to evolve into a more > comprehensive study of hierarchical approaches to segment routing. In that > case, I think it would be useful to see a little more of that evolution > before considering whether to adopt the document. > > > > > > > On 7/24/2016 8:55 AM, John G. Scudder wrote: > >> Dear WG, >> >> As we discussed at our meeting, working group adoption has been requested >> for draft‐filsfils‐spring‐large-scale-interconnect. Please reply to the >> list with your comments, including although not limited to whether or not >> you support adoption. Non-authors are especially encouraged to comment. >> >> We will end the call on August 31, 2015. >> >> Authors, please indicate whether you are aware of any relevant IPR and if >> so, whether it has been disclosed. Also, the length of the author list for >> this document greatly exceeds the maximum recommended. Assuming the >> document is adopted, the authors should be prepared to correct this when >> submitting as a WG document, ideally by reducing the list to simply the >> active editor(s) and making use of the "contributors" section for the full >> list. >> >> Thanks, >> >> --Bruno and John >> >> _______________________________________________ >> spring mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/spring >> > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
