Comment 9 for bug 1452362

Reviewed: https://review.opencontrail.org/12127
Committed: http://github.org/Juniper/contrail-controller/commit/b88973dd9852cf8bc975a9fb002d0e64f7d6d7d5
Submitter: Zuul
Branch: R2.20

commit b88973dd9852cf8bc975a9fb002d0e64f7d6d7d5
Author: Manish <email address hidden>
Date: Wed Jul 1 15:27:58 2015 +0530

Dangling EVPN allocated MPLS label.

Problem:
Multicast allocates mpls label for use in evpn. This label is deleted once all
paths in the flood route goes off. Label is stored in multicast object created
for flood route. In problematic scenario multicast object was deleted either via
all VM going off(in regular agent) or via VN in TSN. Because of this unsubscribe
is sent to control-node which in turns issues withdraw of route with peer as CN.
However when this request is received at multicast handler, it tries to search
for multicast object and if it is not found then request is ignored. Hence path
keeps pending in route and label is also active.
Now multicast object gets added again because of VM coming in or VN subscription
is received in TSN. This will result in new evpn label allocation. Again this
results in export of route to CN with new label. CN sends EVPN olist with new
label. On receiving it multicast tries to search for object and finds the new
one. It picks label(new) and sends it for path addition in route. It results in
update of old path which was not deleted for peer CN. This updation results in
label update in evpn path as well and the last context of old mpls label is
lost. This results in dangling MPLS DB entry.

Solution:
If multicast object is null and delete request is received, use label as 0 as it
does not matter what is passed.

Change-Id: I75f5a3e12d312500259532fe95c543fa567eaeed
Closes-bug: 1452362