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

swallow@cisco.com

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