Subject: [mpls] Question regarding RFC5443

From: Ed <[email-masked]>
Date: Thu, 4 Nov 2010 17:18:34 +1100

Hi All,

RFC 5443 proposed a solution to avoid blackholing of labelled traffic in
situations where IGP is operational but LDP is not on a particular link. The
proposed solution is to discourage the use of such links for IP forwarding
by increasing the IGP cost of the link to the maximum metric.

My question is from an operational/implemetation point of view - whether
this leaves the network vulnerable if the LDP is flapping for any reason on
a particular link. This could happen due to operational bugs, for example.
In such instance, the constant change in IGP metric could cause excessive
LSA/LSP flooding. Is there any mechanism proposed to guard against this -
for example, via a backoff timer that regulates when the IGP to increase
it's metric each time the LDP flaps, or any other mechanisms?

Thanks.

Regards,
Edward

---

From: "iLya" <[email-masked]>
Date: Thu, 4 Nov 2010 10:03:32 +0100

Edward,

--------------------------------------------------
> it's metric each time the LDP flaps, or any other mechanisms?

Such backoff mechanism is already present in IGP - LSA/LSP pacing. In ISIS, 
for example, router will increase time between generating subsequent LSP 
(but will go back to fast behaviour after network is stable for some while), 
and will throttle number of LSP sent out to N LSP per second. From IGP 
perspective LDP flapping is not much different from interface flapping 
(though slight difference still exists - you can configure interface 
dampening).

Additionally, if you have frequent LDP flapping you'll hopefully notice it 
in the monitoring system and can permanently increase IGP cost of that link. 
Otherwise you have more problems to worry about rather than just LSP flood.

Kind regards,
iLya

---

From: <[email-masked]>
Date: Thu, 4 Nov 2010 10:14:40 +0100

iLya, Edward,

----
> Such backoff mechanism is already present in IGP - LSA/LSP pacing. In
ISIS, for example, router will increase time 
> between generating subsequent LSP (but will go back to fast behaviour
after network is stable for some while), and will
> throttle number of LSP sent out to N LSP per second. From IGP
perspective LDP flapping is not much different from
> interface flapping (though slight difference still exists - you can
configure interface dampening).

iLya I totally agree with you, all is available inside IGP to perform
the ISIS slowdown : you can touch LSP generation interval or SPF/PRC
computation trigger (exponential or linear backoff algorithm depending
on vendor implementation).

Regards,

Stephane

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Ed <[email-masked]>
Date: Mon, 8 Nov 2010 12:14:51 +1100

Thanks Stephane and iLya. That is a good point - the OSPF and ISIS already
has mechanisms to handle LSA/LSP flooding.

I am wondering - does this mechanism ensure that the link across which the
LDP is flapping remains down/non-preferred from the IGP's perspective? i.e.
will the LSA/LSP pacing mechanism in IGP will cause IGP cost across the link
to remain infinite and the blackhole scenario described in the RFC does not
occur?

I understand that the NOC can react to the LDP flaps and manually implement
workarounds, but I know of one major carrier who filters LDP related flaps
to minimise alarm storm if a physical link flaps, and hence will not detect
the issue where only LDP flaps.

Thanks again.

Best Regards,
Edward