From rtg-bfd-bounces@ietf.org Sun Jun 11 19:50:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZgv-0004Fm-Kg; Sun, 11 Jun 2006 19:50:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZgu-0004Fh-Sn for rtg-bfd@ietf.org; Sun, 11 Jun 2006 19:50:00 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpZgq-00046C-G2 for rtg-bfd@ietf.org; Sun, 11 Jun 2006 19:50:00 -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 k5BNnt1Z056911; Sun, 11 Jun 2006 16:49:55 -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 k5BNnt540990; Sun, 11 Jun 2006 16:49:55 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <20060530051413.40645.qmail@web53814.mail.yahoo.com> References: <20060530051413.40645.qmail@web53814.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D5AACD1-D536-4F68-B7CE-159653321B64@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Sun, 11 Jun 2006 16:49:53 -0700 To: "Dr. Soumitra Sinha Roy" X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: rtg-bfd@ietf.org Subject: Re: Regarding Demultiplexing of BFD Control Packets 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 Not sure if this was ever replied to... On May 29, 2006, at 10:14 PM, Dr. Soumitra Sinha Roy wrote: > Sir, > In draft-ietf-bfd-base-04.txt Sec 6.3 (Page 18), It is > mentioned that " Once the remote end echoes back the > local administrator, all further received packets are > demultiplexed based on the Your duscriminator field > only(which means that, among other things , the source > address field can change, or the interface over which > the packets are recived can change, but the packets > will still be associated with proper session.)" > > Does this mean that Suppose we have two routers RT1 > and RT2. > > A session is established between Rt1 and Rt2 at I1 > interface.My Discriminator for RT1 At I1 is X. My > Discriminator for Rt2 is Y at Interface I1.and session > state for Rt2 is init.Now, If I send a packet at I2 > interface of RT1 with Your Discriminator as > Y(My.Discriminator of Rt2 at I1) and My. Discriminator > = X , then Rt2 will send a BFD Packet with session > state 3 at Interface I1. The states and interfaces are immaterial (as is, for that matter, the value of My Discriminator, which is free to change.) The point of the spec is that if a packet is received on any interface that has Your Discriminator nonzero, that value is used to find the session and the protocol mechanism does whatever it needs to do based on the receipt of that packet. The choice of outgoing interface is highly dependent on the scenario; for the one hop case it is tightly bound, but for the multihop case the received packets may arrive on any interface, and the outgoing interface choice may be based on routing, for example. --Dave From rtg-bfd-bounces@ietf.org Tue Jun 13 23:57:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqMVb-0003hq-0F; Tue, 13 Jun 2006 23:57:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqMVZ-0003hk-BZ for rtg-bfd@ietf.org; Tue, 13 Jun 2006 23:57:33 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqMVY-0000ft-1O for rtg-bfd@ietf.org; Tue, 13 Jun 2006 23:57:33 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5E3vVX78862 for ; Tue, 13 Jun 2006 20:57:31 -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 k5E3vQ579899 for ; Tue, 13 Jun 2006 20:57:26 -0700 (PDT) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: quoted-printable Message-Id: Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed To: bfd From: Dave Katz Date: Tue, 13 Jun 2006 20:57:23 -0700 X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: Updated Specs 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 I've just sent off updated versions of all of the Two Daves' specs =20 (base, 1hop, multihop, generic) to the Secretariat. They should be =20 posted shortly. The only technical changes are fixing verbiage around asymmetric echo =20= timers in the base spec (which I missed on the last version, oops) =20 and documenting the officially assigned port number for multihop. I bit the bullet and moved all of the control-protocol-specific stuff =20= out of the 1hop and into the generic (which is probably misnamed, but =20= we can revisit the name when it goes to RFC so as to not generate =20 administrative headaches.) A lot of text got shredded and glued back =20= together, so it's worth a close read. Since the docs are done "early" (as in more than 12 hours prior to =20 the meeting cutoff) we will have time to revisit them once more prior =20= to Montr=E9al, so I would appreciate it if folks would take a close =20 look at the Generic draft in particular. If I've made any egregious =20 mistakes, I can fix them prior to the meeting and then hopefully move =20= to RFC on this stuff. Thanks, Dave'n'Dave From rtg-bfd-bounces@ietf.org Wed Jun 14 12:07:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXtV-0008Ih-9Y; Wed, 14 Jun 2006 12:07:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXtU-0008IZ-Ve for rtg-bfd@ietf.org; Wed, 14 Jun 2006 12:07:00 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXtS-0000hJ-Ht for rtg-bfd@ietf.org; Wed, 14 Jun 2006 12:07:00 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 14 Jun 2006 09:06:58 -0700 X-IronPort-AV: i="4.06,132,1149490800"; d="scan'208"; a="324961444:sNHT39153012" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5EG6vmB006279; Wed, 14 Jun 2006 09:06:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5EG6v9s029338; Wed, 14 Jun 2006 09:06:57 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 09:06:57 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 09:06:57 -0700 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Wed, 14 Jun 2006 11:06:56 -0500 From: David Ward To: Dave Katz , bfd , David Ward Message-ID: Thread-Topic: Updated Specs Thread-Index: AcaPzI7jzY1SP/u/EdqhKQAKlcR7kg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 14 Jun 2006 16:06:57.0118 (UTC) FILETIME=[8F8DE7E0:01C68FCC] DKIM-Signature: a=rsa-sha1; q=dns; l=1701; t=1150301217; x=1151165217; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=dward@cisco.com; z=From:David=20Ward=20 |Subject:Re=3A=20Updated=20Specs; X=v=3Dcisco.com=3B=20h=3DxSASTF9WcbH6rrgcKSJuXs50IPk=3D; b=gjOe0j7Ey+wHKDHP3+u6P4FR3SqK2hxxYthIvxBWU6zTEv90w/lrqaI4qPumu+qd+q7NsNUG I5Pw+hYJfeOitEetNerMjUots/mBqca8cdpJjpTUHiKovXwGFe3Rh7Hk; Authentication-Results: sj-dkim-1.cisco.com; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: Re: Updated Specs 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 All - Note that pending any edits, nits to be picked or other mods ... We will attempt to WG LC these drafts after Montreal (there is not going to be a WG meeting). So, please consider this your last chance to make comments as I would like LC to to be a simple procedural wait period if at all possible. We will need to update the MIB to match the new port numbers and any other changes as appropriate and then I will be sending out a request for implementation reports. -DWard On 6/13/06 10:57 PM, "Dave Katz" wrote: > I've just sent off updated versions of all of the Two Daves' specs > (base, 1hop, multihop, generic) to the Secretariat. They should be > posted shortly. >=20 > The only technical changes are fixing verbiage around asymmetric echo > timers in the base spec (which I missed on the last version, oops) > and documenting the officially assigned port number for multihop. >=20 > I bit the bullet and moved all of the control-protocol-specific stuff > out of the 1hop and into the generic (which is probably misnamed, but > we can revisit the name when it goes to RFC so as to not generate > administrative headaches.) A lot of text got shredded and glued back > together, so it's worth a close read. >=20 > Since the docs are done "early" (as in more than 12 hours prior to > the meeting cutoff) we will have time to revisit them once more prior > to Montr=E9al, so I would appreciate it if folks would take a close > look at the Generic draft in particular. If I've made any egregious > mistakes, I can fix them prior to the meeting and then hopefully move > to RFC on this stuff. >=20 > Thanks, >=20 > Dave'n'Dave From rtg-bfd-bounces@ietf.org Wed Jun 14 12:09:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXwF-0001wH-3m; Wed, 14 Jun 2006 12:09:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXwD-0001w2-DB for rtg-bfd@ietf.org; Wed, 14 Jun 2006 12:09:49 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXwC-00016U-5W for rtg-bfd@ietf.org; Wed, 14 Jun 2006 12:09:49 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 14 Jun 2006 12:09:48 -0400 X-IronPort-AV: i="4.06,132,1149480000"; d="scan'208"; a="90029672:sNHT32091416" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5EG9inq003612; Wed, 14 Jun 2006 12:09:47 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 12:09:45 -0400 Received: from [10.83.15.51] ([10.83.15.51]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 12:09:45 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <33B6AD51-32E3-4E46-8830-81575AAC5C19@cisco.com> Content-Transfer-Encoding: quoted-printable From: "Thomas D. Nadeau" Date: Wed, 14 Jun 2006 12:09:43 -0400 To: David Ward X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 14 Jun 2006 16:09:45.0835 (UTC) FILETIME=[F41E13B0:01C68FCC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: bfd , Dave Katz Subject: Re: Updated Specs 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 We do plan on making one update to the BFD/MPLS draft by the cut-off date. --Tom > All - > > Note that pending any edits, nits to be picked or other mods ... We =20= > will > attempt to WG LC these drafts after Montreal (there is not going to =20= > be a WG > meeting). So, please consider this your last chance to make =20 > comments as I > would like LC to to be a simple procedural wait period if at all =20 > possible. > > We will need to update the MIB to match the new port numbers and =20 > any other > changes as appropriate and then I will be sending out a request for > implementation reports. > > -DWard > > > On 6/13/06 10:57 PM, "Dave Katz" wrote: > >> I've just sent off updated versions of all of the Two Daves' specs >> (base, 1hop, multihop, generic) to the Secretariat. They should be >> posted shortly. >> >> The only technical changes are fixing verbiage around asymmetric echo >> timers in the base spec (which I missed on the last version, oops) >> and documenting the officially assigned port number for multihop. >> >> I bit the bullet and moved all of the control-protocol-specific stuff >> out of the 1hop and into the generic (which is probably misnamed, but >> we can revisit the name when it goes to RFC so as to not generate >> administrative headaches.) A lot of text got shredded and glued back >> together, so it's worth a close read. >> >> Since the docs are done "early" (as in more than 12 hours prior to >> the meeting cutoff) we will have time to revisit them once more prior >> to Montr=E9al, so I would appreciate it if folks would take a close >> look at the Generic draft in particular. If I've made any egregious >> mistakes, I can fix them prior to the meeting and then hopefully move >> to RFC on this stuff. >> >> Thanks, >> >> Dave'n'Dave From rtg-bfd-bounces@ietf.org Wed Jun 14 12:15:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqY1w-00068V-RQ; Wed, 14 Jun 2006 12:15:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqY1v-00068Q-PU for rtg-bfd@ietf.org; Wed, 14 Jun 2006 12:15:43 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqY1s-00029W-2p for rtg-bfd@ietf.org; Wed, 14 Jun 2006 12:15:43 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k5EGFdX88792; Wed, 14 Jun 2006 09:15:39 -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 k5EGFY500430; Wed, 14 Jun 2006 09:15:34 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <33B6AD51-32E3-4E46-8830-81575AAC5C19@cisco.com> References: <33B6AD51-32E3-4E46-8830-81575AAC5C19@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Date: Wed, 14 Jun 2006 09:15:31 -0700 To: "Thomas D. Nadeau" X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: bfd , David Ward Subject: Re: Updated Specs 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 On Jun 14, 2006, at 9:09 AM, Thomas D. Nadeau wrote: > > We do plan on making one update to the BFD/MPLS > draft by the cut-off date. That's good, since the new drafts actually reference the -03 spec. ;-) --Dave From rtg-bfd-bounces@ietf.org Wed Jun 14 15:50:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqbNj-0005cn-GH; Wed, 14 Jun 2006 15:50:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqbNN-00055m-6f; Wed, 14 Jun 2006 15:50:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqbNN-00015W-4Z; Wed, 14 Jun 2006 15:50:05 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqbNK-0000NM-5R; Wed, 14 Jun 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5EJo1WR030756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FqbNJ-0006sn-Pv; Wed, 14 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Jun 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-base-05.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Bidirectional Forwarding Detection Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-base-05.txt Pages : 44 Date : 2006-6-14 This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-base-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-base-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-14125957.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-base-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-base-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-14125957.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Wed Jun 14 16:44:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqcDc-0006zU-ND; Wed, 14 Jun 2006 16:44:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqcDa-0006xF-UK; Wed, 14 Jun 2006 16:44:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqbcq-0004Gx-IK; Wed, 14 Jun 2006 16:06:04 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqbOI-0000QS-EZ; Wed, 14 Jun 2006 15:51:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5EJo1mU007468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FqbNJ-0006t2-SO; Wed, 14 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-generic-02.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Generic Application of BFD Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-generic-02.txt Pages : 16 Date : 2006-6-14 This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-generic-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-generic-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-generic-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-14130347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-generic-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-generic-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-14130347.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Wed Jun 14 17:27:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqcu4-0000Qn-BD; Wed, 14 Jun 2006 17:27:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqcu3-0000QX-EI; Wed, 14 Jun 2006 17:27:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqbcq-0004E7-L8; Wed, 14 Jun 2006 16:06:04 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqbOI-0000QR-EL; Wed, 14 Jun 2006 15:51:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5EJo1mU007470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FqbNJ-0006tC-Ts; Wed, 14 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-v4v6-1hop-05.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD for IPv4 and IPv6 (Single Hop) Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-v4v6-1hop-05.txt Pages : 8 Date : 2006-6-14 This document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-v4v6-1hop-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-v4v6-1hop-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-v4v6-1hop-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-14130622.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-v4v6-1hop-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-v4v6-1hop-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-14130622.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Wed Jun 14 17:45:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqdAp-0002ev-7j; Wed, 14 Jun 2006 17:45:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqdAo-0002dT-0c; Wed, 14 Jun 2006 17:45:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqbcq-0004E7-N8; Wed, 14 Jun 2006 16:06:04 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqbOI-0000QP-9j; Wed, 14 Jun 2006 15:51:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5EJo1mU007466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FqbNJ-0006ss-Qg; Wed, 14 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-multihop-04.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD for Multihop Paths Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-multihop-04.txt Pages : 7 Date : 2006-6-14 This document describes the use of the Bidirectional Forwarding Detection protocol (BFD) over multihop paths, including unidirectional links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-multihop-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-multihop-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-multihop-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-14130129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-multihop-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-multihop-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-14130129.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Thu Jun 15 03:25:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqmE6-0001GF-3z; Thu, 15 Jun 2006 03:25:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqmE5-0001E0-20 for rtg-bfd@ietf.org; Thu, 15 Jun 2006 03:25:13 -0400 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqmE3-00053p-QO for rtg-bfd@ietf.org; Thu, 15 Jun 2006 03:25:13 -0400 Received: from [127.0.0.1] (c-69-181-147-36.hsd1.ca.comcast.net[69.181.147.36]) by comcast.net (sccrmhc11) with ESMTP id <2006061507251001100epog6e>; Thu, 15 Jun 2006 07:25:11 +0000 Message-ID: <44910B3C.7000301@hotpop.com> Date: Thu, 15 Jun 2006 00:24:44 -0700 From: Syed Junaid Farooqi User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: David Ward References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: bfd , Dave Katz Subject: Re: Updated Specs 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, In draft-ietf-bfd-base-05.txt Section 6.5 Demand mode, The mechanism used does not have to be the same in both directions, and is outside of the scope of this specification. *One possible mechanism is the receipt of traffic from the remote system;* another is the use of the Echo function. > Wouldnt it be better to avoid generalizing receipt of traffic as presence of connectivity, what i mean is you would have a scenario where you have two links on a system running two BFD sessions - one on each, but the traffic forwarding is done only on one of the links in which case the receipt of traffic wouldnt hold good unless we use the echo function (either on one or both links) or we use other alternative means. How about reframing the sentence to "*One possible mechanism is the use of Echo function*" ~Junaid David Ward penned, On 6/14/2006 9:06 AM: > All - > > Note that pending any edits, nits to be picked or other mods ... We will > attempt to WG LC these drafts after Montreal (there is not going to be a WG > meeting). So, please consider this your last chance to make comments as I > would like LC to to be a simple procedural wait period if at all possible. > > We will need to update the MIB to match the new port numbers and any other > changes as appropriate and then I will be sending out a request for > implementation reports. > > -DWard > > > On 6/13/06 10:57 PM, "Dave Katz" wrote: > > >> I've just sent off updated versions of all of the Two Daves' specs >> (base, 1hop, multihop, generic) to the Secretariat. They should be >> posted shortly. >> >> The only technical changes are fixing verbiage around asymmetric echo >> timers in the base spec (which I missed on the last version, oops) >> and documenting the officially assigned port number for multihop. >> >> I bit the bullet and moved all of the control-protocol-specific stuff >> out of the 1hop and into the generic (which is probably misnamed, but >> we can revisit the name when it goes to RFC so as to not generate >> administrative headaches.) A lot of text got shredded and glued back >> together, so it's worth a close read. >> >> Since the docs are done "early" (as in more than 12 hours prior to >> the meeting cutoff) we will have time to revisit them once more prior >> to Montréal, so I would appreciate it if folks would take a close >> look at the Generic draft in particular. If I've made any egregious >> mistakes, I can fix them prior to the meeting and then hopefully move >> to RFC on this stuff. >> >> Thanks, >> >> Dave'n'Dave >> > > > > > From rtg-bfd-bounces@ietf.org Thu Jun 15 12:09:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquP7-0002WG-11; Thu, 15 Jun 2006 12:09:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquP6-0002WB-0o for rtg-bfd@ietf.org; Thu, 15 Jun 2006 12:09:08 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FquP2-0006UP-LV for rtg-bfd@ietf.org; Thu, 15 Jun 2006 12:09:08 -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 k5FG8l1Z029622; Thu, 15 Jun 2006 09:08:47 -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 k5FG8l566846; Thu, 15 Jun 2006 09:08:47 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <44910B3C.7000301@hotpop.com> References: <44910B3C.7000301@hotpop.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <451B3692-5A0C-465E-8336-92FC03AEB758@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 15 Jun 2006 09:08:45 -0700 To: Syed Junaid Farooqi X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: bfd , David Ward Subject: Re: Updated Specs 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 On Jun 15, 2006, at 12:24 AM, Syed Junaid Farooqi wrote: > >> Wouldnt it be better to avoid generalizing receipt of traffic as >> presence of connectivity, what i mean is you would have a scenario > where you have two links on a system running two BFD sessions - one > on each, but the traffic forwarding is done only on one of the links > in which case the receipt of traffic wouldnt hold good unless we > use the echo function (either on one or both links) or we use other > alternative means. How about reframing the sentence to "*One > possible mechanism is the use of Echo function*" The point is that there are some situations in which the receipt of data traffic is a useful and low-cost way of verifying connectivity. The specific case in mind was a very large fan-in device, where the cost of running the BFD Control protocol might prove to be impractical. The text does not purport that this is always a good idea, or always works, but only that it is one possible mechanism that can be used if appropriate. (The subtext is that there was a draft to do something like this in a rather arcane way for IPsec and we were trying to avoid having someone invent Yet Another Hello Protocol.) --Dave From rtg-bfd-bounces@ietf.org Thu Jun 15 12:13:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquT2-0004BX-Ru; Thu, 15 Jun 2006 12:13:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquT0-0004BN-Ut for rtg-bfd@ietf.org; Thu, 15 Jun 2006 12:13:10 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FquSz-0006i4-D1 for rtg-bfd@ietf.org; Thu, 15 Jun 2006 12:13:10 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 15 Jun 2006 09:13:00 -0700 X-IronPort-AV: i="4.06,137,1149490800"; d="scan'208"; a="295308366:sNHT3431487198" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k5FGD0FA024572; Thu, 15 Jun 2006 09:13:00 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5FGD0Is022723; Thu, 15 Jun 2006 09:13:00 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Jun 2006 09:13:00 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Jun 2006 09:12:59 -0700 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Thu, 15 Jun 2006 11:12:58 -0500 From: David Ward To: Dave Katz , Syed Junaid Farooqi , David Ward Message-ID: Thread-Topic: Updated Specs Thread-Index: AcaQlpERz+xw9/yJEdqi5wAKlcR7kg== In-Reply-To: <451B3692-5A0C-465E-8336-92FC03AEB758@juniper.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Jun 2006 16:13:00.0007 (UTC) FILETIME=[92441F70:01C69096] DKIM-Signature: a=rsa-sha1; q=dns; l=1583; t=1150387980; x=1151251980; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:David=20Ward=20 |Subject:Re=3A=20Updated=20Specs; X=v=3Dcisco.com=3B=20h=3D0Z4PgTSc+SwqrSAZPrlQ+ratx/w=3D; b=B6XujYRv8Syfrc6K/P2Ht2FqeLPomiHvZWyS99FRJQ20XjvGm4LGJ6W1AO/pf7cjHP9FO5sT uEd8xE+5lxmyuyBUF8m3nPE1T3XqU+S8TBJidTtPXO8rIZ2HzFG1WOeo; Authentication-Results: sj-dkim-6.cisco.com; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: bfd Subject: Re: Updated Specs 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 As DK says, we cribbed the idea from existing IPsec DPD (Dead Peer Detection). Note that if you are in BFD demand mode, you still get bidir detection as the other side is monitoring you and can request a poll sequence. -DWard On 6/15/06 11:08 AM, "Dave Katz" wrote: > > On Jun 15, 2006, at 12:24 AM, Syed Junaid Farooqi wrote: > >> >>> Wouldnt it be better to avoid generalizing receipt of traffic as >>> presence of connectivity, what i mean is you would have a scenario >> where you have two links on a system running two BFD sessions - one >> on each, but the traffic forwarding is done only on one of the links >> in which case the receipt of traffic wouldnt hold good unless we >> use the echo function (either on one or both links) or we use other >> alternative means. How about reframing the sentence to "*One >> possible mechanism is the use of Echo function*" > > The point is that there are some situations in which the receipt of > data traffic is a useful and low-cost way of verifying connectivity. > The specific case in mind was a very large fan-in device, where the > cost of running the BFD Control protocol might prove to be impractical. > > The text does not purport that this is always a good idea, or always > works, but only that it is one possible mechanism that can be used if > appropriate. > > (The subtext is that there was a draft to do something like this in a > rather arcane way for IPsec and we were trying to avoid having > someone invent Yet Another Hello Protocol.) > > --Dave From rtg-bfd-bounces@ietf.org Thu Jun 15 12:55:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqv7i-0000gN-Ny; Thu, 15 Jun 2006 12:55:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqv7h-0000eq-Oz for rtg-bfd@ietf.org; Thu, 15 Jun 2006 12:55:13 -0400 Received: from rwcrmhc14.comcast.net ([216.148.227.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqv7g-00028q-GC for rtg-bfd@ietf.org; Thu, 15 Jun 2006 12:55:13 -0400 Received: from [127.0.0.1] (c-69-181-147-36.hsd1.ca.comcast.net[69.181.147.36]) by comcast.net (rwcrmhc14) with ESMTP id <20060615165511m14000h8j5e>; Thu, 15 Jun 2006 16:55:11 +0000 Message-ID: <449190E6.8050507@hotpop.com> Date: Thu, 15 Jun 2006 09:55:02 -0700 From: Syed Junaid Farooqi User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Dave Katz References: <44910B3C.7000301@hotpop.com> <451B3692-5A0C-465E-8336-92FC03AEB758@juniper.net> In-Reply-To: <451B3692-5A0C-465E-8336-92FC03AEB758@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: bfd , David Ward Subject: Re: Updated Specs 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 Dave Katz penned, On 6/15/2006 9:08 AM: > > On Jun 15, 2006, at 12:24 AM, Syed Junaid Farooqi wrote: > >> >>> Wouldnt it be better to avoid generalizing receipt of traffic as >>> presence of connectivity, what i mean is you would have a scenario >> where you have two links on a system running two BFD sessions - one >> on each, but the traffic forwarding is done only on one of the links >> in which case the receipt of traffic wouldnt hold good unless we use >> the echo function (either on one or both links) or we use other >> alternative means. How about reframing the sentence to "*One possible >> mechanism is the use of Echo function*" > > The point is that there are some situations in which the receipt of > data traffic is a useful and low-cost way of verifying connectivity. > The specific case in mind was a very large fan-in device, where the > cost of running the BFD Control protocol might prove to be impractical. True, I had the idea of Multiple BGP peers on a box and registering the BGP sessions with BFD for fast detection e.g. I have close to 200 BGP peers on a box all the BGP sessions registered with BFD, in this particular case, I can run demand mode as i do not want the extra overhead, however, I can have demand mode + echo mode and still get fast detection. In this case, i would have a problem if i implemented demand mode + traffic receipt as traffic is being received from only a few of the peers. My concern here is that the draft should not be misunderstood as promoting traffic receipt as one of the preferred means of checking connectivity ( I am not against using receipt of traffic as a means of checking connectivity per se, in fact on low speed links i would rather use this method). > > The text does not purport that this is always a good idea, or always > works, but only that it is one possible mechanism that can be used if > appropriate. > > (The subtext is that there was a draft to do something like this in a > rather arcane way for IPsec and we were trying to avoid having someone > invent Yet Another Hello Protocol.) > --Dave > > > From rtg-bfd-bounces@ietf.org Fri Jun 16 13:37:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIG7-0008Ux-W6; Fri, 16 Jun 2006 13:37:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIG5-0008JY-Pa for rtg-bfd@ietf.org; Fri, 16 Jun 2006 13:37:25 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrI9V-0003tj-LQ for rtg-bfd@ietf.org; Fri, 16 Jun 2006 13:30:39 -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 k5GHUZ1Z049434; Fri, 16 Jun 2006 10:30:35 -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 k5GHUY554638; Fri, 16 Jun 2006 10:30:34 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <449190E6.8050507@hotpop.com> References: <44910B3C.7000301@hotpop.com> <451B3692-5A0C-465E-8336-92FC03AEB758@juniper.net> <449190E6.8050507@hotpop.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Date: Fri, 16 Jun 2006 10:30:32 -0700 To: Syed Junaid Farooqi X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: bfd , David Ward Subject: Re: Updated Specs 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 On Jun 15, 2006, at 9:55 AM, Syed Junaid Farooqi wrote: >> The point is that there are some situations in which the receipt >> of data traffic is a useful and low-cost way of verifying >> connectivity. The specific case in mind was a very large fan-in >> device, where the cost of running the BFD Control protocol might >> prove to be impractical. > True, I had the idea of Multiple BGP peers on a box and registering > the BGP sessions with BFD for fast detection e.g. I have close to > 200 BGP peers on a box > all the BGP sessions registered with BFD, in this particular case, > I can run demand mode as i do not want the extra overhead, however, > I can have demand mode + echo mode and still get fast detection. In > this case, i would have a problem if i implemented demand mode + > traffic receipt as traffic is being received from only a few of the > peers. This is of course an option (and called out as such.) The assumption is that the vendors are smart enough to decide what mechanism to use based on their own needs and environments; Darwin will clean up after those who are not. > My concern here is that the draft should not be misunderstood as > promoting traffic receipt as one of the preferred means of checking > connectivity ( I am not against using receipt of traffic as a > means of checking connectivity per se, in fact on low speed links i > would rather use this method). There is no "preferred" method; essentially none of this is subject to standardization, there are few if any real interoperability issues, and implementors are free to be imaginative (all of this was an explicit goal of BFD, at least from the authors' point of view.) In this particular case, traffic receipt and the echo function were given equal billing (and certainly the existence of the whole echo protocol and the hooks for it in the control protocol give it a bit more weight than a half sentence mentioning traffic receipt.) Both are listed as "possible" mechanisms; if this is "promotion" it's pretty weak. A small troll sitting under each end of the link deciding when to do a poll sequence is also a possible mechanism. ;-) --Dave From rtg-bfd-bounces@ietf.org Fri Jun 16 14:00:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIcS-00076e-Pq; Fri, 16 Jun 2006 14:00:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIcR-00075p-De for rtg-bfd@ietf.org; Fri, 16 Jun 2006 14:00:31 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrIcQ-0005tO-6C for rtg-bfd@ietf.org; Fri, 16 Jun 2006 14:00:31 -0400 Received: from [127.0.0.1] (c-69-181-147-36.hsd1.ca.comcast.net[69.181.147.36]) by comcast.net (sccrmhc14) with ESMTP id <2006061618002401400aqmcoe>; Fri, 16 Jun 2006 18:00:24 +0000 Message-ID: <4492F1B4.6000407@hotpop.com> Date: Fri, 16 Jun 2006 11:00:20 -0700 From: Syed Junaid Farooqi User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Dave Katz References: <44910B3C.7000301@hotpop.com> <451B3692-5A0C-465E-8336-92FC03AEB758@juniper.net> <449190E6.8050507@hotpop.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: bfd , David Ward Subject: Re: Updated Specs 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 Dave Katz penned, On 6/16/2006 10:30 AM: > > On Jun 15, 2006, at 9:55 AM, Syed Junaid Farooqi wrote: > >>> The point is that there are some situations in which the receipt of >>> data traffic is a useful and low-cost way of verifying >>> connectivity. The specific case in mind was a very large fan-in >>> device, where the cost of running the BFD Control protocol might >>> prove to be impractical. >> True, I had the idea of Multiple BGP peers on a box and registering >> the BGP sessions with BFD for fast detection e.g. I have close to 200 >> BGP peers on a box >> all the BGP sessions registered with BFD, in this particular case, I >> can run demand mode as i do not want the extra overhead, however, I >> can have demand mode + echo mode and still get fast detection. In >> this case, i would have a problem if i implemented demand mode + >> traffic receipt as traffic is being received from only a few of the >> peers. > > This is of course an option (and called out as such.) The assumption > is that the vendors are smart enough to decide what mechanism to use > based on their own needs and environments; Darwin will clean up after > those who are not. > >> My concern here is that the draft should not be misunderstood as >> promoting traffic receipt as one of the preferred means of checking >> connectivity ( I am not against using receipt of traffic as a means >> of checking connectivity per se, in fact on low speed links i would >> rather use this method). > > There is no "preferred" method; essentially none of this is subject > to standardization, there are few if any real interoperability issues, > and implementors are free to be imaginative (all of this was an > explicit goal of BFD, at least from the authors' point of view.) Agreed ! > > In this particular case, traffic receipt and the echo function were > given equal billing (and certainly the existence of the whole echo > protocol and the hooks for it in the control protocol give it a bit > more weight than a half sentence mentioning traffic receipt.) Both > are listed as "possible" mechanisms; if this is "promotion" it's > pretty weak. *A small troll sitting under each end of the link > deciding when to do a poll sequence is also a possible mechanism. ;-) * This is priceless, for everything else - mastercard :) > > --Dave > > > -- Syed Junaid Farooqi Redback Networks From rtg-bfd-bounces@ietf.org Mon Jun 19 05:23:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsFyG-0005sK-BK; Mon, 19 Jun 2006 05:23:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsFy1-0005qZ-RB for rtg-bfd@ietf.org; Mon, 19 Jun 2006 05:22:45 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsFkE-0004kC-TR for rtg-bfd@ietf.org; Mon, 19 Jun 2006 05:08:32 -0400 Received: by ug-out-1314.google.com with SMTP id m3so747309uge for ; Mon, 19 Jun 2006 02:08:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YCKl6WlybRbXB/cENfYQyYv4QpvJLq9QqJigvxjJ8yoESuVKJf5ME5ktRySmQ2+EK3scK9ZTG01OuFaUGAkC7bvH8q0ZBtwxXMdTcQ/UgPvKLhsvBhb/mmV5c7UGX7B1XLNQFzk2fJ0NMdDzhLHu5a+/m7EsTT/a6N5zcNwpo4E= Received: by 10.78.45.13 with SMTP id s13mr1921360hus; Mon, 19 Jun 2006 02:08:30 -0700 (PDT) Received: by 10.78.17.10 with HTTP; Mon, 19 Jun 2006 02:08:29 -0700 (PDT) Message-ID: <9e31186f0606190208r2e93c355q8e6004d949de38a8@mail.gmail.com> Date: Mon, 19 Jun 2006 11:08:29 +0200 From: "Carlos Garcia Braschi" To: rtg-bfd@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: David Ward , Dave Katz Subject: Re: Rtg-bfd Digest, Vol 21, Issue 3 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 2006/6/15, rtg-bfd-request@ietf.org : > Date: Wed, 14 Jun 2006 11:06:56 -0500 > From: David Ward > Subject: Re: Updated Specs > To: Dave Katz , bfd , David War= d > > Message-ID: > Content-Type: text/plain; charset=3D"ISO-8859-1" > > All - > > Note that pending any edits, nits to be picked or other mods ... We will > attempt to WG LC these drafts after Montreal (there is not going to be a = WG > meeting). So, please consider this your last chance to make comments as I > would like LC to to be a simple procedural wait period if at all possible= . > > We will need to update the MIB to match the new port numbers and any othe= r > changes as appropriate and then I will be sending out a request for > implementation reports. > > -DWard > > > On 6/13/06 10:57 PM, "Dave Katz" wrote: > > > I've just sent off updated versions of all of the Two Daves' specs > > (base, 1hop, multihop, generic) to the Secretariat. They should be > > posted shortly. > > > > The only technical changes are fixing verbiage around asymmetric echo > > timers in the base spec (which I missed on the last version, oops) > > and documenting the officially assigned port number for multihop. > > > > I bit the bullet and moved all of the control-protocol-specific stuff > > out of the 1hop and into the generic (which is probably misnamed, but > > we can revisit the name when it goes to RFC so as to not generate > > administrative headaches.) A lot of text got shredded and glued back > > together, so it's worth a close read. > > Good you bit the bullet, I find the new structure easier to understand. Although part 8 is not normative, I'd suggest small improvements so that it also mentions session establishment for BGP and RIP protocols, and the t= ype of BFD session to be used for RIP. This would mention the same points for a= ll non-normative references to protocols. I'm not experienced at standard writing, but I mean something like: for 8.2: BFD session establishment for EBGP is simple, as there is no discovery protocol, because all BGP sessions are explicitly configured. So BFD support for each EBGP session needs to be configured explicity, to be taken into account as another parameter in EBGP parameter negotiation beteween peers at the administrative level. Possibly, BGP capability negotiation could be extended to express BFD capability in a particular session, so that negotiation is automatic at the protocol level. for 8.3 BFD session establishment with the RIP protocol could be triggered by a RIP response message reception, be it solicited or unsolicited. Of course, it can also be statically configured. Also, this brief mention is made for ISIS, OSPF, BGP but not RIP: As RIP does not have the possibility to traverse more than one hop, RIP routes being advised by BFD should establish a one hop [BFD-1HOP] session. > > Since the docs are done "early" (as in more than 12 hours prior to > > the meeting cutoff) we will have time to revisit them once more prior > > to Montr=E9al, so I would appreciate it if folks would take a close > > look at the Generic draft in particular. If I've made any egregious > > mistakes, I can fix them prior to the meeting and then hopefully move > > to RFC on this stuff. > > > > Thanks, > > > > Dave'n'Dave > > > > From rtg-bfd-bounces@ietf.org Mon Jun 19 19:16:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsSyh-0003M9-Du; Mon, 19 Jun 2006 19:16:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsSyg-0003Lv-Dn for rtg-bfd@ietf.org; Mon, 19 Jun 2006 19:16:18 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsSye-0008Ur-1i for rtg-bfd@ietf.org; Mon, 19 Jun 2006 19:16:18 -0400 Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by kremlin.juniper.net with ESMTP; 19 Jun 2006 16:16:15 -0700 X-IronPort-AV: i="4.06,153,1149490800"; d="scan'208"; a="556062932:sNHT30468552" Received: from emailcorp2.jnpr.net ([66.129.254.12]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 16:16:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Jun 2006 16:17:21 -0700 Message-ID: <5C46C0918C867B4090C18D62C83563B84B3EAF@emailcorp2.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Specs Thread-Index: AcaQlpERz+xw9/yJEdqi5wAKlcR7kgDX2HRg From: "Geoffrey Huang" To: "David Ward" , "Dave Katz" , "Syed Junaid Farooqi" X-OriginalArrivalTime: 19 Jun 2006 23:16:15.0250 (UTC) FILETIME=[5CA9AF20:01C693F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: bfd Subject: RE: Updated Specs 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 > -----Original Message----- > From: David Ward [mailto:dward@cisco.com] > Sent: Thursday, June 15, 2006 9:13 AM > To: Dave Katz; Syed Junaid Farooqi; David Ward > Cc: bfd > Subject: Re: Updated Specs >=20 > As DK says, we cribbed the idea from existing IPsec DPD (Dead Peer > Detection). I'm honored (I think). In all seriousness, my opinion is that the DPD scheme of "let the interested party decide" has worked out well. This is especially true when contrasted with previous, less scalable methods for liveliness detection in IKE. As your BFD draft points out (and as you have pointed out elsewhere in this thread), the behavior is optional. -g > Note that if you are in BFD demand mode, you still get bidir detection as > the other side is monitoring you and can request a poll sequence. >=20 > -DWard >=20 >=20 > On 6/15/06 11:08 AM, "Dave Katz" wrote: >=20 > > > > On Jun 15, 2006, at 12:24 AM, Syed Junaid Farooqi wrote: > > > >> > >>> Wouldnt it be better to avoid generalizing receipt of traffic as > >>> presence of connectivity, what i mean is you would have a scenario > >> where you have two links on a system running two BFD sessions - one > >> on each, but the traffic forwarding is done only on one of the links > >> in which case the receipt of traffic wouldnt hold good unless we > >> use the echo function (either on one or both links) or we use other > >> alternative means. How about reframing the sentence to "*One > >> possible mechanism is the use of Echo function*" > > > > The point is that there are some situations in which the receipt of > > data traffic is a useful and low-cost way of verifying connectivity. > > The specific case in mind was a very large fan-in device, where the > > cost of running the BFD Control protocol might prove to be impractical. > > > > The text does not purport that this is always a good idea, or always > > works, but only that it is one possible mechanism that can be used if > > appropriate. > > > > (The subtext is that there was a draft to do something like this in a > > rather arcane way for IPsec and we were trying to avoid having > > someone invent Yet Another Hello Protocol.) > > > > --Dave From rtg-bfd-bounces@ietf.org Tue Jun 27 15:51:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJaS-00086U-38; Tue, 27 Jun 2006 15:51:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJZW-00060J-RX; Tue, 27 Jun 2006 15:50:07 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJZT-0001OF-Fn; Tue, 27 Jun 2006 15:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo31u030586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jun 2006 19:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZT-0005Jh-7M; Tue, 27 Jun 2006 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 15:50:03 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-mpls-03.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD For MPLS LSPs Author(s) : R. Aggarwal, et al. Filename : draft-ietf-bfd-mpls-03.txt Pages : 12 Date : 2006-6-27 One desirable application of Bi-directional Forwarding Detection (BFD) is to detect a MPLS LSP data plane failure. LSP-Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However the control plane processing required for BFD control packets is relatively smaller than the processing required for LSP-Ping messages. A combination of LSP-Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability of BFD in relation to LSP-Ping for this application. It also describes procedures for using BFD in this environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-mpls-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-mpls-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-mpls-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-27145838.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-mpls-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-mpls-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27145838.I-D@ietf.org> --OtherAccess-- --NextPart--