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
[email protected]
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
