[spring] Comments on Section 2//WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

Alvaro,

Please refer to following comments regarding Section 2 of draft-martin-spring-segment-routing-ipv6-use-cases

'
       To reach the
       same scale, an operator would need to introduce additional
       complexity, such as mechanisms described in
       [I-D.ietf-mpls-seamless-mpls]
'
I have explained the inappropriate involvement of seamless MPLS here in previous comment. Firstly maybe I need the authors explain what's the additional complexity. In order to cope with the scalability issue, label BGP, etc is introduced in seamless MPLS which in my opinion it may be the only major complexity. But it is because of the L2VPN/L3VPN which need the LSP for the host address. If only take into account the reachability of IP, I think using MPLS can also be simple. I wonder for the same scale network like seamless MPLS and L2VPN/L3VPN is also necessary, what is the possible solution based on IPv6 segment routing? Complex configuration on explicit path is introduced for edge devices in the network. Or again, the unproved SDN solution will be proposed to simplify the configuration. But how complex and difficult it may be to control 100,000 access nodes.

'
   Specifically, there are a class of use cases that motivate an IPv6
   data plane.  We identify some fundamental scenarios that, when
   recognized in conjunction, strongly indicate an IPv6 data plane:
'
I would not like to lead to the debate between MPLS fans and MPLS haters. I truly agree there exists the scenarios which only use IPv6 data plane instead of MPLS data plane. But I think the text here conveys a little misleading information. It mainly justfiy IPv6 data plane instead of IPv6 segment routing. IPv6 data plane and IPv6 segment routing are different concepts. When debate with possible fans, we would understand what IPv6 is debating :). According to the draft, if authors try to justify IPv6 data plane, it is enough to take little text to clarify it. More effort should focus on justifying IPv6 segment routing.

'
   In any environment with requirements such as those listed above, an
   IPv6 data plane provides a powerful combination of capabilities for a
   network operator to realize benefits in explicit routing, protection
   and restoration, high routing scalability, traffic engineering,
   service chaining, service differentiation and application flexibility
   via programmability.
'
1. In draft-previdi-spring-problem-statement, the problem statement is simple: fast reroute, traffic engineering. 
2. According to draft-previdi-spring-problem-statement and RFC 2702, traffic engineering should includes explicit routing, protection and restoration. 
3. Regarding service chain, until now it has not justified its relation with segment routing. 
4. Regarding service differentiation, need clarification. If it does not repeat service chain, according to my understanding, L2VPN/L3VPN based on MPLS are always to differentiate services.

'
   In addition to the use cases described in this document the SPRING
   architecture can be applied to all the use cases described in
   [I-D.filsfils-rtgwg-segment-routing-use-cases] for the SPRING MPLS
   data plane, when an IPv6 data plane is present.
'
I do not think it is so simple that all use cases in [I-D.filsfils-rtgwg-segment-routing-use-cases] can apply to IPv6 data plane directly. For example, if the IPv6 segment routing header in draft-previdi-6man-segment-routing-header-00 does work, at least, comparing with MPLS , it may propose security concern since it will expose the whole IP address list other than the meaningless MPLS labels. In my opinion, the traffic engineering and fast re-route need rethinking in IPv6 environment. 

Regards,
Zhenbin(Robin)

> 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-us
> e-ca
ses
> 
> Thanks!

>From section 2.5:

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring