Re: Ability to detect swapped/merged LSPs

[Jeffrey Haas <[e-mail]>]

Richard,

I wont claim to be a MPLS expert, but I'm struck by the following:

On Tue, Mar 01, 2005 at 05:09:26PM -0000, [e-mail] wrote:
> If we get a swapped LSP (e.g. due to a corrupted forwarding table or configuration error) then all BFD packets received for the corresponding session will be dropped and the session will be declared down as a detection timeout will occur. However, if we get a merging defect where a node receives both valid BFD packets in addition to invalid BFD packets then this defect will not be detected.
> 
> In both cases, traffic is being forwarded onto the wrong destination and therefore these defects need to be detected and appropriate actions taken, e.g. raise an alarm and inform the LSP source (using the appropriate BFD status code) that a defect has occurred so that the source can stop forwarding packets or switch over to an alternative path if one exists.

If we are receiving some other node's traffic due to forwarding
corruption in the network, then wouldn't:
a. The intended target of the session time out the session after the
   appropriate interval?
b. The node that is accidentally receiving the traffic may be potentially
   unable to respond due to the inherent unidirectionality of an LSP?
   (In other words, the case where we do not have an LSP that would
   permit us to respond.)

> By adding new processing rules and status codes, both of these defects could be detected using BFD. An alternative would be to use LSP ping but it would not provide the same defect detection speed, i.e. an LSP might only get tested using LSP pings every 30mins or maybe every hour in a large network with hundreds of thousands of PWs/LSPs, as opposed to BFD packets that can be sent every second.

It's probably worth reminding people that a session for BFD for
MPLS LSPs must be bootstrapped using LSP-Ping.

Upon failure of a BFD session, it's very reasonable to use LSP-Ping not
only to reinitialize (or attempt to reinitialize) the BFD session, but
also do further troubleshooting.

> Richard

-- 
Jeff Haas 
NextHop Technologies