RE: Resetting the sequence number in an authenticated BFD session
"Nitin Bahadur" <nitinb@juniper.net> Thu, 10 January 2008 21:42 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 1JD5AY-0003Xj-LI; Thu, 10 Jan 2008 16:42:34 -0500
Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1JD5AX-0003Xe-Bz for rtg-bfd-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 16:42:33 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD5AW-0003XW-Vv for rtg-bfd@ietf.org; Thu, 10 Jan 2008 16:42:33 -0500
Received: from exprod7og104.obsmtp.com ([64.18.2.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JD5AV-0005lz-U1 for rtg-bfd@ietf.org; Thu, 10 Jan 2008 16:42:32 -0500
Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Thu, 10 Jan 2008 13:41: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 13:41:24 -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 13:41:16 -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_01C853D1.86AF95EB"
Date: Thu, 10 Jan 2008 13:41:15 -0800
Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E8B22F9@emailcorp3.jnpr.net>
In-Reply-To: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Resetting the sequence number in an authenticated BFD session
Thread-Index: AchTxJoMy3m6iHfxTVCQbsdfBl6XpAAC7lpQ
References: <64122293A6365B4A9794DC5636F9ACFD0252D70A@ILPTEX02.ecitele.com>
From: Nitin Bahadur <nitinb@juniper.net>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, David Ward <dward@cisco.com>, Dave Katz <dkatz@juniper.net>
X-OriginalArrivalTime: 10 Jan 2008 21:41:16.0231 (UTC) FILETIME=[873DE570:01C853D1]
X-Spam-Score: 0.6 (/)
X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e
Cc: BFD WG <rtg-bfd@ietf.org>, Ronen Sommer <Ronen.Sommer@ecitele.com>, Igor Danilovich <Igor.Danilovich@ecitele.com>
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
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
- 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