LDP up convergence

[oettls]

Hi,

I heard of plans to optimize LDP convergence issues when switching back to a previously failed link. The problem is that when the IGP converges faster than LDP (especially with throttle timers) MPLS (VPN) traffic is blackholed until LDP is up.

- targeted LDP session by default: Something like auto-discovery of the transport address over a standard hello adj. Even after all connected links to the peer fail the LDP session is still maintained through normal routing when alternate paths between LSRs exist. When the failed link comes back up again, labels are already present.

- IGP / LDP synchronization: IGP waits for LDP to converge BEFORE switching to the alternate path. I guess something like 'max-metric router-lsa wait-for-ldp' ?

When will these features appear in IOS ?

We are currently facing the problem described above, but manually configuring targeted LDP between all core routers is somewhat cumbersome ;-)

thanks in advance

Stefan

[mheusinger]

Well, MPLS TE between all PE routers would also do the job. However I do not know whether that is too "expensive" from an operation point of view.

regards

Martin

[maher]

Hi there,

Just to share my info regarding this matters few month ago. Well I noticed that all about LDP convergence under the RFC2547.Tried to ask Cisco expert but MPLS TE is the available choice.Perhaps a simple mechanism if there is no route/label to here forward to another available path just like oettls mension.

Another solution would be MPLS OAM but is's only for detection where the problem lies but not fixing the actual cause. Perhaps a good solution and simple for service provider network to implement MPLS/VPN ?

just me 2 cents...

thanks.

maher

[oettls]

Hi Martin,

you're right, TE would be an option. But as you mentioned it's rather an operations issue to deploy a full mesh of PE-PE TE tunnels (or some hierarchy) for convergence reasons. We already have TE signalling / flooding configured, but tunnels are only used on an exceptional basis.

cheers,

Stefan

[adityakaul]

As far as RFC2547 vpn's are concerned the signalling(VPN Label xchange) is done via MBGP.

Its a known fact that if your BGP flaps your IPV4 table converges first and then the VPNV4 table.

It can be critical if you are having full Internet table on the same box.

This also leads to certain amount of downtime before the traffic is forwarded apart from IGP/LDP sync as mentioned by you.

[maher]

Hi Adityakaul,

You are right! Thanks for the info.The syncronization between LDP/IGP may cause the link somesort of flapping.

Would be glad if the MPLS OAM could do that via ping mpls/traceroute mpls.

BTW, does Cisco have somekind " The bidirectional forwarding detection (BFD)" ?

thanks

maher

[adityakaul]

Both Cisco/Juniper supported draft-katz-ward-bfd,

but only juniper has implemented it.

There is another BFD draft from Juniper which has support for .

a) RSVP IPv4/IPv6 Session [RSVP-TE]

b) LDP IPv4/IPv6 prefix [LDP]

c) VPN IPv4/IPv6 prefix [2547]

d) Layer 2 VPN [L2-VPN]

e) Layer 2 Circuit ID [LDP-PW]

draft-raggarwa-mpls-bfd-00.txt

[romccallum]

Use targetted hellos to your neighbours. Ok its a manual thing but its not that tough to do. Just do the directly connected neighbours. When the link comes back up or goes down nothing changes regarding LDP as the targetted session remains active (if it has more than one path of course). Combine this with strict IGP timers and your network shall converge in under 50ms without any requirement or need for TE.

[maher]

Hi there,

Thanks for the info. BTW, any technical documentation for that? Perhaps a link ?

thanks in advance.

maher

[oettls]

Hi,

thanks for all your comments and suggestions.

At the moment configuring targeted LDP manually between directly connected peers seems to be the least painful (and proven to be working) option for us.

Perhaps some day an automatic mechanism will make it into IOS to overcome these IGP/LDP sync issues.

cheers,

Stefan