Expert Advice: What are the points to be considered when implementing LDP tunnelling over RSVP?
When you set up LDP tunneling between equipment from different vendors, you need to:
If one area is NSSA, then the loopback (/32 prefix) is not redistributed from backbone to the NSSA area, which means you will have only the default route. You need to test whether the default route visibility (instead of /32) is sufficient to establish an inter-area RSVP TE tunnel and targeted LDP session.
Based on the original LDP specification (RFC 5036), for LDP to process FEC, that is, to generate a label, an exact match must be present in the routing table. If a loopback route in the backbone area is 172.16.0.1/32 and is in the NSSA area, only summary route 172.16.0.0/24 is visible, then the labels for 172.16.0.1/32 are not generated in the NSSA.
RFC 5283 removes that restriction, and is enough to have some summary (or default) route -- an exact match is not needed. RFC 5283 is currently not implemented in Junos, but it will be available in a future release. Until Junos OS supports RFC 5283, you need to use the inter-area RSVP tunnel up. Note that no Forward Equivalence Class (FEC) labels are exchanged unless you redistribute the /32 loopbacks between areas.
The inter-domain configuration statement allows you to establish an RSVP tunnel to a destination outside local area (destination not included in OSPF LSA Type 1, but in other LSA types).
For more information, see Tunneling LDP LSPs Inside RSVP-TE LSPs.
Thank you! I've replaced "Forward Error Correction" with "Forward Equivalence Class."
Great expert advice.
Just as a side note, I'm sure it meant Forward Equivalence Class (FEC) labels and not Forward Error Correction, as it is something different. Just thought on pointing it out as it might confuse someone.