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

From: Yakov Rekhter <[email-masked]>
Date: Mon, 24 Mar 2014 11:18:44 -0700

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.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 26 Mar 2014 09:50:05 +0000

Hi Yakov, 

thanks for the comment. See below.

> actual solutions. This applies not just to Section 5, but to the

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