Hi Yakov, thanks for your comments. See below.
On Mar 26, 2014, at 6:39 PM, Yakov Rekhter wrote: > Alvaro, > >> Hi! >> >> This message officially starts the call for adoption for >> draft-martin-spring-segment-routing-ipv6-use-cases. >> >> Please indicate your position about adopting this use cases >> draft by end-of-day on March 27, 2014. >> >> http://tools.ietf.org/html/draft-martin-spring-segment-routing-ipv6-use-ca > ses >> >> Thanks! > >> From section 2: > > However, there are other cases and/or specific network environments > where MPLS may not be available or deployable for lack of support on > network elements or for an operator's design choice. In such > scenarios a non-MPLS based solution would be required. > > The above assumes that the already available technology, MPLS, "may > not be available or deployable for lack of support on network > elements", yet a brand new technology, a new IPv6 Segment Routing > header, will be available, deployable, and supported on network > elements. The authors should elaborate on what makes them think so. we can reword the statement so to explain that there are places where mpls is not planned to be deployed while ipv6 is and it is preferred (by the network operators of such infrastructures) to extend ipv6 with sr rather than changing dataplane. > Wrt "for an operator's design choice", the draft should present a > rational explanation for such choice. I don't think so. It's a reality we have to cope with. > Otherwise, the draft should > just say that its use cases are the folks who go into anaphylactic > shock at the mention of MPLS. or maybe just mention that mpls, being a great technology, is not deployed everywhere. I'd skip the "anaphylactic shock" part of your comment which, btw can apply to both mpls-haters and mpls-addicted. They usually share the same symptoms. At the end, I believe the vast majority (if not all) of the people who adopted mpls did so because of good and practical reasons. The same applies to the ones who deployed ipv6, don't you think so ? The reality of the industry is that we have both dataplanes so it's obvious that we may want to provide similar functionalities for both without claiming one technology is the solution for everything. > More from section 2: > > 4. There is a need to connect millions of addressable segment > endpoints, thus high routing scalability is a requirement. IPv6 > addresses are inherently summarizable: a very large operator > could scale by summarizing IPv6 subnets at various internal > boundaries. This is very simple and is a basic property of IP > routing. MPLS node segments are not summarizable. > > Where is the use case that illustrates application of summarizable > Node-SIDs ? I think it's explained in the text but we can add more details if necessary. > 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. Thanks. s. > > Yakov. > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
