Subject: Re: [spring] WG adoption requested for draft‐filsfils‐spring‐large-scale-interconnect

From: Eric C Rosen <[email-masked]>
Date: Fri, 5 Aug 2016 16:31:52 -0400

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-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 5 Aug 2016 23:09:46 +0200

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-masked]> wrote:

> I'm afraid I really don't understand just what the point of adopting this
> document would be.
>
> 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.
>
> 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 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.
>
> 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.
>
>
>
>
>
>
>> 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.
>>
>> 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
>>

---

From: Rob Shakir <[email-masked]>
Date: Thu, 11 Aug 2016 23:43:36 -0600

> On 5 Aug 2016, at 14:31, Eric C Rosen <[email-masked]> 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.

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 15 Aug 2016 09:53:46 -0400

On 8/12/2016 1:43 AM, Rob Shakir wrote:
> 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 opera…

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."