Re: Resetting the sequence number in an authenticated BFD session

David Ward <dward@cisco.com> Thu, 10 January 2008 23:39 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 1JD6zx-00006f-1q; Thu, 10 Jan 2008 18:39:45 -0500
Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JD6zw-00006Y-5e for rtg-bfd-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 18:39:44 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD6zv-00006O-H7 for rtg-bfd@ietf.org; Thu, 10 Jan 2008 18:39:43 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JD6zu-0007yF-IA for rtg-bfd@ietf.org; Thu, 10 Jan 2008 18:39:43 -0500
X-IronPort-AV: E=Sophos; i="4.24,269,1196658000"; d="scan'208,217"; a="82989615"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 Jan 2008 18:39:42 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0ANdgcq029195; Thu, 10 Jan 2008 18:39:42 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0ANdbpi001033; Thu, 10 Jan 2008 23:39:37 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); Thu, 10 Jan 2008 18:39:37 -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); Thu, 10 Jan 2008 18:39:37 -0500
In-Reply-To: <7FA0C743C38E5340BFC2873488FA1E8E8B22FD@emailcorp3.jnpr.net>
References: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22F9@emailcorp3.jnpr.net> <A1C094AD-3891-4660-AE2C-DADE1FF7DD96@cisco.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22FC@emailcorp3.jnpr.net> <CC15BFAB-5E34-4D4C-914E-8320804B1731@cisco.com> <2F29F5E4-C64E-4F36-BD27-DCE8F3E66919@cisco.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22FD@emailcorp3.jnpr.net>
Mime-Version: 1.0 (Apple Message framework v753)
Content-Type: multipart/alternative; boundary="Apple-Mail-1-510350660"
Message-Id: <C1329D64-7A04-42DC-BED6-5BD6470478CE@cisco.com>
From: David Ward <dward@cisco.com>
Date: Thu, 10 Jan 2008 17:39:26 -0600
To: Nitin Bahadur <nitinb@juniper.net>
X-Mailer: Apple Mail (2.753)
X-OriginalArrivalTime: 10 Jan 2008 23:39:37.0371 (UTC) FILETIME=[0FD9DEB0:01C853E2]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16618; t=1200008382; x=1200872382; 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:=20=22Nitin=20Bahadur=22=20<nitinb@juniper.net>; bh=0cUgh+0vWC0TE/euPtKbrvEiWWPaIcsK6jiQw67rJlU=; b=mV7CbA/D65taK0e7HpQI8zZjst02i88CaFYJTE1nrFAP+SLGuOzGxEvXnH Wj4+mip9MSIKNRy0FbM8uheDDaBcq31d2anSeGCvtbfMEW0/lOFSaf6s0W+C K3lQJdOKPo;
Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
X-Spam-Score: 2.4 (++)
X-Scan-Signature: 343d06d914165ffd9d590a64755216ca
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

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