RE: Resetting the sequence number in an authenticated BFD session

["Peter Arberg" <[e-mail]>]

Hi David,
 
When you say:
 
---
Difficult but, not impossible. Again, there are multiple interoperable
implementations that work over enet bundles, MLPP, etc. Fortunately none of
them change the packets on the wire or protocol state machine.
---
 
I take it you are refering to BFD over a link-bundle, where the bundle is
considered "1" link, so
just 1 BFD session, so it is a bundle "keepalive" instead of a per link
inside the bundle
monitoring/keepalive.
 
correct ?
 
thanks,
Peter
 
 


  _____  

From: David Ward [mailto:[e-mail]] 
Sent: 11. januar 2008 06:23
To: Alexander Vainshtein
Cc: Ronen Sommer; Dave Katz; Igor Danilovich; David Ward; BFD WG
Subject: Re: Resetting the sequence number in an authenticated BFD session


Sasha - 


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


David, Nitin and all,
 
IMHO the problem raised is specific because it represents a combination of
situations:

1.	

	Handling of a non-planned event is required

*	

	From my experience, card failures fail quite often into this
category


This is a generic problem.


*	

*	

	Since the ecent is non-planned, the BFD machine cannot prepare the
peer for this event. Handling of planned events could, e.g., begin with the
peer expecting

*	

	such an event decalring the BFD session administratively down and
thus precluding any undesirable action by the peer


This is also a generic problem.


2.	

	The event affects the authentication procedure. This means (and my
reading of the draft) that regardless of what the BFD machine after the
event tries to do, it will not be achieved because the packets it sends
shall not be authenticated and hence shall not affect the peer behavior.


Again, this is no different if other "helping" BFD processes didn't have any
of the session state. Any BFD information given w/ unknown session
information is ignored. This isn't limited to Auth.


The real-time side of the story (namely sequence numbers chagning quite
fast) makes any solution based on synchronization between tow incarnations
(before and after the event) of the BFD machine very difficult.





Difficult but, not impossible. Again, there are multiple interoperable
implementations that work over enet bundles, MLPP, etc. Fortunately none of
them change the packets on the wire or protocol state machine.

-DWard




Regards,

                 Sasha

  _____  

From: David Ward [mailto:[e-mail]]
Sent: Fri 1/11/2008 1:39 AM
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


The solution for this is outside the scope of the spec.  Note that the
problem you describe is not specific to auth at all, it is a generic system
problem. The problem is the same if you receive any BFD notification over
any link and you need to disseminate that information to all component
links. Discrim change, timer change, etc they all fit into this category. 

You can home the BFD machine on one LC (yes, a form of centralization) and
fwd bfd packets to it, you can run BFD on all LCs homing component links and
send notifications between them (proprietary solution) - there are many
variants of this. It is much, much harder to put the solution into
forwarding chips themselves but, again it is not an unsolvable problem
either.

In any event, the meta point is that this problem is not limited to
authentication seq_id rollover and unfort is not a solution that requires
specification for interoperability. Towards that end I know of multiple
interoperable implementations that work over bundles.


-DWard 

On Jan 10, 2008, at 5:14 PM, Nitin Bahadur wrote:



 
The case I was thinking of was as follows..
 
       ____________                             ________
      |    Bundle        |                           |   Bundle |   
 A  +---------------------+ B ------ C  ------ D +------------+ E  
      |____________ |
 
A and E are iBGP peers. iBGP doesn't know/care bout link bundling. The peers
establish a BFD mhop session between them. The links A-B and D-E are link
bundles. One cannot guarantee that the link bundle components will be on the
same line-card. How can one maintain auth semantics if the line card on A
hosting  the BFD session goes down.
 
 

  _____  

 
*      run BFD on all component links independently
This solution does not work for multi-hop bfd sessions. If the outgoing link
for a mhop session is a link-bundle, then you would need to create a 1
session per component link just to monitor the health of a single bfd peer.
Also, for a mhop session, if there are link bundles on both the peers, I'm
not sure how it would work.
 
 
DW: The picture would be that the component links in an L2 bundle are
directly adjacent.  In an L2 bundle situation where you want to test each
link  independently with bidir comms between two routers why would it be
mhop? MHop session are for those w/o being directly adjacent.
 
 
DW: Perhaps you meant that two routers running a mhop BFD session that
traversed a link bundle somewhere inbetween. In this case there is nothing
you can do as there is nothing you can to to guarantee you are going to
traverse the same component links of the bundle inbetween two other routers.
The forwarding choice of how to balance those flows over the component links
is a local decision that the mhop BFD'ing routers cannot bias.