On 8/15/16, 6:53 AM, "spring on behalf of Eric C Rosen" <[email protected] on behalf of [email protected]> wrote:
>On 8/12/2016 1:43 AM, Rob Shakir wrote: >>> 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. > >I agree that an IETF WG should not adopt a draft that attempts to >restrict what operators should do. This draft provide a way of how to use SR to scale MPLS network. It is NOT about restrict what operators should do. As others said, operators could certainly deploy their network in different way which is fine. There are many informational ietf drafts which did the same thing: provide one way (the best way the authors may think) to solve the operator¹s problem. > >> >> The intention of this document is to describe a high-level architecture >>that could be used to scale an MPLS domain using SR. > >But all the document really says is "use two levels of hierarchy, or >optionally three". It's not clear that anything is required or >prohibited. The draft raises some issues that have to be thought about >when designing a deployment. If the draft simply said "here are some >operational considerations to think about if you have a hierarchy in >which the lower layers have limited FIB size", and if the draft made >clear that it isn't mandating (or even describing) a particular >solution, I think it would be less problematic. > >> 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, > >"might use" ---> "might or might not use" ? > >> 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. > >I don't believe the document has nearly enough content to say how any >particular problem is or is not to be solved in any particular >deployment scenario, so I don't think it is useful for that purpose. > >I can however see the document being used in ways that probably aren't >intended. Since the document is mostly about a 2-level hierarchy, and >allows a third level "optionally", one could interpret the document as >prohibiting a 4-level hierarchy. I doubt that that is intended. But >maybe it is, it's not really possible to tell. > >Even for the single application that is mentioned, it is not clear what >if anything is being ruled out or why. > >And given that different operators will require different approaches, I >don't see why we would want to rule out different approaches. > >> >> 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. >> > >I'd have less of a problem if the document said, "here is some guidance >as to how one might use SR to scale an MPLS domain, but no claim is made >that this is the only way, or the best way, or the preferred way; >different deployment scenarios and/or requirements may require different >procedures." > > > > >_______________________________________________ >spring mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
