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