On Apr 11, 2014, at 4:28 PM, Yakov Rekhter wrote: > Stefano, > >> Hi Yakov, >> >> thanks for your comments. See below. > > in-line below... > > [clipped...] > >>> To reach the >>> same scale, an operator would need to introduce additional >>> complexity, such as mechanisms described in >>> [I-D.ietf-mpls-seamless-mpls] >>> >>> Perhaps before claiming "additional complexity" in >>> [I-D.ietf-mpls-seamless-mpls] the authors of the draft should >>> count the number of times the word "simple" or "simplicity" >>> occurs in [I-D.ietf-mpls-seamless-mpls] (which btw has one >>> of its authors the same as one of the authors of >>> draft-martin-spring-segment-routing-ipv6-use-cases). >> >> a co-author on both drafts is a good thing as it demonstrate >> we have different solutions for different (dataplanes) use cases >> and this doesn't mean one prevails over the other. >> >> I don't find anything wrong with this. > > The above still does not explain what exactly are the mechanisms that > "introduce additional complexity" in [I-D.ietf-mpls-seamless-mpls], > and how SPRING is going to make the overall solution simpler than > [I-D.ietf-mpls-seamless-mpls]. >
> Moreover, if all you want is to "demonstrate we have different > solutions for different (dataplanes) use cases, and this doesn't > mean one prevails over the other", then the discussion about > the "additional complexity" is clearly outside the scope of > the use cases document. the authors want to demonstrate how TE is deployed today and what SR must support and address with the removal of intermediate state maintenance (i.e.: simplification), other than the usual igp state. s. > > Yakov. > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
