Re: Resetting the sequence number in an authenticated BFD session

David Ward <dward@cisco.com> Fri, 11 January 2008 14:19 UTC

Return-path: <rtg-bfd-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDKj4-0003F1-5P; Fri, 11 Jan 2008 09:19:14 -0500
Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JDKj2-0003Cd-Qi for rtg-bfd-confirm+ok@megatron.ietf.org; Fri, 11 Jan 2008 09:19:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDKj2-0003CV-Gs for rtg-bfd@ietf.org; Fri, 11 Jan 2008 09:19:12 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDKj1-0005lw-6Z for rtg-bfd@ietf.org; Fri, 11 Jan 2008 09:19:12 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 11 Jan 2008 09:19:10 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0BEJAPW017199; Fri, 11 Jan 2008 09:19:10 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0BEJ073012452; Fri, 11 Jan 2008 14:19:10 GMT
Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 09:19:01 -0500
Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 09:19:01 -0500
In-Reply-To: <64122293A6365B4A9794DC5636F9ACFD0252D70B@ILPTEX02.ecitele.com>
References: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22F9@emailcorp3.jnpr.net> <A1C094AD-3891-4660-AE2C-DADE1FF7DD96@cisco.com> <64122293A6365B4A9794DC5636F9ACFD0252D70B@ILPTEX02.ecitele.com>
Mime-Version: 1.0 (Apple Message framework v753)
Content-Type: multipart/alternative; boundary="Apple-Mail-9-563115903"
Message-Id: <A050B43B-2ABA-4FCC-811E-2017003A1B50@cisco.com>
From: David Ward <dward@cisco.com>
Date: Fri, 11 Jan 2008 08:18:51 -0600
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
X-Mailer: Apple Mail (2.753)
X-OriginalArrivalTime: 11 Jan 2008 14:19:01.0317 (UTC) FILETIME=[E99D1750:01C8545C]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17548; t=1200061150; x=1200925150; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20<dward@cisco.com> |Subject:=20Re=3A=20Resetting=20the=20sequence=20number=20i n=20an=20authenticated=20BFD=20session |Sender:=20 |To:=20Alexander=20Vainshtein=20<Alexander.Vainshtein@ecite le.com>; bh=VmXCkb25O0QXKAleNZQP9gNgKPeKZPiT51SAnXx9z+0=; b=E/7tDb6WnONwjrd3cuoezlbYkfB2B77Asx//kkSJxYYUmOSHVb5rYSgPri dk8MV2CS1UIcKoT3PylcGLPjzP/GrgXzdqgW3aCbCmv9s4bWNz9k9dF5V6iJ PVayMSqURM;
Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c
Cc: Ronen Sommer <Ronen.Sommer@ecitele.com>, Dave Katz <dkatz@juniper.net>, Igor Danilovich <Igor.Danilovich@ecitele.com>, David Ward <dward@cisco.com>, BFD WG <rtg-bfd@ietf.org>
Subject: Re: Resetting the sequence number in an authenticated BFD session
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Errors-To: rtg-bfd-bounces@ietf.org

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:dward@cisco.com]
> 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:Alexander.Vainshtein@ecitele.com]
>> 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
>>
>