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