Hi Robert, Pleaser refer to my inline comments.
Regards, Robin ________________________________ 发件人: [email protected] [[email protected]] 代表 Robert Raszuk [[email protected]] 发送时间: 2015年1月28日 20:54 收件人: Lizhenbin 抄送: [email protected]; [email protected]; [email protected] 主题: Re: [spring] New Comments on Segment Routing(8): Loop Prevention and Error Handling for SR Robin, Most if not of your observations circle around idea to use segment routing as MPLS label signalling mechanism. I do not think this is that interesting scenario. Personally I would not deploy it for such purpose of hop by hop MPLS switching. We have LDP for that. [Robin] 1. I wonder whether this is your own idea or the well-accepted idea of all authors of segment routing. From the draft-filsfils-spring-segment-routing-ldp-interop-02/draft-francois-spring-segment-routing-ti-lfa-01, it seems that the SR-BE path is the replacement of LDP. From the draft-ietf-pce-segment-routing-00, it seems that the SR-TE path is the replacement of RSVP-TE. 2. I think the packet steering is truly an ambiguous concept. I agree with your usecases. We also appreciated the possible chances proposed by the SR and promote the idea in my draft draft-li-spring-mpls-path-programming-00 that MPLS label is becoming the indicator beyond the reachability and can be used as the representation of flexible services combination. I think these topics can develop the existing IP/MPLS world into some new fields. But the ambiguous thing is that the traditional routing and MPLS traffic engieering can also be seen as some types of traffic steering. I think this will be repeated work if SR's objective to solve the internal end-to-end reachability issue. My comments is just to explain the possible challenges and complexity for IGP-based SR path comparing with the existing LDP/RSVP-TE. And I do not think SR can solve the issues better than LDP/RSVP-TE though there maybe some advantage. If we can be aware of this, we should stop the complex protocol extensions work for SR in this field. Or else, it is just to make mess in the MPLS world and produce complexity for the service providers. This is the reason that the SR proposes too many ambiguous things which I will explain later. Contrary I would use SR for controlled packet steering where responsibility is take to make the right header (be it label or extension headers) upon operator or his controller. To the point of the loop .. note that you may have valid cases to traverse given appliance (SFC use case) more then onces hence I would claim it is not aa architecture spec problem, but if so deployment bug. Best, r. On Wed, Jan 28, 2015 at 12:30 PM, Lizhenbin <[email protected]<mailto:[email protected]>> wrote: Hi all authors of segment routing, This is the eighth comments. The issues proposed here apply to both SR-TE path and SR-BE path. For LDP and RSVP-TE, there is the loop prevention mechanism when setup LSP. For the SR, the SR path is always setup at the ingress node. It is difficult to detect the possible loop in the network. For example, if the microloop of route happens, the loop prevention mechanism will prevent LDP to setup LSP. But for the segment routing, once the ingress node downloads the forwarding entry and the traffic will experience the microloop. How can SR to cope with the issue or just leave it as the traditional routing? For LDP and RSVP-TE, there is the error notification mechanism based on the LDP notification message or the RSVP-TE PathErr/Resv messages. Based on the error notification, the nodes along the LSP can take possible actions against the possible errors. But for SR, there is no such information communicated among the nodes along the SR Path. The result will be that once the packet is forwarded by the ingress node, they may experience the possible errors which may be prevented by the negotiation in the control plane. From the previous comments, we can see that in the traditional LSP, the LSP setup is negotiated through the signalling between the upstream node and the downstream node. During the negotiation, it is not only to set up the forwarding the entry for the purpose of reachablity, but also includes many aspects (I call them as the operation and maintenence of the LSP. Hope it is appropriate. ) such as the end-to-end connectivity verification, the loop prevention, path MTU, negotiation, path recording, error notification and handling, etc. Though SR always proposes its advantage, in my opinion, these advantages are from the reachability part such as the advantage that the label statck in the ingress node reduces the states in the network. But the requirements of the operational and maintenance for the traditional LSP still exist. Taking into account that the flooding mode of the IGP, it stops the communication between the nodes along the path, the work may become more complex. According to the past experience, the possible ways I could think out are as follows: 1) Depend on the third-party mechanisms. But the problem is that there may involve more mechanisms and there may be no mechanisms. For example, LSP Ping can be adopted to check the end-to-end connectivity or loop for the SR-BE path, but it cannot be used for path MTU negotiation. For the end-to-end path recording, LSP Tracert may have to be introduced. If these requirements and mechanisms are considered, it means SR does not reduce the compexity. Instead it just transfers more complexity to the other possible signallings. 2) Depend on one nodes to implement the possible functions. For example, for SR-TE path, it can depend on the PCE or the ingress node to collect all path info proposed by path recording or even path MTU negotiation. Even so, there is still some drawbacks for some scenarios if only depend on the ingress node. Moreover these methods cannot apply to SR-BE path.If the possible work is done through the ingress node, it will begin to change the essence of SR-BE and become the SR-TE. 3) Leave as it is. That is, these issues are not solved for SR path. In my own opinion, 20 years ago, only solving the reachability issues may be accepted. But today, as the concept of carrier-grade IP network has been widely accepted and these features mentioned has been deployed in the traditional MPLS network, I don't think they can be removed easily. In one word, though some advantage driven from the reachbility of SR is apparent, the complexity introcuded by the synthesized requirements are not reduced. And it may become more complex for SR. Regards, Robin _______________________________________________ spring mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
