Re: [spring] WG Adoption Call for draft-previdi-spring-problem-statement - Section 5

["Stefano Previdi (sprevidi)" <[e-mail]>]

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