From Bevan.Das@alcatel-lucent.com Wed Sep 14 13:20:45 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A0C21F8D14 for ; Wed, 14 Sep 2011 13:20:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZP0VttgI5R9 for ; Wed, 14 Sep 2011 13:20:44 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id C73DF21F8D22 for ; Wed, 14 Sep 2011 13:20:44 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p8EKMrle021242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 14 Sep 2011 15:22:53 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8EKMrA3024085 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 14 Sep 2011 15:22:53 -0500 Received: from USNAVSXCHMBSB2.ndc.alcatel-lucent.com ([135.3.39.128]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Wed, 14 Sep 2011 15:22:53 -0500 From: "Das, Bevan N (Bevan)" To: "rtg-bfd@ietf.org" Date: Wed, 14 Sep 2011 15:22:52 -0500 Subject: implementation of BFD in passive mode? Thread-Topic: implementation of BFD in passive mode? Thread-Index: AcxzHBRAbR9ywVzyQdeYnu/tE45omw== Message-ID: <339AB015E0D8994084533A6EE52303B0A49C28F1@USNAVSXCHMBSB2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 20:25:04 -0000 Hi, I am a software tester in Alcatel-Lucent, and part of my current work is ve= rifying BFD interoperability of one of our products with routers. In reading through RFC 5880 and in searching through web guides for BFD, I = have seen two modes possible for BFD: "active" and "passive". However, al= l the routers that I have worked with up until now only implement "active" = mode. Are there any implementations of BFD that actually use "passive" mod= e? In other words, am I safe in just verifying interoperability with route= rs in "active" mode? Thank you for your time, Bevan Das bevan.das@alcatel-lucent.com= From binnyjeshan@gmail.com Wed Sep 14 20:23:43 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836DD21F8ACA for ; Wed, 14 Sep 2011 20:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6irKmNf1796 for ; Wed, 14 Sep 2011 20:23:43 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id B09C021F8744 for ; Wed, 14 Sep 2011 20:23:42 -0700 (PDT) Received: by fxd18 with SMTP id 18so216036fxd.31 for ; Wed, 14 Sep 2011 20:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PFsWIDsgS+oSm4C13D4GnGVQkWAN/+5YIETRfSRcayo=; b=H5KwuXdvKL+iwTxwrd3yPgXpAjU2uqje2NX30V9Kq1/qtEmBAY9UMcLQfFphcXi8JG CDiiaYE+YzdNJA9GQdLAMUNvMhZnbk7KFMtHesUId8VzKKdgR8z3mMvkGxWH7JxCb3HV CueQafZI2x24Frg2XY+XADDlpVNcD7V/dLWrc= MIME-Version: 1.0 Received: by 10.223.20.18 with SMTP id d18mr955054fab.102.1316057152763; Wed, 14 Sep 2011 20:25:52 -0700 (PDT) Received: by 10.223.95.202 with HTTP; Wed, 14 Sep 2011 20:25:52 -0700 (PDT) In-Reply-To: <339AB015E0D8994084533A6EE52303B0A49C28F1@USNAVSXCHMBSB2.ndc.alcatel-lucent.com> References: <339AB015E0D8994084533A6EE52303B0A49C28F1@USNAVSXCHMBSB2.ndc.alcatel-lucent.com> Date: Thu, 15 Sep 2011 08:55:52 +0530 Message-ID: Subject: Re: implementation of BFD in passive mode? From: binny jeshan To: "Das, Bevan N (Bevan)" Content-Type: multipart/alternative; boundary=00151747b77218378604acf26f48 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 03:23:43 -0000 --00151747b77218378604acf26f48 Content-Type: text/plain; charset=ISO-8859-1 Hi Bevan, As per my understanding about BFD in passive mode, its should be implemented in all routes supporting 5880, except when explicitly passive mode is said to be not supported. I believe the Spirent Test Center BFD base package has already implemented this and you can test your SUT using it. You can test the negative scenario passive-passive too. The same applies for Poll-final sequence also. Some routers may implement this, whereas some may not. They require to bring down the session and edit the BFD session parameters. Hope this helps you. Thanks, Binny Jeshan. On 15 September 2011 01:52, Das, Bevan N (Bevan) < Bevan.Das@alcatel-lucent.com> wrote: > Hi, > > I am a software tester in Alcatel-Lucent, and part of my current work is > verifying BFD interoperability of one of our products with routers. > > In reading through RFC 5880 and in searching through web guides for BFD, I > have seen two modes possible for BFD: "active" and "passive". However, all > the routers that I have worked with up until now only implement "active" > mode. Are there any implementations of BFD that actually use "passive" > mode? In other words, am I safe in just verifying interoperability with > routers in "active" mode? > > Thank you for your time, > > Bevan Das > bevan.das@alcatel-lucent.com --00151747b77218378604acf26f48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Bevan,

As per my understanding about BFD in passive m= ode, its should be implemented in all routes supporting 5880, except when e= xplicitly passive mode is said to be not supported. I believe the Spirent T= est Center BFD base package has already implemented this and you can test y= our SUT using it. You can test the negative=A0scenario passive-passive too.=

The same applies for Poll-final sequence also. Some rou= ters may implement this, whereas some may not. They require to bring down t= he session and edit the BFD session parameters.

Hope this helps you.

Thanks,
Binny Jesha= n.

On 15 September 2011 01:52, Das, Bevan= N (Bevan) <Bevan.Das@alcatel-lucent.com> wrote:
Hi,

I am a software tester in Alcatel-Lucent, and part of my current work is ve= rifying BFD interoperability of one of our products with routers.

In reading through RFC 5880 and in searching through web guides for BFD, I = have seen two modes possible for BFD: =A0"active" and "passi= ve". =A0However, all the routers that I have worked with up until now = only implement "active" mode. =A0Are there any implementations of= BFD that actually use "passive" mode? =A0In other words, am I sa= fe in just verifying interoperability with routers in "active" mo= de?

Thank you for your time,

Bevan Das
bevan.das@alcatel-lucent.co= m

--00151747b77218378604acf26f48-- From Alexander.Vainshtein@ecitele.com Wed Sep 14 21:38:18 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE8821F85F1 for ; Wed, 14 Sep 2011 21:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.392 X-Spam-Level: X-Spam-Status: No, score=-4.392 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmrBYIvZa7qY for ; Wed, 14 Sep 2011 21:38:18 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 55F5021F8558 for ; Wed, 14 Sep 2011 21:38:17 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-9.tower-174.messagelabs.com!1316061626!25431772!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.4.1; banners=-,-,- Received: (qmail 15305 invoked from network); 15 Sep 2011 04:40:26 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-9.tower-174.messagelabs.com with SMTP; 15 Sep 2011 04:40:26 -0000 X-AuditID: 93eaf2e7-b7bd7ae00000587a-af-4e7181af202c Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id DD.92.22650.FA1817E4; Thu, 15 Sep 2011 07:40:15 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 15 Sep 2011 06:40:25 +0200 From: Alexander Vainshtein To: binny jeshan Date: Thu, 15 Sep 2011 06:40:25 +0200 Subject: RE: implementation of BFD in passive mode? Thread-Topic: implementation of BFD in passive mode? Thread-Index: AcxzVz98eonJorsJT26J5KWWiUnxOwACNxcs Message-ID: References: <339AB015E0D8994084533A6EE52303B0A49C28F1@USNAVSXCHMBSB2.ndc.alcatel-lucent.com>, 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_A3C5DF08D38B6049839A6F553B331C760111EF7BD49DILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3WTfUgTYRzHee7mOtfOzrXpowhdl71QTLZUMmr2ApJFWZFQGFHX7Wm72t3W bpkLKoOyMohKo1LKSVpZ1tDeoxdakSlGQYJmr5SVzejFxN61O69MiO6v7/2+n9/L8/B7CNzw UxtP8KIPeUXWxWh1mqJwZ5c5uGl1lqWzLjXt4Z4mbdqnH+fAVCzzYsnjQZkVFV+xeVhOPpjM iqLbx/oQbUcSZ2PmeflclvMzNG+3MVaG9rhYDglI9NkY1uNBop1J19H/fJNljBdpJHJuOy86 bMzMBXPNaWmpE81WJn3UCGvyJF22k5doZBZY3kULSJJYB6LlyLIzuPPttp2Y5+bCvKst5zX5 oHN6IYgkIJUCD1RtAaqOgfeeBLWKNlBXAKw8kl0IdLIuBrD1U0sfpKVssPbE4z7ISI2BZc01 uKJxKgcerP4SoWgNNRLurmns44dSyfBSQVeEyqfAD2fbf+vxMPS8qo8hqflwR9sdXG1WDmDg fZOmEBBEpGyE6iWFAfJwnxuqMbVXLGxtK8PUoSlYcfkurmoTfPOiJ0LlTfDR1iBQeTcMl+34 3Ssa1h9o06h8HLx+rEWzC8SUDChbMiClZECKGk+CLXuLtaoeB4+Ud+CqNsP9PSHNwHgADDoO TLzL41suOCzWJMTxPuRCSZxbqAXq7ry+AL6VJYYARQBGTy7r8WQZIthcyS+EQByBMSZSJ6+W IWq52+53spJzqXeNC0khAAmcMZKGDhkn7ax/HfK6/1gZ8u3vxuMHc255S0Xf0mSL5f8/TCz5 kns7x0A55M1chZAHef/USSAIBpJZSvtoL3KgvBW8y/fXxohIZQy9PMZshSElDytIvEP1G8Dw +FjSrhiUYjjXiP25yqvZ2NvbGwax8qGHkrkKpZffVH92WC6MyYVHlCrnk+RX02/F5wPLtIzM hEP6R4GNm7mn1jfTmBszTo5e6Y+qG1YkFPBxefsuHrq9tvHmhSkwAGrJ9DGBW4sLryWmWnQb 3nU+i3EX0DnZXUZ93fVTNe2l3aUpiYO/J4y+//Hb6fZg8PCs7si86u2f9faKtQ9+dm1p1gvG 7vDRRWLleteejiETXi0x9poYjeRkrWNxr8T+ArLDqs8QBAAA Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 04:38:19 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD49DILPTMAIL02e_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Binny, You say that some routers may not implement the poll-final sequence for BFD= and require bringing down their BFD sessions in order to change the session= parameters. I wonder how this is supposed to be compatible with the following in RFC 588= 0: >From Section 6.2 "BFD State Machine": +--+ | | UP, ADMIN DOWN, TIMER | V DOWN +------+ INIT +------------| |------------+ | | DOWN | | | +-------->| |<--------+ | | | +------+ | | | | | | | | ADMIN DOWN,| | | |ADMIN DOWN, DOWN,| | | |TIMER TIMER| | V | | V +------+ +------+ +----| | | |----+ DOWN| | INIT |--------------------->| UP | |INIT, UP +--->| | INIT, UP | |<---+ +------+ +------+ >From Section 6.8.3 "Timer Manipulation": 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. To me these two fragments mean that BFD sessions are always started as "slow= " (i.e., not faster than 1 packet/second), revert to "slow" every time they= go down, and can only progress to the desired rate via the Final/Poll negot= iation. Did I miss something substantial? Regards, Sasha ________________________________ From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of binny= jeshan [binnyjeshan@gmail.com] Sent: Thursday, September 15, 2011 5:25 AM To: Das, Bevan N (Bevan) Cc: rtg-bfd@ietf.org Subject: Re: implementation of BFD in passive mode? Hi Bevan, As per my understanding about BFD in passive mode, its should be implemented= in all routes supporting 5880, except when explicitly passive mode is said= to be not supported. I believe the Spirent Test Center BFD base package has= already implemented this and you can test your SUT using it. You can test t= he negative scenario passive-passive too. The same applies for Poll-final sequence also. Some routers may implement th= is, whereas some may not. They require to bring down the session and edit th= e BFD session parameters. Hope this helps you. Thanks, Binny Jeshan. On 15 September 2011 01:52, Das, Bevan N (Bevan) > wrote: Hi, I am a software tester in Alcatel-Lucent, and part of my current work is ver= ifying BFD interoperability of one of our products with routers. In reading through RFC 5880 and in searching through web guides for BFD, I h= ave seen two modes possible for BFD: "active" and "passive". However, all= the routers that I have worked with up until now only implement "active" mo= de. Are there any implementations of BFD that actually use "passive" mode?= In other words, am I safe in just verifying interoperability with routers= in "active" mode? Thank you for your time, Bevan Das bevan.das@alcatel-lucent.com This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD49DILPTMAIL02e_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
Binny,
You say that some routers may not implem= ent the poll-final sequence for BFD and require bringing down their BFD sess= ions in order to change the session parameters.
 
I wonder how this is supposed to be comp= atible with the following in RFC 5880:
 
From Section 6.2 "BFD State Machine= ":
<quote>
                             +--+
                             |  | UP, ADMIN DOWN, TIMER
                             |  V
                     DOWN  +------+  INIT
              +------------|      |------------+
              |            | DOWN |            |
              |  +-------->|      |<--------+  |
              |  |         +------+         |  |
              |  |                          |  |
              |  |               ADMIN DOWN,|  |
              |  |ADMIN DOWN,          DOWN,|  |
              |  |TIMER                TIMER|  |
              V  |                          |  V
            +------+                      +------+
       +----|      |                      |      |----+
   DOWN|    | INIT |--------------------->|  UP  |    |INIT, UP
       +--->|      | INIT, UP             |      |<---+
            +------+                      +------+
<end quote>
 
From Section 6.8.3 "Timer Manipulat= ion":
<quote>
   When bfd.SessionState is not Up, the system MU=
ST set
   bfd.DesiredMinTxInterval to a value of not less than one se=
cond
   (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.<=
/pre>
<end quote>
 
To me these two fragments mean that BFD sessions= are always started as "slow" (i.e., not faster than 1 packet/seco= nd), revert to "slow" every time they go down, and can only progress to the desired rate via the Final/Poll negotiation= .
 
Did I miss something substantial?=
 
Regards,
     Sasha
From: rtg-bfd-boun= ces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of binny jeshan [binnyjesh= an@gmail.com]
Sent: Thursday, September 15, 2011 5:25 AM
To: Das, Bevan N (Bevan)
Cc: rtg-bfd@ietf.org
Subject: Re: implementation of BFD in passive mode?

Hi Bevan,

As per my understanding about BFD in passive mode, its should be implem= ented in all routes supporting 5880, except when explicitly passive mode is= said to be not supported. I believe the Spirent Test Center BFD base packag= e has already implemented this and you can test your SUT using it. You can test the negative scenario= passive-passive too.

The same applies for Poll-final sequence also. Some routers may impleme= nt this, whereas some may not. They require to bring down the session and ed= it the BFD session parameters.

Hope this helps you.

Thanks,
Binny Jeshan.

On 15 September 2011 01:52, Das, Bevan N (Bevan)= <Bevan.Das@alcatel-lucent= .com> wrote:
Hi,

I am a software tester in Alcatel-Lucent, and part of my current work is ver= ifying BFD interoperability of one of our products with routers.

In reading through RFC 5880 and in searching through web guides for BFD, I h= ave seen two modes possible for BFD:  "active" and "pass= ive".  However, all the routers that I have worked with up until n= ow only implement "active" mode.  Are there any implementatio= ns of BFD that actually use "passive" mode?  In other words, am= I safe in just verifying interoperability with routers in "active"= ; mode?

Thank you for your time,

Bevan Das
bevan.das@alcatel-lucent.com=

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD49DILPTMAIL02e_-- From binnyjeshan@gmail.com Wed Sep 14 22:29:22 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DB821F86DD for ; Wed, 14 Sep 2011 22:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SGFVdPVvi2c for ; Wed, 14 Sep 2011 22:29:21 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 56D5721F86EE for ; Wed, 14 Sep 2011 22:29:04 -0700 (PDT) Received: by fxd18 with SMTP id 18so286932fxd.31 for ; Wed, 14 Sep 2011 22:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ei58503ZGAt4QtYeY7c/NPaoAJoEvzsXJWsne6y09kk=; b=S3wchdhHdfivrpabVDue7dV3vjzqs0YKYvca6/BTNA/BLqkCHebR2X3iry5rrT19Xq lJXSj7fcnrln8ztS75O6ESTjvQGMsNUhc+miBWDBGYz+xbHpt4Mg2RABkBVVAuMFQjur LSaMTcbGoZrFE4cKRnvYMErRsS5aeovPJKEL4= MIME-Version: 1.0 Received: by 10.223.50.154 with SMTP id z26mr1144179faf.64.1316064674594; Wed, 14 Sep 2011 22:31:14 -0700 (PDT) Received: by 10.223.95.202 with HTTP; Wed, 14 Sep 2011 22:31:14 -0700 (PDT) In-Reply-To: References: <339AB015E0D8994084533A6EE52303B0A49C28F1@USNAVSXCHMBSB2.ndc.alcatel-lucent.com> Date: Thu, 15 Sep 2011 11:01:14 +0530 Message-ID: Subject: Re: implementation of BFD in passive mode? From: binny jeshan To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=00151747c35c6e3ea704acf42fc3 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 05:29:22 -0000 --00151747c35c6e3ea704acf42fc3 Content-Type: text/plain; charset=ISO-8859-1 Hi Sasha, Your points are correct. In the same section, i find the below aspects also. * * *The time values used to determine BFD packet transmission intervals and the session Detection Time may be modified at any time without affecting the state of the session. When the timer parameters are changed for any reason, the requirements of this section apply.* ** * * *If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up, the actual transmission interval used MUST NOT change until the Poll Sequence described above has terminated. This is to ensure that the remote system updates its Detection Time before the transmission interval increases.* ** * * Changing timers can be done in two ways as per my understanding. 1. Router A operator can initiate the timing change through poll request and at the end of the poll sequence the new timer values are applied. 2. Route A and B can bring the session Admin Down, Change its timers and start-off again.. Slow interval can be used in below cases as per my understanding. 1. When session starts up in Down state 2. When session goes down due to any defects When you start a session, you need not do a polling, since the timer negotiation section 6.8.2, will be used, and not the polling. Polling will be used only when timer is 'modified'. Why some routers may not implement Polling? One reason could be that in cases if BFD is accelerated in a Fast Path ASIC (for sub-second interval configurations), it becomes hard to change parameters in run-time using polling without affecting the running session. This is due to implementation limitations at hardware level. In such case, these routers allow polling for sessions running at software. Thanks for the question.. Regards, Binny Jeshan On 15 September 2011 10:10, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Binny, > You say that some routers may not implement the poll-final sequence for BFD > and require bringing down their BFD sessions in order to change the session > parameters. > > I wonder how this is supposed to be compatible with the following in RFC > 5880: > > From Section 6.2 "BFD State Machine": > > > +--+ > | | UP, ADMIN DOWN, TIMER > | V > DOWN +------+ INIT > +------------| |------------+ > | | DOWN | | > | +-------->| |<--------+ | > | | +------+ | | > | | | | > | | ADMIN DOWN,| | > | |ADMIN DOWN, DOWN,| | > | |TIMER TIMER| | > V | | V > +------+ +------+ > +----| | | |----+ > DOWN| | INIT |--------------------->| UP | |INIT, UP > +--->| | INIT, UP | |<---+ > +------+ +------+ > > > > From Section 6.8.3 "Timer Manipulation": > > > 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. > > > > To me these two fragments mean that BFD sessions are always started as > "slow" (i.e., not faster than 1 packet/second), revert to "slow" every time > they go down, and can only progress to the desired rate via the Final/Pollnegotiation. > > Did I miss something substantial? > > Regards, > Sasha > ------------------------------ > *From:* rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of > binny jeshan [binnyjeshan@gmail.com] > *Sent:* Thursday, September 15, 2011 5:25 AM > *To:* Das, Bevan N (Bevan) > *Cc:* rtg-bfd@ietf.org > *Subject:* Re: implementation of BFD in passive mode? > > Hi Bevan, > > As per my understanding about BFD in passive mode, its should be > implemented in all routes supporting 5880, except when explicitly passive > mode is said to be not supported. I believe the Spirent Test Center BFD base > package has already implemented this and you can test your SUT using it. You > can test the negative scenario passive-passive too. > > The same applies for Poll-final sequence also. Some routers may implement > this, whereas some may not. They require to bring down the session and edit > the BFD session parameters. > > Hope this helps you. > > Thanks, > Binny Jeshan. > > On 15 September 2011 01:52, Das, Bevan N (Bevan) < > Bevan.Das@alcatel-lucent.com> wrote: > >> Hi, >> >> I am a software tester in Alcatel-Lucent, and part of my current work is >> verifying BFD interoperability of one of our products with routers. >> >> In reading through RFC 5880 and in searching through web guides for BFD, I >> have seen two modes possible for BFD: "active" and "passive". However, all >> the routers that I have worked with up until now only implement "active" >> mode. Are there any implementations of BFD that actually use "passive" >> mode? In other words, am I safe in just verifying interoperability with >> routers in "active" mode? >> >> Thank you for your time, >> >> Bevan Das >> bevan.das@alcatel-lucent.com > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us > by e-mail, phone or fax, and then delete the original and all copies > thereof. > --00151747c35c6e3ea704acf42fc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Sasha,

Your points are correct. In the same section, = i find the below aspects also.

<quote>= ;
The time values=
 used to determine BFD packet transmission intervals
   and the session Detection Time may be modified at any time without
   affecting the state of the session.  When the timer para=
meters are
   changed for any reason, the requirements of this section apply.
<end>

<quote>
If bfd.DesiredMinTxI=
nterval is increased and bfd.SessionState is Up,
   the actual transmi=
ssion interval used MUST NOT change until the Poll
   Sequence described above has terminated.  This is to ensure that the
   remote system updates its Detection Time before the transmission
   interval increases.
<end>

Changing timers can be done in two = ways as per my understanding.=A0

1. Router A operator can initiate the timing change thr= ough poll request and at the end of the poll sequence the new timer values = are applied.
2. Route A and B can bring the session Admin Down, Change i= ts timers and start-off again..

Slow interval can be used in below cases as per my unde= rstanding.
1. When session starts up in Down state
2. W= hen session goes down due to any defects

When you = start a session, you need not do a polling, since the timer negotiation sec= tion=A06.8.2,=A0will be used, and not the pollin= g.
Polling will be used only when timer is 'modified'.=A0

Why some routers may not implement Polling?=A0
= One reason could be that in cases if BFD is accelerated in a Fast Path ASIC= (for sub-second interval configurations), it becomes hard to change parame= ters in run-time using polling without affecting the running session. This = is due to implementation limitations at hardware level. In such case, these= routers allow polling for sessions running at software.

Thanks for the question..

Rega= rds,
Binny Jeshan


On 15 September 2011 10:10, Alexander Vainshtein <Alexander.Vainshte= in@ecitele.com> wrote:
Binny,
You say that some routers may not imple= ment the poll-final sequence for BFD and require bringing down their BFD se= ssions in order to change the session parameters.
=A0
I wonder how this is supposed to be com= patible with the following in RFC 5880:
=A0
From Section 6.2 "BFD State Machin= e":
<quote>
                             +--+
                             |  | UP, ADMIN DOWN, TIMER
                             |  V
                     DOWN  +------+  INIT
              +------------|      |------------+
              |            | DOWN |            |
              |  +-------->|      |<--------+  |
              |  |         +------+         |  |
              |  |                          |  |
              |  |               ADMIN DOWN,|  |
              |  |ADMIN DOWN,          DOWN,|  |
              |  |TIMER                TIMER|  |
              V  |                          |  V
            +------+                      +------+
       +----|      |                      |      |----+
   DOWN|    | INIT |--------------------->|  UP  |    |INIT, UP
       +--->|      | INIT, UP             |      |<---+
            +------+                      +------+
<end quote>
=A0
From Section 6.8.3 "Timer Manipula= tion":
<quote>
   When bfd.SessionState=
 is not Up, the system MUST set
   bfd.DesiredMinTxInterval to a value of not less than one s=
econd
   (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.=
<end quote>
=A0
To me these two fragments mean that BFD session= s are always started as "slow" (i.e., not faster than 1 packet/se= cond), revert to "slow" every time they go=A0down,=A0and can only progress to the desired rate via the Final/Poll negotiatio= n.
=A0
Did I miss something substantial?
=A0
Regards,
=A0=A0=A0=A0 Sasha
From: rtg-bfd-bounces@ietf.org= [rtg-bfd= -bounces@ietf.org] On Behalf Of binny jeshan [binnyjeshan@gmail.com]
Sent: Thursday, September 15, 2011 5:25 AM
To: Das, Bevan N (Bevan)
Cc: rtg-bfd@ie= tf.org
Subject: Re: implementation of BFD in passive mode?

Hi Bevan,

As per my understanding about BFD in passive mode, its should be imple= mented in all routes supporting 5880, except when explicitly passive mode i= s said to be not supported. I believe the Spirent Test Center BFD base pack= age has already implemented this and you can test your SUT using it. You can test the negative=A0scenario p= assive-passive too.

The same applies for Poll-final sequence also. Some routers may implem= ent this, whereas some may not. They require to bring down the session and = edit the BFD session parameters.

Hope this helps you.

Thanks,
Binny Jeshan.

On 15 September 2011 01:52, Das, Bevan N (Bevan) <Bevan= .Das@alcatel-lucent.com> wrote:
Hi,

I am a software tester in Alcatel-Lucent, and part of my current work is ve= rifying BFD interoperability of one of our products with routers.

In reading through RFC 5880 and in searching through web guides for BFD, I = have seen two modes possible for BFD: =A0"active" and "passi= ve". =A0However, all the routers that I have worked with up until now = only implement "active" mode. =A0Are there any implementations of BFD that actually use "passive" mode? =A0In other words, am I= safe in just verifying interoperability with routers in "active"= mode?

Thank you for your time,

Bevan Das
bevan.das= @alcatel-lucent.com

This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.


--00151747c35c6e3ea704acf42fc3-- From Alexander.Vainshtein@ecitele.com Thu Sep 15 00:57:05 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E632621F84D5 for ; Thu, 15 Sep 2011 00:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.414 X-Spam-Level: X-Spam-Status: No, score=-4.414 tagged_above=-999 required=5 tests=[AWL=0.788, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ToxURFS+IeX for ; Thu, 15 Sep 2011 00:57:02 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 1613C21F84D7 for ; Thu, 15 Sep 2011 00:57:00 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-14.tower-216.messagelabs.com!1316073505!18337555!22 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.4.1; banners=-,-,- Received: (qmail 28356 invoked from network); 15 Sep 2011 07:59:10 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-14.tower-216.messagelabs.com with SMTP; 15 Sep 2011 07:59:10 -0000 X-AuditID: 93eaf2e7-b7bd7ae00000587a-3e-4e71b04306c8 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 59.CB.22650.340B17E4; Thu, 15 Sep 2011 10:58:59 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 15 Sep 2011 09:59:08 +0200 From: Alexander Vainshtein To: binny jeshan Date: Thu, 15 Sep 2011 09:59:07 +0200 Subject: RE: implementation of BFD in passive mode? Thread-Topic: implementation of BFD in passive mode? Thread-Index: AcxzaLCvJla+/ieOQ9m+2sbqWVhntQAEsqRQ Message-ID: References: <339AB015E0D8994084533A6EE52303B0A49C28F1@USNAVSXCHMBSB2.ndc.alcatel-lucent.com> 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_A3C5DF08D38B6049839A6F553B331C760111EFD4BFD2ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3WTa0gUURTHuTP7GDcnxnXV29JjGE3K2nB9gD22ohIsyMwkyg/ZNHvdHdqd XXc2yQo0SiUjyh6IRrmFhZhiSUX5oFoJSoKCiszXFw0fq2kWbUZpMwyaEM2n/z3nd8//zOUc AteXaY0EL3iRR2AdjEanujQy+c209W5eevzgzLKU7ovvNClffz0Em7G0x1W92rSamiksA8su AhtYQXB5WS+irUjkLEyGh89nuQKG5q0WxszQbgfLIScSvBaGdbuRYGU26uh/vg0Sxgs0EjiX lRdsFmb7nl2mlJTktSYzszE22py4Xpdl50UamZws76CdSBRZG6KlyMH7uP1WxTTm9gfB0ebf L/EiEOwEZYAgIJUEz9TuKwMhkoyEb/oaNWVAR+ipNgArxse1yuEygMN9E1qZ0lAW2HSnVyNr A7UCVn+4h8sap7LhtfofalmrqOWwof0kkHU4lQibS76pFT4JTjwYUsvGBioBXi8ulMMktRte fT6KKV5NGBwt7dLITIiU+O3bIjNAai7YUY8pVlGwa6AaU5qmYE3ra1zREXC4f1qt8BGwp7QR KLwLBsr7VIpXGHxZOaBS+EXwWW2n6gKIrJpXtmrelap5V5T4auhrmdQoehW8fSOAz+pXT/ux +XEf0NaBCN7h9h5y2uLNaxDHe5EDreFcziagDM/gI/CzOsYPKAIwoeTBaXe6Xs3miwVOP1hE YEwEubIxL12/8JDLWmBnRXuO54gDiX4ACZwxkPqAhJNWtuAY8rhmU6nS45fjxgWcSxpTwZuT GB///wMTRX7iRnfqKZs0mocRciPPbJ3FBMFAcki2D/MgGzqayzu8f9MYESK3ESq1UdwgMaTo Zp0ib1PyHcBEXKg4/QLoVYJLQMYoclIuRMmQ/YgwV0deocKZmZkRECU9QDjZK1Oh0oLNVRqR TDDJJPqq/K+itEJzKWMRiNmRGWz+3loR/mPb0OeGsy0tzJOE2O7Gc7Et7UunHrb1TL03nFhS V/zYeCku8+b1jlO9B4Z9FtXxr0v2ftGNOFMLg3Hly9iFY5FrU0+Urj/Preu6WBKAbwN0U3KJ sdXatnlpt+FK+/4if752X6CYy93kid5myvvV9dE49r3SaBKyGJVoZ81xuEdk/wCA9cHfHQQA AA== Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 07:57:06 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111EFD4BFD2ILPTMAIL02e_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Jinny, Lots of thanks for a prompt response. I am not sure that changing the parameters in AdminDown state of the session= is compliant with 5880. Please note that the fragment I've quoted refers to the situation when the B= FD session is not Up, which clearly includes AdminDown. Note also that the session may go Down for natural reasons (if they were not= , why should we bother to set them up anyway?), and should resume their orig= inal fast operation once they come up back. Last but not least, I am aware of at least two implementations that use BFD= HW accelerators (what you call the fast path ASICs) to support intervals an= d timers in the millisecond range combined with 5880-compliant Final/Poll pr= ocessing in SW. The protocol has been specifically designed to facilitate th= is kind of HW/SW interaction IMO. Regards, Sasha From: binny jeshan [mailto:binnyjeshan@gmail.com] Sent: Thursday, September 15, 2011 8:31 AM To: Alexander Vainshtein Cc: rtg-bfd@ietf.org; Robert Rennison Subject: Re: implementation of BFD in passive mode? Hi Sasha, Your points are correct. In the same section, i find the below aspects also. The time values used to determine BFD packet transmission intervals and the session Detection Time may be modified at any time without affecting the state of the session. When the timer parameters are changed for any reason, the requirements of this section apply. If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up, the actual transmission interval used MUST NOT change until the Poll Sequence described above has terminated. This is to ensure that the remote system updates its Detection Time before the transmission interval increases. Changing timers can be done in two ways as per my understanding. 1. Router A operator can initiate the timing change through poll request and= at the end of the poll sequence the new timer values are applied. 2. Route A and B can bring the session Admin Down, Change its timers and sta= rt-off again.. Slow interval can be used in below cases as per my understanding. 1. When session starts up in Down state 2. When session goes down due to any defects When you start a session, you need not do a polling, since the timer negotia= tion section 6.8.2, will be used, and not the polling. Polling will be used only when timer is 'modified'. Why some routers may not implement Polling? One reason could be that in cases if BFD is accelerated in a Fast Path ASIC= (for sub-second interval configurations), it becomes hard to change paramet= ers in run-time using polling without affecting the running session. This is= due to implementation limitations at hardware level. In such case, these ro= uters allow polling for sessions running at software. Thanks for the question.. Regards, Binny Jeshan On 15 September 2011 10:10, Alexander Vainshtein > wrote: Binny, You say that some routers may not implement the poll-final sequence for BFD= and require bringing down their BFD sessions in order to change the session= parameters. I wonder how this is supposed to be compatible with the following in RFC 588= 0: >From Section 6.2 "BFD State Machine": +--+ | | UP, ADMIN DOWN, TIMER | V DOWN +------+ INIT +------------| |------------+ | | DOWN | | | +-------->| |<--------+ | | | +------+ | | | | | | | | ADMIN DOWN,| | | |ADMIN DOWN, DOWN,| | | |TIMER TIMER| | V | | V +------+ +------+ +----| | | |----+ DOWN| | INIT |--------------------->| UP | |INIT, UP +--->| | INIT, UP | |<---+ +------+ +------+ >From Section 6.8.3 "Timer Manipulation": 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. To me these two fragments mean that BFD sessions are always started as "slow= " (i.e., not faster than 1 packet/second), revert to "slow" every time they= go down, and can only progress to the desired rate via the Final/Poll negot= iation. Did I miss something substantial? Regards, Sasha ________________________________ From: rtg-bfd-bounces@ietf.org [rtg-bfd-bou= nces@ietf.org] On Behalf Of binny jeshan [b= innyjeshan@gmail.com] Sent: Thursday, September 15, 2011 5:25 AM To: Das, Bevan N (Bevan) Cc: rtg-bfd@ietf.org Subject: Re: implementation of BFD in passive mode? Hi Bevan, As per my understanding about BFD in passive mode, its should be implemented= in all routes supporting 5880, except when explicitly passive mode is said= to be not supported. I believe the Spirent Test Center BFD base package has= already implemented this and you can test your SUT using it. You can test t= he negative scenario passive-passive too. The same applies for Poll-final sequence also. Some routers may implement th= is, whereas some may not. They require to bring down the session and edit th= e BFD session parameters. Hope this helps you. Thanks, Binny Jeshan. On 15 September 2011 01:52, Das, Bevan N (Bevan) > wrote: Hi, I am a software tester in Alcatel-Lucent, and part of my current work is ver= ifying BFD interoperability of one of our products with routers. In reading through RFC 5880 and in searching through web guides for BFD, I h= ave seen two modes possible for BFD: "active" and "passive". However, all= the routers that I have worked with up until now only implement "active" mo= de. Are there any implementations of BFD that actually use "passive" mode?= In other words, am I safe in just verifying interoperability with routers= in "active" mode? Thank you for your time, Bevan Das bevan.das@alcatel-lucent.com This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760111EFD4BFD2ILPTMAIL02e_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Jinny,<= /o:p>

Lots of thanks for a prompt respo= nse.

 

I am not sure that changing the parameters i= n AdminDown state of the session is compliant with 5880.

Please note that the fragment I’ve quoted= refers to the situation when the BFD session is not Up,  which clearly= includes AdminDown.

Note= also that the session may go Down for natural reasons (if they were not, wh= y should we bother to set them up anyway?), and should resume their original= fast operation once they come up back.

 

Last but= not least, I am aware of at least two implementations that use BFD HW accel= erators (what you call the fast path ASICs) to support intervals and timers= in the millisecond range combined with 5880-compliant Final/Poll processing= in SW. The protocol has been specifically designed to facilitate this kind= of HW/SW interaction IMO.

 

Regards,<= /span>

     Sasha

 

From: binny jeshan [mailto:binnyjeshan@gmail.com= ]
Sent: Thursday, September 15, 2011 8:31 AM
To: Alexan= der Vainshtein
Cc: rtg-bfd@ietf.org; Robert Rennison
Subject= : Re: implementation of BFD in passive mode?

=

 

Hi Sash= a,

 

<= p class=3DMsoNormal>Your points are correct. In the same section, i find the= below aspects also.

&nbs= p;

<quote>

 
The time values used to determine BFD packet transmission intervals
   and the session Detectio=
n Time may be modified at any time without<=
o:p>
 &n=
bsp; affecting the state of the session.  When the timer parameters are
   changed for any reason, the requirements of this section apply.=

<end>
 
<quote>
If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up,=

   the actual transmission interval used MUST NOT change until=
 the Poll
   Sequence desc=
ribed above has terminated.  This is to ensure that the
   remote system updates its Detection Ti=
me before the transmission
 &nb=
sp; interval increases.
<en=
d>

Changing timers can be done in two ways as per= my understanding. 

 =

1. Router A operator can initiate= the timing change through poll request and at the end of the poll sequence= the new timer values are applied.
2. Route A and B can bring the session= Admin Down, Change its timers and start-off again..

 

= Slow interval can be used in below cases as per my understanding.=

1. When session starts up in Down state<= o:p>

2. When session goes down due= to any defects

 

When you start a session, you need no= t do a polling, since the timer negotiation section 6.8.2, will be used, and not the polling.

Polling will be used only when t= imer is 'modified'. 

 

Why some routers may not im= plement Polling? 

One rea= son could be that in cases if BFD is accelerated in a Fast Path ASIC (for su= b-second interval configurations), it becomes hard to change parameters in r= un-time using polling without affecting the running session. This is due to= implementation limitations at hardware level. In such case, these routers a= llow polling for sessions running at software.

 

Thanks= for the question..

 = ;

Regards,

Binny Jeshan

 

 <= /p>

On 15 September 2011 10:10, Alexander Vainshtei= n <Alexander.Vainshte= in@ecitele.com> wrote:

Binny,

You say that some routers may no= t implement the poll-final sequence for BFD and require bringing down their= BFD sessions in order to change the session parameters.

 

I= wonder how this is supposed to be compatible with the following in RFC 5880= :

 

From Section 6.2 "BFD State Machine":

<= quote>

          =
;            &nb=
sp;      +--+
      &nb=
sp;            &=
nbsp;         |  | UP, ADMIN DO=
WN, TIMER
           &n=
bsp;             =
;    |  V
       =
;            &nb=
sp; DOWN  +------+  INIT
       =
;       +------------|    =
  |------------+
         &n=
bsp;    |        &nbs=
p;   | DOWN |         =
;   |
          &n=
bsp;   |  +-------->|      |<-=
-------+  |
          &=
nbsp;   |  |        =
 +------+         |  |
 &nbs=
p;            | =
 |            &n=
bsp;            =
 |  |
           &=
nbsp;  |  |         &=
nbsp;     ADMIN DOWN,|  |
    &nb= sp;         |  |ADMIN DOWN,&nbs= p;         DOWN,|  |= 
  =
            |  |=
TIMER            =
;    TIMER|  |
       =
;       V  |     =
;            &nb=
sp;        |  V
   &nbs=
p;        +------+    =
;            &nb=
sp;     +------+
       +---=
-|      |       =
            &nbs=
p;  |      |----+
=
   DOWN|  =
  | INIT |--------------------->|  UP  |   =
 |INIT, UP
       +--->|   &nb=
sp;  | INIT, UP         &n=
bsp;   |      |<---+=

   &=
nbsp;        +------+   &n=
bsp;            =
      +------+

<end quote>

 

<= /div>

From Section 6.8.= 3 "Timer Manipulation":

<quote>

= 
   W=
hen bfd.SessionState is not Up, the system MUST set
<= pre>   bfd.DesiredMi= nTxInterval to a value of not less than one second   (1,000,000 mic= roseconds).  This is intended to ensure that the
   bandwidth c=
onsumed by BFD sessions that are not Up is negligible,
   particular=
ly in the case where a neighbor may not be running BFD.

<end quote>=

 <= /o:p>

= To me these two fragments mean that BFD sessions are always started as "= ;slow" (i.e., not faster than 1 packet/second), revert to "slow&qu= ot; every time they go down, and can only progress to the desired= rate via the Final/Poll negotiation.

 

Did I miss something= substantial?

 

Regards,

     Sasha<= o:p>

From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf O= f binny jeshan [b= innyjeshan@gmail.com]
Sent: Thursday, September 15, 2011 5:25= AM
To: Das, Bevan N (Bevan)
Cc: rtg-bfd@ietf.org
Subject: Re: i= mplementation of BFD in passive mode?

Hi Bevan,

 

As per my understanding about BFD in pass= ive mode, its should be implemented in all routes supporting 5880, except wh= en explicitly passive mode is said to be not supported. I believe the Spiren= t Test Center BFD base package has already implemented this and you can test= your SUT using it. You can test the negative scenario passive-passive= too.

 

The same applies for Poll-final sequence also. Some r= outers may implement this, whereas some may not. They require to bring down= the session and edit the BFD session parameters.

 

Hope this= helps you.

 

Thanks,

Bin= ny Jeshan.

On 15 September 2011 0= 1:52, Das, Bevan N (Bevan) <Bevan.Das@alcatel-lucent.com> wrote:

Hi,

I= am a software tester in Alcatel-Lucent, and part of my current work is veri= fying BFD interoperability of one of our products with routers.

In re= ading through RFC 5880 and in searching through web guides for BFD, I have s= een two modes possible for BFD:  "active" and "passive&q= uot;.  However, all the routers that I have worked with up until now on= ly implement "active" mode.  Are there any implementations of= BFD that actually use "passive" mode?  In other words, am I= safe in just verifying interoperability with routers in "active"= mode?

Thank you for your time,

Bevan Das
bevan.das@alcatel-lucent.co= m

 

This e-ma= il message is intended for the recipient only and contains information which= is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have re= ceived this transmission in error, please inform us by e-mail, phone or fax,= and then delete the original and all copies thereof.

<= /div>

 

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C760111EFD4BFD2ILPTMAIL02e_-- From binnyjeshan@gmail.com Thu Sep 15 02:02:11 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7021621F84F8 for ; Thu, 15 Sep 2011 02:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJL5u88dv09Y for ; Thu, 15 Sep 2011 02:02:10 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29FA421F84E1 for ; Thu, 15 Sep 2011 02:02:09 -0700 (PDT) Received: by fxd18 with SMTP id 18so481736fxd.31 for ; Thu, 15 Sep 2011 02:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O2ADwgnPqe33RpQ/fYUjl3gmLY3MyEpD0REcREestvs=; b=c81C++OJ5P1Q/oMemNlvzJqBk30iD5T3Ex69hflkJbvepDnC2DuyJQfUZpwYhUQ29d zBZfE6wtiebQtAdAr36VGAmDFEd5Nk0Dqsyd4yVm6QKIDdYRQ7ir1siisYZyBy1oLJQE KNsg8vVBYOg0u1Csyj/LDIirC3nMJ4mkRC3XI= MIME-Version: 1.0 Received: by 10.223.33.10 with SMTP id f10mr87042fad.121.1316077459821; Thu, 15 Sep 2011 02:04:19 -0700 (PDT) Received: by 10.223.95.202 with HTTP; Thu, 15 Sep 2011 02:04:19 -0700 (PDT) In-Reply-To: References: <339AB015E0D8994084533A6EE52303B0A49C28F1@USNAVSXCHMBSB2.ndc.alcatel-lucent.com> Date: Thu, 15 Sep 2011 14:34:19 +0530 Message-ID: Subject: Re: implementation of BFD in passive mode? From: binny jeshan To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=0015174484787d565f04acf72950 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 09:02:11 -0000 --0015174484787d565f04acf72950 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Sasha, True. It is required to have poll/final to complete the 5880 compliance. Ma= y be it could take some more time for those devices who aren't doing it now :) Also for Bevan's original Q, i hope passive mode is available in all routers. Some more thoughts: If a session goes down for natural reasons like packet loss, session will continue at "Slow rate". If the session comes up naturally again, there nee= d not be a poll-final since there was no change made to it. Similarly, when the session is in Down due to natural reasons, and operator wishes to change the interval, poll sequence will be initiated, completed and upon complete transmission will start at newer time interval, after which a session may come up or may not. (Example case:.. typically could be used if there is partial traffic loss and toggling BFD states) Going in Admin Down case, my understanding is that at one point we stop sending BFD packets in Admin Down state and resume sending only on Admin Up= . There is no clear definition of what happens in between. But, its clearly mentioned that in AdminDown State do not receive packets(that includes poll/final/other).. And, IMO changing BFD parameters is operator's decision and could be allowed Only issue could be that timer change should be done a= t both ends before waking the sessions up.. Else, there could be a LOC. What is your thought on Admin Down otherwise? What is allowed to be done after Admin Down? Regards, Binny On 15 September 2011 13:29, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Jinny,**** > > Lots of thanks for a prompt response.**** > > ** ** > > I am not sure that changing the parameters in AdminDown state of the > session is compliant with 5880.**** > > Please note that the fragment I=92ve quoted refers to the situation when = the > BFD session is not Up, which clearly includes AdminDown.**** > > Note also that the session may go Down for natural reasons (if they were > not, why should we bother to set them up anyway?), and should resume thei= r > original fast operation once they come up back.**** > > ** ** > > Last but not least, I am aware of at least two implementations that use B= FD > HW accelerators (what you call the fast path ASICs) to support intervals = and > timers in the millisecond range combined with 5880-compliant Final/Poll > processing in SW. The protocol has been specifically designed to facilita= te > this kind of HW/SW interaction IMO. **** > > ** ** > > Regards,**** > > Sasha**** > > ** ** > > *From:* binny jeshan [mailto:binnyjeshan@gmail.com] > *Sent:* Thursday, September 15, 2011 8:31 AM > *To:* Alexander Vainshtein > *Cc:* rtg-bfd@ietf.org; Robert Rennison > > *Subject:* Re: implementation of BFD in passive mode?**** > > ** ** > > Hi Sasha,**** > > ** ** > > Your points are correct. In the same section, i find the below aspects > also.**** > > ** ** > > **** > > ** ** > > *The time values used to determine BFD packet transmission intervals* > > * and the session Detection Time may be modified at any time without* > > * affecting the state of the session**. When the timer parameters are* > > * changed for any reason**, the requirements of this section apply.****= * > > ****** > > * > * > > ** ** > > **** > > *If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up,* > > * the actual transmission interval used MUST NOT change until the Poll* > > * Sequence described above has terminated. This is to ensure that the* > > * remote system updates its Detection Time before the transmission* > > * interval increases.***** > > ****** > > * > * > > Changing timers can be done in two ways as per my understanding. **** > > ** ** > > 1. Router A operator can initiate the timing change through poll request > and at the end of the poll sequence the new timer values are applied. > 2. Route A and B can bring the session Admin Down, Change its timers and > start-off again..**** > > ** ** > > Slow interval can be used in below cases as per my understanding.**** > > 1. When session starts up in Down state**** > > 2. When session goes down due to any defects**** > > ** ** > > When you start a session, you need not do a polling, since the timer > negotiation section *6.8.2,* will be used, and not the polling.**** > > Polling will be used only when timer is 'modified'. **** > > ** ** > > Why some routers may not implement Polling? **** > > One reason could be that in cases if BFD is accelerated in a Fast Path AS= IC > (for sub-second interval configurations), it becomes hard to change > parameters in run-time using polling without affecting the running sessio= n. > This is due to implementation limitations at hardware level. In such case= , > these routers allow polling for sessions running at software.**** > > ** ** > > Thanks for the question..**** > > ** ** > > Regards,**** > > Binny Jeshan**** > > ** ** > > ** ** > > On 15 September 2011 10:10, Alexander Vainshtein < > Alexander.Vainshtein@ecitele.com> wrote:**** > > Binny,**** > > You say that some routers may not implement the poll-final sequence for B= FD > and require bringing down their BFD sessions in order to change the sessi= on > parameters.**** > > **** > > I wonder how this is supposed to be compatible with the following in RFC > 5880:**** > > **** > > From Section 6.2 "BFD State Machine":**** > > **** > > +--+**** > > | | UP, ADMIN DOWN, TIMER**** > > | V**** > > DOWN +------+ INIT**** > > +------------| |------------+**** > > | | DOWN | |**** > > | +-------->| |<--------+ |**** > > | | +------+ | |**** > > | | | |**** > > | | ADMIN DOWN,| |**** > > | |ADMIN DOWN, DOWN,| |**** > > | |TIMER TIMER| |**** > > V | | V**** > > +------+ +------+**** > > +----| | | |----+**** > > DOWN| | INIT |--------------------->| UP | |INIT, UP**** > > +--->| | INIT, UP | |<---+**** > > +------+ +------+**** > > **** > > **** > > From Section 6.8.3 "Timer Manipulation":**** > > **** > > 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.**** > > **** > > **** > > To me these two fragments mean that BFD sessions are always started as > "slow" (i.e., not faster than 1 packet/second), revert to "slow" every ti= me > they go down, and can only progress to the desired rate via the Final/Pol= l > negotiation.**** > > **** > > Did I miss something substantial?**** > > **** > > Regards,**** > > Sasha**** > ------------------------------ > > *From:* rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of > binny jeshan [binnyjeshan@gmail.com] > *Sent:* Thursday, September 15, 2011 5:25 AM > *To:* Das, Bevan N (Bevan) > *Cc:* rtg-bfd@ietf.org > *Subject:* Re: implementation of BFD in passive mode?**** > > Hi Bevan, **** > > ** ** > > As per my understanding about BFD in passive mode, its should be > implemented in all routes supporting 5880, except when explicitly passive > mode is said to be not supported. I believe the Spirent Test Center BFD b= ase > package has already implemented this and you can test your SUT using it. = You > can test the negative scenario passive-passive too.**** > > ** ** > > The same applies for Poll-final sequence also. Some routers may implement > this, whereas some may not. They require to bring down the session and ed= it > the BFD session parameters.**** > > ** ** > > Hope this helps you.**** > > ** ** > > Thanks,**** > > Binny Jeshan.**** > > On 15 September 2011 01:52, Das, Bevan N (Bevan) < > Bevan.Das@alcatel-lucent.com> wrote:**** > > Hi, > > I am a software tester in Alcatel-Lucent, and part of my current work is > verifying BFD interoperability of one of our products with routers. > > In reading through RFC 5880 and in searching through web guides for BFD, = I > have seen two modes possible for BFD: "active" and "passive". However, = all > the routers that I have worked with up until now only implement "active" > mode. Are there any implementations of BFD that actually use "passive" > mode? In other words, am I safe in just verifying interoperability with > routers in "active" mode? > > Thank you for your time, > > Bevan Das > bevan.das@alcatel-lucent.com**** > > ** ** > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform u= s > by e-mail, phone or fax, and then delete the original and all copies > thereof. **** > > ** ** > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform u= s > by e-mail, phone or fax, and then delete the original and all copies > thereof. > --0015174484787d565f04acf72950 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Sasha,

True. It is required to have poll/final to com= plete the 5880 compliance. May be it could take some more time for those de= vices who aren't =A0doing it now :)

Also for B= evan's original Q, i hope passive mode is available in all routers.

Some more thoughts:
If a session goes down fo= r natural reasons like packet loss, session will continue at "Slow rat= e". If the session comes up naturally again, there need not be a poll-= final since there was no change made to it.
Similarly, when the session is in Down due to natural reasons, and ope= rator wishes to change the interval, poll sequence will be initiated, compl= eted and upon complete transmission will start at newer time interval, afte= r which a session may come up or may not. (Example case:.. typically could = be used if there is partial traffic loss and toggling BFD states)=A0

Going in Admin Down case, my understanding is that at o= ne point we stop sending BFD packets in Admin Down state and resume sending= only on Admin Up. There is no clear definition of what happens in between.= But, its clearly mentioned that in AdminDown State do not receive packets(= that includes poll/final/other).. And, IMO changing BFD parameters is opera= tor's decision and could be allowed Only issue could be that timer chan= ge should be done at both ends before waking the sessions up.. Else, there = could be a LOC.

What is your thought on Admin Down otherwise? What is a= llowed to be done after Admin Down?=A0

Regards,
Binny

On 15 Sep= tember 2011 13:29, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com= > wrote:

Jinny,

Lots = of thanks for a prompt response.

=A0

I am not sure that changing = the parameters in AdminDown state of the session is compliant with 5880.=

Please note that the fragment I=92ve quoted refers to the = situation when the BFD session is not Up, =A0which clearly includes AdminDo= wn.

Note = also that the session may go Down for natural reasons (if they were not, wh= y should we bother to set them up anyway?), and should resume their origina= l fast operation once they come up back.

=A0

Last but not least, I am aware of at least two implementa= tions that use BFD HW accelerators (what you call the fast path ASICs) to s= upport intervals and timers in the millisecond range combined with 5880-com= pliant Final/Poll processing in SW. The protocol has been specifically desi= gned to facilitate this kind of HW/SW interaction IMO.

=A0

Regards,

<= span style=3D"font-size:11.0pt;color:#1F497D">=A0=A0=A0=A0 Sasha<= /u>

=A0

From:= binny jeshan [mailto:binnyjeshan@gmail.com]
Se= nt: Thursday, September 15, 2011 8:31 AM
To: Alexander Vainshtein
Cc: rtg-bfd@ietf.org; Robert Rennison


Subject: Re: implementation of B= FD in passive mode?

=A0

Hi Sasha,<= /p>

=A0

Your points are correct. In the same section, i find the below aspects also= .

=A0

<= /div>

<quote>

= 
=A0
The time values used to determine BFD packet transmis=
sion intervals
=A0=A0 and the session Detectio=
n Time may be modified at any time without=

=A0=A0 affecting the state of the session=
. <=
span style=3D"background:#FFFF33">=A0When the timer parameters are
=A0=A0 changed for any reason<=
span style=3D"font-family:"Georgia","serif"">, the requ=
irements of this section apply.
&=
lt;end>

=A0
<quote><=
u>
If bfd.DesiredMinTxInterval is increased and bfd.Sess=
ionState is Up,
=
=A0=A0 the actual transmission interval us=
ed MUST NOT change until the Poll
= 
=A0=A0=
 Sequence described above has terminated.=A0 This is to ensure that the<=
/u>
=A0=A0 remote system updates its Detection Time b=
efore the transmission
=
=A0=A0 interval increases.
<end>

Changing tim= ers can be done in two ways as per my understanding.=A0

=A0

1. Router A operator= can initiate the timing change through poll request and at the end of the = poll sequence the new timer values are applied.
2. Route A and B can bri= ng the session Admin Down, Change its timers and start-off again..

=A0

Slow interval can be used in below cases as per my understan= ding.

1. When session st= arts up in Down state

2. When session goes down due to any defe= cts

=A0

When you start a session, you need not d= o a polling, since the timer negotiation section=A06.8.2,=A0will be used, and not the polling.

Polling will be used only when timer is &= #39;modified'.=A0

=A0

Why some routers may n= ot implement Polling?=A0

One reason could be that in cases if BFD = is accelerated in a Fast Path ASIC (for sub-second interval configurations)= , it becomes hard to change parameters in run-time using polling without af= fecting the running session. This is due to implementation limitations at h= ardware level. In such case, these routers allow polling for sessions runni= ng at software.

=A0

Thanks for the question..

=A0

Reg= ards,

Binny Jeshan

=

=A0

=A0

On 15 September 2011 10:10, A= lexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:

Binny,=

You say that some routers may not implement the poll-final sequenc= e for BFD and require bringing down their BFD sessions in order to change t= he session parameters.

=A0=

I wonder how this is supposed to be compatible with the following in RFC = 5880:

=A0=

From Section 6.2 "BFD State Machine":

<= /div>

<quote><= /u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 +--+
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 | UP, ADMIN DOWN, TIMER
=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0|=A0 V<=
u>
=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DOWN=A0 +------+=
=A0 INIT
=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 +------------|=A0=A0=A0=A0=A0 |------------+<=
/span>
=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | DOWN |=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 |=A0 +-------->|=A0=A0=A0=A0=A0 |<--------+=A0 |
=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 +---=
---+=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 |
=A0=A0=A0=A0=A0=A0=A0 =
=A0=A0=A0=A0=A0=A0|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ADMIN DOWN,|=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 |=A0 |ADMIN DOWN,=A0=A0=A0=A0=A0=A0=A0=A0=A0 DOWN,|=A0 |=

=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 |TIMER=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 TIMER|=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 V=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 V
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-----=
-+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------+<=
u>
=A0=A0=A0=A0=A0=A0 +----=
|=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 |=A0=A0=A0=A0=A0 |----+
=A0=A0 DOWN|=A0=A0=A0 | INIT |----------=
----------->|=A0 UP=A0 |=A0=A0=A0 |INIT, UP
=A0=A0=A0=A0=A0=A0 +---&=
gt;|=A0=A0=A0=A0=A0 | INIT, UP=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=
=A0=A0=A0 |<---+
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------+=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------+

<end quote= >

=A0

From Section 6.8.3 "Timer Manipulation= ":

<quote>= 

=A0=A0 When bfd.SessionState is not Up, the system MUST set<=
/u>
=A0=A0 bfd.DesiredMinTxI=
nterval to a value of not less than one second
=A0=A0 (1,000,000 microsec= onds).=A0 This is intended to ensure that the 
=A0=A0 bandwidth consume=
d by BFD sessions that are not Up is negligible,
= 
=A0=A0 particularly in t=
he case where a neighbor may not be running BFD.

<end quote= >

=A0

To me these two fragments mean that BFD ses= sions are always started as "slow" (i.e., not faster than 1 packe= t/second), revert to "slow" every time they go=A0down,=A0and can = only progress to the desired rate via the Final/Poll negotiation.=

=A0=

Did I miss something substantial?

=A0

Regards,

=A0=A0=A0=A0= Sasha

From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Beh= alf Of binny jeshan [binnyjeshan@gmail.com]
Sent: Thursday, September 15, 2011 5:25 AM
To: Das, Bevan = N (Bevan)
Cc: rtg-bfd@ietf.org
Subject: Re: implementation of BFD in pas= sive mode?

Hi = Bevan,

=A0

= As per my understanding about BFD in passive mo= de, its should be implemented in all routes supporting 5880, except when ex= plicitly passive mode is said to be not supported. I believe the Spirent Te= st Center BFD base package has already implemented this and you can test yo= ur SUT using it. You can test the negative=A0scenario passive-passive too.<= u>

=A0=

The same applies for Poll-final sequence also. Some routers may implement= this, whereas some may not. They require to bring down the session and edi= t the BFD session parameters.

=A0=

Hope this helps you.

=A0

Thanks,

This e-mail message is intended for the re= cipient only and contains information which is CONFIDENTIAL and which may b= e proprietary to ECI Telecom. If you have received this transmission in err= or, please inform us by e-mail, phone or fax, and then delete the original = and all copies thereof.

=A0

<= /div>

This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.


--0015174484787d565f04acf72950-- From gregimirsky@gmail.com Thu Sep 15 10:13:03 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F2021F88A0; Thu, 15 Sep 2011 10:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOoMnX2C0E2Z; Thu, 15 Sep 2011 10:13:02 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5F921F8558; Thu, 15 Sep 2011 10:13:02 -0700 (PDT) Received: by gxk9 with SMTP id 9so3291310gxk.40 for ; Thu, 15 Sep 2011 10:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VK1j4kprTSPE/srMnLNRXgPxf7zSjcl9V3E3ZM9wxyo=; b=GuVzwQeWdNlITOLm6t4kDMojsHBULuohf+Ql4QhnvzMPxysx8l7ohEcSPZEuiK8vI2 PJgaG48GoZ2vGdrSxRamDOI1mTO/xgaXo+ggqINMAYUEifCwrH9/SNPwHtX6iRkyXSqR wDVUfmdIvHaJl84DA9q90wurCP1Kl0xJLyYdI= MIME-Version: 1.0 Received: by 10.52.66.70 with SMTP id d6mr357612vdt.351.1316106914494; Thu, 15 Sep 2011 10:15:14 -0700 (PDT) Received: by 10.52.158.73 with HTTP; Thu, 15 Sep 2011 10:15:14 -0700 (PDT) In-Reply-To: References: <339AB015E0D8994084533A6EE52303B0A49C28F1@USNAVSXCHMBSB2.ndc.alcatel-lucent.com> Date: Thu, 15 Sep 2011 10:15:14 -0700 Message-ID: Subject: Re: implementation of BFD in passive mode? From: Greg Mirsky To: Alexander Vainshtein Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" , mpls@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 17:13:03 -0000 Dear Sasha, I believe that changing timers through taking session into Admin Down is compliant with RFC 5880. It is mentioned in parameter update method in MPLS-TP CC-CV-RDI. Section 3.7.1: In the rare circumstance where an operator has a reason to further change session parameters, beyond the initial migration from default values; poll/final discipline can be used with the caveat that a peer implementation may consider a session change unacceptable and/or bring the BFD session down via the use of the ADMIN DOWN state. Regards, Greg On Thu, Sep 15, 2011 at 12:59 AM, Alexander Vainshtein wrote: > Jinny, > > Lots of thanks for a prompt response. > > > > I am not sure that changing the parameters in AdminDown state of the sess= ion > is compliant with 5880. > > Please note that the fragment I=92ve quoted refers to the situation when = the > BFD session is not Up, =A0which clearly includes AdminDown. > > Note also that the session may go Down for natural reasons (if they were > not, why should we bother to set them up anyway?), and should resume thei= r > original fast operation once they come up back. > > > > Last but not least, I am aware of at least two implementations that use B= FD > HW accelerators (what you call the fast path ASICs) to support intervals = and > timers in the millisecond range combined with 5880-compliant Final/Poll > processing in SW. The protocol has been specifically designed to facilita= te > this kind of HW/SW interaction IMO. > > > > Regards, > > =A0=A0=A0=A0 Sasha > > > > From: binny jeshan [mailto:binnyjeshan@gmail.com] > Sent: Thursday, September 15, 2011 8:31 AM > To: Alexander Vainshtein > Cc: rtg-bfd@ietf.org; Robert Rennison > > Subject: Re: implementation of BFD in passive mode? > > > > Hi Sasha, > > > > Your points are correct. In the same section, i find the below aspects al= so. > > > > > > > > The time values used to determine BFD packet transmission intervals > > =A0=A0 and the session Detection Time may be modified at any time without > > =A0=A0 affecting the state of the session. =A0When the timer parameters a= re > > =A0=A0 changed for any reason, the requirements of this section apply. > > > > > > > > If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up, > > =A0=A0 the actual transmission interval used MUST NOT change until the Po= ll > > =A0=A0 Sequence described above has terminated.=A0 This is to ensure that= the > > =A0=A0 remote system updates its Detection Time before the transmission > > =A0=A0 interval increases. > > > > Changing timers can be done in two ways as per my understanding. > > > > 1. Router A operator can initiate the timing change through poll request = and > at the end of the poll sequence the new timer values are applied. > 2. Route A and B can bring the session Admin Down, Change its timers and > start-off again.. > > > > Slow interval can be used in below cases as per my understanding. > > 1. When session starts up in Down state > > 2. When session goes down due to any defects > > > > When you start a session, you need not do a polling, since the timer > negotiation section=A06.8.2,=A0will be used, and not the polling. > > Polling will be used only when timer is 'modified'. > > > > Why some routers may not implement Polling? > > One reason could be that in cases if BFD is accelerated in a Fast Path AS= IC > (for sub-second interval configurations), it becomes hard to change > parameters in run-time using polling without affecting the running sessio= n. > This is due to implementation limitations at hardware level. In such case= , > these routers allow polling for sessions running at software. > > > > Thanks for the question.. > > > > Regards, > > Binny Jeshan > > > > > > On 15 September 2011 10:10, Alexander Vainshtein > wrote: > > Binny, > > You say that some routers may not implement the poll-final sequence for B= FD > and require bringing down their BFD sessions in order to change the sessi= on > parameters. > > > > I wonder how this is supposed to be compatible with the following in RFC > 5880: > > > > From Section 6.2 "BFD State Machine": > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 +--+ > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 |=A0 | UP, ADMIN DOWN, TIMER > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0= =A0=A0=A0=A0|=A0 V > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DOWN=A0 +---= ---+=A0 INIT > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------|=A0=A0=A0=A0=A0 |--= ----------+ > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 | DOWN |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +-------->|=A0=A0=A0=A0=A0 |= <--------+=A0 | > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 +-= -----+=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 | > > =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 | > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 ADMIN DOWN,|=A0 | > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 |ADMIN DOWN,=A0=A0=A0=A0=A0= =A0=A0=A0=A0 DOWN,|=A0 | > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 |TIMER=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 TIMER|=A0 | > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 V=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 V > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------+ > > =A0=A0=A0=A0=A0=A0 +----|=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0 |----+ > > =A0=A0 DOWN|=A0=A0=A0 | INIT |--------------------->|=A0 UP=A0 |=A0=A0=A0= |INIT, UP > > =A0=A0=A0=A0=A0=A0 +--->|=A0=A0=A0=A0=A0 | INIT, UP=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0 |<---+ > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------+ > > > > > > From Section 6.8.3 "Timer Manipulation": > > > > =A0=A0 When bfd.SessionState is not Up, the system MUST set > > =A0=A0 bfd.DesiredMinTxInterval to a value of not less than one second > > =A0=A0 (1,000,000 microseconds).=A0 This is intended to ensure that the > > =A0=A0 bandwidth consumed by BFD sessions that are not Up is negligible, > > =A0=A0 particularly in the case where a neighbor may not be running BFD. > > > > > > To me these two fragments mean that BFD sessions are always started as > "slow" (i.e., not faster than 1 packet/second), revert to "slow" every ti= me > they go=A0down,=A0and can only progress to the desired rate via the Final= /Poll > negotiation. > > > > Did I miss something substantial? > > > > Regards, > > =A0=A0=A0=A0 Sasha > > ________________________________ > > From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of bi= nny > jeshan [binnyjeshan@gmail.com] > Sent: Thursday, September 15, 2011 5:25 AM > To: Das, Bevan N (Bevan) > Cc: rtg-bfd@ietf.org > Subject: Re: implementation of BFD in passive mode? > > Hi Bevan, > > > > As per my understanding about BFD in passive mode, its should be implemen= ted > in all routes supporting 5880, except when explicitly passive mode is sai= d > to be not supported. I believe the Spirent Test Center BFD base package h= as > already implemented this and you can test your SUT using it. You can test > the negative=A0scenario passive-passive too. > > > > The same applies for Poll-final sequence also. Some routers may implement > this, whereas some may not. They require to bring down the session and ed= it > the BFD session parameters. > > > > Hope this helps you. > > > > Thanks, > > Binny Jeshan. > > On 15 September 2011 01:52, Das, Bevan N (Bevan) > wrote: > > Hi, > > I am a software tester in Alcatel-Lucent, and part of my current work is > verifying BFD interoperability of one of our products with routers. > > In reading through RFC 5880 and in searching through web guides for BFD, = I > have seen two modes possible for BFD: =A0"active" and "passive". =A0Howev= er, all > the routers that I have worked with up until now only implement "active" > mode. =A0Are there any implementations of BFD that actually use "passive" > mode? =A0In other words, am I safe in just verifying interoperability wit= h > routers in "active" mode? > > Thank you for your time, > > Bevan Das > bevan.das@alcatel-lucent.com > > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform u= s > by e-mail, phone or fax, and then delete the original and all copies > thereof. > > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform u= s > by e-mail, phone or fax, and then delete the original and all copies > thereof. From manav.bhatia@alcatel-lucent.com Fri Sep 16 05:25:05 2011 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3F721F8B72 for ; Fri, 16 Sep 2011 05:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.284 X-Spam-Level: X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAJBTjMilSfz for ; Fri, 16 Sep 2011 05:25:05 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 2C23A21F8B34 for ; Fri, 16 Sep 2011 05:25:05 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p8GCREqc012544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 16 Sep 2011 07:27:16 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8GCRDwY021544 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 16 Sep 2011 17:57:14 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.59]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 16 Sep 2011 17:57:13 +0530 From: "Bhatia, Manav (Manav)" To: "rtg-bfd@ietf.org" Date: Fri, 16 Sep 2011 17:57:14 +0530 Subject: Generic crypto BFD draft Thread-Topic: Generic crypto BFD draft Thread-Index: Acx0a/cS6JbXASIZTOud41+4Gt/RVw== Message-ID: <7C362EEF9C7896468B36C9B79200D8350D002F1916@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 12:25:05 -0000 Hi, As part of the BFD WG rechartering we have posted a generic crypto authenti= cation mechanism for BFD that provides support for both algorithm and key a= gility. The second draft, which discusses how we can specifically do SHA2 a= nd HMAC-SHA2 will follow in some time. The generic crypto draft is available here: http://www.ietf.org/internet-drafts/draft-bhatia-bfd-generic-crypto-authen-= 00.txt=20 Would be great if the WG can review this and provide comments. Cheers, Manav=