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