Aggregated IP FEC <draft-swallow-mpls-aggregated-FEC-00.txt> swallow@cisco

1. Aggregated IP FEC<draft-swallow-mpls-aggregated-FEC-00.txt>swallow@cisco.com

2. ABR2 ABR1 PE2 PE1 Area 0 Area 2 Area 1 Aggregated IP FEC • Problem: MPLS requires PE to PE LSPs for PWE3 and VPN traffic • Routes cannot be aggregated • All routers have routes and LDP labels for all PE • draft-ietf-mpls-ldp-interarea-00.txt also deals with this problem

3. Aggregated-IPv4 FEC • New FEC Type • Semantics are the same as an IPv4 FEC except • Indication that the next label is a De-aggregation Label indicating a specific (/32) IP route • The de-aggregation label is to be interpreted in a context particular to this FEC • The de-aggregation labels are determined algorithmically

4. De-aggregation Labels • A de-aggregation label is derived as follows AND the IP address with a 32 bit mask where the bits in the summary route are set to zeros and the low order bits are set to ones Add 16 (to bypass reserved range) • Supports a /13 or longer prefix • Algorithmic derivation ensures that all ABRs advertising an Aggregated IP FEC have the same deaggregation labels

5. Label Distribution • A router which is summarizing IP routes may advertise an Aggregated-IPv4 FEC • The label must be non-null (no PHP) • Aggregated-IPv4 FECs must be distributed in downstream ordered mode

6. ILM for De-aggregation labels • For each aggregated-IPv4 there is a unique Incoming Label map (ILM) • The entries of the ILM must point to a next hop label forwarding entry which is one of: • An IPv4/32 FEC • Another (more specific) aggregated-IPv4 FEC stacked upon a de-aggregation label

7. ABR2 ABR1 PE2 PE1 Area 0 Area 2 Area 1 Routing Summarization & Label Distribution (1) • Within Area 2 labels are distributed for IPv4/32 routes • ABR2 advertises 10.10.2/24 into Area 0 • ABR1 advertises 10.10.2/24 into Area 1 • ABR2 selects a label for 10.10.2/24 and distributes it in LDP as a Aggregated-IPv4 FEC 10.10.0.1 10.10.0.2 10.10.1.1 10.10.2.2

8. ABR2 ABR1 PE2 PE1 Area 0 Area 2 Area 1 Routing Summarization & Label Distribution (2) • LDP propagates the Aggregated-IPv4 FEC throughout areas which have the route 10.10.2/24 • ABR2 builds an ILM to be used in the context of a received label indicating Aggregated-IPv4 FEC 10.10.2/24 • For each /32 route covered by Aggregated-IPv4 FEC 10.10.2/24 that has a label binding, ABR2 algorithmically maps a label entry 10.10.0.1 10.10.0.2 10.10.1.1 10.10.2.2

9. P-Router 1 P-Router 2 ABR1 ABR2 PE1 PE2 Area 0 Area 2 Area 1 11 18 47 Label Operations:L3-VPN Imposition VPN Addr: 192.169.0.22 Next Hop: 10.10.2.2 Label Stk: 47 Aggregated- IPv4 FEC: 10.10.2/24 Label: 51 • Sending to VPN Route 192.169.0.22, PE1 pushes VPN label 47 • Selects Aggregated-IPv4 FEC 10.10.2/24 as longest match & FEC matching BGP-NH • Algorithmically derives De-aggregation label 18 and pushes onto stack • Push LDP label (11) for aggregated-IPv4 FEC received from IGP next hop 10.10.2.2 10.10.0.2 10.10.0.1 10.10.1.1

10. P-Router 2 ABR2 ABR1 PE2 PE1 Area 0 Area 2 Area 1 51 11 18 18 47 47 Label Operations:Pop & Swap at ABR2 VPN Addr: 192.169.0.22 Next Hop: 10.10.2.2 Label Stk: 47 Aggregated- IPv4 FEC: 10.10.2/24 Label: 51 • ABR2 receives packet label stack 51/18/47 • ABR2 pops label 51 and locates the indicated label space • ABR2 looks up label 18 and maps it to a label (36) received for the IPv4 FEC 10.10.2.2 • Label processing from this point is exactly as current L3VPNs 10.10.2.2 10.10.0.2 10.10.0.1 10.10.1.1 36 47 47

11. Draw Backs • Requires processing two labels at ABR • There will be a performance penalty on some platforms • Others will take it in stride • Looses Next-Hop tracking • We’re looking into ways of fixing that • Expect to have something for Vancouver

12. Benefits • Greatly reduces label distribution • LDP distributed host specific labels are only needed within the area of the destination PE • Conserves LFIB space • Note that PEs imposing these labels need not put them into the LFIB • Keeps LDP distributed labels coordinated with the IGP