Area 0Area 1 Area 2
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
PE2ABR2ABR1PE1
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
De-aggregation Labels
• A de-aggregation label is derived as followsAND 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
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
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
Area 0Area 1 Area 2
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
PE2ABR2ABR1PE1 10.10.2.210.10.0.210.10.1.1 10.10.0.1
Area 0Area 1 Area 2
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
PE2ABR2ABR1PE1 10.10.2.210.10.0.210.10.1.1 10.10.0.1
Area 0Area 1 Area 2
Label Operations:L3-VPN Imposition
• 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
PE2ABR2ABR1PE1
10.10.2.210.10.0.2
10.10.1.1 10.10.0.1
VPN Addr: 192.169.0.22Next Hop: 10.10.2.2Label Stk: 47
P-Router 2
11
18
47
Aggregated-IPv4 FEC: 10.10.2/24Label: 51
P-Router 1
Label Operations:Pop & Swap at ABR2
• 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
Area 0Area 1 Area 2
PE2ABR2ABR1PE1
10.10.2.210.10.0.2
10.10.1.1 10.10.0.1
VPN Addr: 192.169.0.22Next Hop: 10.10.2.2Label Stk: 47
P-Router 211
18
4747
36
47
Aggregated-IPv4 FEC: 10.10.2/24Label: 51
51
18
47
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
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