Re: Ability to detect swapped/merged LSPs

["Thomas D. Nadeau" <[e-mail]>]

>> 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.
>
> Does anyone have any arguments for/against adding the ability to 
> detect these defects into BFD?
>
> Thanks,
> Richard
>
>
>
>
>
>
>
>
>
>