Subject: [mpls] New Comments on Segment Routing(9): Challenge of Interoperability of SR with LDP

From: Lizhenbin <[email-masked]>
Date: Thu, 29 Jan 2015 10:59:54 +0000

Hi all authors of segment routing,

This is the ninth comments to discuss the possible issues proposed by the interoperability of SR with LDP.

In fact, I have not read the draft draft-filsfils-spring-segment-routing-ldp-interop-02 yet. According to

the past experience, I think the possilbe choice is no other than hierarchy or stitching.

I propose the first case as the following scenario,

          SR          LDP          LDP          SR
  S11-----------S12----------S13---------S14---------S15
   |             |            |           |           |
   |             |            |           |           |
   |             |            |           |           |
  S21-----------S22----------S23---------S24---------S25

Assume all other nodes support SR and only S12/S13/S14 support LDP. If the LSP stitching is adopted, there will

be following process:
-- In S12, the egress SR-BE path will stitch the ingress LDP LSP, If the link between the S12 and S13 fails

firstly, then restored, the IGP-LDP sync is also necessary.
-- In S14, the egress LDP LSP will stitch the ingress SR-BE path.

Morevoer, if the scenario is changes to the opposite way, that is all other nodes support LDP and only S12/S13/S14

support SR, it has to introduce the proxy egress for SR-BE path which has explained in the previous comments that

it will be difficult to be supported by the SR.

From the case, could I say that the SR-LDP interoperability issue is more difficult that the IGP-LDP sync

which could be removed by SR as claimed?

I propose the second case as the following scenario,

          LDP          LDP
  S11-----------S12----------S13
   |                          |
 SR|                          |SR
   |                          |
  S21-----------S22----------S23
        SR             SR

Assume S11/S12/S13 support LDP and S11/S21/S22/S23/S13 support SR. If the primary path to S13 is S11->S12->S13

is based on LDP LSP. In order to achieve the 100% network coverage, LDP remote peer can be set up between S11

and S13 to advertise label mapping directly from the S13 to S11. The the backup path can be: the backup LDP

label goes through the SR path S11->S21->S22->S23->S13. This means that the Remote LFA must co-exist with TI-LFA.

Could I say that the combined FRR solutions is more complex than one of these FRR solutions?

From the pervious comments, we can see that some of the existing LDP scenarios cannot be supported by SR-BE path.

This means if SR is adopted, it has to co-exist with LDP in these scenarios. For the legacy network using LDP,

if SR is adopted to replace the LDP, it is also inevitable that the SR has to co-exist with LDP.

If these scenarios happens, there will be a mess of solutions in the network. In fact, this is not a new one.

Almost ten years ago, when we implemented the LDP, we assumed that there can be one network in which some nodes

run LDP DoD, others run LDP DU, some nodes run LDP Ordered, others run LDP Independent, some nodes run LDP liberal,

others run LDP conservative. Finally we found the issues could not converge at all. At last we had to give up

and provided the specification for any network there is only one label advertisement mode, only one label

distribution mode, only one label retention mode. Until today DU + Ordered + Liberal becomes almost the most

popular choice.

But for SR, it works in the totally different way from the LDP in many aspects. If SR and LDP co-exist in one

network and the behaviors could not be unifyed through the unifying configuration, the mess of the solutions

is inevitable. Taking into account SR's interworking with LDP's two LSP advertisement mode, two LSP distribution

mode, two label retension mode, two types of LDP peer as well as new IGP-LDP stiching/hierarchy/sync and the

intworking LFA/R-LFA FRR for LDP with the TI-LFA for SR, I don't think this is an easy work to clarify all

possible details in one draft and much of the details maybe implementation specific and potential risk for the
interoperability. Moreover, based on the analysis in the previous comments, there is some requirements of LDP

which cannot be supported by SR-BE path yet now. If these issues are not solved, the introducing of SR in the

LDP network will affect the normal process of LDP.

According to the above analyisis, my recommendation for the network transition is that if there is the scenario

in which SR-BE path is truly applicable, it is better to replace the existing LDP all at once to avoid the possible

interoperability issue.

Regarding the interoperability of SR-TE path with RSVP-TE, the general problem is that both SR-TE path and RSVP-TE

cannot support proxy egress now and the stitching would not work at all. The only way is just to replace the whole

RSVP-TE LSP with the SR-TE path if the SR-TE path is truly applicable.

Regards,

Robin