RE: Ability to detect swapped/merged LSPs

[[e-mail]]

Tom,

Thanks for your response. Having thought about the defects again I agree that both will be detected, if BFD packets are being sent to the wrong place then you're going to get a detection timeout somewhere, regardless of whether the LSPs are swapped or merged.

The only downside to the BFD approach is that in both cases the defect code will just be "1 -- Control Detection Time Expired", i.e. BFD will not provide any indication of what the defect might be. Saying that, the main point is that the problem will be detected, other tools such as LSP ping can be used to diagnose and locate the problem.

Regards,
Richard


> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[e-mail]]
> Sent: 01 March 2005 17:52
> To: Spencer,R,Richard,XDE73 R
> Cc: [e-mail]
> Subject: Re: Ability to detect swapped/merged LSPs
> 
> 
> 
> >> 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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>