From rtg-bfd-bounces@ietf.org Wed Jul 2 22:49:58 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD0613A6CBC; Wed, 2 Jul 2008 22:49:58 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B6553A6CBC for ; Wed, 2 Jul 2008 22:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeaoeCq1bQHr for ; Wed, 2 Jul 2008 22:49:56 -0700 (PDT) Received: from mxout.qos.net.il (mxout.qos.net.il [91.143.233.135]) by core3.amsl.com (Postfix) with ESMTP id 446B73A6930 for ; Wed, 2 Jul 2008 22:49:56 -0700 (PDT) Received: by mxout.qos.net.il (Postfix, from userid 2002) id DAB3D73D576; Thu, 3 Jul 2008 08:35:51 +0300 (IDT) Received: from mail.axerra.com (webmail.axerra.com [80.74.100.75]) by mxout.qos.net.il (Postfix) with ESMTP id 8299973D16D for ; Thu, 3 Jul 2008 08:35:49 +0300 (IDT) 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_01C8DCD0.49A641C0" Subject: Timer Manipulation Date: Thu, 3 Jul 2008 08:49:58 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Timer Manipulation Thread-Index: Acjc0KBd5v9w3ceVS+WGAvj8KtAUzQ== From: "Avi Ezra" To: X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Jul 3 08:35:51 2008 X-DSPAM-Confidence: 0.9973 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 486c6537205451694518382 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8DCD0.49A641C0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Hi I have a question regarding the BFD protocol, In Bidirectional Forwarding Detection draft-ietf-bfd-based-08.txt=20 section 6.8.3 Timer Manipulation written: =20 When bfd.SessionState is not Up, the system MUST set bfd.DesiredMinTxInterval to a value of not less than one second (1,000,000 microseconds.) This is intended to ensure that the bandwidth consumed by BFD sessions that are not Up is negligible, particularly in the case where a neighbor may not be running BFD. =20 Please follow this scenario: 1. The Timer Negotiation is finished and the DesireMinTXInterval set to = 10 ms in both direction 2. The session is already in Up state for long time 3. There is a failure in the line and the session state goes to Down = state=20 =20 My question is: Do I have to set the DesireMinTXInterval to one second again and to send = BFD messages in one second interval? or can I continue to send BFD messages in 10 ms interval in order to get = fast detection of the line recovery=20 =20 Best Regards Avi Ezra =20 No virus found in this outgoing message. Checked by AVG.=20 Version: 7.5.524 / Virus Database: 270.4.3 - Release Date: 28/06/2008 = 00:00 =20 ------_=_NextPart_001_01C8DCD0.49A641C0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Hi
I have a = question regarding=20 the BFD protocol,
In = Bidirectional Forwarding=20 Detection draft-ietf-bfd-based-08.txt 
section 6.8.3 = Timer=20 Manipulation written:
 
When bfd.SessionState is not Up, the system MUST = set
   bfd.DesiredMinTxInterval to a value of not less than = one=20 second
   (1,000,000 microseconds.)  This is intended = to=20 ensure that the
   bandwidth consumed by BFD sessions that = are not=20 Up is negligible,
   particularly in the case where a = neighbor may=20 not be running BFD.
 
Please=20 follow this scenario:
1. The=20 Timer Negotiation is finished and the DesireMinTXInterval set to 10 ms = in both=20 direction
2. The session is already  in Up  state  for long=20 time
3. There=20 is a failure in the line and the session state goes to Down state 
 
My=20 question is:
Do I=20 have to set the DesireMinTXInterval to one second again and to send = BFD=20 messages in one second interval?
or can I=20 continue to send BFD messages in 10 ms interval in order to get = fast=20 detection of the line recovery
 
Best = Regards
Avi=20 Ezra
 

No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 270.4.3 - Release Date: 28/06/2008 = 00:00

------_=_NextPart_001_01C8DCD0.49A641C0-- From rtg-bfd-bounces@ietf.org Thu Jul 3 12:48:28 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B2CA3A6ACB; Thu, 3 Jul 2008 12:48:28 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66A343A68DD for ; Thu, 3 Jul 2008 12:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTNp0ClDwBEn for ; Thu, 3 Jul 2008 12:48:22 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id D963D3A6A60 for ; Thu, 3 Jul 2008 12:48:21 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Thu, 03 Jul 2008 12:48:06 PDT Received: from emailcorp3.jnpr.net ([66.129.254.13]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jul 2008 12:48:03 -0700 Received: from 172.23.4.103 ([172.23.4.103]) by emailcorp3.jnpr.net ([66.129.254.13]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Jul 2008 19:41:54 +0000 User-Agent: Microsoft-Entourage/12.0.0.071130 Date: Thu, 03 Jul 2008 12:43:44 -0700 Subject: Re: Timer Manipulation From: Nitin Bahadur To: Avi Ezra , Message-ID: Thread-Topic: Timer Manipulation Thread-Index: Acjc0KBd5v9w3ceVS+WGAvj8KtAUzQAdHm2a In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3297933825_570998" X-OriginalArrivalTime: 03 Jul 2008 19:48:03.0901 (UTC) FILETIME=[B4FCD6D0:01C8DD45] X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3297933825_570998 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Avi, Once the BFD session goes DOWN (or even to INIT), you need to set the BFD messages to 1sec. interval The BFD failure could be do to tons of reasons =AD BFD being deconfigured on peer router for instance. One should not continue to send packets at 10ms interval....since in DOWN state one doesn=B9t know at what rate the peer wants to accept packets at. Fast failure detection is only possible when the BFD session is UP. I see your point that there is a small time between the time when the BFD session comes UP and the time the intervals are reset to 10ms (from 1sec) and one won=B9t get fast failure detection in that interval, but I think that=B9s too much of a corner case to be worried about. You can try optimizing these corner cases with not resetting the interval, but it might start having other side-effects. Thanks Nitin On 7/2/08 10:49 PM, "Avi Ezra" wrote: > Hi > I have a question regarding the BFD protocol, > In Bidirectional Forwarding Detection draft-ietf-bfd-based-08.txt > section 6.8.3 Timer Manipulation written: > =20 > When bfd.SessionState is not Up, the system MUST set > bfd.DesiredMinTxInterval to a value of not less than one second > (1,000,000 microseconds.) This is intended to ensure that the > bandwidth consumed by BFD sessions that are not Up is negligible, > particularly in the case where a neighbor may not be running BFD. > =20 > Please follow this scenario: > 1. The Timer Negotiation is finished and the DesireMinTXInterval set to 1= 0 ms > in both direction > 2. The session is already in Up state for long time > 3. There is a failure in the line and the session state goes to Down stat= e > =20 > My question is: > Do I have to set the DesireMinTXInterval to one second again and to send = BFD > messages in one second interval? > or can I continue to send BFD messages in 10 ms interval in order to get = fast > detection of the line recovery > =20 > Best Regards > Avi Ezra > =20 >=20 >=20 > No virus found in this outgoing message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 270.4.3 - Release Date: 28/06/2008 00:= 00 > =20 >=20 --B_3297933825_570998 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: Timer Manipulation Hi Avi,

Once the BFD session goes DOWN (or even to INIT), you need to set the BFD m= essages to 1sec. interval
The BFD failure could be do to tons of reasons – BFD being deconfigur= ed on peer router for instance.

One should not continue to send packets at 10ms interval....since in DOWN s= tate one doesn’t know at what rate
the peer wants to accept packets at.

Fast failure detection is only possible when the BFD session is UP. I see y= our point that there is a small time between
the time when the BFD session comes UP and the time the intervals are reset= to 10ms (from 1sec)  and one won’t get fast failure detection in that  interval, but I think that’s too much of a corner case = to be worried about.

You can try optimizing these corner cases with not resetting the interval, = but it might start having other side-effects.

Thanks
Nitin

On 7/2/08 10:49 PM, "Avi Ezra" <avie@AXERRA.com> wrote:

Hi
I have a question regarding the BFD protocol,
In Bidirectional Forwarding Detection draft-ietf-bfd-based-08.txt
section 6.8.3 Timer Manipulation written:
When bfd.SessionState is not Up, the system MUST = set
   bfd.DesiredMinTxInterval to a value of not less than one = second
   (1,000,000 microseconds.)  This is intended to ensur= e that the
   bandwidth consumed by BFD sessions that are not Up is neg= ligible,
   particularly in the case where a neighbor may not be runn= ing BFD.
Please follow this scenario:
1. The Timer Negotiation is finished and the DesireMinTXInterval set to 10 = ms in both direction
2. The session is already  in Up  state  for long time
3. There is a failure in the line and the session state goes to Down state =

My question is:
Do I have to set the DesireMinTXInterval to one second again and to send BF= D messages in one second interval?
or can I continue to send BFD messages in 10 ms interval in order to get fa= st detection of the line recovery

Best Regards
Avi Ezra


No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 270.4.3 - Release Date: 28/06/2008 00:00=
 

--B_3297933825_570998-- From rtg-bfd-bounces@ietf.org Sat Jul 5 21:55:23 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 077E33A6827; Sat, 5 Jul 2008 21:55:23 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0A503A683D for ; Sat, 5 Jul 2008 21:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LUGCh3JE+AM for ; Sat, 5 Jul 2008 21:55:16 -0700 (PDT) Received: from mxout.qos.net.il (mxout.qos.net.il [91.143.233.135]) by core3.amsl.com (Postfix) with ESMTP id 649503A67A6 for ; Sat, 5 Jul 2008 21:55:14 -0700 (PDT) Received: by mxout.qos.net.il (Postfix, from userid 2002) id 3C88873D0E6; Sun, 6 Jul 2008 07:40:36 +0300 (IDT) Received: from mail.axerra.com (webmail.axerra.com [80.74.100.75]) by mxout.qos.net.il (Postfix) with ESMTP id 81C7973D0E4 for ; Sun, 6 Jul 2008 07:40:34 +0300 (IDT) 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_01C8DF24.21E854B0" Subject: RE: Timer Manipulation Date: Sun, 6 Jul 2008 07:55:16 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Timer Manipulation Thread-Index: Acjc0KBd5v9w3ceVS+WGAvj8KtAUzQAdHm2aAHehUWA= References: From: "Avi Ezra" To: "Nitin Bahadur" , X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Sun Jul 6 07:40:36 2008 X-DSPAM-Confidence: 0.9978 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 48704cc4190491519718915 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8DF24.21E854B0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Hi Nitin Thank you for your answer =20 My point is to achieve fast detection of the RECOVERY of the line. If I'll go to 1 sec. interval I'll achieve fast failure detection but = very slow detection of the recovery =20 Thanks Avi=20 _____ =20 From: Nitin Bahadur [mailto:nitinb@juniper.net]=20 Sent: Thursday, July 03, 2008 10:44 PM To: Avi Ezra; rtg-bfd@ietf.org Subject: Re: Timer Manipulation=20 Hi Avi, Once the BFD session goes DOWN (or even to INIT), you need to set the = BFD messages to 1sec. interval=20 The BFD failure could be do to tons of reasons =96 BFD being = deconfigured on peer router for instance. One should not continue to send packets at 10ms interval....since in = DOWN state one doesn=92t know at what rate the peer wants to accept packets at. Fast failure detection is only possible when the BFD session is UP. I = see your point that there is a small time between the time when the BFD session comes UP and the time the intervals are = reset to 10ms (from 1sec) and one won=92t get fast failure detection=20 in that interval, but I think that=92s too much of a corner case to be = worried about. You can try optimizing these corner cases with not resetting the = interval, but it might start having other side-effects. Thanks Nitin On 7/2/08 10:49 PM, "Avi Ezra" wrote: Hi I have a question regarding the BFD protocol, In Bidirectional Forwarding Detection draft-ietf-bfd-based-08.txt=20 section 6.8.3 Timer Manipulation written: When bfd.SessionState is not Up, the system MUST set bfd.DesiredMinTxInterval to a value of not less than one second (1,000,000 microseconds.) This is intended to ensure that the bandwidth consumed by BFD sessions that are not Up is negligible, particularly in the case where a neighbor may not be running BFD. Please follow this scenario: 1. The Timer Negotiation is finished and the DesireMinTXInterval set to = 10 ms in both direction 2. The session is already in Up state for long time 3. There is a failure in the line and the session state goes to Down = state=20 My question is: Do I have to set the DesireMinTXInterval to one second again and to send = BFD messages in one second interval? or can I continue to send BFD messages in 10 ms interval in order to get = fast detection of the line recovery=20 Best Regards Avi Ezra No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.4.3 - Release Date: 28/06/2008 = 00:00 =20 No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.4.5 - Release Date: 03/07/2008 = 00:00 No virus found in this outgoing message. Checked by AVG.=20 Version: 7.5.524 / Virus Database: 270.4.5/1536 - Release Date: = 05/07/2008 10:15 =20 ------_=_NextPart_001_01C8DF24.21E854B0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Re: Timer Manipulation
Hi=20 Nitin
Thank=20 you for your answer
 
My=20 point is to achieve fast detection of the RECOVERY of the=20 line.
If=20 I'll go to 1 sec. interval I'll achieve fast failure = detection=20 but very slow detection of the recovery
 
Thanks
Avi 

From: Nitin Bahadur = [mailto:nitinb@juniper.net]=20
Sent: Thursday, July 03, 2008 10:44 PM
To: Avi = Ezra;=20 rtg-bfd@ietf.org
Subject: Re: Timer Manipulation =

Hi Avi,

Once the BFD session goes DOWN = (or even=20 to INIT), you need to set the BFD messages to 1sec. interval
The BFD = failure=20 could be do to tons of reasons – BFD being deconfigured on peer = router for=20 instance.

One should not continue to send packets at 10ms=20 interval....since in DOWN state one doesn’t know at what = rate
the peer wants=20 to accept packets at.

Fast failure detection is only possible = when the=20 BFD session is UP. I see your point that there is a small time = between
the=20 time when the BFD session comes UP and the time the intervals are reset = to 10ms=20 (from 1sec)  and one won’t get fast failure detection
in = that=20  interval, but I think that’s too much of a corner case to be = worried=20 about.

You can try optimizing these corner cases with not = resetting the=20 interval, but it might start having other=20 side-effects.

Thanks
Nitin

On 7/2/08 10:49 PM, "Avi = Ezra"=20 <avie@AXERRA.com> wrote:
Hi
I have a question regarding the BFD protocol,
In = Bidirectional Forwarding Detection draft-ietf-bfd-based-08.txt =
section=20 6.8.3 Timer Manipulation written:

When=20 bfd.SessionState is not Up, the system MUST=20 set
   bfd.DesiredMinTxInterval to a value of not = less than=20 one second
   (1,000,000 microseconds.)  This = is=20 intended to ensure that the
   bandwidth consumed by = BFD=20 sessions that are not Up is = negligible,
   particularly in=20 the case where a neighbor may not be running BFD.

Please=20 follow this scenario:
1. The Timer Negotiation is finished and the=20 DesireMinTXInterval set to 10 ms in both direction
2. The session = is=20 already  in Up  state  for long time
3. There is a = failure=20 in the line and the session state goes to Down state

My=20 question is:
Do I have to set the DesireMinTXInterval to one second = again=20 and to send BFD messages in one second interval?
or can I continue = to send=20 BFD messages in 10 ms interval in order to get fast detection of the = line=20 recovery

Best=20 Regards
Avi Ezra



No virus found = in this=20 outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus = Database:=20 270.4.3 - Release Date: 28/06/2008=20 00:00
 


No virus found in this incoming message.
Checked by = AVG.
Version: 7.5.524 / Virus Database: 270.4.5 - Release Date: = 03/07/2008=20 00:00


No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 270.4.5/1536 - Release Date: = 05/07/2008 10:15

------_=_NextPart_001_01C8DF24.21E854B0-- From rtg-bfd-bounces@ietf.org Mon Jul 14 01:03:52 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0E683A6886; Mon, 14 Jul 2008 01:03:51 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B8C63A68A8 for ; Mon, 14 Jul 2008 01:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.714 X-Spam-Level: X-Spam-Status: No, score=-5.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUwd1jcrnAuP for ; Mon, 14 Jul 2008 01:03:44 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id AEE853A6886 for ; Mon, 14 Jul 2008 01:03:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,358,1212364800"; d="scan'208,217";a="52506405" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 14 Jul 2008 08:04:10 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6E84AuL029257; Mon, 14 Jul 2008 01:04:10 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6E84Acl016987; Mon, 14 Jul 2008 08:04:10 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 01:04:09 -0700 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_01C8E588.31D4C29F" Subject: RE: Timer Manipulation Date: Mon, 14 Jul 2008 01:06:39 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Timer Manipulation Thread-Index: Acjc0KBd5v9w3ceVS+WGAvj8KtAUzQAdHm2aAHehUWABmPyrUA== References: From: "Nobo Akiya (nobo)" To: "Avi Ezra" , "Nitin Bahadur" , X-OriginalArrivalTime: 14 Jul 2008 08:04:09.0895 (UTC) FILETIME=[321A3370:01C8E588] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12694; t=1216022650; x=1216886650; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=nobo@cisco.com; z=From:=20=22Nobo=20Akiya=20(nobo)=22=20 |Subject:=20RE=3A=20Timer=20Manipulation=20 |Sender:=20; bh=vtdPF66/EBl1nPVJmmvRs6PJH0dun6kRdUQT18Yx4WA=; b=nu0iMaTHowQzBnTF/zPnQPLVvoCNwstZmWg79uZrOxTknZ5XhyV62iitAB KSxux68cAaVRzW2V5oRtTEj9nBWwMeqj2osheeUXRX61EsuVwxT5eyHKiiDi e7VJP3i6JR; Authentication-Results: sj-dkim-2; header.From=nobo@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E588.31D4C29F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Avi. =20 Another point to consider is that if you allow BFD session to flap (UP->DOWN->UP) too fast, you maybe triggering two route convergences in a very short period of time. =20 - UP-> DOWN - Routes converge away from failed link. - DOWN -> UP - Routes converge back to original. =20 That could cause quite lot of churn at both system and network level, worse if the flapping continues. =20 Thanx, Nobo ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Avi Ezra Sent: Sunday, July 06, 2008 1:55 PM To: Nitin Bahadur; rtg-bfd@ietf.org Subject: RE: Timer Manipulation=20 =09 =09 Hi Nitin Thank you for your answer =20 My point is to achieve fast detection of the RECOVERY of the line. If I'll go to 1 sec. interval I'll achieve fast failure detection but very slow detection of the recovery =20 Thanks Avi=20 ________________________________ From: Nitin Bahadur [mailto:nitinb@juniper.net]=20 Sent: Thursday, July 03, 2008 10:44 PM To: Avi Ezra; rtg-bfd@ietf.org Subject: Re: Timer Manipulation=20 =09 =09 Hi Avi, =09 Once the BFD session goes DOWN (or even to INIT), you need to set the BFD messages to 1sec. interval=20 The BFD failure could be do to tons of reasons - BFD being deconfigured on peer router for instance. =09 One should not continue to send packets at 10ms interval....since in DOWN state one doesn't know at what rate the peer wants to accept packets at. =09 Fast failure detection is only possible when the BFD session is UP. I see your point that there is a small time between the time when the BFD session comes UP and the time the intervals are reset to 10ms (from 1sec) and one won't get fast failure detection=20 in that interval, but I think that's too much of a corner case to be worried about. =09 You can try optimizing these corner cases with not resetting the interval, but it might start having other side-effects. =09 Thanks Nitin =09 On 7/2/08 10:49 PM, "Avi Ezra" wrote: =09 =09 Hi I have a question regarding the BFD protocol, In Bidirectional Forwarding Detection draft-ietf-bfd-based-08.txt=20 section 6.8.3 Timer Manipulation written: =09 When bfd.SessionState is not Up, the system MUST set bfd.DesiredMinTxInterval to a value of not less than one second (1,000,000 microseconds.) This is intended to ensure that the bandwidth consumed by BFD sessions that are not Up is negligible, particularly in the case where a neighbor may not be running BFD. =09 Please follow this scenario: 1. The Timer Negotiation is finished and the DesireMinTXInterval set to 10 ms in both direction 2. The session is already in Up state for long time 3. There is a failure in the line and the session state goes to Down state=20 =09 My question is: Do I have to set the DesireMinTXInterval to one second again and to send BFD messages in one second interval? or can I continue to send BFD messages in 10 ms interval in order to get fast detection of the line recovery=20 =09 Best Regards Avi Ezra =09 =09 =09 No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.4.3 - Release Date: 28/06/2008 00:00 =20 =09 =09 No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.4.5 - Release Date: 03/07/2008 00:00 =09 No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.4.5/1536 - Release Date: 05/07/2008 10:15 =09 ------_=_NextPart_001_01C8E588.31D4C29F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: Timer Manipulation
Hello Avi.
 
Another point to consider is that if you allow = BFD session=20 to flap (UP->DOWN->UP) too fast, you maybe triggering two route=20 convergences in a very short period of time.
 
    - UP-> DOWN - Routes = converge away=20 from failed link.
    - DOWN -> UP - Routes = converge back=20 to original.
 
That could cause quite lot of churn at both = system and=20 network level, worse if the flapping continues.
 
Thanx,
Nobo

From: rtg-bfd-bounces@ietf.org=20 [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Avi = Ezra
Sent:=20 Sunday, July 06, 2008 1:55 PM
To: Nitin Bahadur;=20 rtg-bfd@ietf.org
Subject: RE: Timer Manipulation=20

Hi=20 Nitin
Thank you for your answer
 
My=20 point is to achieve fast detection of the RECOVERY of the=20 line.
If=20 I'll go to 1 sec. interval I'll achieve fast failure = detection=20 but very slow detection of the recovery
 
Thanks
Avi 

From: Nitin Bahadur=20 [mailto:nitinb@juniper.net]
Sent: Thursday, July 03, 2008 = 10:44=20 PM
To: Avi Ezra; rtg-bfd@ietf.org
Subject: Re: = Timer=20 Manipulation

Hi Avi,

Once the BFD session goes = DOWN (or even=20 to INIT), you need to set the BFD messages to 1sec. interval
The = BFD=20 failure could be do to tons of reasons – BFD being deconfigured = on peer router=20 for instance.

One should not continue to send packets at 10ms=20 interval....since in DOWN state one doesn’t know at what = rate
the peer=20 wants to accept packets at.

Fast failure detection is only = possible=20 when the BFD session is UP. I see your point that there is a small = time=20 between
the time when the BFD session comes UP and the time the = intervals=20 are reset to 10ms (from 1sec)  and one won’t get fast = failure detection=20
in that  interval, but I think that’s too much of a = corner case to be=20 worried about.

You can try optimizing these corner cases with = not=20 resetting the interval, but it might start having other=20 side-effects.

Thanks
Nitin

On 7/2/08 10:49 PM, "Avi = Ezra"=20 <avie@AXERRA.com> wrote:
Hi
I have a question regarding the BFD = protocol,
In=20 Bidirectional Forwarding Detection draft-ietf-bfd-based-08.txt =
section=20 6.8.3 Timer Manipulation written:

When=20 bfd.SessionState is not Up, the system MUST=20 set
   bfd.DesiredMinTxInterval to a value of not = less=20 than one second
   (1,000,000 microseconds.) =  This is=20 intended to ensure that the
   bandwidth consumed = by BFD=20 sessions that are not Up is = negligible,
   particularly in=20 the case where a neighbor may not be running BFD.

Please=20 follow this scenario:
1. The Timer Negotiation is finished and = the=20 DesireMinTXInterval set to 10 ms in both direction
2. The session = is=20 already  in Up  state  for long time
3. There is a = failure=20 in the line and the session state goes to Down state =

My=20 question is:
Do I have to set the DesireMinTXInterval to one = second again=20 and to send BFD messages in one second interval?
or can I = continue to=20 send BFD messages in 10 ms interval in order to get fast detection = of the=20 line recovery

Best=20 Regards
Avi Ezra



No virus = found in this=20 outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus = Database:=20 270.4.3 - Release Date: 28/06/2008=20 00:00
 


No virus found in this incoming message.
Checked = by=20 AVG.
Version: 7.5.524 / Virus Database: 270.4.5 - Release Date: = 03/07/2008=20 00:00


No virus found in this outgoing message.
Checked = by=20 AVG.
Version: 7.5.524 / Virus Database: 270.4.5/1536 - Release = Date:=20 05/07/2008 10:15

------_=_NextPart_001_01C8E588.31D4C29F-- From rtg-bfd-bounces@ietf.org Mon Jul 14 04:44:07 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D863A6A26; Mon, 14 Jul 2008 04:44:07 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E58603A6A26 for ; Mon, 14 Jul 2008 04:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.786 X-Spam-Level: X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZGAlvrFECDD for ; Mon, 14 Jul 2008 04:43:59 -0700 (PDT) Received: from eci-iron1.ecitele.com (eci-iron1.ecitele.com [147.234.242.117]) by core3.amsl.com (Postfix) with ESMTP id 1EE9B3A6783 for ; Mon, 14 Jul 2008 04:43:57 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 14 Jul 2008 15:05:50 +0300 Received: from ilptexch01.ecitele.com ([172.31.244.40]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 14:44:19 +0300 Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Mon, 14 Jul 2008 14:44:17 +0300 From: Alexander Vainshtein To: "Nobo Akiya (nobo)" , Avi Ezra Date: Mon, 14 Jul 2008 14:44:16 +0300 Subject: RE: Timer Manipulation Thread-Topic: Timer Manipulation Thread-Index: Acjc0KBd5v9w3ceVS+WGAvj8KtAUzQAdHm2aAHehUWABmPyrUAAHvfkA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76801DE571C5ILPTMAIL02eci_" MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jul 2008 11:44:19.0359 (UTC) FILETIME=[F38E72F0:01C8E5A6] Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --_000_A3C5DF08D38B6049839A6F553B331C76801DE571C5ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Avi, Nobo and all, I concur with Nobo's comment. It is quite customary to stabilize DOWN-->UP = transitions in order to prevent flapping. Regards, Sasha ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Nobo Akiya (nobo) Sent: Monday, July 14, 2008 11:07 AM To: Avi Ezra; Nitin Bahadur; rtg-bfd@ietf.org Subject: RE: Timer Manipulation Hello Avi. Another point to consider is that if you allow BFD session to flap (UP->DOW= N->UP) too fast, you maybe triggering two route convergences in a very shor= t period of time. - UP-> DOWN - Routes converge away from failed link. - DOWN -> UP - Routes converge back to original. That could cause quite lot of churn at both system and network level, worse= if the flapping continues. Thanx, Nobo ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Avi Ezra Sent: Sunday, July 06, 2008 1:55 PM To: Nitin Bahadur; rtg-bfd@ietf.org Subject: RE: Timer Manipulation Hi Nitin Thank you for your answer My point is to achieve fast detection of the RECOVERY of the line. If I'll go to 1 sec. interval I'll achieve fast failure detection but very = slow detection of the recovery Thanks Avi ________________________________ From: Nitin Bahadur [mailto:nitinb@juniper.net] Sent: Thursday, July 03, 2008 10:44 PM To: Avi Ezra; rtg-bfd@ietf.org Subject: Re: Timer Manipulation Hi Avi, Once the BFD session goes DOWN (or even to INIT), you need to set the BFD m= essages to 1sec. interval The BFD failure could be do to tons of reasons - BFD being deconfigured on = peer router for instance. One should not continue to send packets at 10ms interval....since in DOWN s= tate one doesn't know at what rate the peer wants to accept packets at. Fast failure detection is only possible when the BFD session is UP. I see y= our point that there is a small time between the time when the BFD session comes UP and the time the intervals are reset= to 10ms (from 1sec) and one won't get fast failure detection in that interval, but I think that's too much of a corner case to be worri= ed about. You can try optimizing these corner cases with not resetting the interval, = but it might start having other side-effects. Thanks Nitin On 7/2/08 10:49 PM, "Avi Ezra" wrote: Hi I have a question regarding the BFD protocol, In Bidirectional Forwarding Detection draft-ietf-bfd-based-08.txt section 6.8.3 Timer Manipulation written: When bfd.SessionState is not Up, the system MUST set bfd.DesiredMinTxInterval to a value of not less than one second (1,000,000 microseconds.) This is intended to ensure that the bandwidth consumed by BFD sessions that are not Up is negligible, particularly in the case where a neighbor may not be running BFD. Please follow this scenario: 1. The Timer Negotiation is finished and the DesireMinTXInterval set to 10 = ms in both direction 2. The session is already in Up state for long time 3. There is a failure in the line and the session state goes to Down state My question is: Do I have to set the DesireMinTXInterval to one second again and to send BF= D messages in one second interval? or can I continue to send BFD messages in 10 ms interval in order to get fa= st detection of the line recovery Best Regards Avi Ezra No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.4.3 - Release Date: 28/06/2008 00:00 No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.4.5 - Release Date: 03/07/2008 00:00 No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.4.5/1536 - Release Date: 05/07/2008 = 10:15 --_000_A3C5DF08D38B6049839A6F553B331C76801DE571C5ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: Timer Manipulation
Avi,=20 Nobo and all,
I=20 concur with Nobo's comment. It is quite customary to stabilize DOWN-->UP= =20 transitions in order to prevent flapping.
 
Regards,
    Sasha
 

From: rtg-bfd-bounces@ietf.org=20 [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya=20 (nobo)
Sent: Monday, July 14, 2008 11:07 AM
To: Avi E= zra;=20 Nitin Bahadur; rtg-bfd@ietf.org
Subject: RE: Timer Manipulation= =20

Hello Avi.
 
Another point to consider is that if you allow B= FD=20 session to flap (UP->DOWN->UP) too fast, you maybe triggering two r= oute=20 convergences in a very short period of time.
 
    - UP-> DOWN - Routes conve= rge away=20 from failed link.
    - DOWN -> UP - Routes conv= erge back=20 to original.
 
That could cause quite lot of churn at both syst= em and=20 network level, worse if the flapping continues.
 
Thanx,
Nobo

From: rtg-bfd-bounces@ietf.org=20 [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Avi=20 Ezra
Sent: Sunday, July 06, 2008 1:55 PM
To: Nitin= =20 Bahadur; rtg-bfd@ietf.org
Subject: RE: Timer Manipulation=20

Hi=20 Nitin
Thank you for your answer
 
My=20 point is to achieve fast detection of the RECOVERY of the=20 line.
If=20 I'll go to 1 sec. interval I'll achieve fast failure=20 detection but very slow detection of the recovery
 
Thanks
Avi 

From: Nitin Bahadur=20 [mailto:nitinb@juniper.net]
Sent: Thursday, July 03, 2008 10= :44=20 PM
To: Avi Ezra; rtg-bfd@ietf.org
Subject: Re: Time= r=20 Manipulation

Hi=20 Avi,

Once the BFD session goes DOWN (or even to INIT), you need = to=20 set the BFD messages to 1sec. interval
The BFD failure could be do = to=20 tons of reasons – BFD being deconfigured on peer router for=20 instance.

One should not continue to send packets at 10ms=20 interval....since in DOWN state one doesn’t know at what rate
= the peer=20 wants to accept packets at.

Fast failure detection is only possi= ble=20 when the BFD session is UP. I see your point that there is a small time= =20 between
the time when the BFD session comes UP and the time the inte= rvals=20 are reset to 10ms (from 1sec)  and one won’t get fast failur= e detection=20
in that  interval, but I think that’s too much of a corn= er case to=20 be worried about.

You can try optimizing these corner cases with= not=20 resetting the interval, but it might start having other=20 side-effects.

Thanks
Nitin

On 7/2/08 10:49 PM, "Avi Ez= ra"=20 <avie@AXERRA.com> wrote:
Hi
I have a question regarding the BFD protocol,
I= n=20 Bidirectional Forwarding Detection draft-ietf-bfd-based-08.txt
se= ction=20 6.8.3 Timer Manipulation written:

When=20 bfd.SessionState is not Up, the system MUST=20 set
   bfd.DesiredMinTxInterval to a value of not l= ess=20 than one second
   (1,000,000 microseconds.)  = This=20 is intended to ensure that the
   bandwidth consume= d by=20 BFD sessions that are not Up is=20 negligible,
   particularly in the case where a nei= ghbor=20 may not be running BFD.

Please follow this scenario:
1. The Timer Negotiation= is=20 finished and the DesireMinTXInterval set to 10 ms in both direction2.=20 The session is already  in Up  state  for long time3.=20 There is a failure in the line and the session state goes to Down sta= te=20

My=20 question is:
Do I have to set the DesireMinTXInterval to one secon= d=20 again and to send BFD messages in one second interval?
or can I=20 continue to send BFD messages in 10 ms interval in order to get fast= =20 detection of the line recovery

Best=20 Regards
Avi Ezra



No virus foun= d in=20 this outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus= =20 Database: 270.4.3 - Release Date: 28/06/2008=20 00:00
 


No virus found in this incoming message.
Checked b= y=20 AVG.
Version: 7.5.524 / Virus Database: 270.4.5 - Release Date:=20 03/07/2008 00:00


No virus found in this outgoing message.
Checked b= y=20 AVG.
Version: 7.5.524 / Virus Database: 270.4.5/1536 - Release Date:= =20 05/07/2008 10:15

--_000_A3C5DF08D38B6049839A6F553B331C76801DE571C5ILPTMAIL02eci_-- From rtg-bfd-bounces@ietf.org Mon Jul 14 06:20:39 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 212E128C0CE; Mon, 14 Jul 2008 06:20:39 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C77CE28C0CE for ; Mon, 14 Jul 2008 06:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iv8JLY+tUn2N for ; Mon, 14 Jul 2008 06:20:37 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 6A5F03A6A46 for ; Mon, 14 Jul 2008 06:20:37 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6EDL2PH012361 for ; Mon, 14 Jul 2008 09:21:02 -0400 Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6EDL2sx012345; Mon, 14 Jul 2008 09:21:02 -0400 Received: from IMCSRV5.MITRE.ORG ([129.83.20.200]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 09:21:01 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Timer Manipulation Date: Mon, 14 Jul 2008 09:17:52 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Timer Manipulation Thread-Index: Acjc0KBd5v9w3ceVS+WGAvj8KtAUzQAdHm2aAHehUWABmPyrUAAHvfkAAAK1DYA= References: From: "Nakamoto, Glen" To: "Alexander Vainshtein" , "Nobo Akiya (nobo)" , "Avi Ezra" X-OriginalArrivalTime: 14 Jul 2008 13:21:01.0835 (UTC) FILETIME=[761A05B0:01C8E5B4] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org We have an application where we are simulating two radios (with different transceiver characteristics) on a mobile platform where rapid flapping may be a desired trait (however, this is very much localized to prevent spread). In our scenario, we are using static routes (one high and the other low) to traverse this RF chasm. We are working on the assumption that one of the two radios will be available close to 100% of the time even though a single radio can be interrupted regularly (due to obstructions such as buildings or trees). Our model has a preferred path (lower cost $$) and a secondary path ($$/byte). As such we would like to use the preferred path as much as possible and only use the secondary path when the preferred path is unavailable. We have coded up a Linux box with BFD that talks to the RF side and when the signal is about to cut, we "shut down" the BFD with the Cisco router (which uses the higher cost static route to the other radio in about 150 ms (3 X 50 ms). While we haven't done so yet, we also plan on sending a signal to the other peer Linux box to inform them that we are doing the switch. When the preferred path signal is good for some time period (TBD), we reactivate the BFD (Linux box talking to Cisco) and the router switches back in 10 ms (preferred path goes UP). We can switch back and forth very rapidly (every few seconds or less) and maintain a fairly stable communication link between the two radio links. Even when terminated abruptly (pull the plug so to speak), we lose about 15 packets (at 1.5 Mbps) vice thousands if waiting on optimized OSPF to detect the failure. We are still trying to figure out if we can "drop" the link in 50 ms or less (rather than the 3 failures of 50 ms). This is a very specialized situation (and somewhat constrained) and I wouldn't recommend it in general but it does seem to work (so far) in our experiments in rapid detection and recovery for mobile platforms that support multihoming. We are currently looking at other "failure" modes to see what other troubles we may get into. If anyone has been doing any work with BFD in mobile situations, I would appreciate any feedback. Glen ... -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Monday, July 14, 2008 7:44 AM To: Nobo Akiya (nobo); Avi Ezra Cc: rtg-bfd@ietf.org Subject: RE: Timer Manipulation=20 Avi, Nobo and all, I concur with Nobo's comment. It is quite customary to stabilize DOWN-->UP transitions in order to prevent flapping. =20 Regards, Sasha =20 ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (nobo) Sent: Monday, July 14, 2008 11:07 AM To: Avi Ezra; Nitin Bahadur; rtg-bfd@ietf.org Subject: RE: Timer Manipulation=20 =09 Hello Avi. =20 Another point to consider is that if you allow BFD session to flap (UP->DOWN->UP) too fast, you maybe triggering two route convergences in a very short period of time. =20 - UP-> DOWN - Routes converge away from failed link. - DOWN -> UP - Routes converge back to original. =20 That could cause quite lot of churn at both system and network level, worse if the flapping continues. =20 Thanx, Nobo ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Avi Ezra Sent: Sunday, July 06, 2008 1:55 PM To: Nitin Bahadur; rtg-bfd@ietf.org Subject: RE: Timer Manipulation=20 =09 =09 Hi Nitin Thank you for your answer =20 My point is to achieve fast detection of the RECOVERY of the line. If I'll go to 1 sec. interval I'll achieve fast failure detection but very slow detection of the recovery =20 Thanks Avi=20 ________________________________ From: Nitin Bahadur [mailto:nitinb@juniper.net]=20 Sent: Thursday, July 03, 2008 10:44 PM To: Avi Ezra; rtg-bfd@ietf.org Subject: Re: Timer Manipulation=20 =09 =09 Hi Avi, =09 Once the BFD session goes DOWN (or even to INIT), you need to set the BFD messages to 1sec. interval=20 The BFD failure could be do to tons of reasons - BFD being deconfigured on peer router for instance. =09 One should not continue to send packets at 10ms interval....since in DOWN state one doesn't know at what rate the peer wants to accept packets at. =09 Fast failure detection is only possible when the BFD session is UP. I see your point that there is a small time between the time when the BFD session comes UP and the time the intervals are reset to 10ms (from 1sec) and one won't get fast failure detection=20 in that interval, but I think that's too much of a corner case to be worried about. =09 You can try optimizing these corner cases with not resetting the interval, but it might start having other side-effects. =09 Thanks Nitin =09 On 7/2/08 10:49 PM, "Avi Ezra" wrote: =09 =09 Hi I have a question regarding the BFD protocol, In Bidirectional Forwarding Detection draft-ietf-bfd-based-08.txt=20 section 6.8.3 Timer Manipulation written: =09 When bfd.SessionState is not Up, the system MUST set bfd.DesiredMinTxInterval to a value of not less than one second (1,000,000 microseconds.) This is intended to ensure that the bandwidth consumed by BFD sessions that are not Up is negligible, particularly in the case where a neighbor may not be running BFD. =09 Please follow this scenario: 1. The Timer Negotiation is finished and the DesireMinTXInterval set to 10 ms in both direction 2. The session is already in Up state for long time 3. There is a failure in the line and the session state goes to Down state=20 =09 My question is: Do I have to set the DesireMinTXInterval to one second again and to send BFD messages in one second interval? or can I continue to send BFD messages in 10 ms interval in order to get fast detection of the line recovery=20 =09 Best Regards Avi Ezra =09 =09 =09 No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.4.3 - Release Date: 28/06/2008 00:00 =20 =09 =09 No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.4.5 - Release Date: 03/07/2008 00:00 =09 No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.4.5/1536 - Release Date: 05/07/2008 10:15 =09 From rtg-bfd-bounces@ietf.org Mon Jul 14 16:48:00 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 134B53A6A41; Mon, 14 Jul 2008 16:48:00 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30FA43A6AA1 for ; Mon, 14 Jul 2008 16:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.318 X-Spam-Level: X-Spam-Status: No, score=-4.318 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eF8vrybDdpBa for ; Mon, 14 Jul 2008 16:47:56 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 093323A68EC for ; Mon, 14 Jul 2008 16:47:56 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Mon, 14 Jul 2008 16:47:03 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 16:47:47 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 16:47:47 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 16:47:46 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6ENljx82251; Mon, 14 Jul 2008 16:47:45 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-Id: From: Dave Katz To: Alexander Vainshtein In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-1--598619700 Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Timer Manipulation Date: Mon, 14 Jul 2008 17:47:45 -0600 References: X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 14 Jul 2008 23:47:46.0909 (UTC) FILETIME=[0478F0D0:01C8E60C] Cc: "rtg-bfd@ietf.org" , Avi Ezra X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --Apple-Mail-1--598619700 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Note that the spec explicitly allows for rapid exchange of BFD packets =20= if the contents are changing (typically state transitions)--see =20 section 6.8.7. There is nothing in the spec blocking the rapid =20 reestablishment of a BFD session. As others have mentioned, the point of slowing down the transmit =20 interval is to not spew BFD packets when the other guy is dead, or has =20= BFD turned off, etc. Sending BFD packets at 10 msec intervals =20 indefinitely after a session failure would be a bad thing. --Dave On Jul 14, 2008, at 5:44 AM, Alexander Vainshtein wrote: > Avi, Nobo and all, > I concur with Nobo's comment. It is quite customary to stabilize =20 > DOWN-->UP transitions in order to prevent flapping. > > Regards, > Sasha > > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On =20= > Behalf Of Nobo Akiya (nobo) > Sent: Monday, July 14, 2008 11:07 AM > To: Avi Ezra; Nitin Bahadur; rtg-bfd@ietf.org > Subject: RE: Timer Manipulation > > Hello Avi. > > Another point to consider is that if you allow BFD session to flap =20 > (UP->DOWN->UP) too fast, you maybe triggering two route convergences =20= > in a very short period of time. > > - UP-> DOWN - Routes converge away from failed link. > - DOWN -> UP - Routes converge back to original. > > That could cause quite lot of churn at both system and network =20 > level, worse if the flapping continues. > > Thanx, > Nobo > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On =20= > Behalf Of Avi Ezra > Sent: Sunday, July 06, 2008 1:55 PM > To: Nitin Bahadur; rtg-bfd@ietf.org > Subject: RE: Timer Manipulation > > Hi Nitin > Thank you for your answer > > My point is to achieve fast detection of the RECOVERY of the line. > If I'll go to 1 sec. interval I'll achieve fast failure detection =20 > but very slow detection of the recovery > > Thanks > Avi > > From: Nitin Bahadur [mailto:nitinb@juniper.net] > Sent: Thursday, July 03, 2008 10:44 PM > To: Avi Ezra; rtg-bfd@ietf.org > Subject: Re: Timer Manipulation > > Hi Avi, > > Once the BFD session goes DOWN (or even to INIT), you need to set =20 > the BFD messages to 1sec. interval > The BFD failure could be do to tons of reasons =96 BFD being =20 > deconfigured on peer router for instance. > > One should not continue to send packets at 10ms interval....since in =20= > DOWN state one doesn=92t know at what rate > the peer wants to accept packets at. > > Fast failure detection is only possible when the BFD session is UP. =20= > I see your point that there is a small time between > the time when the BFD session comes UP and the time the intervals =20 > are reset to 10ms (from 1sec) and one won=92t get fast failure =20 > detection > in that interval, but I think that=92s too much of a corner case to =20= > be worried about. > > You can try optimizing these corner cases with not resetting the =20 > interval, but it might start having other side-effects. > > Thanks > Nitin > > On 7/2/08 10:49 PM, "Avi Ezra" wrote: > > Hi > I have a question regarding the BFD protocol, > In Bidirectional Forwarding Detection draft-ietf-bfd-based-08.txt > section 6.8.3 Timer Manipulation written: > > When bfd.SessionState is not Up, the system MUST set > bfd.DesiredMinTxInterval to a value of not less than one second > (1,000,000 microseconds.) This is intended to ensure that the > bandwidth consumed by BFD sessions that are not Up is negligible, > particularly in the case where a neighbor may not be running BFD. > > Please follow this scenario: > 1. The Timer Negotiation is finished and the DesireMinTXInterval set =20= > to 10 ms in both direction > 2. The session is already in Up state for long time > 3. There is a failure in the line and the session state goes to Down =20= > state > > My question is: > Do I have to set the DesireMinTXInterval to one second again and to =20= > send BFD messages in one second interval? > or can I continue to send BFD messages in 10 ms interval in order to =20= > get fast detection of the line recovery > > Best Regards > Avi Ezra > > > > No virus found in this outgoing message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 270.4.3 - Release Date: =20 > 28/06/2008 00:00 > > > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 270.4.5 - Release Date: =20 > 03/07/2008 00:00 > > > No virus found in this outgoing message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 270.4.5/1536 - Release Date: =20 > 05/07/2008 10:15 > --Apple-Mail-1--598619700 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Note that the spec explicitly = allows for rapid exchange of BFD packets if the contents are changing = (typically state transitions)--see section 6.8.7.  There is nothing = in the spec blocking the rapid reestablishment of a BFD = session.

As others have mentioned, the point of = slowing down the transmit interval is to not spew BFD packets when the = other guy is dead, or has BFD turned off, etc.  Sending BFD packets = at 10 msec intervals indefinitely after a session failure would be a bad = thing.

--Dave


<= div>On Jul 14, 2008, at 5:44 AM, Alexander Vainshtein wrote:

=
Avi, Nobo and all,
=
I concur with Nobo's comment. It is quite = customary to stabilize DOWN-->UP transitions in order to prevent = flapping.
 
=
Regards,
    = Sasha
 

=
From: = rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (nobo)
Sent: Monday, July = 14, 2008 11:07 AM
To: Avi Ezra; Nitin Bahadur; rtg-bfd@ietf.org
Subject: = RE: Timer Manipulation

Hello Avi.
 
Another point to consider is that if you allow BFD session = to flap (UP->DOWN->UP) too fast, you maybe triggering two route = convergences in a very short period of time.
=
 
    - UP-> DOWN - Routes converge away from = failed link.
    - DOWN -> UP - Routes converge back to = original.
 
That could cause quite lot of churn at both system and = network level, worse if the flapping continues.
=
 
Thanx,
Nobo

From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Avi Ezra
Sent: Sunday, July 06, = 2008 1:55 PM
To: Nitin Bahadur; rtg-bfd@ietf.org
Subject: = RE: Timer Manipulation

=
Hi Nitin
=
Thank you for your = answer
 
My point is to achieve fast detection of the RECOVERY of = the line.
If I'll go to 1 sec. interval I'll achieve = fast failure detection but very slow detection of the = recovery
 
Thanks
Avi 

=
From: = Nitin Bahadur [mailto:nitinb@juniper.net] =
Sent: Thursday, July 03, 2008 10:44 PM
To: Avi = Ezra; rtg-bfd@ietf.org
Subject: = Re: Timer Manipulation

Hi Avi,

Once the BFD session goes = DOWN (or even to INIT), you need to set the BFD messages to 1sec. = interval
The BFD failure could be do to tons of reasons =E2=80=93 = BFD being deconfigured on peer router for instance.

One = should not continue to send packets at 10ms interval....since in = DOWN state one doesn=E2=80=99t know at what rate
the peer wants = to accept packets at.

Fast failure detection is only possible = when the BFD session is UP. I see your point that there is a small time = between
the time when the BFD session comes UP and the time the = intervals are reset to 10ms (from 1sec)  and one won=E2=80=99t = get fast failure detection
in that  interval, but I think = that=E2=80=99s too much of a corner case to be worried = about.

You can try optimizing these corner cases with not = resetting the interval, but it might start having other = side-effects.

Thanks
Nitin

On 7/2/08 10:49 PM, "Avi = Ezra" <avie@AXERRA.com> = wrote:
Hi
I have a question = regarding the BFD protocol,
In Bidirectional Forwarding = Detection draft-ietf-bfd-based-08.txt
section 6.8.3 Timer = Manipulation written:

When = bfd.SessionState is not Up, the system MUST = set
   bfd.DesiredMinTxInterval to a value of not less = than one second
   (1,000,000 microseconds.) =  This is intended to ensure that = the
   bandwidth consumed by BFD sessions that = are not Up is negligible,
   particularly in the = case where a neighbor may not be running BFD.

Please follow this scenario:
1. The Timer Negotiation = is finished and the DesireMinTXInterval set to 10 ms in both = direction
2. The session is already  in Up  state =  for long time
3. There is a failure in the line and the = session state goes to Down state

My = question is:
Do I have to set the DesireMinTXInterval to one second = again and to send BFD messages in one second interval?
or can I = continue to send BFD messages in 10 ms interval in order to get fast = detection of the line recovery

Best = Regards
Avi Ezra



No virus found in this outgoing = message.
Checked by AVG.
Version: 7.5.524 / Virus Database: = 270.4.3 - Release Date: 28/06/2008 = 00:00
 


No virus found in this incoming message.
Checked by = AVG.
Version: 7.5.524 / Virus Database: 270.4.5 - Release Date: = 03/07/2008 00:00


No virus found in = this outgoing message.
Checked by AVG.
Version: 7.5.524 / = Virus Database: 270.4.5/1536 - Release Date: 05/07/2008 = 10:15

= --Apple-Mail-1--598619700-- From rtg-bfd-bounces@ietf.org Wed Jul 16 23:23:55 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DA933A69FC; Wed, 16 Jul 2008 23:23:55 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163FA3A69FC for ; Wed, 16 Jul 2008 23:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.856 X-Spam-Level: X-Spam-Status: No, score=-0.856 tagged_above=-999 required=5 tests=[AWL=0.858, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HC1oLq2t-9r for ; Wed, 16 Jul 2008 23:23:45 -0700 (PDT) Received: from mxout.qos.net.il (mxout.qos.net.il [91.143.233.135]) by core3.amsl.com (Postfix) with ESMTP id 115613A6858 for ; Wed, 16 Jul 2008 23:23:43 -0700 (PDT) Received: by mxout.qos.net.il (Postfix, from userid 2002) id 6DA2C73CCE8; Thu, 17 Jul 2008 09:07:49 +0300 (IDT) Received: from mail.axerra.com (webmail.axerra.com [80.74.100.75]) by mxout.qos.net.il (Postfix) with ESMTP id C868473CCF0 for ; Thu, 17 Jul 2008 09:07:39 +0300 (IDT) 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_01C8E7D5.5C8D9BB6" Subject: RE: Timer Manipulation Date: Thu, 17 Jul 2008 09:24:13 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Timer Manipulation Thread-Index: AcjmC9s65hvxYWNMRgCpfjFkSvz0JgBvv+cw References: From: "Avi Ezra" To: "Dave Katz" , "Alexander Vainshtein" X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Jul 17 09:07:49 2008 X-DSPAM-Confidence: 0.9992 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 487ee1b533078136517209 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E7D5.5C8D9BB6 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Hi The BFD protocol concentrate in the detection of failure of the = connection between the two ends, it gives us all the options to set the = speed of failure detection, i.e Tx/Rx interval and Detect time = multiplier. BUT=20 In other hand the protocol not gives us any option to determine the = speed of recovery detection (MUST to resume with 1 second).=20 Why not to give to the APPLICATION the decision how rapidly it want to = detect the recovery of the line, It can be done by it decision to use = this connection only after a receiving X times UP packets to prevent = flapping.=20 I'm not worry to spew BFD packets to a dead or turned off system in the = same rate like I sent before the failure, it is not harm the system and = it not harm the network since I did it few second ago in double rate (Tx = packets from both ends), Just to mention that the packets rate = determined by the capabilities of both ends and not by the network = capability. =20 Some applications have no redundant path and when the session is Down = there is no service, because of that I need to get the Up state very = fast to resume the services even if I'll get some flaps. =20 ...Avi =20 _____ =20 From: Dave Katz [mailto:dkatz@juniper.net]=20 Sent: Tuesday, July 15, 2008 2:48 AM To: Alexander Vainshtein Cc: Nobo Akiya (nobo); Avi Ezra; rtg-bfd@ietf.org Subject: Re: Timer Manipulation=20 Note that the spec explicitly allows for rapid exchange of BFD packets = if the contents are changing (typically state transitions)--see section = 6.8.7. There is nothing in the spec blocking the rapid reestablishment = of a BFD session.=20 As others have mentioned, the point of slowing down the transmit = interval is to not spew BFD packets when the other guy is dead, or has = BFD turned off, etc. Sending BFD packets at 10 msec intervals = indefinitely after a session failure would be a bad thing. --Dave On Jul 14, 2008, at 5:44 AM, Alexander Vainshtein wrote: Avi, Nobo and all, I concur with Nobo's comment. It is quite customary to stabilize = DOWN-->UP transitions in order to prevent flapping. =20 Regards, Sasha =20 _____ =20 From: rtg-bfd-bounces@ietf.org [HYPERLINK = "mailto:rtg-bfd-bounces@ietf.org"mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Nobo Akiya (nobo) Sent: Monday, July 14, 2008 11:07 AM To: Avi Ezra; Nitin Bahadur; HYPERLINK = "mailto:rtg-bfd@ietf.org"rtg-bfd@ietf.org Subject: RE: Timer Manipulation=20 Hello Avi. =20 Another point to consider is that if you allow BFD session to flap = (UP->DOWN->UP) too fast, you maybe triggering two route convergences in = a very short period of time. =20 - UP-> DOWN - Routes converge away from failed link. - DOWN -> UP - Routes converge back to original. =20 That could cause quite lot of churn at both system and network level, = worse if the flapping continues. =20 Thanx, Nobo _____ =20 From: rtg-bfd-bounces@ietf.org [HYPERLINK = "mailto:rtg-bfd-bounces@ietf.org"mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Avi Ezra Sent: Sunday, July 06, 2008 1:55 PM To: Nitin Bahadur; HYPERLINK "mailto:rtg-bfd@ietf.org"rtg-bfd@ietf.org Subject: RE: Timer Manipulation=20 Hi Nitin Thank you for your answer =20 My point is to achieve fast detection of the RECOVERY of the line. If I'll go to 1 sec. interval I'll achieve fast failure detection but = very slow detection of the recovery =20 Thanks Avi=20 _____ =20 From: Nitin Bahadur [HYPERLINK = "mailto:nitinb@juniper.net"mailto:nitinb@juniper.net]=20 Sent: Thursday, July 03, 2008 10:44 PM To: Avi Ezra; HYPERLINK "mailto:rtg-bfd@ietf.org"rtg-bfd@ietf.org Subject: Re: Timer Manipulation=20 Hi Avi, Once the BFD session goes DOWN (or even to INIT), you need to set the = BFD messages to 1sec. interval=20 The BFD failure could be do to tons of reasons =96 BFD being = deconfigured on peer router for instance. One should not continue to send packets at 10ms interval....since in = DOWN state one doesn=92t know at what rate the peer wants to accept packets at. Fast failure detection is only possible when the BFD session is UP. I = see your point that there is a small time between the time when the BFD session comes UP and the time the intervals are = reset to 10ms (from 1sec) and one won=92t get fast failure detection=20 in that interval, but I think that=92s too much of a corner case to be = worried about. You can try optimizing these corner cases with not resetting the = interval, but it might start having other side-effects. Thanks Nitin On 7/2/08 10:49 PM, "Avi Ezra" wrote: Hi I have a question regarding the BFD protocol, In Bidirectional Forwarding Detection draft-ietf-bfd-based-08.txt=20 section 6.8.3 Timer Manipulation written: When bfd.SessionState is not Up, the system MUST set bfd.DesiredMinTxInterval to a value of not less than one second (1,000,000 microseconds.) This is intended to ensure that the bandwidth consumed by BFD sessions that are not Up is negligible, particularly in the case where a neighbor may not be running BFD. Please follow this scenario: 1. The Timer Negotiation is finished and the DesireMinTXInterval set to = 10 ms in both direction 2. The session is already in Up state for long time 3. There is a failure in the line and the session state goes to Down = state=20 My question is: Do I have to set the DesireMinTXInterval to one second again and to send = BFD messages in one second interval? or can I continue to send BFD messages in 10 ms interval in order to get = fast detection of the line recovery=20 Best Regards Avi Ezra No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.4.3 - Release Date: 28/06/2008 = 00:00 =20 No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.4.5 - Release Date: 03/07/2008 = 00:00 No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.4.5/1536 - Release Date: = 05/07/2008 10:15 No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.4.10 - Release Date: 12/07/2008 = 00:00 No virus found in this outgoing message. Checked by AVG.=20 Version: 7.5.524 / Virus Database: 270.4.10 - Release Date: 12/07/2008 = 00:00 =20 ------_=_NextPart_001_01C8E7D5.5C8D9BB6 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Hi
The=20 BFD protocol concentrate in the detection of failure of the connection = between=20 the two ends, it gives us all the options to set the speed of = failure=20 detection, i.e Tx/Rx interval and Detect time=20 multiplier.
BUT 
In=20 other hand the protocol not gives us any option to determine the = speed of=20 recovery detection (MUST to resume with 1 = second). 
Why not to give to the APPLICATION the decision how rapidly it = ;want to detect the recovery of the li= ne, It can be done by it decision to use this connection only after = a receiving X=20 times UP packets to prevent flapping. =
I'm not worry to spew BFD = packets to a=20 dead or turned off system in the same rate like I sent before the = failure, it is=20 not harm the system and it not harm the network since I did it few = second=20 ago in double rate (Tx packets from both ends), Just to mention = that the=20 packets rate determined by the capabilities of both ends and not by the = network=20 capability.
 
Some=20 applications have no redundant path and when the session is Down there = is no=20 service, because of that I need to get the Up state very fast to = resume the=20 services even if I'll get some flaps.
 
...Avi
 
From: Dave Katz = [mailto:dkatz@juniper.net]=20
Sent: Tuesday, July 15, 2008 2:48 AM
To: Alexander=20 Vainshtein
Cc: Nobo Akiya (nobo); Avi Ezra;=20 rtg-bfd@ietf.org
Subject: Re: Timer Manipulation =

Note that the spec explicitly allows for rapid exchange of = BFD=20 packets if the contents are changing (typically state transitions)--see = section=20 6.8.7.  There is nothing in the spec blocking the rapid = reestablishment of=20 a BFD session.

As others have mentioned, the point of slowing down the transmit = interval=20 is to not spew BFD packets when the other guy is dead, or has BFD turned = off,=20 etc.  Sending BFD packets at 10 msec intervals indefinitely after a = session=20 failure would be a bad thing.

--Dave


On Jul 14, 2008, at 5:44 AM, Alexander Vainshtein wrote:
Avi,=20 Nobo and all,
I=20 concur with Nobo's comment. It is quite customary to stabilize = DOWN-->UP=20 transitions in order to prevent flapping.
 
Regards,
    = Sasha
 

From: rtg-bfd-bounces@ietf.org = [mailto:rtg-bfd-bounces@ietf.org<= /A>]=20 On Behalf Of Nobo Akiya (nobo)
Sent: Monday, July = 14, 2008=20 11:07 AM
To: Avi Ezra; Nitin Bahadur; rtg-bfd@ietf.org
Subject: = RE:=20 Timer Manipulation

Hello Avi.
 
Another point to consider is that if you = allow BFD=20 session to flap (UP->DOWN->UP) too fast, you maybe triggering = two=20 route convergences in a very short period of = time.
 
    - UP-> DOWN - Routes = converge=20 away from failed link.
    - DOWN -> UP - Routes = converge=20 back to original.
 
That could cause quite lot of churn at both = system and=20 network level, worse if the flapping continues.
 
Thanx,
Nobo

From: rtg-bfd-bounces@ietf.org = [mailto:rtg-bfd-bounces@ietf.org<= /A>]=20 On Behalf Of Avi Ezra
Sent: Sunday, July 06, 2008 = 1:55=20 PM
To: Nitin Bahadur; rtg-bfd@ietf.org
Subject: = RE:=20 Timer Manipulation

Hi Nitin
Thank you for your answer
 
My point is to achieve fast detection of the RECOVERY of = the=20 line.
If I'll go to 1 sec. interval I'll achieve=20 fast failure detection but very slow detection of the=20 recovery
 
Thanks
Avi 

From: Nitin Bahadur [mailto:nitinb@juniper.net]=20
Sent: Thursday, July 03, 2008 10:44 PM
To: = Avi Ezra;=20 rtg-bfd@ietf.org
Subject: = Re: Timer Manipulation

Hi=20 Avi,

Once the BFD session goes DOWN (or even to INIT), you = need to=20 set the BFD messages to 1sec. interval
The BFD failure could = be do to=20 tons of reasons – BFD being deconfigured on peer router for=20 instance.

One should not continue to send packets at 10ms=20 interval....since in DOWN state one doesn’t know at what = rate
the peer=20 wants to accept packets at.

Fast failure detection is only = possible=20 when the BFD session is UP. I see your point that there is a small = time=20 between
the time when the BFD session comes UP and the time the = intervals are reset to 10ms (from 1sec)  and one won’t = get fast=20 failure detection
in that  interval, but I think = that’s too much=20 of a corner case to be worried about.

You can try = optimizing these=20 corner cases with not resetting the interval, but it might start = having=20 other side-effects.

Thanks
Nitin

On 7/2/08 10:49 = PM, "Avi=20 Ezra" <avie@AXERRA.com>=20 wrote:
Hi
I have a question regarding the BFD = protocol,
In=20 Bidirectional Forwarding Detection draft-ietf-bfd-based-08.txt=20
section 6.8.3 Timer Manipulation written:

When bfd.SessionState is not Up, the system MUST=20 set
   bfd.DesiredMinTxInterval to a value of = not less=20 than one second
   (1,000,000 microseconds.)=20  This is intended to ensure that = the
   bandwidth=20 consumed by BFD sessions that are not Up is=20 negligible,
   particularly in the case where = a=20 neighbor may not be running BFD.

Please follow this scenario:
1. The Timer = Negotiation is=20 finished and the DesireMinTXInterval set to 10 ms in both=20 direction
2. The session is already  in Up  state =  for=20 long time
3. There is a failure in the line and the session = state=20 goes to Down state

My=20 question is:
Do I have to set the DesireMinTXInterval to one = second=20 again and to send BFD messages in one second interval?
or can = I=20 continue to send BFD messages in 10 ms interval in order to get = fast=20 detection of the line recovery

Best Regards
Avi Ezra



No virus = found in=20 this outgoing message.
Checked by AVG.
Version: 7.5.524 / = Virus=20 Database: 270.4.3 - Release Date: 28/06/2008=20 00:00
 


No virus found in this incoming = message.
Checked by=20 AVG.
Version: 7.5.524 / Virus Database: 270.4.5 - Release Date: = 03/07/2008 00:00


No virus found in this outgoing = message.
Checked by=20 AVG.
Version: 7.5.524 / Virus Database: 270.4.5/1536 - Release = Date:=20 05/07/2008=20 10:15


No virus found in this incoming message.
Checked by = AVG.
Version: 7.5.524 / Virus Database: 270.4.10 - Release Date: = 12/07/2008=20 00:00


No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 270.4.10 - Release Date: 12/07/2008 = 00:00

------_=_NextPart_001_01C8E7D5.5C8D9BB6-- From rtg-bfd-bounces@ietf.org Thu Jul 17 10:23:05 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2AE73A6AF2; Thu, 17 Jul 2008 10:23:05 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81EFB3A6AF2 for ; Thu, 17 Jul 2008 10:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.318 X-Spam-Level: X-Spam-Status: No, score=-4.318 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnD9x1uLKE3A for ; Thu, 17 Jul 2008 10:23:02 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 3004D3A6ADC for ; Thu, 17 Jul 2008 10:23:02 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Thu, 17 Jul 2008 10:22:46 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jul 2008 10:22:20 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jul 2008 10:22:19 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jul 2008 10:22:18 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6HHMHx80977; Thu, 17 Jul 2008 10:22:17 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-Id: <1397D2BA-0068-4B8D-9727-C37A221C8D7B@juniper.net> From: Dave Katz To: Avi Ezra In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-8--362547886 Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Timer Manipulation Date: Thu, 17 Jul 2008 11:22:16 -0600 References: X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 17 Jul 2008 17:22:18.0336 (UTC) FILETIME=[AA020600:01C8E831] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --Apple-Mail-8--362547886 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable As I mentioned earlier, the one second transmit interval does not =20 preclude rapid session establishment, so it shouldn't matter. One of the driving design criteria for BFD was to make it self-=20 stabilize when things go south. Pretty much every large-scale network =20= collapse of any sort (AOL '95, ATT SS7, MCI frame relay for 10 days, =20 lots of others) ultimately had the same problem--the network put =20 itself into a metastable failure condition that it couldn't recover =20 from (not unlike ventricular fibrillation) because the underlying =20 liveness detection ultimately could not compete with the flood of =20 control traffic, which in turn caused even more control traffic, and =20 in each case it took manual intervention to recover. BFD tries to avoid this situation by allowing any participant in the =20 protocol to control both the transmit and receive rates (in the hope =20 of staving off failure) and additionally by automatically dropping the =20= transmit rate if the session actually *does* fail. This veteran of the trenches has seen way too many networks go under, =20= and the pressure for faster detection times only makes it more likely =20= to occur unless proper protocol mechanisms are in place. Besides, not only can BFD come up quickly, but there's nothing to stop =20= an implementation from using a link while BFD is in the process of =20 coming up. There is a risk of black holes for the amount of time it =20 takes to determine that the link isn't really working. And there is =20 room for endless creativity in how BFD interacts with its clients. In any case, this is an implementation issue, and not a protocol issue. --Dave On Jul 17, 2008, at 12:24 AM, Avi Ezra wrote: > Hi > The BFD protocol concentrate in the detection of failure of the =20 > connection between the two ends, it gives us all the options to set =20= > the speed of failure detection, i.e Tx/Rx interval and Detect time =20 > multiplier. > BUT > In other hand the protocol not gives us any option to determine the =20= > speed of recovery detection (MUST to resume with 1 second). > Why not to give to the APPLICATION the decision how rapidly it want =20= > to detect the recovery of the line, It can be done by it decision to =20= > use this connection only after a receiving X times UP packets to =20 > prevent flapping. > I'm not worry to spew BFD packets to a dead or turned off system in =20= > the same rate like I sent before the failure, it is not harm the =20 > system and it not harm the network since I did it few second ago in =20= > double rate (Tx packets from both ends), Just to mention that the =20 > packets rate determined by the capabilities of both ends and not by =20= > the network capability. > > Some applications have no redundant path and when the session is =20 > Down there is no service, because of that I need to get the Up state =20= > very fast to resume the services even if I'll get some flaps. > > ...Avi > > From: Dave Katz [mailto:dkatz@juniper.net] > Sent: Tuesday, July 15, 2008 2:48 AM > To: Alexander Vainshtein > Cc: Nobo Akiya (nobo); Avi Ezra; rtg-bfd@ietf.org > Subject: Re: Timer Manipulation > > Note that the spec explicitly allows for rapid exchange of BFD =20 > packets if the contents are changing (typically state transitions)--=20= > see section 6.8.7. There is nothing in the spec blocking the rapid =20= > reestablishment of a BFD session. > > As others have mentioned, the point of slowing down the transmit =20 > interval is to not spew BFD packets when the other guy is dead, or =20 > has BFD turned off, etc. Sending BFD packets at 10 msec intervals =20 > indefinitely after a session failure would be a bad thing. > > --Dave > > > On Jul 14, 2008, at 5:44 AM, Alexander Vainshtein wrote: > >> Avi, Nobo and all, >> I concur with Nobo's comment. It is quite customary to stabilize =20 >> DOWN-->UP transitions in order to prevent flapping. >> >> Regards, >> Sasha >> >> >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On =20= >> Behalf Of Nobo Akiya (nobo) >> Sent: Monday, July 14, 2008 11:07 AM >> To: Avi Ezra; Nitin Bahadur; rtg-bfd@ietf.org >> Subject: RE: Timer Manipulation >> >> Hello Avi. >> >> Another point to consider is that if you allow BFD session to flap =20= >> (UP->DOWN->UP) too fast, you maybe triggering two route =20 >> convergences in a very short period of time. >> >> - UP-> DOWN - Routes converge away from failed link. >> - DOWN -> UP - Routes converge back to original. >> >> That could cause quite lot of churn at both system and network =20 >> level, worse if the flapping continues. >> >> Thanx, >> Nobo >> >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On =20= >> Behalf Of Avi Ezra >> Sent: Sunday, July 06, 2008 1:55 PM >> To: Nitin Bahadur; rtg-bfd@ietf.org >> Subject: RE: Timer Manipulation >> >> Hi Nitin >> Thank you for your answer >> >> My point is to achieve fast detection of the RECOVERY of the line. >> If I'll go to 1 sec. interval I'll achieve fast failure detection =20 >> but very slow detection of the recovery >> >> Thanks >> Avi >> >> From: Nitin Bahadur [mailto:nitinb@juniper.net] >> Sent: Thursday, July 03, 2008 10:44 PM >> To: Avi Ezra; rtg-bfd@ietf.org >> Subject: Re: Timer Manipulation >> >> Hi Avi, >> >> Once the BFD session goes DOWN (or even to INIT), you need to set =20 >> the BFD messages to 1sec. interval >> The BFD failure could be do to tons of reasons =96 BFD being =20 >> deconfigured on peer router for instance. >> >> One should not continue to send packets at 10ms interval....since =20 >> in DOWN state one doesn=92t know at what rate >> the peer wants to accept packets at. >> >> Fast failure detection is only possible when the BFD session is UP. =20= >> I see your point that there is a small time between >> the time when the BFD session comes UP and the time the intervals =20 >> are reset to 10ms (from 1sec) and one won=92t get fast failure =20 >> detection >> in that interval, but I think that=92s too much of a corner case to =20= >> be worried about. >> >> You can try optimizing these corner cases with not resetting the =20 >> interval, but it might start having other side-effects. >> >> Thanks >> Nitin >> >> On 7/2/08 10:49 PM, "Avi Ezra" wrote: >> >> Hi >> I have a question regarding the BFD protocol, >> In Bidirectional Forwarding Detection draft-ietf-bfd-based-08.txt >> section 6.8.3 Timer Manipulation written: >> >> When bfd.SessionState is not Up, the system MUST set >> bfd.DesiredMinTxInterval to a value of not less than one second >> (1,000,000 microseconds.) This is intended to ensure that the >> bandwidth consumed by BFD sessions that are not Up is negligible, >> particularly in the case where a neighbor may not be running BFD. >> >> Please follow this scenario: >> 1. The Timer Negotiation is finished and the DesireMinTXInterval =20 >> set to 10 ms in both direction >> 2. The session is already in Up state for long time >> 3. There is a failure in the line and the session state goes to =20 >> Down state >> >> My question is: >> Do I have to set the DesireMinTXInterval to one second again and to =20= >> send BFD messages in one second interval? >> or can I continue to send BFD messages in 10 ms interval in order =20 >> to get fast detection of the line recovery >> >> Best Regards >> Avi Ezra >> >> >> >> No virus found in this outgoing message. >> Checked by AVG. >> Version: 7.5.524 / Virus Database: 270.4.3 - Release Date: =20 >> 28/06/2008 00:00 >> >> >> >> No virus found in this incoming message. >> Checked by AVG. >> Version: 7.5.524 / Virus Database: 270.4.5 - Release Date: =20 >> 03/07/2008 00:00 >> >> >> No virus found in this outgoing message. >> Checked by AVG. >> Version: 7.5.524 / Virus Database: 270.4.5/1536 - Release Date: =20 >> 05/07/2008 10:15 >> > > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 270.4.10 - Release Date: =20 > 12/07/2008 00:00 > > > No virus found in this outgoing message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 270.4.10 - Release Date: =20 > 12/07/2008 00:00 > --Apple-Mail-8--362547886 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As I mentioned earlier, the one = second transmit interval does not preclude rapid session establishment, = so it shouldn't matter.

One of the driving design = criteria for BFD was to make it self-stabilize when things go south. =  Pretty much every large-scale network collapse of any sort (AOL = '95, ATT SS7, MCI frame relay for 10 days, lots of others) ultimately = had the same problem--the network put itself into a metastable failure = condition that it couldn't recover from (not unlike ventricular = fibrillation) because the underlying liveness detection ultimately could = not compete with the flood of control traffic, which in turn caused even = more control traffic, and in each case it took manual intervention to = recover.

BFD tries to avoid this situation by = allowing any participant in the protocol to control both the transmit = and receive rates (in the hope of staving off failure) and additionally = by automatically dropping the transmit rate if the session actually = *does* fail.

This veteran of the trenches has = seen way too many networks go under, and the pressure for faster = detection times only makes it more likely to occur unless proper = protocol mechanisms are in place.

Besides, not = only can BFD come up quickly, but there's nothing to stop an = implementation from using a link while BFD is in the process of coming = up.  There is a risk of black holes for the amount of time it takes = to determine that the link isn't really working.  And there is room = for endless creativity in how BFD interacts with its = clients.

In any case, this is an implementation = issue, and not a protocol = issue.

--Dave


<= div>On Jul 17, 2008, at 12:24 AM, Avi Ezra wrote:

Hi
The BFD protocol concentrate in the detection of failure of = the connection between the two ends, it gives us all the options to set = the speed of failure detection, i.e Tx/Rx interval = and Detect time multiplier.
BUT 
In other hand the protocol not gives us any option to = determine the speed of recovery detection (MUST to resume with 1 = second). 
Why not to give to the APPLICATION the decision how rapidly it&nbs= p;want to detect the recovery of the li= ne, It can be done by it decision to use this connection only after = a receiving X times UP packets to prevent flapping. =
I'm = not worry to spew BFD packets to a dead or turned off system in the same = rate like I sent before the failure, it is not harm the system and it = not harm the network since I did it few second ago in double = rate (Tx packets from both ends), Just to mention that the packets rate = determined by the capabilities of both ends and not by the network = capability.
 
=
Some applications have no redundant path = and when the session is Down there is no service, because of that I need = to get the Up state very fast to resume the services even if I'll = get some flaps.
 
...Avi
 
From: Dave Katz [mailto:dkatz@juniper.net] =
Sent: Tuesday, July 15, 2008 2:48 AM
To: Alexander = Vainshtein
Cc: Nobo Akiya (nobo); Avi Ezra; rtg-bfd@ietf.org
Subject: = Re: Timer Manipulation

Note that the = spec explicitly allows for rapid exchange of BFD packets if the contents = are changing (typically state transitions)--see section 6.8.7. =  There is nothing in the spec blocking the rapid reestablishment of = a BFD session.

As others have mentioned, the point = of slowing down the transmit interval is to not spew BFD packets when = the other guy is dead, or has BFD turned off, etc.  Sending BFD = packets at 10 msec intervals indefinitely after a session failure would = be a bad thing.

--Dave


On = Jul 14, 2008, at 5:44 AM, Alexander Vainshtein wrote:

=
Avi, Nobo and all,
=
I concur with Nobo's comment. It is quite = customary to stabilize DOWN-->UP transitions in order to prevent = flapping.
 
=
Regards,
    = Sasha
 

=
From: = rtg-bfd-bounces@ietf.org = [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (nobo)
Sent: Monday, = July 14, 2008 11:07 AM
To: Avi Ezra; Nitin Bahadur; rtg-bfd@ietf.org
Subject: = RE: Timer Manipulation

Hello Avi.
 
Another point to consider is that if you = allow BFD session to flap (UP->DOWN->UP) too fast, you maybe = triggering two route convergences in a very short period of = time.
 
    - UP-> DOWN - Routes converge away = from failed link.
    - DOWN -> UP - Routes converge back to = original.
 
That could cause quite lot of churn at both system and = network level, worse if the flapping continues.
=
 
Thanx,
Nobo

=
From:= rtg-bfd-bounces@ietf.org = [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Avi Ezra
Sent: Sunday, July 06, = 2008 1:55 PM
To: Nitin Bahadur; rtg-bfd@ietf.org
Subject: = RE: Timer Manipulation

=
Hi Nitin
=
Thank you for your = answer
 
My point is to achieve fast detection of the RECOVERY of the = line.
If I'll go to 1 sec. interval I'll achieve = fast failure detection but very slow detection of the = recovery
 
Thanks
Avi 

=
From: Nitin Bahadur [mailto:nitinb@juniper.net] =
Sent: Thursday, July 03, 2008 10:44 PM
To: Avi = Ezra; rtg-bfd@ietf.org
Subject: = Re: Timer Manipulation

Hi Avi,

Once the BFD session goes = DOWN (or even to INIT), you need to set the BFD messages to 1sec. = interval
The BFD failure could be do to tons of reasons =E2=80=93= BFD being deconfigured on peer router for instance.

One = should not continue to send packets at 10ms interval....since in = DOWN state one doesn=E2=80=99t know at what rate
the peer wants = to accept packets at.

Fast failure detection is only possible = when the BFD session is UP. I see your point that there is a small = time between
the time when the BFD session comes UP and the = time the intervals are reset to 10ms (from 1sec)  and one = won=E2=80=99t get fast failure detection
in that =  interval, but I think that=E2=80=99s too much of a corner = case to be worried about.

You can try optimizing these = corner cases with not resetting the interval, but it might start having = other side-effects.

Thanks
Nitin

On 7/2/08 10:49 = PM, "Avi Ezra" <avie@AXERRA.com> = wrote:
Hi
I = have a question regarding the BFD protocol,
In Bidirectional = Forwarding Detection draft-ietf-bfd-based-08.txt
section = 6.8.3 Timer Manipulation written:

When = bfd.SessionState is not Up, the system MUST = set
   bfd.DesiredMinTxInterval to a value of not less = than one second
   (1,000,000 microseconds.) =  This is intended to ensure that = the
   bandwidth consumed by BFD sessions that = are not Up is negligible,
   particularly in = the case where a neighbor may not be running = BFD.

Please follow this = scenario:
1. The Timer Negotiation is finished and the = DesireMinTXInterval set to 10 ms in both direction
2. The = session is already  in Up  state  for long = time
3. There is a failure in the line and the session state = goes to Down state

My question is:
Do I = have to set the DesireMinTXInterval to one second again and to = send BFD messages in one second interval?
or can I continue = to send BFD messages in 10 ms interval in order to get fast = detection of the line recovery

Best = Regards
Avi Ezra



No virus found in this outgoing = message.
Checked by AVG.
Version: 7.5.524 / Virus = Database: 270.4.3 - Release Date: 28/06/2008 = 00:00
 


No virus found in this incoming message.
Checked by = AVG.
Version: 7.5.524 / Virus Database: 270.4.5 - Release Date: = 03/07/2008 00:00


No virus found in = this outgoing message.
Checked by AVG.
Version: 7.5.524 / = Virus Database: 270.4.5/1536 - Release Date: 05/07/2008 = 10:15


No virus found in this incoming = message.
Checked by AVG.
Version: 7.5.524 / Virus Database: = 270.4.10 - Release Date: 12/07/2008 00:00

=

No virus found in this outgoing message.
= Checked by AVG.
Version: 7.5.524 / Virus Database: 270.4.10 - = Release Date: 12/07/2008 00:00
 =


= --Apple-Mail-8--362547886-- From rtg-bfd-bounces@ietf.org Thu Jul 17 14:51:19 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD0373A67B6; Thu, 17 Jul 2008 14:51:19 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7810F3A67B6 for ; Thu, 17 Jul 2008 14:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, J_BACKHAIR_22=1, J_BACKHAIR_23=1, J_BACKHAIR_24=1, J_BACKHAIR_25=1, J_BACKHAIR_27=1, J_BACKHAIR_32=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYF+nOe1nXdO for ; Thu, 17 Jul 2008 14:51:15 -0700 (PDT) Received: from psmtp.com (exprod7ob113.obsmtp.com [64.18.2.178]) by core3.amsl.com (Postfix) with ESMTP id E97D23A67DA for ; Thu, 17 Jul 2008 14:51:14 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Thu, 17 Jul 2008 14:51:14 PDT Received: from emailcorp3.jnpr.net ([66.129.254.13]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jul 2008 14:51:11 -0700 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_01C8E855.FECC6822" Subject: RE: Timer Manipulation Date: Thu, 17 Jul 2008 14:42:22 -0700 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E025DD3B5@emailcorp3.jnpr.net> In-Reply-To: <1397D2BA-0068-4B8D-9727-C37A221C8D7B@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Timer Manipulation Thread-Index: AcjoMduBdCne/3olQD27HqEHIlQdmQAI5uSg References: <1397D2BA-0068-4B8D-9727-C37A221C8D7B@juniper.net> From: "Nitin Bahadur" To: "Dave Katz" , "Avi Ezra" X-OriginalArrivalTime: 17 Jul 2008 21:51:11.0991 (UTC) FILETIME=[3A6A6870:01C8E857] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E855.FECC6822 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Dave Katz As I mentioned earlier, the one second transmit interval does not preclude rapid session establishment, so it shouldn't matter. =20 Just to clarify what Dave is saying. Let's say A and B are peers and B goes down. Consequently A goes into BFD Down state. =20 When B comes up, B immediately sends a BFD packet. On receipt of that packet, A will immediately transition to Init state and should immediately send a BFD packet (it doesn't have to wait for 1 second). On receipt of packet from A, B will immediately change it's state and send a packet (immediately) to A. Thus packets sent on state transitions DO NOT have to wait for the 1 second. Thus the BFD session will come up ASAP. I hope this clarifies things. =20 Nitin ------_=_NextPart_001_01C8E855.FECC6822 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Dave Katz

As I mentioned earlier, the one second transmit interval does not preclude rapid session establishment, so it shouldn't matter.

 

=

Just to clarify what Dave is = saying. Let’s say A and B are peers and B goes down. Consequently A goes into BFD Down state.

 

When B comes up, B immediately = sends a BFD packet. On receipt of that = packet, A will immediately transition to Init state and should immediately = send a BFD packet (it doesn’t have to = wait for 1 second). On receipt of = packet from A, B will immediately change it’s state and send a packet (immediately) to A. Thus packets sent on state transitions DO NOT have to wait for the 1 second. Thus the BFD session will = come up ASAP. I hope this clarifies things.

 

Nitin

------_=_NextPart_001_01C8E855.FECC6822-- From rtg-bfd-bounces@ietf.org Thu Jul 17 20:01:34 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72FC23A69CD; Thu, 17 Jul 2008 20:01:34 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 245743A69CD for ; Thu, 17 Jul 2008 20:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=-1.860, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, J_BACKHAIR_22=1, J_BACKHAIR_23=1, J_BACKHAIR_24=1, J_BACKHAIR_25=1, J_BACKHAIR_27=1, J_BACKHAIR_32=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xG7CajiDbVJ for ; Thu, 17 Jul 2008 20:01:32 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id 1D0363A6941 for ; Thu, 17 Jul 2008 20:01:32 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Thu, 17 Jul 2008 20:01:11 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jul 2008 20:01:26 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jul 2008 20:01:26 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jul 2008 20:01:25 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6I31Ox52149; Thu, 17 Jul 2008 20:01:24 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-Id: From: Dave Katz To: Nitin Bahadur In-Reply-To: <7FA0C743C38E5340BFC2873488FA1E8E025DD3B5@emailcorp3.jnpr.net> Content-Type: multipart/alternative; boundary=Apple-Mail-12--327803472 Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: Timer Manipulation Date: Thu, 17 Jul 2008 21:01:21 -0600 References: <1397D2BA-0068-4B8D-9727-C37A221C8D7B@juniper.net> <7FA0C743C38E5340BFC2873488FA1E8E025DD3B5@emailcorp3.jnpr.net> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 18 Jul 2008 03:01:25.0586 (UTC) FILETIME=[90FB9B20:01C8E882] Cc: rtg-bfd@ietf.org, Avi Ezra X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --Apple-Mail-12--327803472 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Yep. And note that the spec allows the extra packet to be sent when =20 *any* of its contents change (other than the P/F bits) which can help =20= some cases along. This also works on initial session establishment. On average there =20 will be a delay of 250 msec between the point where the path becomes =20 viable and one or the other end tries to send the next packet (which =20 will bring the session up.) If there is a datalink protocol running =20 (like PPP) then BFD can be rigged to send the first packet as soon as =20= the datalink comes up, reducing that 250 msec to nearly zero. And don't forget that the total time budget has to include the link =20 latency, which can be significant for long and/or slow paths and will =20= put an upper bound on what's possible. --Dave On Jul 17, 2008, at 3:42 PM, Nitin Bahadur wrote: > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On =20= > Behalf Of Dave Katz > > As I mentioned earlier, the one second transmit interval does not =20 > preclude rapid session establishment, so it shouldn't matter. > > Just to clarify what Dave is saying. Let=92s say A and B are peers and = =20 > B goes down. Consequently A goes into BFD Down state. > > When B comes up, B immediately sends a BFD packet. On receipt of =20 > that packet, A will immediately transition to Init state and should =20= > immediately send a BFD packet (it doesn=92t have to wait for 1 =20 > second). On receipt of packet from A, B will immediately change it=92s = =20 > state and send a packet (immediately) to A. Thus packets sent on =20 > state transitions DO NOT have to wait for the 1 second. Thus the BFD =20= > session will come up ASAP. I hope this clarifies things. > > Nitin --Apple-Mail-12--327803472 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Yep.  And note that the = spec allows the extra packet to be sent when *any* of its contents = change (other than the P/F bits) which can help some cases = along.

This also works on initial session = establishment.  On average there will be a delay of 250 msec = between the point where the path becomes viable and one or the other end = tries to send the next packet (which will bring the session up.) =  If there is a datalink protocol running (like PPP) then BFD can be = rigged to send the first packet as soon as the datalink comes up, = reducing that 250 msec to nearly zero.

And = don't forget that the total time budget has to include the link latency, = which can be significant for long and/or slow paths and will put an = upper bound on what's = possible.

--Dave


On Jul 17, 2008, at 3:42 PM, Nitin Bahadur wrote:

As I mentioned earlier, the one second transmit interval does not preclude = rapid session establishment, so it shouldn't = matter.
 
Just to = clarify what Dave is saying. Let=92s say A and B are peers and B goes = down. Consequently A goes = into BFD Down state.
When B comes up, B immediately sends a BFD packet. On receipt of that = packet, A will immediately transition to Init state and should = immediately send a BFD packet (it doesn=92t have to = wait for 1 second). On receipt of packet from A, B = will immediately change it=92s state and send a packet (immediately) to A. Thus = packets sent on state transitions DO NOT have to = wait for the 1 second. Thus the BFD session will come up ASAP. I hope this = clarifies things.
References: <1397D2BA-0068-4B8D-9727-C37A221C8D7B@juniper.net> <7FA0C743C38E5340BFC2873488FA1E8E025DD3B5@emailcorp3.jnpr.net> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: multipart/alternative; boundary=Apple-Mail-4--324684119 Message-Id: <9EC4F7D7-64AB-4D95-B0F8-F30AB90FA796@cisco.com> From: David Ward Subject: Re: Timer Manipulation Date: Thu, 17 Jul 2008 22:53:20 -0500 To: Dave Katz X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 18 Jul 2008 03:53:30.0816 (UTC) FILETIME=[D7C3DC00:01C8E889] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9910; t=1216353211; x=1217217211; 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 |Subject:=20Re=3A=20Timer=20Manipulation=20 |Sender:=20 |To:=20Dave=20Katz=20; bh=dDnG95992fzSAwG4LtOHUQqBJOBQY9x2dDPWDFvGN0M=; b=jcYLlHUQagABNmpXWwU/m60UazNHvaMtIxBfPZevLHfnQQD2MKfxiGB+7B Dut56vzREnKkWWQ5dIf0JvnWIu/S59mjqwOdEptFqgiAkGWcUtGNJvPqpnTq +pVuF/4lhn; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: rtg-bfd@ietf.org, David Ward , Avi Ezra X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --Apple-Mail-4--324684119 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Note that good news (interface, etc UP) should travel through the =20 system slowing and bad news (interface, etc DOWN) should be =20 instantaneous. Be very careful optimizing bringing things up too =20 quickly. caveat emptor -DWard On Jul 17, 2008, at 10:01 PM, Dave Katz wrote: > Yep. And note that the spec allows the extra packet to be sent =20 > when *any* of its contents change (other than the P/F bits) which =20 > can help some cases along. > > This also works on initial session establishment. On average there =20= > will be a delay of 250 msec between the point where the path =20 > becomes viable and one or the other end tries to send the next =20 > packet (which will bring the session up.) If there is a datalink =20 > protocol running (like PPP) then BFD can be rigged to send the =20 > first packet as soon as the datalink comes up, reducing that 250 =20 > msec to nearly zero. > > And don't forget that the total time budget has to include the link =20= > latency, which can be significant for long and/or slow paths and =20 > will put an upper bound on what's possible. > > --Dave > > > On Jul 17, 2008, at 3:42 PM, Nitin Bahadur wrote: > >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] =20 >> On Behalf Of Dave Katz >> >> As I mentioned earlier, the one second transmit interval does not =20 >> preclude rapid session establishment, so it shouldn't matter. >> >> Just to clarify what Dave is saying. Let=92s say A and B are peers =20= >> and B goes down. Consequently A goes into BFD Down state. >> >> When B comes up, B immediately sends a BFD packet. On receipt of =20 >> that packet, A will immediately transition to Init state and =20 >> should immediately send a BFD packet (it doesn=92t have to wait for =20= >> 1 second). On receipt of packet from A, B will immediately change =20 >> it=92s state and send a packet (immediately) to A. Thus packets sent =20= >> on state transitions DO NOT have to wait for the 1 second. Thus =20 >> the BFD session will come up ASAP. I hope this clarifies things. >> >> Nitin > --Apple-Mail-4--324684119 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Note that good news (interface, etc UP) should travel through the system = slowing and bad news (interface, etc DOWN) should be instantaneous. Be = very careful optimizing bringing things up too = quickly.

caveat = emptor

-DWard

On Jul 17, = 2008, at 10:01 PM, Dave Katz wrote:

Yep. =A0And = note that the spec allows the extra packet to be sent when *any* of its = contents change (other than the P/F bits) which can help some cases = along.

This also works on initial session = establishment. =A0On average there will be a delay of 250 msec between = the point where the path becomes viable and one or the other end tries = to send the next packet (which will bring the session up.) =A0If there = is a datalink protocol running (like PPP) then BFD can be rigged to send = the first packet as soon as the datalink comes up, reducing that 250 = msec to nearly zero.

And don't forget that the = total time budget has to include the link latency, which can be = significant for long and/or slow paths and will put an upper bound on = what's = possible.

--Dave


On Jul 17, 2008, at 3:42 PM, Nitin Bahadur wrote:

As I mentioned earlier, the one=A0second transmit interval does not preclude = rapid=A0session establishment, so it shouldn't = matter.
=A0
Just to clarify what Dave is saying. = Let=92s say A and B are peers and B goes down. Consequently A goes into BFD Down = state.
=A0
When B comes up, B immediately=A0sends a BFD packet. On receipt of that = packet, A will immediately transition to Init state and should = immediately=A0send a BFD packet (it doesn=92t have to = wait for 1=A0second). On receipt of packet from A, B = will immediately change it=92s state and=A0send a packet (immediately) to A. Thus = packets=A0sent on state transitions DO NOT have to = wait for the 1=A0second. Thus the BFD=A0session will come up ASAP. I hope this = clarifies things.
=A0
List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Vitali, I have some comments regarding your draft draft-vinokour-bfd-dhcp-01.txt I believe the intentions of the draft are good. But the main question I have is - is this going to scale? DHCP server serves thousands of clients. You are talking about running BFD for each of these clients. Won't the DHCP server be a bottleneck? If you alleviate scaling concerns by using failure detection intervals in the order of a few seconds, then my question is - is using BFD then worth it? If there is a failure (today, without BFD), are there cases where the failure is NOT detected within a few seconds. Basically, I am not 100% convinced of the motivation for the solution. My other comments are as below: 1) Your draft aims at boot-strapping the BFD session with BFD parameters. IMO, this is not a good idea. BFD parameters are local to a box and shouldn't be dictated by a remote end. BFD relies on parameter negotiation and your draft doesn't support that. The DHCP client could be running on a low-CPU box and I think it's better to have default BFD config on the client rather than have the server dictate what to use. 2) Authentication seems like an issue here. You seem to be passing the authentication keys from server to client. So how are you protecting the keys...in other words, if someone can snoop on the keys, then someone can do nasty things. Also, it seemed to me that the key is going to be the same for both all clients (unless you provision a unique key per client..which doesn't sound scalable to me from a provisioning point of view on the server) and in both directions. This seems like a security hole (if I understand the draft correctly). 3) The draft does not say whether the BFD session is going to be single-hop or multi-hop. 4) You have copied (almost) the entire bfd header in the dhcp server response. I don't think this is the right approach. BFD fields have nothing to do with DHCP (like the C-bit). As I said earlier, negotiate, negotiate and negotiate. The only field I see really necessary is the "remote ip address". 5) Since the remote ip address is typically not known by hosts (as you say), then is making it known now (via the new dhcp tlv) acceptable? That's more of a question for the DHCP folks I guess 6) Why does the BFD version need to be 1 ? BFD version negotiation procedures should negotiate the version. The *current version* could be 2 when someone goes to implement the RFC. They will get confused by the RFC. Thanks Nitin From rtg-bfd-bounces@ietf.org Wed Jul 30 19:40:50 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AC603A6A67; Wed, 30 Jul 2008 19:40:50 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 536C33A6A67 for ; Wed, 30 Jul 2008 19:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPw54wN3Bxb2 for ; Wed, 30 Jul 2008 19:40:48 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id F2EC23A685A for ; Wed, 30 Jul 2008 19:40:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,283,1215388800"; d="scan'208";a="16080737" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Jul 2008 02:41:02 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6V2f1uA027780; Wed, 30 Jul 2008 22:41:01 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6V2ext4002725; Thu, 31 Jul 2008 02:41:01 GMT Received: from xmb-rtp-214.amer.cisco.com ([64.102.31.75]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 22:39:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-vinokour-bfd-dhcp-01.txt Date: Wed, 30 Jul 2008 22:39:56 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-vinokour-bfd-dhcp-01.txt Thread-Index: Acjyj0RJphIuWjkA00GeWI8LovebbQAHjXzg References: From: "Vitali Vinokour (vvinokou)" To: "Nitin Bahadur" , X-OriginalArrivalTime: 31 Jul 2008 02:39:57.0693 (UTC) FILETIME=[B8B57AD0:01C8F2B6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5236; t=1217472062; x=1218336062; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vvinokou@cisco.com; z=From:=20=22Vitali=20Vinokour=20(vvinokou)=22=20 |Subject:=20RE=3A=20draft-vinokour-bfd-dhcp-01.txt |Sender:=20 |To:=20=22Nitin=20Bahadur=22=20,=20; bh=jMdhZ90WSGXeOHq0or4n6HhqNDhXtjKAKnGrUohvsV8=; b=l0pSgbv9OgIe5OA5FD7Q03CXwuNZXvwSJq5Purb6+TRobOdCW0uoMX9R4S OXRWLYTrM6okUuzBP4g+gN7hpDNK0Hkzbe2ECDz+IGa8tji1z6XUKDk0NGBw hKNEoiZHOb; Authentication-Results: rtp-dkim-1; header.From=vvinokou@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Nitin, Thanks for your comments. Please see inline.=20 > -----Original Message----- > From: Nitin Bahadur [mailto:nitinb@juniper.net]=20 > Sent: Wednesday, July 30, 2008 5:58 PM > To: rtg-bfd@ietf.org; Vitali Vinokour (vvinokou) > Subject: Re: draft-vinokour-bfd-dhcp-01.txt >=20 > Hi Vitali, >=20 > I have some comments regarding your draft=20 > draft-vinokour-bfd-dhcp-01.txt I believe the intentions of=20 > the draft are good. But the main question I have is - is this=20 > going to scale? DHCP server serves thousands of clients. You=20 > are talking about running BFD for each of these clients.=20 > Won't the DHCP server be a bottleneck? >=20 DHCP server is configuring the clients anyway. This is a standard broadband scenario. We are just adding an option containing BFD configuration to DHCP messages.=20 > If you alleviate scaling concerns by using failure=20 > detection intervals in the order of a few seconds, then my=20 > question is - is using BFD then worth it? If there is a=20 > failure (today, without BFD), are there cases where the=20 > failure is NOT detected within a few seconds. >=20 There is currently no credible mechanism for CPE to detect layer 3 connectivity failure not accompanied by an l2 link failure; none at all. BFD is proposed as a keepalive for IP sessions for exactly that reason.=20 > Basically, I am not 100% convinced of the motivation for the=20 > solution. >=20 While the draft primarily describes bootstrapping of BFD by DHCP on a CPE the motivation for running BFD between IP CPE and IP Edge is to detect IP connectivity failures. As I said, there is no established mechanism for it today. >=20 > My other comments are as below: >=20 > 1) Your draft aims at boot-strapping the BFD session with BFD=20 > parameters. > IMO, this is not a good idea. BFD parameters are local to a=20 > box and shouldn't be dictated by a remote end. BFD relies on=20 > parameter negotiation and your draft doesn't support that.=20 > The DHCP client could be running on a low-CPU box and I think=20 > it's better to have default BFD config on the client rather=20 > than have the server dictate what to use. >=20 The parameters that DHCP is conveying to CPE are not the ones that BFD end point can negotiate. E.g. BFD does not negotiate Desired Min Tx Interval or Required Min Rx Interval; these values are supposed to be present in the very first message a BFD peer sends out and are supplied by a bootstrapping application. In this case bootstrapping application is DHCP; it happens to be distributed between server and client but it does not change BFD bootstrapping methodology.=20 Note that this draft is targeting routing gateways that are typically under SP control; so DHCP server (configured by the same SP) will be in the position to provide BFD config matching CPE capabilities. > 2) Authentication seems like an issue here. You seem to be=20 > passing the authentication keys from server to client. So how=20 > are you protecting the keys...in other words, if someone can=20 > snoop on the keys, then someone can do nasty things. Also, it=20 > seemed to me that the key is going to be the same for both=20 > all clients (unless you provision a unique key per=20 > client..which doesn't sound scalable to me from a=20 > provisioning point of view on the > server) and in both directions. This seems like a security=20 > hole (if I understand the draft correctly). >=20 Please refer to the Security section of the draft: "To ensure security of authentication keys, DHCP messages containing options TBD_3 or TBD_4 with BFD authentication information MUST be authenticated using the procedures described in [RFC3118]." In any case, it is not expected that BFD authentication will be used in broadband networks. These networks have native security mechanisms (e.g. L2 isolation). > 3) The draft does not say whether the BFD session is going to=20 > be single-hop or multi-hop. It does not matter.=20 >=20 > 4) You have copied (almost) the entire bfd header in the dhcp=20 > server response. I don't think this is the right approach.=20 > BFD fields have nothing to do with DHCP (like the C-bit). As=20 > I said earlier, negotiate, negotiate and negotiate. The only=20 > field I see really necessary is the "remote ip address". >=20 Please see earlier response (to your comment 1). > 5) Since the remote ip address is typically not known by=20 > hosts (as you say), then is making it known now (via the new=20 > dhcp tlv) acceptable? That's more of a question for the DHCP=20 > folks I guess >=20 Yes it is perfectly acceptable and is very similar to functionality of well-established DHCP options. See e.g. RFC 2241, it defines an option for specifying NDS servers to clients.=20 > 6) Why does the BFD version need to be 1 ? BFD version=20 > negotiation procedures should negotiate the version. The=20 > *current version* could be 2 when someone goes to implement=20 > the RFC. They will get confused by the RFC. >=20 Yes I agree, BFD version should be set to the currentBFD version. Thanks, Vitali >=20 > Thanks > Nitin >=20 >=20 From rtg-bfd-bounces@ietf.org Thu Jul 31 18:09:23 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2603C3A6A2D; Thu, 31 Jul 2008 18:09:23 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89CDB3A6B45 for ; Thu, 31 Jul 2008 18:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.097 X-Spam-Level: X-Spam-Status: No, score=-6.097 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JEOxYr3djUb for ; Thu, 31 Jul 2008 18:09:21 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 49F093A6994 for ; Thu, 31 Jul 2008 18:09:21 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Thu, 31 Jul 2008 18:08:55 PDT Received: from emailcorp3.jnpr.net ([66.129.254.13]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jul 2008 18:08:05 -0700 Received: from 172.23.4.112 ([172.23.4.112]) by emailcorp3.jnpr.net ([66.129.254.13]) with Microsoft Exchange Server HTTP-DAV ; Fri, 1 Aug 2008 01:08:04 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 01 Aug 2008 02:10:17 +0100 Subject: Re: draft-vinokour-bfd-dhcp-01.txt From: Nitin Bahadur To: "Vitali Vinokour (vvinokou)" , Message-ID: Thread-Topic: draft-vinokour-bfd-dhcp-01.txt Thread-Index: Acjyj0RJphIuWjkA00GeWI8LovebbQAHjXzgADF4cMc= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Aug 2008 01:08:05.0412 (UTC) FILETIME=[0D8BE640:01C8F373] X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Vitali, Thanks for the prompt response! Please see inline below for some clarifications. On 7/31/08 3:39 AM, "Vitali Vinokour (vvinokou)" wrote: >> I have some comments regarding your draft >> draft-vinokour-bfd-dhcp-01.txt I believe the intentions of >> the draft are good. But the main question I have is - is this >> going to scale? DHCP server serves thousands of clients. You >> are talking about running BFD for each of these clients. >> Won't the DHCP server be a bottleneck? >> > > DHCP server is configuring the clients anyway. This is a standard > broadband scenario. We are just adding an option containing BFD > configuration to DHCP messages. Let me re-phrase my query. My scaling concern is regarding running thousands of BFD sessions from a DHCP server. If a DHCP server runs BFD to each of it's 30,000 clients, then the DHCP server might just die. >> If you alleviate scaling concerns by using failure >> detection intervals in the order of a few seconds, then my >> question is - is using BFD then worth it? If there is a >> failure (today, without BFD), are there cases where the >> failure is NOT detected within a few seconds. >> > While the draft primarily describes bootstrapping of BFD by DHCP on a > CPE the motivation for running BFD between IP CPE and IP Edge is to > detect IP connectivity failures. As I said, there is no established > mechanism for it today. I understand that motivation. But that motivation only holds true if your DHCP server can sustain tens of thousands of BFD sessions to the edge. >> 1) Your draft aims at boot-strapping the BFD session with BFD >> parameters. >> IMO, this is not a good idea. BFD parameters are local to a >> box and shouldn't be dictated by a remote end. BFD relies on >> parameter negotiation and your draft doesn't support that. >> The DHCP client could be running on a low-CPU box and I think >> it's better to have default BFD config on the client rather >> than have the server dictate what to use. >> > > The parameters that DHCP is conveying to CPE are not the ones that BFD > end point can negotiate. E.g. BFD does not negotiate Desired Min Tx > Interval or Required Min Rx Interval; these values are supposed to be > present in the very first message a BFD peer sends out and are supplied > by a bootstrapping application. In this case bootstrapping application > is DHCP; it happens to be distributed between server and client but it > does not change BFD bootstrapping methodology. I think you have misunderstood how BFD works. I'll explain with an example. You can run BFD over OSPF neighbors today to detect fast failure of an OSPF neighbor. In this case, OSPF programs BFD (OSPF is the client of BFD). But there is *NO* OSPF signaling involved. Each OSPF peer individually programs BFD based on whatever parameters each system seems as correct. The detection times are based off the peer's advertised values and the local system's values. I repeat, you DO NOT need to send over timing parameters in DHCP negotiation. You *DO NOT* need to signal any *bfd flags* to the peer to make BFD. > Note that this draft is targeting routing gateways that are typically > under SP control; so DHCP server (configured by the same SP) will be in > the position to provide BFD config matching CPE capabilities. You cannot write a draft that makes generic changes in DHCP and assume that no one else should implement it for their own scenario. Your above explanation of one system assuming the capabilities of the other systems is a bad assumption IMO. >> 2) Authentication seems like an issue here. You seem to be >> passing the authentication keys from server to client. So how >> are you protecting the keys...in other words, if someone can >> snoop on the keys, then someone can do nasty things. Also, it >> seemed to me that the key is going to be the same for both >> all clients (unless you provision a unique key per >> client..which doesn't sound scalable to me from a >> provisioning point of view on the >> server) and in both directions. This seems like a security >> hole (if I understand the draft correctly). >> > > Please refer to the Security section of the draft: "To ensure security > of > authentication keys, DHCP messages containing options TBD_3 or TBD_4 > with BFD authentication information MUST be authenticated using the > procedures described in [RFC3118]." > > In any case, it is not expected that BFD authentication will be used in > broadband networks. These networks have native security mechanisms (e.g. > L2 isolation). This is a security issue. Please take advice of other IETF experts and clean up this section. If BFD auth is not expected to be used then it should not be defined in DHCP. >> 3) The draft does not say whether the BFD session is going to >> be single-hop or multi-hop. > > It does not matter. It DOES matter. BFD packets are sent to different ports based on whether this is single-hop or multi-hop. If the draft does not specify whether the session is single-hop or multi-hop, then the session might never come up. >> >> 4) You have copied (almost) the entire bfd header in the dhcp >> server response. I don't think this is the right approach. >> BFD fields have nothing to do with DHCP (like the C-bit). As >> I said earlier, negotiate, negotiate and negotiate. The only >> field I see really necessary is the "remote ip address". >> > > Please see earlier response (to your comment 1). Doesn't hold. You have misunderstood how BFD works. >> 6) Why does the BFD version need to be 1 ? BFD version >> negotiation procedures should negotiate the version. The >> *current version* could be 2 when someone goes to implement >> the RFC. They will get confused by the RFC. >> > > Yes I agree, BFD version should be set to the currentBFD version. Why does the BFD version needs to be set to the current version? I fail to understand. The BFD version should be set to the version that the box supports. If the box doesn't support version 1, then how can the box set it to version 1 ? Version field is there to specify the version a box supports. It seems like you are trying to solve the problem for a *very specific* case, a case in which scaling might not be an issue. I am not clear on the applicability of the draft. But given that the changes proposed are generic, one could potentially run BFD between a DHCP server and my good old 800 MHz Linux desktop. The draft should probably specify the applicability. If the applicability is not generic enough, then it should be clarified. In any case, I fail to see why anything besides the BFD capability and the "remote peer address" are needed to make this work. Thanks Nitin From rtg-bfd-bounces@ietf.org Fri Aug 1 01:59:18 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7595328C3DA; Fri, 1 Aug 2008 01:59:18 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1F4028C3DA for ; Fri, 1 Aug 2008 01:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv821P55MiP3 for ; Fri, 1 Aug 2008 01:59:13 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 87F9228C3DE for ; Fri, 1 Aug 2008 01:59:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,292,1215388800"; d="scan'208";a="16178996" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 01 Aug 2008 08:59:11 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m718xAmj022796; Fri, 1 Aug 2008 04:59:10 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m718xAau011996; Fri, 1 Aug 2008 08:59:10 GMT Received: from xmb-rtp-214.amer.cisco.com ([64.102.31.75]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Aug 2008 04:59:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-vinokour-bfd-dhcp-01.txt Date: Fri, 1 Aug 2008 04:59:09 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-vinokour-bfd-dhcp-01.txt Thread-Index: Acjyj0RJphIuWjkA00GeWI8LovebbQAHjXzgADF4cMcADizG8A== References: From: "Vitali Vinokour (vvinokou)" To: "Nitin Bahadur" , X-OriginalArrivalTime: 01 Aug 2008 08:59:10.0679 (UTC) FILETIME=[DCF55E70:01C8F3B4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10124; t=1217581150; x=1218445150; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vvinokou@cisco.com; z=From:=20=22Vitali=20Vinokour=20(vvinokou)=22=20 |Subject:=20RE=3A=20draft-vinokour-bfd-dhcp-01.txt |Sender:=20 |To:=20=22Nitin=20Bahadur=22=20,=20; bh=aewunHyAG18D17YEzLHvIMkLSIhlJJDuZK8kdBVU3eQ=; b=PEf8Cic/IvtJYppq2TzCbsV/2H3OseXBzbo6r/MDzjELHwXm7gXzKxdps5 Eh3OlRXW6SH5bLUbSSQxUyIeTaPZSiIXyczCdSsmEFo4cDD1fe6t815oKTyD pghGHgADAj; Authentication-Results: rtp-dkim-2; header.From=vvinokou@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Nitin, Please see inline.=20 > -----Original Message----- > From: Nitin Bahadur [mailto:nitinb@juniper.net]=20 > Sent: Thursday, July 31, 2008 9:10 PM > To: Vitali Vinokour (vvinokou); rtg-bfd@ietf.org > Subject: Re: draft-vinokour-bfd-dhcp-01.txt >=20 >=20 > Hi Vitali, >=20 > Thanks for the prompt response! Please see inline below for=20 > some clarifications. >=20 > On 7/31/08 3:39 AM, "Vitali Vinokour (vvinokou)"=20 > wrote: >=20 > >> I have some comments regarding your draft=20 > >> draft-vinokour-bfd-dhcp-01.txt I believe the intentions of=20 > the draft=20 > >> are good. But the main question I have is - is this going=20 > to scale?=20 > >> DHCP server serves thousands of clients. You are talking about=20 > >> running BFD for each of these clients. > >> Won't the DHCP server be a bottleneck? > >>=20 > >=20 > > DHCP server is configuring the clients anyway. This is a standard=20 > > broadband scenario. We are just adding an option containing BFD=20 > > configuration to DHCP messages. >=20 > Let me re-phrase my query. My scaling concern is regarding=20 > running thousands of BFD sessions from a DHCP server. If a=20 > DHCP server runs BFD to each of it's 30,000 clients, then the=20 > DHCP server might just die. > =20 In a typical broadband scenario, BRAS acting as DHCP server or Relay serves tens of thousands of IP subscribers. The draft explains how BFD can be configured by DHCP server OR relay. In other words: when BRAS is acting as DHCP server, it is perfectly fine for that server to run 30,000 BFD sessions; it does scale by design. In the case of a DHCP server not collocated with BRAS, the BFD sessions terminate on the DHCP relay. =20 > >> If you alleviate scaling concerns by using failure detection=20 > >> intervals in the order of a few seconds, then my question is - is=20 > >> using BFD then worth it? If there is a failure (today,=20 > without BFD),=20 > >> are there cases where the failure is NOT detected within a few=20 > >> seconds. > >>=20 > > While the draft primarily describes bootstrapping of BFD by=20 > DHCP on a=20 > > CPE the motivation for running BFD between IP CPE and IP Edge is to=20 > > detect IP connectivity failures. As I said, there is no established=20 > > mechanism for it today. >=20 > I understand that motivation. But that motivation only holds=20 > true if your DHCP server can sustain tens of thousands of BFD=20 > sessions to the edge. >=20 See above. > >> 1) Your draft aims at boot-strapping the BFD session with BFD=20 > >> parameters. > >> IMO, this is not a good idea. BFD parameters are local to=20 > a box and=20 > >> shouldn't be dictated by a remote end. BFD relies on parameter=20 > >> negotiation and your draft doesn't support that. > >> The DHCP client could be running on a low-CPU box and I think it's=20 > >> better to have default BFD config on the client rather=20 > than have the=20 > >> server dictate what to use. > >>=20 > >=20 > > The parameters that DHCP is conveying to CPE are not the=20 > ones that BFD=20 > > end point can negotiate. E.g. BFD does not negotiate Desired Min Tx=20 > > Interval or Required Min Rx Interval; these values are=20 > supposed to be=20 > > present in the very first message a BFD peer sends out and are=20 > > supplied by a bootstrapping application. In this case bootstrapping=20 > > application is DHCP; it happens to be distributed between=20 > server and=20 > > client but it does not change BFD bootstrapping methodology. >=20 > I think you have misunderstood how BFD works. I'll explain=20 > with an example. > You can run BFD over OSPF neighbors today to detect fast=20 > failure of an OSPF neighbor. In this case, OSPF programs BFD=20 > (OSPF is the client of BFD). But there is *NO* OSPF signaling=20 > involved. Each OSPF peer individually programs BFD based on=20 > whatever parameters each system seems as correct. The=20 > detection times are based off the peer's advertised values=20 > and the local system's values. I repeat, you DO NOT need to=20 > send over timing parameters in DHCP negotiation. You *DO NOT*=20 > need to signal any *bfd flags* to the peer to make BFD. >=20 You do not need to send timing or other BFD parameters over to an OSPF peer because you can configure them locally on each peer. CPE routers are not configured locally; their configuration is either hard coded or dynamically provisioned via DHCP. Are you suggesting hard coding BFD parameters into each CPE? This is pretty much the only way to avoid some kind of remote configuration.=20 Note that the whole purpose of DHCP is to deliever *local* host configuration dynamically from a remote server. So it is quite feasible, from DHCP point of view, to deliver BFD configuration of the CPE. From BFD point of view, the only difference is that the bootstrapping function is "distributed" between DHCP server and client.=20 > =20 > > Note that this draft is targeting routing gateways that are=20 > typically=20 > > under SP control; so DHCP server (configured by the same=20 > SP) will be=20 > > in the position to provide BFD config matching CPE capabilities. >=20 > You cannot write a draft that makes generic changes in DHCP=20 > and assume that no one else should implement it for their own=20 > scenario. Your above explanation of one system assuming the=20 > capabilities of the other systems is a bad assumption IMO. > The mechanism proposed in the draft is applicable to any DHCP scenario. If specific CPE capabilities are not known to the administrator configuring the server the default should be used; any CPE supporting BFD should be able to run with default configuration. The functionality does not depend on the assumption that DHCP server is aware of CPE capabilities.=20 =20 > >> 2) Authentication seems like an issue here. You seem to be passing=20 > >> the authentication keys from server to client. So how are you=20 > >> protecting the keys...in other words, if someone can snoop on the=20 > >> keys, then someone can do nasty things. Also, it seemed to me that=20 > >> the key is going to be the same for both all clients (unless you=20 > >> provision a unique key per client..which doesn't sound=20 > scalable to me=20 > >> from a provisioning point of view on the > >> server) and in both directions. This seems like a security=20 > hole (if I=20 > >> understand the draft correctly). > >>=20 > >=20 > > Please refer to the Security section of the draft: "To=20 > ensure security=20 > > of > > authentication keys, DHCP messages containing options=20 > TBD_3 or TBD_4 > > with BFD authentication information MUST be=20 > authenticated using the > > procedures described in [RFC3118]." > >=20 > > In any case, it is not expected that BFD authentication=20 > will be used=20 > > in broadband networks. These networks have native security=20 > mechanisms (e.g. > > L2 isolation). >=20 > This is a security issue. Please take advice of other IETF=20 > experts and clean up this section. If BFD auth is not=20 > expected to be used then it should not be defined in DHCP. > =20 What exactly is a security issue? Please be more specifc. Authentication per 3118 ensures secure transmission of BFD keys; this mechanism was added in response to concerns of IETF experts.=20 > >> 3) The draft does not say whether the BFD session is going to be=20 > >> single-hop or multi-hop. > >=20 > > It does not matter. >=20 > It DOES matter. BFD packets are sent to different ports based=20 > on whether this is single-hop or multi-hop. If the draft does=20 > not specify whether the session is single-hop or multi-hop,=20 > then the session might never come up. > =20 Yes, I agree. Whether BFD session is single hop or multihop should be specified by a configuration flag. > >>=20 > >> 4) You have copied (almost) the entire bfd header in the=20 > dhcp server=20 > >> response. I don't think this is the right approach. > >> BFD fields have nothing to do with DHCP (like the C-bit).=20 > As I said=20 > >> earlier, negotiate, negotiate and negotiate. The only field I see=20 > >> really necessary is the "remote ip address". > >>=20 > >=20 > > Please see earlier response (to your comment 1). >=20 > Doesn't hold. You have misunderstood how BFD works. > =20 > >> 6) Why does the BFD version need to be 1 ? BFD version negotiation=20 > >> procedures should negotiate the version. The *current=20 > version* could=20 > >> be 2 when someone goes to implement the RFC. They will get=20 > confused=20 > >> by the RFC. > >>=20 > >=20 > > Yes I agree, BFD version should be set to the currentBFD version. >=20 > Why does the BFD version needs to be set to the current=20 > version? I fail to understand. The BFD version should be set=20 > to the version that the box supports. If the box doesn't=20 > support version 1, then how can the box set it to version 1 ?=20 > Version field is there to specify the version a box supports. >=20 The version should be set to the version which the BRAS supports. If CPE does not support BRAS version, it will fail to come up anyway. > It seems like you are trying to solve the problem for a *very=20 > specific* case, a case in which scaling might not be an=20 > issue. I am not clear on the applicability of the draft. But=20 > given that the changes proposed are generic, one could=20 > potentially run BFD between a DHCP server and my good old 800=20 > MHz Linux desktop. The draft should probably specify the=20 > applicability. If the applicability is not generic enough,=20 > then it should be clarified. >=20 Use of DHCP in broadband netowrks can hardly be classified as very specific. And there is nothing in the draft that precludes its use between any DHCP server and client. Thanks, Vitali > In any case, I fail to see why anything besides the BFD=20 > capability and the "remote peer address" are needed to make this work. >=20 > Thanks > Nitin >=20 >=20