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