Hi Folks,
After segment routing solution was proposed, there are a lot of discussion on it. Until now there is still much concern about application and deployment of this solution. According to my understanding and communication with other experts from operators and vendors, I summarize as follows:
1. Issues proposed by depth of label stack
Forwarding packets need to push a SR header with a list of segments(labels). The depth of label stack will be a challenge for some type of devices. I remember that when entropy label is introduced, Kompella did a presentation in MPLS WG meeting to discuss the possible challenge proposed by possible deeper label stack. Comparing with entropy label, the label stack issue is even bigger for segment routing. The challenges propose by the depth of label stack includes:
1) Upgrading of hardware of existing devices;
2) If not upgrade, when do path calculation in control plane, it must be careful not to let the segment routing path to exceed the capability of forwarding plane. In other word, there proposes scalability issue for the control plane.
3) If upgrade forward plane and control plane to make segment routing scalable enough, there will be payload efficiency issue and MTU issue. That is, big size of the header will reduce the efficiency of payload.
Then there will be limited application scenarios for SR caused by the depth label stack. Comparing with segment routing, except soft state issue, RSVP-TE will not cause the limitation described in 2) and 3). Is it necessary to pay higher price to adopt segment routing?

2. Issues proposed by multicast
Multicast proposes more challenge for the segment routing. Now MPLS-based multicast solutions is mature after many years' development. Moreover IP network is widely used to bearing multiple services including unicast, multicast, etc. Segment routing is to replace LDP/RSVP-TE to simplify network operation and maintenance. In fact, it only to replace P2P LDP/RSVP-TE. Thus there will be the situation for multi-service bearing IP network, IGP is to introduce to cope with label-based unicast service while mLDP/P2MP TE is kept to bear multicast service. This is just to add complexity to network other than simplifying. 

3. Issues proposed by state
At the beginning, one major advantage for segment routing is that State is only maintained at the policy head-end. No state is maintained at mid-points and tail-ends. As the development of segment routing, it is beginning to change:
1) If there would only node segment and adjacency segment, it is only for transport layer and there will not be too much states. But as the prefix segment is introduced, there maybe not much difference between LDP/RSVP-TE and IGP in essence. Now there are usecases for IGP allocate label for service chain, ECMP, anycast, etc. In draft-li-isis-mpls-vnode-vlink-00, I proposed another use case to slice the link or node based on bandwidth (you can look on it as bandwidth-guaranteed segment routing). Then there may be more states in the segment-routing-based network to affect the scalability of the network.
2) Regarding to state issue, in some scenarios, MPLS TE may gain advantage over segment routing. For example, as the traffic steering usecase introduced in segment routing to steering traffic to some light-load path, if MPLS TE is used, the states may be only confined to the nodes passed by the MPLS TE path while in segment routing IGP needs to flood segment-routing-related states to all nodes in the network.
In one word, as the segment routing develops from transport layer to service layer, the flooding character of IGP will impose scalability issue to the network too.

4. Issues proposed by implementation in distributed environment
Though the segment routing can be used in distributed environment and central controlled environment, in distributed environment there will be some implementation challenges:
1) Possible configuration introduced by policy control or path control. After the segments are flooded in the distributed network, in some scenarios it has to do a lot configuration work. For example, as the traffic steering usecases, each hop or several hop for the segment routing path in the ingress node must be specified. It is just like that in MPLS TE explicit path must be specified hop by hop. According to my understanding, IGP is used for segment routing owing to its higher scalability than MPLS TE. But the similar configuration work maybe reduce the advantage and affect its deployment. For IP FRR, maybe it is better since the backup path can be calculate automatically according to the available algorithm.
2) Complex IGP's label allocation method. I think the existing method is not a good way to reserve SRGB and allocate segment index. It is complex and also not scalable. We have implemented similar features to reserve a range of label for specific service. When deploy in the network, it must be careful to choose the range. If it is too big, it will have much effect on the scalability of other service which will not use the reserved label range. If it is small, there may be upgrading issues to change the label range as the segment-routing-based service develops( it seems very possible as analysis about state increasing in 3 ). When expand the label range, it will cause the traffic break in the network.
So IMHO, central control is suitable for segment routing. Thus the policy control, the configuration, the global label allocation, the path calculation, the traffic steering, etc, all seems to have a better solution in a central control environment. But as described in draft-farrkingel-pce-abno-architecture-07, there are multiple choices for the central control. Regarding the use cases coped with by segment routing, maybe there exist other better solutions instead of segment routing. Thus segment routing maybe have to face the embarrassing situation: if rely too much on the distributed environment, its deployment will be affected. If rely on the central control environment, there may be better alternative solutions. The situation will have much effect on the actual deployment of segment routing.

In one word, based on existing forwarding plane and control plane there exists apparent scalability issue which limits application scenarios for segment routing. It is inevitable to have doubt on the future application and deployment of segment routing. I have following opinions:
1. For basic scenarios segment routing seems perfect. When dig more, drawbacks may become apparent. For example:
1) the node segment and link segment seems OK. When introduce too many prefix segments and various IGP TLVs, there will be doubt if all the extensions make sense. 
2) There still doubt on scalability of MPLS forwarding for segment routing. Now it seems to move to IPv6 forwarding in a hurry. 
From above two examples, we can see the development of segment routing is a little aggressive. From my point of view, the work may be not helpful to segment routing. Instead, it is just to propose the worry about the cost for segment routing. In my opinion, the WG and the authors should control the scope and development pace of segment routing. 
2. Segment routing truly proposes some important technology elements such IGP-based label allocation, global label, etc. On the other hand, these technology elements may be not only used for segment routing. As a result, the mixing work maybe slow down the development of these important technology elements. I think there should be some decoupling work to be done for these elements from segment routing (For example, IGP-based label allocation can be decoupled from IGP extensions for segment routing). Or else, it may be always confused what belongs to segment routing or not. 


Regards,
Robin




-----邮件原件-----
发件人: spring [mailto:spring-bounces@ietf.org] 代表 Stewart Bryant
发送时间: 2014年1月29日 1:06
收件人: spring-chairs@tools.ietf.org; spring@ietf.org
抄送: spring-ads@tools.ietf.org
主题: [spring] Lack of progress in SPRING WG

All,

We understood when the SPRING WG was formed that it was addressing a problem of importance to both the network operators and the equipment vendors.

We are therefore surprised that there seems to have been no progress on setting out the requirements and architecture.

We are worried to see no apparent progress and we want to understand what the problem is. If there is no interest in continuing with this work in the IETF then we can close the working group, but we suspect that there is actually a lot of interest.

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