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.
Yakov.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
