multipoint ldp (mldp) -...

Multipoint LDP (mLDP) BRKIPM-3111

IJsbrand Wijnands

© 2014 Cisco and/or its affiliates. All rights reserved. BRKIPM-3111 Cisco Public

Agenda

Introduction

FEC encoding

Capability negotiation

P2MP & MP2MP LSPs

Root Node Redundancy

Fast ReRoute using Link Protection

Make Before Break

Recursive FEC

MoFRR

In-band signalling

Configuration and show commands

3

Introduction


Introduction

Customers running MPLS in their network want to run Multicast natively over MPLS

MPLS forwarding plane is shared between unicast and multicast

– By that unicast MPLS features are applied to multicast

Separation of data plane and control plane has advantages

Why mLDP?

5


Introduction (cont)

Simplification compared to PIM

– No shared tree / source tree switchover

– No (S,G,R) prune’s

– No DR election

– No PIM registers

– No Asserts

– No Periodic messaging

– No Auto-RP/BSR

Why mLDP?

6


Introduction

mLDP is an extension to the IETF LDP RFC 3036.

Procedures are documented in IETF RFC 6388

Joined effort by multiple vendors and customers.

mLDP reuses LDP protocol packets and neighbor adjacencies.

mLDP is a client of the LDP infrastructure.

mLDP allows to create P2MP and MP2MP LSP, we refer to these as Multipoint LSPs (MP LSPs).

Extensions to LDP

7


Introduction

P2MP - Point to Multi-point

– Like a PIM SSM tree

MP2MP – Multi-Point to Multi-Point

– Like a PIM Bidir tree

MP LSP – Multi-Point LSP, either P2MP or MP2MP

Label Mapping

– Like a PIM Join

Label Withdraw

– Like a PIM Prune

Label Release, Notification

– Does not exist in PIM

Terminology

8

FEC Encoding


FEC Encoding

FEC stands for “Forwarding Equivalence Class”

FEC is a unique identifier of an forwarding entry;

– For unicast this is a Prefix

– For PIM it is a (S,G) or (*,G)

The FEC in mLDP is combination of 3 tuples;

– Tree Type

– Root Address

– Variable Length Opaque encoding.

The Opaque field consists of TLV’s

– Each service/application can have it own TLV type.

– Very flexible approach to make the FEC unique.

The mLDP FEC Element

10


FEC Encoding

FEC elements are carried within a LDP FEC TLV

mLDP defines three FEC elements for MP LSPs

–P2MP FEC element

–MP2MP downstream FEC element

–MP2MP upstream FEC element

LDP protocol consists of messages which carry TLVs

LDP message encoding

Label Mapping

Message

FEC TLV

Label TLV

FEC Element

Op

aqu

e

Other TLV R

oo

t

Tree Type

11


FEC Encoding

12

The FEC Element encoding

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Address Family | Address Length|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~ Root Node Address ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Opaque Length | Opaque Value ... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +

~ ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Field Description

Type P2MP, MP2MP Up, MP2MP Down

Address Family Address Family Numbers by IANA (IPv4 = 1, IPv6 = 2)

Address Length Length of the address

Root Node Address IP address of MP LSP root (within MPLS core)

Opaque Length Length of the Opaque encoding that follows

Opaque field TLV encoded


FEC Encoding

Root address is used to route the LSP through the network

– Very much like how PIM route’s the tree using Source or RP.

Each LSR in the path resolves next-hop of root address

– Label mapping message then sent to that next-hop

Resulting in a dynamically created MP LSP

– No pre-computed, traffic engineered path

The mLDP Root address

13


FEC Encoding

Opaque field is a variable length value encoded as TLV

mLDP does not care what is encoded in the Opaque value

– Only the applications using the mLDP LSP care.

Value encoded is application specific

– It can represent the (S,G) stream.

– Or can be an LSP identifier (Default/Data MDTs in mVPN)

Opaque Value

14


FEC Encoding The mLDP Opaque TLV encoding

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type < 255 | Length | Value ... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |

~ ~

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type name Type

#

Length Value

Generic LSP ID 1 4 bytes { 4 byte ID }

MVPN MDT 2 11 bytes { VPN-ID, MDT # }

IPv4 In-band signalling 3 8 bytes { Source, Group }

IPv6 In-band signalling 4 32 bytes { Source, Group }

Recursive FEC 7 … { FEC element }

Recursive VPN FEC 8 8 + … { RD, FEC element }

15


FEC Encoding

16

The mLDP Extended Opaque TLV encoding

Defined in case we exceed the available 255 types

Currently not used

First come first service allocation, no IETF draft needed.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type = 255 | Extended Type | Length (high) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

| Length (low) | Value |

+-+-+-+-+-+-+-+-+ |

~ ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



New FEC Elements added to LDP for mLDP

Don’t know if your LDP neighbour understand the new FEC type

Want to prevent certain types to be used in the network

This is inconvenient while troubleshooting/deploying a feature

For that reason Capability Negotiation has been defined for LDP

Why do we need it

18



Allows advertising of capability TLVs

At session initialisation time within the Initialisation Message

Dynamically during the session within a Capabilities Message

Several mLDP capability TLVs are defined – P2MP (Point to Multipoint) – TLV 0x0508

– MP2MP (Multipoint to Multipoint) – TLV 0x0509

– MBB (Make Before Break) – TLV 0x050A

Also use for other purposes (not only mLDP)

– Typed Wildcard FEC

– Upstream Label Assignment

RFC 5561

19

P2MP and MP2MP LSP building


P2MP & MP2MP LSPs

In order to build a tree, the upstream LDP neighbour needs to be determined based on the Root address.

This is similar to the RPF check with PIM.

A unicast route lookup is done on the Root address until a directly connected next-hop is found.

However, it is very likely there is no LDP neighbour with the same address as the next-hop.

That is because the LDP session is run between the loopback addresses.

– Note, this is different with PIM.

LDP announces all of its interfaces addresses to its neighbours.

We use that address database to find the LDP neighbour.

Determining the upstream LDP neighbour

21


P2MP & MP2MP LSPs

22

Upstream LDP neighbour, example for root 10.0.0.1

RP/0/3/CPU0:GSR2#sh mpls ldp neighbor

Peer LDP Identifier: 10.0.0.4:0

TCP connection: 10.0.0.4:17191 - 10.0.0.2:646

Graceful Restart: No

Session Holdtime: 180 sec

State: Oper; Msgs sent/rcvd: 10114/10106; Downstream-Unsolicited

Up time: 6d02h

LDP Discovery Sources:

GigabitEthernet0/5/0/1

Addresses bound to this peer:

10.0.4.1 10.0.7.1 10.0.9.2 10.0.14.1

RP/0/3/CPU0:GSR2#sh route 10.0.0.1

Routing entry for 10.0.0.1/32

Known via "ospf 0", distance 110, metric 3, type intra area

Installed Feb 6 06:43:57.931 for 1w1d

Routing Descriptor Blocks

10.0.4.1, from 10.0.0.1, via GigabitEthernet0/5/0/1

Route metric is 3

No advertising protos.

LDP session 10.0.0.4 10.0.0.2

10.0.4.1

Determine upstream

LDP peer for 10.0.0.1

RP/0/3/CPU0:GSR2#sh mpls mldp neighbors addresses 10.0.4.1

Wed Feb 15 05:51:18.786 UTC

LDP remote address : 10.0.4.1

LDP remote ID(s) : 10.0.0.4:0

10.0.0.1


P2MP & MP2MP LSPs

A Label Mapping is received over the LDP session.

The source of the Label Mapping is the LDP-ID of the sender.

In order to program forwarding, the interface and directly connected next-hop need to be found.

This interface/next-hop does not come with the Label Mapping.

Label Mapping only carries the Label.

We use the LDP Discovery messages to know which interfaces are connected to the LDP neighbour.

There is no equivalent to this in PIM

Determining the downstream interface

23


P2MP & MP2MP LSPs

24

Downstream interface, example for LDP neighbour 10.0.0.2

RP/0/1/CPU0:GSR3#sh mpls ldp neighbor 10.0.0.2


TCP connection: 10.0.0.2:646 - 10.0.0.4:17191

Graceful Restart: No

Session Holdtime: 180 sec

State: Oper; Msgs sent/rcvd: 11594/11605; Downstream-Unsolicited

Up time: 1w0d

LDP Discovery Sources:

GigabitEthernet0/2/1/2

Addresses bound to this peer:

10.0.4.2 10.0.14.2 10.10.10.1

LDP session 10.0.0.4 10.0.0.2

10.0.4.2

Determine downstream

interface for LDP peer 10.0.0.2

10.0.0.1

RP/0/1/CPU0:GSR3#sh mpls ldp discovery 10.0.0.2:0 det

Local LDP Identifier: 10.0.0.4:0

Discovery Sources:

Interfaces:

GigabitEthernet0/2/1/2 (0x3000800) : xmit/recv

Source address: 10.0.4.1; Transport address: 10.0.0.4

Hello interval: 5 sec (due in 1.7 sec)

Quick-start: Enabled

LDP Id: 10.0.0.2:0

Source address: 10.0.4.2; Transport address: 10.0.0.2

Hold time: 15 sec (local:15 sec, peer:15 sec)

(expiring in 12.9 sec)


P2MP & MP2MP LSPs

There can be multiple upstream LDP neighbours to reach the root.

There can be multiple downstream interfaces to reach a neighbour.

We support per LSP load balancing across the candidates.

Upstream and Downstream ECMP

25


P2MP & MP2MP LSPs

P2MP LSP is rooted at Ingress LSR

P2MP LSP is unidirectional.

Egress LSRs initiate the tree creation using the unicast reachability to the root address.

Receiver driven, hop-by-hop to root

P2MP Overview

26


P2MP and MP2MP LSPs

27

P2MP setup North

(10.0.0.1)

West

Label Map

19

P2MP FEC, 10.0.0.1, Opaque

48

Sender

Central

Label Map

48


Label Map

23


19

P2MP FEC 10.0.0.1, Opaque

23

48

Receiver Receiver East

Label Mapping

FEC

Label


P2MP & MP2MP LSPs

28

P2MP packet flow

Do

wn

stream traffic

(S)

22

P2MP state 10.0.0.1, Opaque

20

21

North

(10.0.0.1)

West Receiver Receiver East 21

G

S

Data

Downstream path label


21

G

S

Data

P2MP & MP2MP LSPs

29

show mpls mldp database (S)

22

P2MP state 10.0.0.1, Opaque

20

21

North

(10.0.0.1)

West Receiver Receiver East

RP/0/1/CPU0:GSR3#sh mpls mldp database

Tue Feb 28 06:10:35.101 UTC

mLDP database

LSM-ID: 0x00006 Type: P2MP Uptime: 2w5d

FEC Root : 10.0.0.1

Opaque decoded : [vpnv4 2:2 192.169.0.1 232.2.2.2]

Upstream neighbor(s) :

10.0.0.1:0 [Active] Uptime: 2w5d

Next Hop : 10.0.3.1

Interface : GigabitEthernet0/2/1/1

Local Label (D) : 21

Downstream client(s):

LDP 10.0.0.2:0 Uptime: 2w5d

Next Hop : 10.0.4.2


Remote label (D) : 20


Next Hop : 10.0.5.2



Do

wn

stream traffic


P2MP & MP2MP LSPs

MP2MP LSP allows multiple leaf LSRs to inject packets into tree

MP2MP LSP is constructed using a downstream and an upstream path

Downstream and upstream paths are merged such that we create a MP2MP LSP.

A MP2MP LSP is MP2MP at control plane, but translates into a P2MP replication in the data plane.

MP2MP Overview

• Much like a normal P2MP LSP

Upstream Path • Upstream path is like a P2P LSP upstream • But inherits labels from the downstream path.

Downstream Path

30


P2MP & MP2MP LSPs

31

MP2MP setup

Label Map

22

MP2MP down, 10.0.0.1, Opaque

21

(S)

P-Central

Label Map

21

MP2MP down, 10.0.0.1, Opaque

Label Map

20

MP2MP down, PE-North, Opaque

30

Label Map

30

mP2MP up, 10.0.0.1, Opaque

Label Map

31

MP2MP up, 10.0.0.1, Opaque

Label Map

32

MP2MP up, 10.0.0.1, Opaque

Up

stream traffic

22

MP2MP state 10.0.0.1, Opaque

32 20 31

21 30

North

(10.0.0.1)


Label Mapping

FEC

Downstream path

Label

Upstream path Label

Do

wn

stream traffic


P2MP & MP2MP LSPs

32

MP2MP packet flow (S)

22


32 20 31

21 30

North

(10.0.0.1)


21 G

S D

ata

30 G

S D

ata

Downstream path

Label

Upstream path Label

Up

stream traffic

Do

wn

stream traffic


Downstream path

Label

Upstream path Label

P2MP & MP2MP LSPs

33

show mpls mldp database

Do

wn

stream traffic

(S) U

pstream

traffic 22


32 20 31

21 30

North

(10.0.0.1)


RP/0/1/CPU0:GSR3#sh mpls mldp database

LSM-ID: 0x00001 Type: MP2MP Uptime: 3w1d

FEC Root : 10.0.0.1

Opaque decoded : [mdt 1:1 0]


10.0.0.1:0 [Active] Uptime: 2w5d

Next Hop : 10.0.3.1


Local Label (D) : 21 Remote Label (U): 30



Next Hop : 10.0.4.2


Remote label (D) : 20 Local label (U) : 31


Next Hop : 10.0.5.2


Remote label (D) : 22 Local label (U) : 32


P2MP & MP2MP LSPs

34

MPLS forwarding table

For each direction (North, East and West) a P2MP Label replication entry is programmed into MPLS forwarding table.

The number of label replications depends on the number of LDP neighbours participating in the MP2MP LSP.

P3#sh mpls forwarding-table

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

21 20 [mdt 1:1 0] 11518920 East point2point

22 [mdt 1:1 0] 11518920 West point2point

32 30 [mdt 1:1 0] 11518920 North point2point

20 [mdt 1:1 0] 11518920 East point2point

31 30 [mdt 1:1 0] 11518920 North point2point

22 [mdt 1:1 0] 11518920 West point2point


P2MP & MP2MP LSPs

A MP2MP LSP only creates 1 state in control plane.

– This is independent of the number of senders/receivers

A full mesh of P2MP creates control plane state for each sender/receivers.

A MP2MP LSP uses less labels for creating a MP2MP service compared to a full mesh of P2MP LSPs.

MP2MP benefits

35


P2MP & MP2MP LSPs Full mesh Label and State comparison

PE’s Core

5 PE’s Local

Labels

State

MP2MP 1 1

xP2MP 4 5

Local

Labels

State

MP2MP 5 1

xP2MP 5 5

PE’s Core

100 PE’s Local

Labels

State

MP2MP 1 1

xP2MP 99 99

Local

Labels

State

MP2MP 100 1

xP2MP 100 99

36



The root node is a single point of failure

Only one root node is active in an MP LSP

In case the root is statically configured there is a need for redundancy.

If the root is dynamically learned via BGP there is no need for redundancy procedures.

Requirements are:

– Redundancy mechanism in the event of a root failure

– Fast convergence in selecting a new root

Why do we need it

38



39

Solution 1: Anycast root address

Root inject address 10.1.1.1 with different mask

Longest match is preferred, in this example Root 2

When longest match disappears, use next best.

Root 2

Leaf B

CE

CE

Receiver

CE

Root 1

Source

Source

Leaf A

Leaf C

Root 2 injects 10.1.1.1/32

Root 1 injects 10.1.1.1/31



After the preferred root fails, the LSP is rerouted to the next best root based on the mask length.

All MP2MP LSP’s will prefer the same root node.

There is a single MP2MP LSP at any given time, so no hot standby path.

No load balancing over the anycast root’s.

This type of redundancy is a configuration trick! Also used for PIM.

Solution 1: Anycast root address

40



Create two or more Hot Standby MP2MP LSPs root nodes

Each leaf is configured with the same set of root nodes.

Each leaf joins ALL the configured root nodes.

Each leaf ACCEPTS from ALL roots

Each leaf is ONLY allowed send to ONE selected root.

Solution 2: Hot standby

41



42


Leaf A select Root 1, leaf C selects root 2 as the preferred node.

Leaf B gets the packet from A and C.

Root 2 Leaf B

CE

CE

CE

Root 1

Source Leaf A

Leaf C Source

Receiver



43

Solution 2: Hot standby Root selection is based on IGP reachability of the Leaf.

Root 2 Leaf B

CE

CE

CE

Root 1

Source Leaf A

Leaf C Source

Receiver

Unicast routing update



Switch to new root as fast as IGP convergence

Root selection is a local leaf policy

– Can be based on IGP distance, load, etc…

– Roots can share the tree load from leafs

A separate MP2MP LSP is created for each root

– Multi-path load balancing is supported

– In both the upstream and downstream directions


44



Two types of redundancy

– Anycast root node redundancy

– Hot standby redundancy

Additional state vs. failover time

Both are implemented

Needed only when root node is statically configured

Switchover is in the order of seconds (depending on IGP)

Summary

45

Fast ReRoute


mLDP Fast ReRoute

mLDP shares the downstream assigned label space that unicast is using.

For the MPLS forwarding plane there is in essence no difference between multicast packets or unicast packets.

Since the forwarding plane is shared with unicast, certain unicast feature are inherited for multicast, like FRR.

The link can be protected by a TE P2P LSP or a LDP LFA P2P LSP.

Link Protection

47


mLDP Fast ReRoute

48

Link Protection

1. There is a unicast backup P2P Tunnel that protects Link A.

2. mLDP LSP is build from D, B, A towards the root.

3. Router A installs a downstream forwarding replication over link A to router B.

Link A A

C

B mLDP

D

L16 L17 Root

L18

18 17 16

TE/LFA backup Tunnel For link A

L20


mLDP FastReRoute

49

Link Protection

Link A A

C

B


mLDP

D

1. Link A breaks

2. Traffic over Link A is rerouted over the backup tunnel by imposing the Tunnel label 20.

3. Router C does PhP and strips the outer label 20

4. Router B receives the mLDP packets with label 17 and forwards as normal to router D.

Root L16 L17 L18

18 17 16

PHP

L20


mLDP FastReRoute

50

Link Protection

Link A

A

C

B


mLDP

D

1. mLDP is notified that the root is reachable via Router C and will converge.

2. A new mLDP path is build to router A via C.

3. Router A will forward packets natively using mLDP LSP to B (L22).

4. Temporarily router B will receive packets over the backup P2P tunnel and natively, due to the RPF check on the label only the TE received packets are forwarded

5. Router B uses a make-before-break trigger to switch from the backup tunnel to new native mLDP LSP, label 17 to 21.

6. Router B prunes off the backup tunnel with a label withdraw to router A

Root L16

L17

L18

18 16

PHP

L20 L21 L22


mLDP Fast ReRoute

There are 2 make before break triggers

Additional signaling is added in mLDP to notify the downstream router the LSP is completed.

– As what is documented in the mLDP RFC.

Apply a configurable delay before switching to the new path.

A combination of both is possible.

Link Protection

51


mLDP Fast ReRoute

MP2MP LSP’s are translated into a set of P2MP replications in forwarding.

For FRR, there is no special handling needed for MP2MP because forwarding is based on P2MP.

MP2MP is supported for both TE tunnel and LFA backup tunnels.

MP2MP

52

Make Before Break


Make Before Break

With Make Before Break (MBB) we setup a new tree before we tear down the old tree

This makes sense when the old tree is still forwarding packets

This is typically true in combination with FRR

IGP based convergence based in link-up events or metric changes

When the old tree is broken, MBB does not help!

MBB and FRR go hand-in-hand

MLDP MBB uses Query and Ack signalling to determine the new tree is ready to forward packets.

Introduction

54


Make Before Break

55

MBB Request and Ack

1. Initial tree is from C to B to A

2. Link E - C comes up and provides a better path to reach the root via A

3. C re-converges to E sending a Label Map with MBB Request

4. E has no state yet, forwards the MBB Request to A

5. A has ‘active’ forwarding state, sends a notification with MBB Ack down the tree, hop-by-hop to C. Packets are also forwarded.

A

B

C mLDP

D

Root

L16 L18

18 16

E

Label Map

Label Map with

MBB Request

Notification with

MBB Ack


Make Before Break

56

Switch to new path

1. As soon as C received the MBB Ack

• start accepting from E (Label 23)

• start dropping from B (Label 21)

2. Break the old LSP (withdraw)

A

B

C mLDP

D

Root

E

Label Withdraw

Notification with

MBB Ack 18 16


Make Before Break

57

FRR

A

B

C

1. Recall that with FRR we use the MBB trigger on C to switch from TE tunnel to a new native path, ie. start accepting from L21, dropping from L17

2. C is the tail-end of a Tunnel, so don’t see any tunnel.. for C POV packets are coming from A!!

3. C does MBB procedures between LDP neighbor A and B

4. How can C sent a withdraw to LDP neighbor A while Link AC is down?

5. A and C have configured ‘session protection’, neighbors stays up

6. LDP neighbors are established over TCP session between loopbacks, connectivity remains between A and C via B.

Root LDP session

TE/LFA P2P

backup tunnel


Make Before Break

Label Mapping with MBB Request is forwarded upstream until:

– A node is found with active forwarding state

– The root node is reached

The MBB Ack is send down the tree via a LDP Notification message.

As soon as the node received the MBB Ack, the tree is ready.

Additional delay may be added to clean up the old tree to allow the platform to program all the forwarding state to the linecards.

MBB is needed to avoid additional loss when moving from the FRR TE tunnel to a new native path.

LDP session protection is used to keep the LDP neighbour up.

LDP connectivity remains due to TCP session.

Summary

58

Recursive FEC


Recursive FEC

Recursive FEC is used to route an mLDP LSP across (part) of the network that may not have IGP reachability to the Root of LSP.

RFC 6512

This is similar to the PIM RPF vector

The ‘original’ FEC is encapsulated in a new FEC.

The Root of the new FEC is an reachable intermediate node in the network.

Applicability:

– Carriers Carrier (CsC)

– BGP free core

– Seamless MPLS

Introduction

60


Recursive FEC

61

BGP free core / seamless MPLS / Inter-AS

Label mapping comes in from Access to ABR2 with FEC

ABR2 looks up Root in routing table, finds BGP route next-hop ABR1

ABR1 becomes Root for the recursive FEC

LSP is routed through core based on reachability to ABR1!

ABR1 retrieves the original FEC from the Opaque encoding and continues

P ABR2 ABR1

Root

Core Access Access

ABR1 FEC P2MP

BGP

Root Opaque P2MP Root Opaque P2MP

Recursive FEC


Recursive FEC

62

Multiple recursions

Multiple recursions are supported

ABR2 find a BGP route for Root and immediately encodes into a new FEC

This is typical for an Inter-AS deployment between the ASBRs

ABR2 ABR3 ABR1

Root

Core Access Access

BGP

Root Opaque P2MP Root Opaque P2MP

Recursive FEC

BGP

ABR2 FEC P2MP ABR1 FEC P2MP

Core


Recursive FEC

63

Control plane state example

Root node is 10.0.0.11

Upstream neighbour has Recursive encode LSM-ID, effectively treating the recursive FEC as an upstream neighbour

LSM-ID: 0x0000E Type: P2MP Uptime: 00:00:35

FEC Root : 10.0.0.1

Opaque decoded : [recursive] 10.0.0.11:[static-id 0]

Features : RFEC


10.0.0.1:0 [Active] Uptime: 00:00:35

Next Hop : 10.0.3.1




Recursive 0x0000D Uptime: 00:00:35

LSM-ID: 0x0000D Type: P2MP Uptime: 00:00:30

FEC Root : 10.0.0.11

Opaque decoded : [static-id 0]

Features : RFEC


Recursive encode LSM-ID: 0x0000E


LDP 10.0.0.2:0 Uptime: 00:00:30

Next Hop : 10.0.4.2



Recursive root node is 10.0.0.1

Original FEC (0x00D) is treated

as a downstream client

Opaque encoding has original

FEC


Recursive FEC

64

Forwarding plane example

The Original and Recursive FEC are stitched in the forwarding plane

Local label comes from Recursive FEC (upstream)

Outgoing label comes from the Original FEC (downstream)

Forwarding plane is flat, single entry

RP/0/0/CPU0:GSR3#sh mpls forwarding labels 1048566

Fri Mar 9 22:23:33.835 UTC

Local Outgoing Prefix Outgoing Next Hop Bytes

Label Label or ID Interface Switched

------ ----------- ------------------ ------------ --------------- ------------

1048566 16027 MLDP LSM ID: 0xe Gi0/2/1/2 10.0.4.2 68498


Recursive FEC

There are two types of recursive encodings

A global table recursive encoding

– Used for BGP free core

– Seamless MPLS

– Inter-AS

A VPN recursive encoding.

– Carriers Carrier (CsC).

– Inter-AS

The only difference is the ‘RD’ being part of the encoding.

Encodings

65


Recursive FEC

66

The Recursive Opaque Encoding

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type == 7 | Length | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |

~ P2MP or MP2MP FEC element ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Field Description

Type Recursive Opaque Encoding, type 7 (RFC6512)

Length Variable, depending on FEC element

FEC element The complete mLDP FEC


Recursive FEC

67

The VPN Recursive Opaque Encoding

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type == 8 | Length | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |

| |

| Route Distinguisher +-+-+-+-+-+-+-+-+

| | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |

~ P2MP or MP2MP FEC element ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Field Description

Type VPN Recursive Opaque Encoding, type 8 (RFC6512)

Length Variable + 8, depending on FEC element

RD Route Distinguisher (8 octets)

FEC Element The complete mLDP FEC


Recursive FEC

Recursive FEC is useful in various deployments;

– BGP free core

– Inter-AS

– Seamless MPLS

– Carriers carrier (CsC)

Two different encodings

– Global table

– VPN

Stitched trees at control plane

Flat trees at the forwarding plane

Summary

68

Multicast only Fast ReRoute (MoFRR)


MoFRR

MoFRR is a Live-Live solution to provide redundancy

Based on ECMP or LFA alternate paths, 2 trees are build towards the root of the MP LSP

Documented at IETF via draft-karan-mofrr-02

Applies to PIM and mLDP (initial idea came from PIM)

A node dual connected to 2 trees may switch between the them very quickly based on different triggers;

– Link status

– IGP

– BFD

– Traffic flow

Introduction

70


MoFRR

71

Example Link Status

C has ECMP reachability to Root via B and E

C joins the LSP via both B and E

C forwards packets from B and blocks traffic from E (secondary)

C receives two identical packets, but forwards only one

A

B

C

D

Root

L16 L18

18 16

E


MoFRR

72

Example Link Status

C detects upstream failure to B

C blocks traffic from B

C unblocks traffic from E

Traffic flow has recovered without additional protocol signalling

A

B

C

D

Root

E

18 16

L16 L18


MoFRR

When a previously broken link comes back up, what do we do?

Stick with the existing link or revert back to the previous?

We stick with the existing link to not cause additional traffic loss

Even though the router is receiving both streams, switching from one to the other may either cause duplicates or loss of packets

Not necessarily due to the router, but can also be due to buffering/link delays between both paths

Link coming back up

73


MoFRR

74

Example Link Status

There are two upstream neighbours for the same P2MP FEC

10.0.0.1:0 is the Active neighbour

10.0.0.6:0 is the Inactive (standby) neighbour

A

B

C

D

Root

E

18 16

L16 L18

RP/0/0/CPU0:GSR3#sh mpls mldp database opaquetype static-id

Tue Mar 6 23:12:04.060 UTC

mLDP database

LSM-ID: 0x0000C Type: P2MP Uptime: 00:04:00

FEC Root : 10.0.0.15

Opaque decoded : [static-id 0]

Features : MoFRR


10.0.0.1:0 [Active] Uptime: 00:04:00

Next Hop : 10.0.3.1



10.0.0.6:0 [Inactive] Uptime: 00:00:20

Next Hop : 10.0.9.1




LDP 10.0.0.2:0 Uptime: 00:04:00

Next Hop : 10.0.4.2




MoFRR

Join the same LSP via two different upstream paths

The Repair Point router (initiating the MoFRR) can switch to the standby upstream path based on a fast trigger.

Works best in dual plane topologies

Otherwise path separation is possible with Multi Topology or static routing.

Summary

75

In-band signaling global table


In-band signaling global context

PIM (S,G) tree is mapped to a mLDP P2MP LSP.

Root PE is learned via BGP Next-Hop of the Source address.

R-PE may use SSM Mapping if Receiver is not SSM aware

PIM (S,G) tree is mapped to a mLDP P2MP LSP.


R-PE may use SSM Mapping if Receiver is not SSM aware.

R-PE

Root-PE

Root-PE R-PE

PIM (S1,G) PIM (S2,G)

PIM (S1,G) PIM (S2,G) P2MP LSP FEC {S1,G}

P2MP LSP FEC {S2,G} P2MP LSP FEC {S3,G}


Source

S1,S2

MPLS cloud

Source

S3 PIM (S3,G)

Receiver

Receiver

77



PIM (*,G) tree is mapped to a mLDP P2MP LSP.

Root PE is learned via BGP Next-Hop of the RP address.

All sources known by the RP are forwarded down the tree.

PIM (*,G) tree is mapped to a mLDP P2MP LSP.



R-PE

Root-PE

Root-PE R-PE

PIM (*,G1)

PIM (*,G1) P2MP LSP FEC {*,G1} P2MP LSP FEC {*,G2}

PIM (*,G1)

Source

S1,S2

MPLS cloud

Source

S3 PIM (*,G2)

Receiver

Receiver

RP

RP

78



Very useful for IPTV deployments.

Works with PIM SSM and (*,G) trees, no Sparse-mode.

SSM Mapping may be deployed to convert to SSM.

One-2-One mapping between PIM tree and mLDP LSP.

No flooding/wasting of bandwidth.

Works well if the amount of state is bound.

IOS support

– GSR, CRS (shipping)

– 7600 (shipping)

– ASR9K (shipping)


79

In-band signaling VPN context


In-band signaling MVPN context

PIM (S,G) VPN tree is mapped to a mLDP P2MP LSP.

Root PE is learned via BGP Next-Hop of the VPNv4 Source address.


RD of the source VRF is included in the mLDP FEC to allow overlapping (S,G) addresses

R-PE

Root-PE

Root-PE R-PE


PIM (S1,G) PIM (S2,G) P2MP LSP FEC {RD,S1,G}

P2MP LSP FEC {RD,S2,G} P2MP LSP FEC {RD,S1,G}

PIM (S1,G)

Source

S1,S2 Receiver

Receiver

MPLS cloud

Source

S1 PIM (S1,G)

CE

CE

CE

CE

RD

RD

RD

RD

CE

RD

Receiver

PIM (S1,G)

81


In-band signaling MVPN context

Same characteristics as global table

Not well suited for generic MVPN support.

IOS support

– GSR, CRS (shipping)

– 7600 (shipping)



82



84

Basic mLDP configuration

Configuration of mLDP is a sub-mode of LDP

Applies to all interfaces enabled for LDP by default

Unless explicitly disabled under the interface config

mLDP show commands are under ‘show mpls mldp ..’

RP/0/0/CPU0:GSR3#sh run mpls ldp

mpls ldp

mldp

!

interface GigabitEthernet0/2/1/0

!


!


mldp disable

!

!



85

mLDP status RP/0/0/CPU0:GSR3#sh mpls mldp status

mLDP statistics

Process status : Active, Running and Ready

Multipath upstream : Enabled

Multipath downstream : Enabled

Logging notifications : Disabled

Database count : 12

RIB connection status : Connected

RIB connection open : Yes

TE Intact : Disabled

Active RIB table : default/IPv4/Unicast

Table Name : default

AFI : IPv4

SAFI : Unicast

RIB converged : Yes

Table ID : E0000000

Table Name : default

AFI : IPv4

SAFI : Multicast

RIB converged : Yes

Table ID : E0100000

RP/0/0/CPU0:GSR3#sh mpls mldp status standby

mLDP statistics

Process status : Standby, Running and Ready



86

mLDP feature configuration

MoFRR, MBB and Recursive features can be selectively enabled using a Route-Policy (RPL)

RP/0/0/CPU0:GSR3(config-ldp-mldp)#?

logging MLDP logging commands

make-before-break Make Before Break

mofrr MLDP MoFRR support

no Negate a command or set its defaults

recursive-fec MLDP Recursive FEC support

mpls ldp

mldp

make-before-break delay 0

mofrr

recursive-fec

!



87

mLDP root

RIB information related to the root of a MP LSP

RP/0/0/CPU0:GSR3#sh mpls mldp root

Root node : 10.0.0.14 (We are the root)

Metric : 0

Distance : 0

FEC count : 1

RFEC count : 0

Path count : 1

Path(s) : 10.0.0.14 LDP nbr: none

Root node : 10.0.0.15

Metric : 2

Distance : 110

FEC count : 1

RFEC count : 0

Path count : 2

Path(s) : 10.0.9.1 LDP nbr: 10.0.0.6:0

: 10.0.3.1 LDP nbr: 10.0.0.1:0



88

LDP neighbour capabilities

RP/0/0/CPU0:GSR3#sh mpls ldp neighbor capabilities


Capabilities:

Sent:

0x508 (MP: Point-to-Multipoint (P2MP))

0x509 (MP: Multipoint-to-Multipoint (MP2MP))

0x50b (Typed Wildcard FEC)

Received:

0x508 (MP: Point-to-Multipoint (P2MP))

0x509 (MP: Multipoint-to-Multipoint (MP2MP))

0x50b (Typed Wildcard FEC)

RP/0/0/CPU0:GSR3#sh mpls mldp neighbors 10.0.0.2

Fri Mar 9 23:19:50.327 UTC

MLDP peer ID : 10.0.0.2:0, uptime 00:00:11 Up,

Capabilities : Typed Wildcard FEC, P2MP, MP2MP

Target Adj : No

Upstream count : 1

Branch count : 7

Label map timer : never

Policy filter in : None

Path count : 1

Path(s) : 10.0.4.2 GigabitEthernet0/2/1/2 LDP

Adj list : 10.0.4.2 GigabitEthernet0/2/1/2


Multipoint mLDP

Protocol to build P2MP and MP2MP LSPs

– Scalable due to receiver driven nature, like PIM

Extension to existing LDP protocol

– Reusing existing infrastructure

Simpler compared to PIM due to not supporting Sparse-Mode.

Current mLDP features

– FRR over TE tunnels

– Make Before Break

– MoFRR

– Recursive FEC

Conclusion

89


Call to Action…

Visit the World of Solutions:-

Cisco Campus

Walk-in Labs

Technical Solutions Clinics

Meet the Engineer

Lunch Time Table Topics, held in the main Catering Hall

Recommended Reading: For reading material and further resources for this session, please visit www.pearson-books.com/CLMilan2014

90

http://www.pearson-books.com/CLMilan2014




Complete your online session evaluation

Complete four session evaluations and the overall conference evaluation to receive your Cisco Live T-shirt

Complete Your Online Session Evaluation

91

Questions?

multipoint ldp (mldp) -...

Documents