Hi Yakov, On Apr 2, 2014, at 7:28 PM, Yakov Rekhter wrote: > Stefano, > > The charter asks for "One or more documents describing SPRING use cases", > yet draft-previdi-spring-problem-statement-01 covers not just > use cases but the requirements as well.
well, yes and I don't think it's a bad idea at this stage. s. > > E.g., from section 5: > > 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. > > E.g., from section 5.1.1.1: > > The SPRING architecture should support this use case with the > following requirements: > > o Zero per-service state and signaling on midpoint and tail-end > routers. > > o ECMP-awareness. > > o Node resiliency property: the traffic-engineering policy is not > anchored to a specific core node whose failure could impact the > service. > > etc... > > With all this in mind the authors should keep the scope of the > document to use cases, and remove all the text that talks about > requirements on SPRING. > > Yakov. > > > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
