RE: Resetting the sequence number in an authenticated BFD session

"Nitin Bahadur" <nitinb@juniper.net> Thu, 10 January 2008 23:14 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 1JD6by-0006qj-HF; Thu, 10 Jan 2008 18:14:58 -0500
Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JD6bx-0006qa-2V for rtg-bfd-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 18:14:57 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD6bw-0006qS-Kd for rtg-bfd@ietf.org; Thu, 10 Jan 2008 18:14:56 -0500
Received: from exprod7og106.obsmtp.com ([64.18.2.165]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JD6bv-0007YO-TW for rtg-bfd@ietf.org; Thu, 10 Jan 2008 18:14:56 -0500
Received: from source ([66.129.224.36]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Thu, 10 Jan 2008 15:14:45 PST
Received: from emailcorp1.jnpr.net ([66.129.254.11]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 15:14:41 -0800
Received: from emailcorp3.jnpr.net ([66.129.254.13]) by emailcorp1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 15:14:28 -0800
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C853DE.8BEF99E5"
Date: Thu, 10 Jan 2008 15:14:27 -0800
Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E8B22FD@emailcorp3.jnpr.net>
In-Reply-To: <2F29F5E4-C64E-4F36-BD27-DCE8F3E66919@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Resetting the sequence number in an authenticated BFD session
Thread-Index: AchT17OkujRHVBY9REC/cjhfLDLFJgAAvAbg
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>
From: Nitin Bahadur <nitinb@juniper.net>
To: David Ward <dward@cisco.com>
X-OriginalArrivalTime: 10 Jan 2008 23:14:28.0316 (UTC) FILETIME=[8C6259C0:01C853DE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: abb8110dde048486ea2be9c769692569
Cc: Ronen Sommer <Ronen.Sommer@ecitele.com>, BFD WG <rtg-bfd@ietf.org>, Igor Danilovich <Igor.Danilovich@ecitele.com>, Dave Katz <dkatz@juniper.net>
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 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.