mpls-4 only] [compatibility mode]

8/9/2019 Mpls-4 Only] [Compatibility Mode]

1/12


2/12

Area 0Area 1 Area 2

Aggregated IP FEC

PE2ABR2ABR1PE1

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/12

Aggregated-IPv4 FEC

New FEC Type Semantics are the same as an IPv4 FEC except

Indication that the next label is a De-aggregation Labelindicatin a s ecific /32 IP route

The de-aggregation label is to be interpreted in acontext particular to this FEC

The de-aggregation labels are determined

algorithmically


4/12

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

Add 16 (to bypass reserved range)

Supports a /13 or longer prefix

Algorithmic derivation ensures that all ABRsadvertising an Aggregated IP FEC have thesame deaggregation labels


5/12

Label Distribution

A router which is summarizing IP routesmay advertise an Aggregated-IPv4 FEC

The label must be non-null no PHP

Aggregated-IPv4 FECs must bedistributed in downstream ordered mode


6/12

ILM for De-aggregation labels

For each aggregated-IPv4 there is aunique Incoming Label map (ILM)

The entries of the ILM must point to a next

op a e orwar ng en ry w c s one o : An IPv4/32 FEC

Another (more specific) aggregated-IPv4 FEC

stacked upon a de-aggregation label


7/12

Area 0Area 1 Area 2

Routing Summarization & Label

Distribution (1)

PE2ABR2ABR1PE1 10.10.2.210.10.0.210.10.1.1 10.10.0.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 aAggregated-IPv4 FEC


8/12

Area 0Area 1 Area 2

Routing Summarization & Label

Distribution (2)

PE2ABR2ABR1PE1 10.10.2.210.10.0.210.10.1.1 10.10.0.1

LDP propagates the Aggregated-IPv4 FEC throughout areas which havethe route 10.10.2/24

ABR2 builds an ILM to be used in the context of a received labelindicating Aggregated-IPv4 FEC 10.10.2/24

For each /32 route covered by Aggregated-IPv4 FEC 10.10.2/24 that hasa label binding, ABR2 algorithmically maps a label entry


9/12

Area 0Area 1 Area 2

Label Operations:

L3-VPN Imposition

10.10.2.210.10.0.2

VPN Addr: 192.169.0.22Next Hop: 10.10.2.2Label Stk: 47

11

18

47

Aggregated-IPv4 FEC: 10.10.2/24Label: 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 matchingBGP-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.1.1 10.10.0.1

P-Router 2P-Router 1


10/12

Label Operations:

Pop & Swap at ABR2

Area 0Area 1 Area 2

10.10.2.210.10.0.2

VPN Addr: 192.169.0.22Next Hop: 10.10.2.2Label Stk: 47

Aggregated-IPv4 FEC: 10.10.2/24Label: 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 IPv4FEC 10.10.2.2

Label processing from this point is exactly as current L3VPNs

PE2ABR2ABR1PE1

10.10.1.1 10.10.0.1

P-Router 211

18

47

47

36

47

51

18

47


11/12

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

Were looking into ways of fixing that

Expect to have something for Vancouver


12/12

Benefits

Greatly reduces label distribution LDP distributed host specific labels are only

needed within the area of the destination PE

onserves space Note that PEs imposing these labels need not

put them into the LFIB

Keeps LDP distributed labels coordinatedwith the IGP

mpls-4 only] [compatibility mode]

Documents