Hi Saku, IIRC, this kind of interop between RSVP and LDP used to be done via LDP tunneling, although it requires LDP to be running on all routers and not far from full-mesh tLDP approach. Your idea looks neat and seems has already been implemented to certain extend for SR-ISIS to RSVP-TE interaction. Quick googling gave me some links: https://infocenter.nokia.com/public/7750SR222R1A/index.jsp?topic=%2Fcom.noki... https://infocenter.nokia.com/public/7750SR217R1A/index.jsp?topic=%2Fcom.noki... https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/conc... https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/exam... From Juniper's example, an LSP has to be explicitly configured in isis to be used as forwarding adjacency. It definitely makes it less convenient than if all tunnels could be considered for forwarding adjacency by default, although in a network with many tunnels it may create very complex IGP topologies. As for LDP, I think all it's functions have been already replicated in SR, so new feature development for LDP probably isn't getting much of vendors' attention. Kind regards, Andrey Saku Ytti via NANOG писал(а) 2025-06-07 04:26:
I just want to double check that I'm not confused.
Since day1 we have had excellent LDP/SR interop, that is, for your SR network, connecting LDP-only nodes or islands doesn't require soiling your entire SR network with LDP state.
Do we really not have a similar solution for RSVP?
Let's imagine an RSVP-only network, where we add a single LDP-only speaker.
Instead of tLDP from every RSVPOnly to RSVPBorder and then LDP between RSVPBorder and LDPOnly, why can't RSVPBorder handle the interop?
RSVP -> LDP - Every RSVPOnly would have 1 LSP to RSVPBorder and 1 LSP for each LDP nodes RSVPBorder meets, via RESV TunnelId or such discriminator you can of course have arbitrary amount of LSPs between two endpoints - RSVPBorder will advertise different labels for each of these LSPs, like it would for split LSPs or QoS based LSPs - the LSP terminating on RSVPBorder is popped, the LSPs intended for LDP speaker are swapped from RSVP label to the LDP label
LDP -> RSVP - RSVPBorder synthesises for each RSVPOnly/32 LDP route to LDPOnly - As LDPOnly sends LDP label to RSVPBorder, RSVPBorder swaps it to the RSVP label
Now in practice when this requirement exists, everyone is running full mesh tLDP, because that's easy to provision. Ending up having thousands of useless LDP sessions with state and fragility that comes with it.