Re: Resetting the sequence number in an authenticated BFD session

[David Ward <[e-mail]>]

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

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