Aggregated IP FEC

<draft-swallow-mpls-aggregated-FEC-00.txt>

swallow@cisco.com
 Aggregated IP FEC

Area 1 Area 0 Area 2

PE1 ABR1 ABR2 PE2

• 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
 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 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
 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
 Routing Summarization & Label
Distribution (1)

Area 1 Area 0 Area 2

10.10.1.1 10.10.0.1 10.10.0.2 10.10.2.2
PE1 ABR1 ABR2 PE2

• 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
 Routing Summarization & Label
Distribution (2)

Area 1 Area 0 Area 2

10.10.1.1 10.10.0.1 10.10.0.2 10.10.2.2
PE1 ABR1 ABR2 PE2

• 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
 Label Operations:
L3-VPN Imposition
Aggregated- VPN Addr: 192.169.0.22
11 Next Hop: 10.10.2.2
IPv4 FEC: 10.10.2/24
18 Label: 51 Label Stk: 47

47

10.10.0.2 10.10.2.2
Area 1 Area 0 Area 2
10.10.1.1 10.10.0.1
PE1 ABR1 ABR2 PE2

P-Router 1 P-Router 2

• 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
 Label Operations:
Pop & Swap at ABR2
Aggregated- VPN Addr: 192.169.0.22
IPv4 FEC: 10.10.2/24 Next Hop: 10.10.2.2
Label: 51 Label Stk: 47

10.10.0.2 10.10.2.2
Area 1 Area 0 Area 2
10.10.1.1 10.10.0.1
PE1 ABR1 ABR2 PE2

11
51 36 P-Router 2
18
47 47
18
47
47

• 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
 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