RE: Resetting the sequence number in an authenticated BFD session

[Alexander Vainshtein <[e-mail]>]

David and all,
Lots of thanks for a prompt and detailed response.
 
My gut feeling is that replicated state (or something like that) is part
of all the approaches you've outlined, but I must carefully  re-check
this feeling.
 
Regards,
                Sasha

________________________________

From: David Ward [mailto:[e-mail]] 
Sent: Sunday, January 13, 2008 6:18 PM
To: Alexander Vainshtein
Cc: David Ward; Nitin Bahadur; Dave Katz; Ronen Sommer; BFD WG; Igor
Danilovich
Subject: Re: Resetting the sequence number in an authenticated BFD
session


Sasha - 

What you need to realize is that you have a layering problem to solve
and one could solve it multiple ways today.

One solution:

Run LACP or UDLD between the router and the switch that has the bundled
interface, monitor component links and the state of the bundle.
Independently run a BFD session between the two routers. 


Second solution:

Run BFD between the two routers and on the router with the bundled
interface, have a distributed state machine on all cards that home
component links (this is an implementation specific design).


Third solution:

Run BFD between the router and the switch with the bundled interface via
IP and monitor all component links. Run a second BFD between the two
routers and use either a centralized BFD, a master link (that can
receive all BFD packets through internal forwarding) or replicate state
via #2.



All three of the above solve the problem (there are obvious variants)
and are deployed today.

-DWard



On Jan 12, 2008, at 11:24 PM, Alexander Vainshtein wrote:


	David,
	I have probably poorly presented the case of an intermediate L2
device. 
	What I have in mind is the following combination:

	1.	
		A single L3 adjacency monitored by BFD that has been
established across an intermediate L2 device
	2.	
		Different number of L2-bundled links between each of the
L3 peers and the intermediate L2 device.

	I do not see how your proposed solutions would help to resolve
the problem:

	1.	Not sure why UDLR is relevant to this scenario, will
look-up the appropriate RFC first 
	2.	LACP operates per L2-bundled link. It would help to
detect a failure of such a link, but, IMHO, no more than that




	3.	L3 BFD between a L3 and L2 device would not affect the
state of the L3 BFD session between the L3 peers.

	






	Regards,

	                Sasha


________________________________

	From: David Ward [mailto:[e-mail]]
	Sent: Fri 1/11/2008 4:18 PM
	To: Alexander Vainshtein
	Cc: David Ward; Nitin Bahadur; Dave Katz; Ronen Sommer; BFD WG;
Igor Danilovich
	Subject: Re: Resetting the sequence number in an authenticated
BFD session
	
	
	Sasha - 


	I think I already covered your points on centralization and
master component link. WRT the issue that a L3 device is connected to an
L2 device via a bundled interface and the far L3 device is single
attached ... BFD is currently an L3 solution. You'd have to run LACP,
UDLR or BFD at L3 to the L2 device to cover this scenario.

	-DWard


	On Jan 11, 2008, at 4:11 AM, Alexander Vainshtein wrote:


		David, Nitin and all,
		Please see inline below (blue italics)..Unfortunately it
seems that none of the options explicitly proposed by David resolve the
issue.
		 
		Regards,
		                 Sasha

________________________________

		From: David Ward [mailto:[e-mail]]
		Sent: Thu 1/10/2008 11:51 PM
		To: Nitin Bahadur
		Cc: David Ward; Alexander Vainshtein; Dave Katz; Ronen
Sommer; BFD WG; Igor Danilovich
		Subject: Re: Resetting the sequence number in an
authenticated BFD session
		
		
		Solutions include (and are alluded to in the drafts): 

		run BFD on bundled interfaces (any flavor) centrally
[Sasha] This rasies the issue of the central component failover (as
mentioned in my oriinal message).
		 
		run BFD on all component links independently [Sasha]
IMHO this is not a viable option. E.g., consider a L3 1-hop situation
where the bundled interfaces run between one of the routers and a L2
switch, while the L3 adjacency is unaware of bundling. This is easily
achieved with LAG. 
		 
		run BFD on a master component link [Sasha] The failure
of the LC that carries the "master componet link" is the original
scenario described in my original email, and the issue remains unsloved
IMO.

		There are other variants as well.

		-DWard

		On Jan 10, 2008, at 3:41 PM, Nitin Bahadur wrote:


			
			Alexander,
			 
			   I agree that keeping the sequence number
consistent between line cards is not practical. We need a way for a
system to indicate that it wants to restart the sequence.
			 
			Nitin
			 
			
________________________________

			From: Alexander Vainshtein
[mailto:[e-mail]] 
			Sent: Thursday, January 10, 2008 12:42 PM
			To: David Ward; Dave Katz
			Cc: Ronen Sommer; BFD WG; Igor Danilovich
			Subject: Resetting the sequence number in an
authenticated BFD session
			Importance: High
			 
			Hi all,
			I have a question related to the expected
behavior of sequence numbers in an aythenticated (MD5 or SHA1) BFD
session.
			 
			The corresdponding sections of
draft-ietf-bfd-base-06 state that, once the packet has been
authenticated by the receiver, its sequence number MUST be checked; if
its value is out of range defined by the last received sequence number
and the Detect Multiplexor, the packet MUST be discarded.
			 
			This may result in the a BFD session going down
in the situation when the transceiver "loses" the information about its
last transmitted sequence number. A suitable use case is a multilink
interface (LAG, ML-PPP, etc.) with the links residing in different line
cards, and e BFD implemented in one of these cards: if this card fails,
the BFD would could be re-started in one of the remaining cards. Such a
restart would not affect the local session because the BFD machine would
be restarted with bfd.AuthSeqKnown = 0, but keeping bfd.XmitAuthSeq
consistent between different line cards seems problematic. (Implemeting
BFD in some common card would resolve the situation with the multilink
interfaces but would raise similar issues when the common card fails).
			 
			Note that this problem would not occur for a
non-authenticated BFD session.
			 
			IMHO this problem is real, and I do not see a
simple solution for it. 
			I would highly appreciate any feedback from the
draft authors and/or from the WG.
			 
			Regards,
			                  Sasha