Subject: Ability to detect swapped/merged LSPs

From: [email-masked]
Date: Tue, 1 Mar 2005 17:09:26 -0000

>From the current base draft "If the Your Discriminator field is nonzero, it MUST be used to select the session with which this BFD packet is associated. If no session is found, the packet MUST be discarded."

If a node receives a BFD packet with a Discriminator field that it doesn't have a session for then there is a problem somewhere in the network, so why is the packet simply dropped and no further action taken?

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.

I know that the idea behind the BFD draft is to keep it as simple as possible, but speaking as an operator, I would consider these defects to be just as important as loss of connectivity defects. They might not occur as frequently but are potentially more dangerous, e.g. I don't want to unknowingly be sending packets from customer As network to customer Bs network. 

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.

Does anyone have any arguments for/against adding the ability to detect these defects into BFD?

Thanks,
Richard

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 1 Mar 2005 12:51:44 -0500

>> From the current base draft "If the Your Discriminator field is 
>> nonzero, it MUST be used to select the session with which this BFD 
>> packet is associated. If no session is found, the packet MUST be 
>> discarded."
>
> If a node receives a BFD packet with a Discriminator field that it 
> doesn't have a session for then there is a problem somewhere in the 
> network, so why is the packet simply dropped and no further action 
> taken?

	The packet is discarded, but the device can certainly take note of it. 
It
just has to make sure this will not result in a DoS attack on the 
device.

> 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.

	Hi Richard,

	The defect will be detected in both cases due to the fact that the BFD
session ID information at the receiver should be incorrect. Lets 
consider both
cases:

	1) Correct LSP, but corrupted BFD session parameters.

	This is the case you describe above. It is easily handled by virtue
	of	BFD session parameter mismatch.

	2) Incorrect LSP due to corrupted TFIB, but the payload remains
		intact and thus valid BFD session parameters.

	In this case the packet might make it to an LSR that happens to have 
BFD running.
	If it does, the BFD session information will not match with the 
source/destination.
	Thus, that should be detected as a failure since that node will not 
respond.
	The only case I think can't be detected with just BFD is the case where
	the mis-merged LSP happens to swap to a label that gets you to the 
	correct destination LSR, albeit with the wrong label stack, and thus 
over the
	wrong last bit of the LSP. In this case, since the BFD information is 
valid,
	this MIGHT work okay, but not in all cases. For instance, if the end 
node is
	a PE for L3 or L2 VPN/PWs (i.e.: in VCCV), the application label will 
also be bound to
	the BFD session, and thus will fail. So there seems to be some 
unlikely corner cases
	where the basic mechanism can fail. The good news is that in all 
cases, if you just
	run LSP ping "every now and then", you can detect all of these corner 
cases
	as well due to the diag. processing in LSP ping.
	
	--Tom

> 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.
>
> I know that the idea behind the BFD draft is to keep it as simple as 
> possible, but speaking as an operator, I would consider these defects 
> to be just as important as loss of connectivity defects. They might 
> not occur as frequently but are potentially more dangerous, e.g. I 
> don't want to unknowingly be sending packets from customer As network 
> to customer Bs network.
>
> 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.
>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Mar 2005 12:55:43 -0500

Richard,

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

> 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 (us…

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,…

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.

-- 
Jeff Haas 
NextHop Technologies