Subject: [mpls] New Comments on Segment Routing(8): Loop Prevention and Error Handling for SR

From: Lizhenbin <[email-masked]>
Date: Wed, 28 Jan 2015 11:30:35 +0000

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 28 Jan 2015 13:54:47 +0100

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-masked]> wrote:

> PCE or the ingress node to collect all path info proposed by path
> recording or even path MTU negotiation. Even so,
>
> cannot apply to SR-BE path.If the possible work is done through the
> ingress node, it will begin to change the
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>
>

---

From: Lizhenbin <[email-masked]>
Date: Thu, 29 Jan 2015 07:47:17 +0000

Hi Robert,

Pleaser refer to my inline comments.

Regards,

Robin

________________________________
发件人: [email-masked] [[email-masked]] 代表 Robert Raszuk [[email-masked]]
发送时间: 2015年1月28日 20:54
收件人: Lizhenbin
抄送: [email-masked]; [email-masked]; [email-masked]
主题: 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-masked]<mailto:[email-masked]>> wrote:

as follows:

Regards,

Robin

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring