Re: Resetting the sequence number in an authenticated BFD session

[David Ward <[e-mail]>]

Nitin -


On Jan 10, 2008, at 4:19 PM, David Ward wrote:

>
> Nitin -
>
> inline
>
> On Jan 10, 2008, at 4:10 PM, Nitin Bahadur wrote:
>
>> That’s not sufficient from a practical point of view. Here’s why.
>>
>> Ø      run BFD on bundled interfaces (any flavor) centrally
>> Can’t support very low detection times. Only line cards can  
>> support tens of ms.
>>
>> Ø      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.


I wasn't sure if you were thinking of that case.


-DWard




>
>> Ø      run BFD on a master component link
>> What if the master goes down? The link is still UP. If you now  
>> assign the master to a different line card, you end up with  
>> problem of sequence number out of sync.
>>
>> I would be interested in knowing the other variants that might  
>> help solve the above issues.
>
>
> DW: Many of them do not require modifications to the protocol to be  
> interoperable and would be outside the scope of the BFD specification.
>
> -DWard
>
>>
>> Thanks
>> Nitin
>>
>> From: David Ward [mailto:[e-mail]]
>> Sent: Thursday, January 10, 2008 1: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
>> run BFD on all component links independently
>> run BFD on a master component link
>>
>> 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
>>
>>
>