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/[email protected]/message/3SM47NHJPMAGHWJEGS4NQYM2VMNRQ2NO/
