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. > >
- Resetting the sequence number in an authenticated… Alexander Vainshtein
- RE: Resetting the sequence number in an authentic… Nitin Bahadur
- RE: Resetting the sequence number in an authentic… Nitin Bahadur
- Re: Resetting the sequence number in an authentic… David Ward
- Re: Resetting the sequence number in an authentic… David Ward
- RE: Resetting the sequence number in an authentic… Nitin Bahadur
- Re: Resetting the sequence number in an authentic… David Ward
- RE: Resetting the sequence number in an authentic… Alexander Vainshtein
- RE: Resetting the sequence number in an authentic… Alexander Vainshtein
- Re: Resetting the sequence number in an authentic… David Ward
- Re: Resetting the sequence number in an authentic… David Ward
- RE: Resetting the sequence number in an authentic… Peter Arberg
- Re: Resetting the sequence number in an authentic… Dave Katz
- RE: Resetting the sequence number in an authentic… Alexander Vainshtein
- RE: Resetting the sequence number in an authentic… Alexander Vainshtein
- Re: Resetting the sequence number in an authentic… David Ward
- RE: Resetting the sequence number in an authentic… Alexander Vainshtein