RE: Resetting the sequence number in an authenticated BFD session

"Nitin Bahadur" <nitinb@juniper.net> Thu, 10 January 2008 22:11 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 1JD5cu-0006bO-09; Thu, 10 Jan 2008 17:11:52 -0500
Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JD5cs-0006bJ-SM for rtg-bfd-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 17:11:50 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD5cs-0006bA-Es for rtg-bfd@ietf.org; Thu, 10 Jan 2008 17:11:50 -0500
Received: from exprod7og110.obsmtp.com ([64.18.2.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JD5cr-0006He-Ct for rtg-bfd@ietf.org; Thu, 10 Jan 2008 17:11:50 -0500
Received: from source ([66.129.224.36]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Thu, 10 Jan 2008 14:11:45 PST
Received: from emailcorp2.jnpr.net ([66.129.254.12]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 14:11:41 -0800
Received: from emailcorp3.jnpr.net ([66.129.254.13]) by emailcorp2.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 14:10:51 -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_01C853D5.A8C7B3A3"
Date: Thu, 10 Jan 2008 14:10:50 -0800
Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E8B22FC@emailcorp3.jnpr.net>
In-Reply-To: <A1C094AD-3891-4660-AE2C-DADE1FF7DD96@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Resetting the sequence number in an authenticated BFD session
Thread-Index: AchT0vfa1VyobG3RSpWwPFWe+pDrkAAAV0cg
References: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com> <7FA0C743C38E5340BFC2873488FA1E8E8B22F9@emailcorp3.jnpr.net> <A1C094AD-3891-4660-AE2C-DADE1FF7DD96@cisco.com>
From: Nitin Bahadur <nitinb@juniper.net>
To: David Ward <dward@cisco.com>
X-OriginalArrivalTime: 10 Jan 2008 22:10:51.0057 (UTC) FILETIME=[A91EDA10:01C853D5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0fa531afcd551ff81145d3275aa425e
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

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.

 

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

 

Thanks

Nitin

 

________________________________

From: David Ward [mailto:dward@cisco.com] 
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: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