Aggregated IP FEC <draft-swallow-mpls-aggregated-FEC-00.txt> [e-mail]

1
Aggregated IP FECltdraft-swallow-mpls-aggregated-F
EC-00.txtgtswallow_at_cisco.com
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

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
Routing Summarization Label Distribution (1)
10.10.0.1
10.10.0.2
10.10.1.1
10.10.2.2

• 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

8
Routing Summarization Label Distribution (2)
10.10.0.1
10.10.0.2
10.10.1.1
10.10.2.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

9
Label OperationsL3-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
10.10.2.2
10.10.0.2
10.10.0.1
10.10.1.1

• 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
Label OperationsPop 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
10.10.2.2
10.10.0.2
10.10.0.1
10.10.1.1
36
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

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