Re: LDP interop with RSVP and SR

[Andrey Kostin via NANOG <nanog () lists nanog org>]

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.nokia.MPLS_Guide%2Fsr_shortest_pat-ai9emdyo5y.html
https://infocenter.nokia.com/public/7750SR217R1A/index.jsp?topic=%2Fcom.nokia.MPLS_Guide_21.7.R1%2Fforwarding_adja-d12e13319.html
https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/concept/segment-routing-rsvp-fa.html
https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/example/isis-advertise-lsp.html

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.

_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/3SM47NHJPMAGHWJEGS4NQYM2VMNRQ2NO/