> On 5 Aug 2016, at 14:31, Eric C Rosen <[email protected]> wrote: > > 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.
It will not be possible to define such a document within the standards process anyway, every network operator will have different constraints as to what their problem space is, and hence the exact details of the solution will differ from operator to operator. (Speaking as someone that has designed a solution for the same problem of MPLS in the aggregation domain for multiple operators, and come out with different solutions each time.) The intention of this document is to describe a high-level architecture that could be used to scale an MPLS domain using SR. The advantage of documenting such things is that the IETF provides some guidance as to how one might use some of the protocols it develops, which informs network architects as they choose what technology to implement. The advantage of doing this from a vendor perspective is that one might limit the many different approaches that exist to solve a certain problem, limiting the number of unique-snowflake architectures that must be supported in network element code. One could assert that the IETF is not the right place to publish such documents, but I really agree with Robert that we are collectively neglecting an opportunity to write documents which aid operators (including those that might not care about the exact encoding of bits on the wire) in deploying the technologies that we define. r. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
