On 8/12/2016 1:43 AM, Rob Shakir wrote:
On 5 Aug 2016, at 14:31, Eric C Rosen <ero...@juniper.net> 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.
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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
