1. LDP extension for Inter-Area LSP draft-decraene-mpls-ldp-interarea-04 Bruno DecraeneFrance Telecom / Orange Jean-Louis Le RouxFrance Telecom / Orange Ina MineiJuniper Networks IETF 68 – 22/03/2007

2. Summary of problem statement & solution Changes since lastest presentation Next steps 1 2 3 Outline

3. Problem Statement MPLS VPN networks are expanding with the success of L2 & L3 VPN services and MPLS Backbones are growing In density: addition of PEs to connect new customers In footprint: MPLS is spreading in aggregation / metro networks  IGP areas are being introduced  inter area LSPs needed LDP does not set up inter area LSPs if the IGP performs IP aggregation between areas RFC 3036 mandates that the FEC should exactly match a RIB entry The draft proposes to accept the FEC if a longest match is found in the RIB.

4. Draft history Version 03 was presented in San Diego (IETF 67). Current version 04 addresses comments received in San Diego and on the mailing list: Some rephrasing / re-wording Thanks to Alfred Hoenes Clarification on “longest match” FEC must either exactly match the RIB entry (current situation) Or FEC must be a subset of a RIB entry Eg FEC 192.0.0.0/30 does NOT match RIB entry 192.0.0.0/32 Positioning with regards to inter-area RSVP-TE

5. Interaction with the RIB As per RFC 3036, LDP has interactions with the RIB and LSR needs to be aware of the following RIB events: prefix UP (a new IP prefix appears in the RIB); prefix DOWN (an existing prefix disappears); Next-Hop change (an existing prefix have a new next hop). With the longest match procedure, multiple FECs may be concerned by a single RIB prefix change: prefix UP  LSR MUST check all FEC elements which are a subset of this RIB prefix For each FEC, check if this prefix is a better match. May result in changing the LSR used as next hop and hence the NHLFE. E.g. the FEC elements 192.0.2.1/32 and 192.0.2.2/32 use the IP RIB entry 192.0/16. A new more specific IP RIB entry 192.0.2/24 appears. Prefix DOWN  LSR MUST check all FEC elements using this RIB prefix. For each FEC, search for a new best match in the RIB. If no match found, the LSR MUST remove the FEC binding and send a label withdraw message. Next-Hop change  LSR MUST change the NHLFE of all FEC elements using this RIB prefix.

6. Conclusion Straightforward specification extension Limited impact on LDP specification Solve an operational problem Existing deployments of multi-areas MPLS networks Stable specification Implementation underway Would like to request for adoption as WG document.

7. Thank You