Hi Yakov, thanks for the comment. See below.
On Mar 24, 2014, at 7:18 PM, Yakov Rekhter wrote: > Alvaro, > >> Hi! >> >> This message officially starts the call for adoption for >> draft-previdi-spring-problem-statement. >> >> Please indicate your position about adopting this use cases draft >> by end-of-day on March 27, 2014. >> >> Some additional background: We had issued a call for adoption for >> draft-filsfils-rtgwg-segment-routing-use-cases-02 back in November. >> From both the discussion at the meeting in Vancouver and on the >> list, there was consensus to adopt. The authors published >> draft-previdi-spring-problem-statement-00 as a revision to the >> original draft without the solution being present in the use case >> description. >> >> http://tools.ietf.org/html/draft-previdi-spring-problem-statement >> >> Thanks! > > draft-previdi-spring-problem-statement-00 is not just > "a revision to the original draft without the solution being > present in the use case description", but the revision of > the original draft without *any* use case description. To > illustrate this point just look at Section 5 of the draft: > > Section 5 - Traffic Engineering. > > The SPRING architecture should support traffic engineering, > including: > > o loose or strict options > > o bandwidth admission control > > o distributed vs. centralized model (PCE, SDN Controller) > > o disjointness in dual-plane networks > > o egress peering traffic engineering > > o load-balancing among non-parallel links > > o Limiting (scalable, preferably zero) per-service state and > signaling on midpoint and tail-end routers. > > o ECMP-awareness > > o node resiliency property (i.e.: the traffic-engineering policy is > not anchored to a specific core node whose failure could impact > the service. > > The SPRING use case document has to elaborate each use case in > sufficient details that we could each read it and agree on how the > functionality would be accomplished, but without describing the > actual solutions. This applies not just to Section 5, but to the > whole document. I tend to agree with you and my first approach was to take the segment routing use cases draft, spoil it from any solution description, and publish it as spring-use-case-prolem-statment. But the first comments I got from that approach were not positive so we went for a more "summarized" form which, I agree with you, is probably not detailed enough for the process. Note that the problem statement draft is a first version and I'm already incorporate changes (among which your comments). Thanks. s. > > Yakov. > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
