From rtg-bfd-bounces@ietf.org Mon Aug 21 07:09:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF7dz-0006Qa-Sj; Mon, 21 Aug 2006 07:08:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF7dz-0006QV-CB for rtg-bfd@ietf.org; Mon, 21 Aug 2006 07:08:35 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF7dy-0000zm-6V for rtg-bfd@ietf.org; Mon, 21 Aug 2006 07:08:35 -0400 Received: by py-out-1112.google.com with SMTP id z59so1179251pyg for ; Mon, 21 Aug 2006 04:08:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fNBGoa7tZdMRUIjlxMyDLlKjBjqAwX8Ned8dMWdhgrlA6bKCEgdyi2s3IywBNAeV9xfN/pSFNAtHuIGN6zeasGk1AfMivs9XCJJTkhKlzHdSGvucyQRh0GKITXdsXKv3Z/QsMV8ik7WZKaHbHxTszYyQ8k+Evl9cLqOCUQdNve0= Received: by 10.35.49.4 with SMTP id b4mr13058319pyk; Mon, 21 Aug 2006 04:08:33 -0700 (PDT) Received: by 10.35.8.5 with HTTP; Mon, 21 Aug 2006 04:08:33 -0700 (PDT) Message-ID: Date: Mon, 21 Aug 2006 16:38:33 +0530 From: "Abhishek Verma" To: rtg-bfd@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: Interop Required for Routing with BFD X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org Hi, I have a question wrt Interoperability of routing protocols support in BFD. Cisco (or some other vendor) supports BFD with BGP and I am not sure if it is based on any specific standard. I believe its a simple implementation of draft-ietf-bfd-base-05.txt. The question is, if I implement the generic BFD standard for layer-3, when used with BGP or RIP would it be interoperable with the Cisco (or any other vendor) implementation? Thanks, Abhishek From rtg-bfd-bounces@ietf.org Wed Aug 30 04:00:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIKz0-0002Mx-Qd; Wed, 30 Aug 2006 03:59:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIKxf-0001ZN-Aq for rtg-bfd@ietf.org; Wed, 30 Aug 2006 03:58:11 -0400 Received: from mx1-012.rad.co.il ([212.199.240.8] helo=antivir1.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIKl0-0003sk-1Z for rtg-bfd@ietf.org; Wed, 30 Aug 2006 03:45:10 -0400 Received: from antivir1.rad.co.il (localhost [127.0.0.1]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k7U7cbt8004038 for ; Wed, 30 Aug 2006 10:38:37 +0300 (IDT) Received: from exrad3.ad.rad.co.il (exrad2 [192.114.24.112]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k7U7caZf004035 for ; Wed, 30 Aug 2006 10:38:36 +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_01C6CC10.F4AA66F3" Date: Wed, 30 Aug 2006 10:47:42 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D1B79D3@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Detect Multiplier Change Thread-index: AcbMEP3wgRjrBZmcT7azlHie05BaFA== From: "Oren Geron" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: Detect Multiplier Change X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6CC10.F4AA66F3 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, If I understand correctly, In Asynchronous mode, only when the = DesiredMinTxInterval or RequiredMinRxInterval is changed we set the Poll (P) bit. I find it useful to set the Poll bit when changing the Detection = Multiplier value as well. By doing so, we let the remote system know that it should update its = Detection time. The other alternative is to calculate the detection time after each BFD = packet reception (even if the DesiredMinTxInterval or = RequiredMinRxInterval has not changed), just for the possibility that the Detection Multiplier has changed. Can you please clarify this issue ? Regards, Oren. ------_=_NextPart_001_01C6CC10.F4AA66F3 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Detect Multiplier Change

Hi,

If I understand correctly, In = Asynchronous mode, only when the DesiredMinTxInterval or = RequiredMinRxInterval

is changed we set the Poll = (P) bit.

I find it useful to set the = Poll bit when changing the Detection Multiplier value as = well.

By doing so, we let the = remote system know that it should update its Detection time.

The = other alternative is to calculate the detection time after each BFD = packet reception (even if the DesiredMinTxInterval or RequiredMinRxInterval = has not changed),

just for = the possibility that the Detection Multiplier has = changed.

Can you = please clarify this issue ?

Regards,

        Oren.





------_=_NextPart_001_01C6CC10.F4AA66F3-- From rtg-bfd-bounces@ietf.org Wed Aug 30 20:20:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIaIJ-0006JN-J7; Wed, 30 Aug 2006 20:20:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIaII-0006I1-OX for rtg-bfd@ietf.org; Wed, 30 Aug 2006 20:20:30 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIa6q-0008OY-OY for rtg-bfd@ietf.org; Wed, 30 Aug 2006 20:08:42 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k7V08d1Z049276; Wed, 30 Aug 2006 17:08:40 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k7V08Zg87370; Wed, 30 Aug 2006 17:08:39 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D1B79D3@exrad3.ad.rad.co.il> References: <457D36D9D89B5B47BC06DA869B1C815D1B79D3@exrad3.ad.rad.co.il> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-19-434556513 Message-Id: <2D2D58FB-CFDA-49B2-AEE9-A5F4F277E46D@juniper.net> From: Dave Katz Date: Wed, 30 Aug 2006 17:08:19 -0700 To: Oren Geron X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: rtg-bfd@ietf.org Subject: Re: Detect Multiplier Change X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --Apple-Mail-19-434556513 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Aug 30, 2006, at 1:47 AM, Oren Geron wrote: > Hi, > > If I understand correctly, In Asynchronous mode, only when the > DesiredMinTxInterval or RequiredMinRxInterval > > is changed we set the Poll (P) bit. > > I find it useful to set the Poll bit when changing the Detection > Multiplier value as well. > > By doing so, we let the remote system know that it should update > its Detection time. > > The other alternative is to calculate the detection time after each > BFD packet reception (even if the DesiredMinTxInterval or > RequiredMinRxInterval has not changed), > > just for the possibility that the Detection Multiplier has changed. The Poll bit is necessary for the interval changes because the system changing the intervals needs to know that the remote end is aware of the changes before actually changing the transmission rate (lest the sending system start sending packets more slowly and the session times out.) I don't see much utility in what you suggest here, since it's not particularly difficult to calculate the detection time (it's certainly a whole lot cheaper than the act of receiving the packet. Even if it were useful, it would arguably require a version number change to rely on, since no implementation in the field does this currently and there would be no way otherwise to know if it did. What part of calculating the detection time on every packet do you find unreasonable? --Dave --Apple-Mail-19-434556513 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Aug 30, 2006, = at 1:47 AM, Oren Geron wrote:

Hi,

If I understand correctly, = In Asynchronous mode, only when the DesiredMinTxInterval or = RequiredMinRxInterval

is changed we set the Poll (P) bit.

I find it useful to set the = Poll bit when changing the Detection Multiplier value as = well.

By doing = so, we let the remote system know that it should update its Detection = time.

The other alternative is to calculate the detection time = after each BFD packet reception (even if the DesiredMinTxInterval or = RequiredMinRxInterval has not changed),

just for = the possibility that the Detection Multiplier has = changed.

The Poll bit is necessary for the = interval changes because the system changing the intervals needs to know = that the remote end is aware of the changes before actually changing the = transmission rate (lest the sending system start sending packets more = slowly and the session times out.)

I don't see much utility in = what you suggest here, since it's not particularly difficult to = calculate the detection time (it's certainly a whole lot cheaper than = the act of receiving the packet.=A0 Even if it were useful, it would = arguably require a version number change to rely on, since no = implementation in the field does this currently and there would be no = way otherwise to know if it did.

What part of calculating the = detection time on every packet do you find unreasonable?

--Dave

= --Apple-Mail-19-434556513--