Subject: [spring] Comments on Abstraction//WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

From: Lizhenbin <[email-masked]>
Date: Thu, 10 Apr 2014 09:12:57 +0000

Alvaro,

Abstraction of draft-martin-spring-segment-routing-ipv6-use-cases presents as follows:

'
   SPRING allows to
   enforce a flow through any topological path and service chain while
   maintaining per-flow state only at the ingress node to the SPRING
   domain. 
'
I wonder if now SPRING still keeps this rule. Besides node segment and link segment for composing the explicit path, segments has being extended to many types of services and transit nodes will have to maintain more states.

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

---

From: Lizhenbin <[email-masked]>
Date: Thu, 10 Apr 2014 09:25:33 +0000

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)

ses

---

From: Lizhenbin <[email-masked]>
Date: Thu, 10 Apr 2014 09:38:46 +0000

Alvaro,

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

These sections describe the use cases of segment routing in home network and access network. I would like to quote the text which concerns MPLS scalability in section 2:
'
       4.  There is a need to connect millions of addressable segment
       endpoints, thus high routing scalability is a requirement.
'
I am glad that authors can take into account scalability issue. But scalability will be from multiple aspects. For the scenarios of the home network and access network which likes to use IPv6 segment routing, the complex configuration for the explicit routing will also be a challenge on scalability. In addition, in these scenarios, the end user is easily involved. I wonder if the user could do or likes to do such professional path policy configuration. Maybe SDN is a possible solutions. But for the home network and the access network, there maybe huge number of devices to control (e.g. 100, 000 access nodes mentioned in seamless MPLS). It will also propose enough scalability challenge to the possible controller. From my own point of view, the use case proposed here is not persuasive enough until now.

Regards,
Zhenbin(Robin)

ses

---

From: Lizhenbin <[email-masked]>
Date: Thu, 10 Apr 2014 10:02:17 +0000

Alvaro,

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

These sections describe the use cases of segment routing in data center network.
1. I wonder if now there is a hot discussion on using IPv6 in data center. What is the drive to introduce IPv6 into data center, lack of IP addresses?
2. Regarding "Service Function Chain", it is earlier to involve IPv6 segment routing in the field. Until now, the requirement and architecture of SFC WG is not determined yet. The solution proposed in SFC seems to prefer independent service header or reusing exiting header. Here the solution based on IPv6 segment routing seems only has relation with the use case described by SFC WG. If the SFC WG is taken into account, the requirement, architecture, the solution in SFC WG should also be taken into account. If so, binding the service chain function with a specific IP header maybe not a good choice. That is, for IPv6 segment routing, it is too early to utilize advantage of service chain.

Regards,
Zhenbin(Robin)

ses