From rtg-bfd-bounces@ietf.org Tue Feb 1 03:25:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01795; Tue, 1 Feb 2005 03:25:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvteF-0001wA-SK; Tue, 01 Feb 2005 03:44:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvtJU-0004tu-OK; Tue, 01 Feb 2005 03:23:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvtHE-0004UD-Tz for rtg-bfd@megatron.ietf.org; Tue, 01 Feb 2005 03:20:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01219 for ; Tue, 1 Feb 2005 03:20:47 -0500 (EST) From: richard.spencer@bt.com Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvtPe-0001Sj-5P for rtg-bfd@ietf.org; Tue, 01 Feb 2005 03:29:31 -0500 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Tue, 1 Feb 2005 08:11:42 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 1 Feb 2005 08:11:39 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Feb 2005 08:11:38 -0000 Message-ID: Thread-Topic: Transition from failing state Thread-Index: AcUINWVN55ybcHdgTgWnbj2cvi9FQw== To: , X-OriginalArrivalTime: 01 Feb 2005 08:11:39.0158 (UTC) FILETIME=[A7CF0B60:01C50835] X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org Subject: Transition from failing state 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Section 6.6.6 of draft-ietf-bfd-base-00.txt states:=20 Else if bfd.SessionState is Failing=20 If I Hear You is zero, set bfd.SessionState to Down However, unless I'm missing something, the draft does not appear to = describe what happens if bfd.SessionState is Failing and: - The sink/destination receives a BFD packet - The source receives a BFD packet with a nonzero I Hear You Should the node transition to the init state? Thanks, Richard From rtg-bfd-bounces@ietf.org Tue Feb 1 05:29:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11554; Tue, 1 Feb 2005 05:29:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvvZj-00059l-HV; Tue, 01 Feb 2005 05:48:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvvDG-0000HI-9L; Tue, 01 Feb 2005 05:24:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvvBg-0008Uy-2J for rtg-bfd@megatron.ietf.org; Tue, 01 Feb 2005 05:23:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10833 for ; Tue, 1 Feb 2005 05:23:09 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvvTi-0004zE-7m for rtg-bfd@ietf.org; Tue, 01 Feb 2005 05:41:55 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IB8007069ZZ7W@szxga02-in.huawei.com> for rtg-bfd@ietf.org; Tue, 01 Feb 2005 18:19:11 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IB800KRD9ZZ3R@szxga02-in.huawei.com> for rtg-bfd@ietf.org; Tue, 01 Feb 2005 18:19:11 +0800 (CST) Received: from z11024 ([10.110.49.48]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IB800JW79ZXF9@szxml02-in.huawei.com>; Tue, 01 Feb 2005 18:19:09 +0800 (CST) Date: Tue, 01 Feb 2005 18:19:39 +0800 From: zhaisuping To: "richard.spencer@bt.com" , "dkatz@juniper.net" , "dward@cisco.com" Message-id: <0IB800JW89ZXF9@szxml02-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7BIT Cc: "rtg-bfd@ietf.org" Subject: Re: Transition from failing state X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhaisuping@huawei.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7BIT I think that Fail state is redundant,the state machine can be simplified as following: H(1) |-------------->| | H(0) H(1) | init--->down--->up | H(0) | |<------| Should this can be simple? Regards suping zhai >Section 6.6.6 of draft-ietf-bfd-base-00.txt states: > >Else if bfd.SessionState is Failing > If I Hear You is zero, set bfd.SessionState to Down > >However, unless I'm missing something, the draft does not appear to describe what happens if bfd.SessionState is Failing and: > >- The sink/destination receives a BFD packet >- The source receives a BFD packet with a nonzero I Hear You > >Should the node transition to the init state? > >Thanks, >Richard From rtg-bfd-bounces@ietf.org Tue Feb 1 18:02:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12179; Tue, 1 Feb 2005 18:02:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw7Kg-0003bh-5M; Tue, 01 Feb 2005 18:21:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw71W-0002MF-HG; Tue, 01 Feb 2005 18:01:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw6yr-0001TD-Pq for rtg-bfd@megatron.ietf.org; Tue, 01 Feb 2005 17:58:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11923 for ; Tue, 1 Feb 2005 17:58:43 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw7H6-0003Wb-7N for rtg-bfd@ietf.org; Tue, 01 Feb 2005 18:17:36 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 349652D49BE; Tue, 1 Feb 2005 17:57:21 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 72220-02-91; Tue, 1 Feb 2005 17:57:20 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 0716B2D497D; Tue, 1 Feb 2005 17:57:20 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j11MvJe11358; Tue, 1 Feb 2005 17:57:19 -0500 (EST) Date: Tue, 1 Feb 2005 17:57:19 -0500 From: Jeffrey Haas To: richard.spencer@bt.com Message-ID: <20050201225719.GJ3965@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: rtg-bfd@ietf.org, dkatz@juniper.net, dward@cisco.com Subject: Re: Transition from failing state 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Richard, On Tue, Feb 01, 2005 at 08:11:38AM -0000, richard.spencer@bt.com wrote: > Section 6.6.6 of draft-ietf-bfd-base-00.txt states: > > Else if bfd.SessionState is Failing > If I Hear You is zero, set bfd.SessionState to Down > > However, unless I'm missing something, the draft does not appear to describe what happens if bfd.SessionState is Failing and: > > - The sink/destination receives a BFD packet > - The source receives a BFD packet with a nonzero I Hear You In section 6.1: Once a session has been declared down, it cannot come back up until the remote end first signals that it is down (by setting its outgoing I Hear You field to zero), thus implementing a three-way handshake. Thus the failing state is meant to wait until the other side has timed out. We transition to the Failing state upon packet reception like this: Else if bfd.SessionState is Up If I Hear You is zero Set bfd.LocalDiag to 3 (Neighbor signaled session down) Set bfd.SessionState to Failing Set bfd.RemoteHeard to 0 Or similarly upon a timeout: If Demand mode is not active, and a period of time equal to the Detection Time passes without receiving a BFD Control packet from the remote system, and bfd.SessionState is Init or Up, the session has gone down--the local system MUST set bfd.SessionState to Failing, bfd.RemoteHeard to zero, and bfd.LocalDiag to 1 (Control Detection Time Expired.) The timeout in Init state is to avoid a potential deadlock in which one system is in Failing state and the other is in Init state (which could happen if a packet were lost at the right time.) The system will then begin transmitting packets with "I Hear You" of 0, which will cause the remote system to tear down the connection. Similarly, when using echo packets: BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not Up. BFD Echo packets MUST NOT be transmitted unless the last BFD Control packet received from the remote system contains a nonzero value in Required Min Echo RX Interval. Hopefully this helps. > Richard -- Jeff Haas NextHop Technologies From rtg-bfd-bounces@ietf.org Wed Feb 2 17:00:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13022; Wed, 2 Feb 2005 17:00:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwSqv-0002QD-Tn; Wed, 02 Feb 2005 17:20:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwSAh-0000Aj-Ta; Wed, 02 Feb 2005 16:36:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwRXn-0008CQ-Pe for rtg-bfd@megatron.ietf.org; Wed, 02 Feb 2005 15:56:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28155 for ; Wed, 2 Feb 2005 15:56:07 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwRqE-0005Ze-L3 for rtg-bfd@ietf.org; Wed, 02 Feb 2005 16:15:14 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 6AF762D487C; Wed, 2 Feb 2005 15:52:29 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 60869-01-68; Wed, 2 Feb 2005 15:52:28 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 278542D4825; Wed, 2 Feb 2005 15:52:28 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j12KqRJ14642; Wed, 2 Feb 2005 15:52:27 -0500 (EST) Date: Wed, 2 Feb 2005 15:52:27 -0500 From: Jeffrey Haas To: richard.spencer@bt.com Message-ID: <20050202205227.GR3965@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: rtg-bfd@ietf.org, dkatz@juniper.net, dward@cisco.com Subject: Re: Transition from failing state 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 On Wed, Feb 02, 2005 at 12:29:23PM -0000, richard.spencer@bt.com wrote: > Therefore, it seems to me that whilst A->B connectivity is lost, Node B will remain permanently in the Failing state, whilst Node A will loop continuously though the Failing, Down, Init states. Is this correct or am I missing something? Correct. By analogy, this isn't much worse (given the fallback to a 1 second timer for sending packets) than something like BGP transitioning through it's statemachine. It is up to an implementation whether it wants to leave a BFD instance running on a session that is otherwise down for a long period of time. For example, if BFD was supporting OSPF, then one could presume an implementation would delete the BFD instance for a given pair of peers until the OSPF hello protocol noticed that the session was up again. > Also, the only exit criteria described for the Failing state is as follows: > > Else if bfd.SessionState is Failing > If I Hear You is zero, set bfd.SessionState to Down > > What happens if just after entering the Failing state (due to detection timeout as in the previous example), connectivity A->B is restored and Node B receives a BFD packet from node A with a I Hear You of nonzero? This would occur if node A (whilst still in the Up state) sends a BFD packet to node B before it receives the BFD failure notification from Node B (with H bit set to 0 and Diag set to 1). This isn't any different than B saying that it wishes to tear the connection down. The state machine could go through the usual motions of restoring the connection, but B would do so starting from the failing state and would have to wait for A to acknowledge it. > Richard -- Jeff Haas NextHop Technologies From rtg-bfd-bounces@ietf.org Wed Feb 2 17:51:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21876; Wed, 2 Feb 2005 17:51:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwTe8-0005Pr-0U; Wed, 02 Feb 2005 18:10:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwTGc-0005mJ-3v; Wed, 02 Feb 2005 17:46:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwTBJ-0003rg-AM for rtg-bfd@megatron.ietf.org; Wed, 02 Feb 2005 17:41:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20555 for ; Wed, 2 Feb 2005 17:41:00 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwTTk-00050i-TM for rtg-bfd@ietf.org; Wed, 02 Feb 2005 18:00:09 -0500 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 j12MeV906810; Wed, 2 Feb 2005 14:40:31 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.201] (nimbus-bsr.juniper.net [172.16.12.201]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j12MeIe75258; Wed, 2 Feb 2005 14:40:18 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <20050202205227.GR3965@nexthop.com> References: <20050202205227.GR3965@nexthop.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <69F34D82-756B-11D9-ACA0-000D93298656@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Wed, 2 Feb 2005 14:40:18 -0800 To: Jeffrey Haas X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org, dward@cisco.com Subject: Re: Transition from failing state 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit On Feb 2, 2005, at 12:52 PM, Jeffrey Haas wrote: > On Wed, Feb 02, 2005 at 12:29:23PM -0000, richard.spencer@bt.com wrote: >> Therefore, it seems to me that whilst A->B connectivity is lost, Node >> B will remain permanently in the Failing state, whilst Node A will >> loop continuously though the Failing, Down, Init states. Is this >> correct or am I missing something? > > Correct. By analogy, this isn't much worse (given the fallback to a 1 > second timer for sending packets) than something like BGP transitioning > through it's statemachine. > > It is up to an implementation whether it wants to leave a BFD instance > running on a session that is otherwise down for a long period of time. > For example, if BFD was supporting OSPF, then one could presume an > implementation would delete the BFD instance for a given pair of peers > until the OSPF hello protocol noticed that the session was up again. Yep, in the case of one-way connectivity, this is what will happen. Given that the only "interesting" transition is Up->Failing (or perhaps, in limited cases, Init->Up) the machinations of the state machine hurt nobody. One could indeed claim that they are useful; in particular, timing out of Init state carries useful semantics. > >> Also, the only exit criteria described for the Failing state is as >> follows: >> >> Else if bfd.SessionState is Failing >> If I Hear You is zero, set bfd.SessionState to Down >> >> What happens if just after entering the Failing state (due to >> detection timeout as in the previous example), connectivity A->B is >> restored and Node B receives a BFD packet from node A with a I Hear >> You of nonzero? This would occur if node A (whilst still in the Up >> state) sends a BFD packet to node B before it receives the BFD >> failure notification from Node B (with H bit set to 0 and Diag set to >> 1). > > This isn't any different than B saying that it wishes to tear the > connection > down. The state machine could go through the usual motions of > restoring > the connection, but B would do so starting from the failing state and > would > have to wait for A to acknowledge it. Indeed. The intent of the state machine is to make sure both sides *always* know that the session has failed. If it takes a couple of extra packets to get the session going again in some relatively unusual instances, that's no big deal (and not worth the complexity to try to optimize it out.) --Dave From rtg-bfd-bounces@ietf.org Wed Feb 2 20:49:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07676; Wed, 2 Feb 2005 20:49:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwWQ7-0002M7-CT; Wed, 02 Feb 2005 21:08:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwVyw-0004Rx-3z; Wed, 02 Feb 2005 20:40:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwVxd-0003wU-0u for rtg-bfd@megatron.ietf.org; Wed, 02 Feb 2005 20:39:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06913 for ; Wed, 2 Feb 2005 20:39:03 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwWG3-00020c-KH for rtg-bfd@ietf.org; Wed, 02 Feb 2005 20:58:13 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IBB008EAB928P@szxga01-in.huawei.com> for rtg-bfd@ietf.org; Thu, 03 Feb 2005 09:39:02 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IBB006DWB91JX@szxga01-in.huawei.com> for rtg-bfd@ietf.org; Thu, 03 Feb 2005 09:39:01 +0800 (CST) Received: from z11024 ([10.110.49.48]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IBB00CDJBA0HX@szxml02-in.huawei.com> for rtg-bfd@ietf.org; Thu, 03 Feb 2005 09:39:36 +0800 (CST) Date: Thu, 03 Feb 2005 09:40:03 +0800 From: zhaisuping To: "rtg-bfd@ietf.org" Message-id: <0IBB00CDKBA0HX@szxml02-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7BIT Subject: Fw: Re: Transition from failing state X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhaisuping@huawei.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7BIT So nobody response the following question? I think that Fail state is redundant,the state machine can be simplified as following: H(1) |-------------->| | H(0) H(1) | init--->down--->up | H(0) | |<------| Should this can be simple? Regards suping zhai >Section 6.6.6 of draft-ietf-bfd-base-00.txt states: > >Else if bfd.SessionState is Failing > If I Hear You is zero, set bfd.SessionState to Down > >However, unless I'm missing something, the draft does not appear to describe what happens if bfd.SessionState is Failing and: > >- The sink/destination receives a BFD packet >- The source receives a BFD packet with a nonzero I Hear You > >Should the node transition to the init state? > >Thanks, >Richard From rtg-bfd-bounces@ietf.org Thu Feb 3 01:42:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05140; Thu, 3 Feb 2005 01:42:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwazg-0002ls-QQ; Thu, 03 Feb 2005 02:01:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwabq-0003ih-CV; Thu, 03 Feb 2005 01:36:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwaZU-0003E9-Ea for rtg-bfd@megatron.ietf.org; Thu, 03 Feb 2005 01:34:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04265 for ; Thu, 3 Feb 2005 01:34:31 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwarz-0002TI-EA for rtg-bfd@ietf.org; Thu, 03 Feb 2005 01:53:40 -0500 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 j136XYBm016810; Wed, 2 Feb 2005 22:33:44 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.201] (nimbus-bsr.juniper.net [172.16.12.201]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j136XYe72195; Wed, 2 Feb 2005 22:33:34 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <0IBB00CDKBA0HX@szxml02-in.huawei.com> References: <0IBB00CDKBA0HX@szxml02-in.huawei.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <869ACE0D-75AD-11D9-ACA0-000D93298656@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Wed, 2 Feb 2005 22:33:33 -0800 To: zhaisuping@huawei.com X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: "rtg-bfd@ietf.org" Subject: Re: Transition from failing state 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit The problem with this approach is that it is possible to flap one side of the session without the other side knowing. That is why there is a three-way handshake for both session establishment and session failure (and thus four states.) --Dave On Feb 2, 2005, at 5:40 PM, zhaisuping wrote: > So nobody response the following question? > > > I think that Fail state is redundant,the state machine can be > simplified as following: > > H(1) > |-------------->| > | H(0) H(1) | > init--->down--->up > | H(0) | > |<------| > > Should this can be simple? > > Regards > suping zhai >> Section 6.6.6 of draft-ietf-bfd-base-00.txt states: >> >> Else if bfd.SessionState is Failing >> If I Hear You is zero, set bfd.SessionState to Down >> >> However, unless I'm missing something, the draft does not appear to >> describe what happens if bfd.SessionState is Failing and: >> >> - The sink/destination receives a BFD packet >> - The source receives a BFD packet with a nonzero I Hear You >> >> Should the node transition to the init state? >> >> Thanks, >> Richard > > > From rtg-bfd-bounces@ietf.org Thu Feb 3 01:44:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05417; Thu, 3 Feb 2005 01:44:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwb1Y-0002pe-5S; Thu, 03 Feb 2005 02:03:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwahP-00055D-19; Thu, 03 Feb 2005 01:42:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwabu-0003iy-5V for rtg-bfd@megatron.ietf.org; Thu, 03 Feb 2005 01:37:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04574 for ; Thu, 3 Feb 2005 01:37:01 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwauQ-0002Zs-2c for rtg-bfd@ietf.org; Thu, 03 Feb 2005 01:56:10 -0500 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 j136aUBm016828; Wed, 2 Feb 2005 22:36:30 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.201] (nimbus-bsr.juniper.net [172.16.12.201]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j136aUe72519; Wed, 2 Feb 2005 22:36:30 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <200412061000.15317.cnogradi@laurelnetworks.com> References: <200412061000.15317.cnogradi@laurelnetworks.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Date: Wed, 2 Feb 2005 22:36:29 -0800 To: Chris Nogradi X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: BFD implementation 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Looks like this never was replied to, sorry... On Dec 6, 2004, at 7:00 AM, Chris Nogradi wrote: > Hello, I have some BFD implementation questions: > > 1. Section 6.6.2 specifies in the last paragraph that a '... Control > packet > with the Poll (P) bit clear and the Final (F) bit set...' MUST be sent > as a > result of receiving a packet with the poll bit set. And later, in > section > 6.6.3, the 3rd paragraph states that if the intervals are changed, > '... all > subsequent transmitted Control packets MUST be sent with the Poll (P) > bit set > until a packet is received with the Final (F) bit set.' It is not > clear to > me how to implement these seemingly contradictory statements. Good catch. The statement that all packets have to be sent with Poll should not apply to packets being generated in response to a received Poll. This will be fixed... > > 2. While I am not sure that the document specifically states this, it > appears > to me that the poll and final bits should only be set when in the up > state? Yep. Originally the P/F bits were only used when Demand Mode was active, which can only happen in Up state. However, we leveraged P/F for parameter changes. This should only apply in Up state. Will be fixed... --Dave From rtg-bfd-bounces@ietf.org Thu Feb 3 01:55:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06213; Thu, 3 Feb 2005 01:55:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwbCY-000383-29; Thu, 03 Feb 2005 02:14:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwal9-0005vA-BE; Thu, 03 Feb 2005 01:46:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwahT-00055r-K4 for rtg-bfd@megatron.ietf.org; Thu, 03 Feb 2005 01:42:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05175 for ; Thu, 3 Feb 2005 01:42:46 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwazz-0002ln-PS for rtg-bfd@ietf.org; Thu, 03 Feb 2005 02:01:56 -0500 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 j136f6Bm016870; Wed, 2 Feb 2005 22:41:06 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.201] (nimbus-bsr.juniper.net [172.16.12.201]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j136f6e73106; Wed, 2 Feb 2005 22:41:06 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <93E78778-75AE-11D9-ACA0-000D93298656@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Wed, 2 Feb 2005 22:41:05 -0800 To: X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org, dward@cisco.com Subject: Re: Transition from failing state 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit On Feb 1, 2005, at 12:11 AM, wrote: > Section 6.6.6 of draft-ietf-bfd-base-00.txt states: > > Else if bfd.SessionState is Failing > If I Hear You is zero, set bfd.SessionState to Down > > However, unless I'm missing something, the draft does not appear to > describe what happens if bfd.SessionState is Failing and: > > - The sink/destination receives a BFD packet > - The source receives a BFD packet with a nonzero I Hear You > > Should the node transition to the init state? Nope, the whole point of Failing state is to wait there until IHU=0, thus ensuring that the other end has killed the session as well. In the pseudocode in the spec, you simply fall through on that test and go on with the rest of the process. --Dave \ From rtg-bfd-bounces@ietf.org Thu Feb 3 02:00:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07162; Thu, 3 Feb 2005 02:00:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwbHP-0003HF-OP; Thu, 03 Feb 2005 02:19:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwawt-0008WO-BX; Thu, 03 Feb 2005 01:58:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwav8-0007vm-ID for rtg-bfd@megatron.ietf.org; Thu, 03 Feb 2005 01:56:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06329 for ; Thu, 3 Feb 2005 01:56:53 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwbDe-0003Am-RG for rtg-bfd@ietf.org; Thu, 03 Feb 2005 02:16:03 -0500 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 j136uLBm016938; Wed, 2 Feb 2005 22:56:21 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.201] (nimbus-bsr.juniper.net [172.16.12.201]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j136uLe75465; Wed, 2 Feb 2005 22:56:21 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Date: Wed, 2 Feb 2005 22:56:20 -0800 To: X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org, dward@cisco.com Subject: Re: Transition from failing state 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Looks like this never was replied to, sorry... On Dec 6, 2004, at 7:00 AM, Chris Nogradi wrote: > Hello, I have some BFD implementation questions: > > 1. Section 6.6.2 specifies in the last paragraph that a '... Control > packet > with the Poll (P) bit clear and the Final (F) bit set...' MUST be sent > as a > result of receiving a packet with the poll bit set. And later, in > section > 6.6.3, the 3rd paragraph states that if the intervals are changed, > '... all > subsequent transmitted Control packets MUST be sent with the Poll (P) > bit set > until a packet is received with the Final (F) bit set.' It is not > clear to > me how to implement these seemingly contradictory statements. Good catch. The statement that all packets have to be sent with Poll should not apply to packets being generated in response to a received Poll. This will be fixed... > > 2. While I am not sure that the document specifically states this, it > appears > to me that the poll and final bits should only be set when in the up > state? Yep. Originally the P/F bits were only used when Demand Mode was active, which can only happen in Up state. However, we leveraged P/F for parameter changes. This should only apply in Up state. Will be fixed... --Dave From rtg-bfd-bounces@ietf.org Thu Feb 3 02:45:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25628; Thu, 3 Feb 2005 02:45:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwbz2-0004Xd-Mw; Thu, 03 Feb 2005 03:05:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwbfI-0000bJ-1Y; Thu, 03 Feb 2005 02:44:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwbdS-0008VL-JE for rtg-bfd@megatron.ietf.org; Thu, 03 Feb 2005 02:42:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25329 for ; Thu, 3 Feb 2005 02:42:41 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwbvy-0004Sr-AU for rtg-bfd@ietf.org; Thu, 03 Feb 2005 03:01:51 -0500 Received: by rproxy.gmail.com with SMTP id f1so176319rne for ; Wed, 02 Feb 2005 23:42:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=rwgpeNMOfNiBsh/80BQx+eKxIeuYi3bHsWTMSn0pEm/pmVT5GNQoDH7sDWq/W+0QFTfIPx4gjWb4IbuwaGFaAG/LYarT2BZoIqtYmNUK8PcuGWImy5JpSU9FItNR/aaIzLreToLWvCAwLWYdtKlbQP/GnR1EsbrD8Zqk6mmhb8Y= Received: by 10.38.59.52 with SMTP id h52mr105637rna; Wed, 02 Feb 2005 23:42:40 -0800 (PST) Received: by 10.38.125.72 with HTTP; Wed, 2 Feb 2005 23:42:40 -0800 (PST) Message-ID: <9e31186f05020223425e32fff8@mail.gmail.com> Date: Thu, 3 Feb 2005 08:42:40 +0100 From: Carlos Garcia Braschi To: rtg-bfd@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: static routes and eBGP specifications for BFD X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Carlos Garcia Braschi List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Hi, I have just re-read most of the archives on the list and haven't found more about BFD for eBGP and static routes that it has been called for and that is included in the WG charter. Unfortunately, those would be our most needed usages for this mechanism. Is support for them going to be added to the 1hop/multihop draft anytime soon? Are there any difficulties associated with drafting/implementing it? eBGP does not seem very different from OSPF / IS-IS implementation. Are the drafts going to be un-expired soon? Regards, Carlos. -- Telefonica Empresas From rtg-bfd-bounces@ietf.org Thu Feb 3 02:48:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25838; Thu, 3 Feb 2005 02:48:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwc1Z-0004eu-9s; Thu, 03 Feb 2005 03:07:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwbhy-000136-DD; Thu, 03 Feb 2005 02:47:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwbfY-0000bd-Gm for rtg-bfd@megatron.ietf.org; Thu, 03 Feb 2005 02:44:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25570 for ; Thu, 3 Feb 2005 02:44:51 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwby0-0004Vc-7B for rtg-bfd@ietf.org; Thu, 03 Feb 2005 03:04:01 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IBB00KBUS23IT@szxga01-in.huawei.com> for rtg-bfd@ietf.org; Thu, 03 Feb 2005 15:42:03 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IBB004LTS23VJ@szxga01-in.huawei.com> for rtg-bfd@ietf.org; Thu, 03 Feb 2005 15:42:03 +0800 (CST) Received: from z11024 ([10.110.49.48]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IBB00CSFS31O9@szxml02-in.huawei.com>; Thu, 03 Feb 2005 15:42:37 +0800 (CST) Date: Thu, 03 Feb 2005 15:43:06 +0800 From: zhaisuping To: Dave Katz Message-id: <0IBB00CSGS31O9@szxml02-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7BIT Cc: "rtg-bfd@ietf.org" Subject: Re: Re: Transition from failing state X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhaisuping@huawei.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7BIT comments on the BFD mechanism for MPLS application: 1.may the detection type add the FEC_Mismatch in MPLS application? we can do so by adding some fiels,for example FEC Filter as in Y.1713 to BFD control packet. 2.can the BFD development the mechanism to notify the defect to the far end of the LSP, I mean when the nested LSP has a defect, how the upper LSP know the defect? I think a way to solve this problem is that, when LSP is setup, record some information for this use is ok. So when nested LSP is wrong, it can be notified to the upper LSP layer through the BFD packet, in which I Hear You is 0, and Diag is 7(administratively down). welcome the further discuss. best regards, suping >On Feb 1, 2005, at 12:11 AM, wrote: > >> Section 6.6.6 of draft-ietf-bfd-base-00.txt states: >> >> Else if bfd.SessionState is Failing >> If I Hear You is zero, set bfd.SessionState to Down >> >> However, unless I'm missing something, the draft does not appear to >> describe what happens if bfd.SessionState is Failing and: >> >> - The sink/destination receives a BFD packet >> - The source receives a BFD packet with a nonzero I Hear You >> >> Should the node transition to the init state? > >Nope, the whole point of Failing state is to wait there until IHU=0, >thus ensuring that the other end has killed the session as well. In >the pseudocode in the spec, you simply fall through on that test and go >on with the rest of the process. > >--Dave >\ From rtg-bfd-bounces@ietf.org Thu Feb 3 03:03:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26922; Thu, 3 Feb 2005 03:03:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwcGO-00054h-H2; Thu, 03 Feb 2005 03:22:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwbqR-0002lq-Sd; Thu, 03 Feb 2005 02:56:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwboX-0002Jj-4X for rtg-bfd@megatron.ietf.org; Thu, 03 Feb 2005 02:54:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26157 for ; Thu, 3 Feb 2005 02:54:07 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwc72-0004ne-IP for rtg-bfd@ietf.org; Thu, 03 Feb 2005 03:13:18 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j137rUv09911; Thu, 3 Feb 2005 09:53:31 +0200 Date: Thu, 3 Feb 2005 09:53:30 +0200 (EET) From: Pekka Savola To: Carlos Garcia Braschi In-Reply-To: <9e31186f05020223425e32fff8@mail.gmail.com> Message-ID: References: <9e31186f05020223425e32fff8@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: rtg-bfd@ietf.org Subject: Re: static routes and eBGP specifications for 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Thu, 3 Feb 2005, Carlos Garcia Braschi wrote: > Is support for them going to be added to the 1hop/multihop draft > anytime soon? Are there any difficulties associated with > drafting/implementing it? eBGP does not seem very different from OSPF > / IS-IS implementation. > Are the drafts going to be un-expired soon? I submitted some text which was hashed over on the mailing list, so I think (hope!) the status is "going to be included in the next revision". -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rtg-bfd-bounces@ietf.org Thu Feb 3 03:37:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29477; Thu, 3 Feb 2005 03:37:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwcmY-000603-0c; Thu, 03 Feb 2005 03:56:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwcP5-00024B-IU; Thu, 03 Feb 2005 03:31:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwcN0-0001S2-Qy for rtg-bfd@megatron.ietf.org; Thu, 03 Feb 2005 03:29:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28900 for ; Thu, 3 Feb 2005 03:29:45 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwcfX-0005nQ-12 for rtg-bfd@ietf.org; Thu, 03 Feb 2005 03:48:56 -0500 Received: by rproxy.gmail.com with SMTP id f1so180256rne for ; Thu, 03 Feb 2005 00:29:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=pODMrZG/hVRVpogzSbJGXGRgPFZb/wMTP1+BDsDPGg8v2KXkJq8JGMcS9U+GT9IEAupBSPX60dFLG8pmfFKOuXcbYoGATeByih+vlViy0hoNMk6YSZB3D7TxZc2JLYnhiqU2oApqeg9iUP4INZrkSYE0xABCZSWBN0NujlDMVWE= Received: by 10.38.81.76 with SMTP id e76mr66745rnb; Thu, 03 Feb 2005 00:29:44 -0800 (PST) Received: by 10.38.125.72 with HTTP; Thu, 3 Feb 2005 00:29:44 -0800 (PST) Message-ID: <9e31186f0502030029574416ef@mail.gmail.com> Date: Thu, 3 Feb 2005 09:29:44 +0100 From: Carlos Garcia Braschi To: Pekka Savola In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <9e31186f05020223425e32fff8@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: static routes and eBGP specifications for BFD X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Carlos Garcia Braschi List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit On Thu, 3 Feb 2005 09:53:30 +0200 (EET), Pekka Savola wrote: > On Thu, 3 Feb 2005, Carlos Garcia Braschi wrote: > > Is support for them going to be added to the 1hop/multihop draft > > anytime soon? Are there any difficulties associated with > > drafting/implementing it? eBGP does not seem very different from OSPF > > / IS-IS implementation. > > Are the drafts going to be un-expired soon? > > I submitted some text which was hashed over on the mailing list, so I Thanks for the answer. I have been reading through all the archives but were not able to find anything more about eBGP and static than the discussions about the charter. The archives of the mailing list are empty from June to September, perhaps was it discussed then and later the archive got lost? (I thought it was just lack of activity, but other quiet months do at least have the monthly reminder). > think (hope!) the status is "going to be included in the next > revision". > From rtg-bfd-bounces@ietf.org Sat Feb 12 03:39:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08742; Sat, 12 Feb 2005 03:39:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czt8m-0005CM-9c; Sat, 12 Feb 2005 04:00:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzsnG-0001CA-6e; Sat, 12 Feb 2005 03:38:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzsmQ-0000yw-KH for rtg-bfd@megatron.ietf.org; Sat, 12 Feb 2005 03:37:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08623 for ; Sat, 12 Feb 2005 03:37:28 -0500 (EST) From: richard.spencer@bt.com Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czt6o-00058Q-EW for rtg-bfd@ietf.org; Sat, 12 Feb 2005 03:58:34 -0500 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Sat, 12 Feb 2005 08:38:37 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Sat, 12 Feb 2005 08:38:37 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 12 Feb 2005 08:38:37 -0000 Message-ID: Thread-Topic: Transition from failing state Thread-Index: AcUJeG1yKC+pQTLLQYySDo+YrYMmQgGySsUA To: , X-OriginalArrivalTime: 12 Feb 2005 08:38:37.0588 (UTC) FILETIME=[3F031D40:01C510DE] X-Spam-Score: 0.3 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org, dward@cisco.com Subject: State machine diagram & alarm generation 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable Dave, Jeff, Sorry for the delay in responding to your comments.=20 First of all, thank you for taking the time to clarify the state = machine. Do you think it would be worthwhile adding a state machine = diagram to the base document to provide clarification? I think this = would help anyone reading the draft for the first time understand the = state transitions without having to methodically work through the = If/Then statements. Regarding my comments about looping through the Failing, Down, Init = states whilst a unidirectional failure exists, my concern is from an = alarm perspective. If an implementation is configured to raise an alarm = upon entering the Failing state, then it may continuously send out = alarms as it loops through the various states. If we had a tunnel LSP = failure that was carrying thousands of PWs, each running VCCV BFD, then = this would be a lot of unnecessary alarms to deal with. Obviously this = could be avoided by requiring that the implementation only raises an = alarm when transitioning from the up state to the Failing state (not = Init to Failing state). Do you know how alarms are raised in current BFD = implementations? Also, in the MPLS case an alarm should only be raised if an FDI/AIS = hasn't been received from an underlying server layer, Therefore, on = entering the Failing defect state (if this is indeed when an alarm is = raised) then a node should wait a couple of seconds to see if it gets an = FDI before raising an alarm. The issue of raising alarms is not covered in the current draft, other = than saying "The exact action taken when the session state changes is = outside the scope of this specification, though it is expected that this = state change (particularly to and from Up state) is reported to other = components of the system." Perhaps this is seen as an implementation = issue? However, in a multivendor environment, alarms must be generated = in a consistent manner across different boxes. If there is no intention = to address the issue of when alarms should be raised within the current = BFD drafts, are there plans to cover this issue elsewhere in a separate = draft, e.g. something like a BFD best practices draft? Thanks, Richard > -----Original Message----- > From: Dave Katz [mailto:dkatz@juniper.net] > Sent: 02 February 2005 22:40 > To: Jeffrey Haas > Cc: rtg-bfd@ietf.org; dward@cisco.com; Spencer,R,Richard,XDE R > Subject: Re: Transition from failing state >=20 >=20 >=20 > On Feb 2, 2005, at 12:52 PM, Jeffrey Haas wrote: >=20 > > On Wed, Feb 02, 2005 at 12:29:23PM -0000,=20 > richard.spencer@bt.com wrote: > >> Therefore, it seems to me that whilst A->B connectivity is=20 > lost, Node=20 > >> B will remain permanently in the Failing state, whilst Node A will=20 > >> loop continuously though the Failing, Down, Init states. Is this=20 > >> correct or am I missing something? > > > > Correct. By analogy, this isn't much worse (given the=20 > fallback to a 1 > > second timer for sending packets) than something like BGP=20 > transitioning > > through it's statemachine. > > > > It is up to an implementation whether it wants to leave a=20 > BFD instance > > running on a session that is otherwise down for a long=20 > period of time. > > For example, if BFD was supporting OSPF, then one could presume an > > implementation would delete the BFD instance for a given=20 > pair of peers > > until the OSPF hello protocol noticed that the session was up again. >=20 > Yep, in the case of one-way connectivity, this is what will happen. =20 > Given that the only "interesting" transition is Up->Failing (or=20 > perhaps, in limited cases, Init->Up) the machinations of the state=20 > machine hurt nobody. One could indeed claim that they are=20 > useful; in=20 > particular, timing out of Init state carries useful semantics. >=20 > > > >> Also, the only exit criteria described for the Failing state is as=20 > >> follows: > >> > >> Else if bfd.SessionState is Failing > >> If I Hear You is zero, set bfd.SessionState to Down > >> > >> What happens if just after entering the Failing state (due to=20 > >> detection timeout as in the previous example),=20 > connectivity A->B is=20 > >> restored and Node B receives a BFD packet from node A with=20 > a I Hear=20 > >> You of nonzero? This would occur if node A (whilst still in the Up=20 > >> state) sends a BFD packet to node B before it receives the BFD=20 > >> failure notification from Node B (with H bit set to 0 and=20 > Diag set to=20 > >> 1). > > > > This isn't any different than B saying that it wishes to tear the=20 > > connection > > down. The state machine could go through the usual motions of=20 > > restoring > > the connection, but B would do so starting from the failing=20 > state and=20 > > would > > have to wait for A to acknowledge it. >=20 > Indeed. The intent of the state machine is to make sure both sides=20 > *always* know that the session has failed. If it takes a couple of=20 > extra packets to get the session going again in some=20 > relatively unusual=20 > instances, that's no big deal (and not worth the complexity to try to=20 > optimize it out.) >=20 > --Dave >=20 >=20 From rtg-bfd-bounces@ietf.org Mon Feb 14 12:39:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25566; Mon, 14 Feb 2005 12:39:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0kWr-0007tK-3X; Mon, 14 Feb 2005 13:01:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0kAi-0005uD-0S; Mon, 14 Feb 2005 12:38:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0k8U-0005gw-JL for rtg-bfd@megatron.ietf.org; Mon, 14 Feb 2005 12:35:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25333 for ; Mon, 14 Feb 2005 12:35:47 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0kTM-0007np-Nf for rtg-bfd@ietf.org; Mon, 14 Feb 2005 12:57:25 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 58C092D4C78; Mon, 14 Feb 2005 12:35:12 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11174-01-3; Mon, 14 Feb 2005 12:35:07 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 616872D5343; Mon, 14 Feb 2005 12:20:50 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j1EHKni22826; Mon, 14 Feb 2005 12:20:49 -0500 (EST) Date: Mon, 14 Feb 2005 12:20:49 -0500 From: Jeffrey Haas To: richard.spencer@bt.com Message-ID: <20050214172049.GE9306@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: rtg-bfd@ietf.org, dkatz@juniper.net, dward@cisco.com Subject: Re: State machine diagram & alarm generation 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Richard, On Sat, Feb 12, 2005 at 08:38:37AM -0000, richard.spencer@bt.com wrote: > First of all, thank you for taking the time to clarify the state > machine. Do you think it would be worthwhile adding a state machine > diagram to the base document to provide clarification? I'll let the authors answer, but it sounds useful to me. :-) > Regarding my comments about looping through the Failing, Down, > Init states whilst a unidirectional failure exists, my concern is > from an alarm perspective. The proposed MIB had covered this particular issue. The MIB authors are waiting on the base specification authors before they republish. (This is a reminder to everyone that the time left to submit drafts prior to the next IETF is rapdily dwindling.) >From the MIB: bfdSessUp NOTIFICATION-TYPE OBJECTS { bfdSessDiag, -- low range value bfdSessDiag -- high range value } STATUS current DESCRIPTION "This notification is generated when the bfdSessState object for one or more contiguous entries in bfdSessTable are about to enter the up(2) state from some other state. The included values of bfdSessDiag MUST both be set equal to this new state (i.e: up(1)). The two instances of bfdSessDiag in this notification indicate the range of indexes that are affected. Note that all the indexes of the two ends of the range can be derived from the instance identifiers of these two objects. For cases where a contiguous range of sessions have transitioned into the up(1) state at roughly the same time, the device SHOULD issue a single notification for each range of contiguous indexes in an effort to minimize the emission of a large number of notifications. If a notification has to be issued for just a single bfdSessEntry, then the instance identifier (and values) of the two bfdSessDiag objects MUST be the identical." ::= { bfdNotifications 1 } bfdSessDown NOTIFICATION-TYPE OBJECTS { bfdSessDiag, -- low range value bfdSessDiag -- high range value } STATUS current DESCRIPTION "This notification is generated when the bfdSessState object for one or more contiguous entries in bfdSessTable are about to enter the down(4) or adminDown(5) states from some other state. The included values of bfdSessDiag MUST both be set equal to this new state (i.e: down(4) or adminDown(5)). The two instances of bfdSessDiag in this notification indicate the range of indexes that are affected. Note that all the indexes of the two ends of the range can be derived from the instance identifiers of these two objects. For cases where a contiguous range of sessions have transitioned into the down(4) or adminDown(5) states at roughly the same time, the device SHOULD issue a single notification for each range of contiguous indexes in an effort to minimize the emission of a large number of notifications. If a notification has to be issued for just a single bfdSessEntry, then the instance identifier (and values) of the two bfdSessDiag objects MUST be the identical." ::= { bfdNotifications 2 } > If an implementation is configured to > raise an alarm upon entering the Failing state, then it may > continuously send out alarms as it loops through the various states. The events in BFD that are of primary use are the transitions in and out of the up state. While an implementation might have some valid use for transitions amongst other states, I suspect that most wont. To provide a similar example, the SNMP notification events for BGP's state machine theoretically cover any state transition from a higher numbered state to a lower numbered state. In practice, this just generates unnecessary events. Several implementations will only send these events when a transition occurs out of Established. > However, in a multivendor environment, > alarms must be generated in a consistent manner across different > boxes. If there is no intention to address the issue of when alarms > should be raised within the current BFD drafts, are there plans to > cover this issue elsewhere in a separate draft, e.g. something like > a BFD best practices draft? Do you think that addressing this outside the MIB is appropriate? If so, perhaps you could propose some text. > Richard -- Jeff Haas NextHop Technologies From rtg-bfd-bounces@ietf.org Tue Feb 15 18:47:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29477; Tue, 15 Feb 2005 18:47:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Cl1-0005md-O7; Tue, 15 Feb 2005 19:09:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1CJX-0006RI-Mj; Tue, 15 Feb 2005 18:41:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1CFo-0005IU-96 for rtg-bfd@megatron.ietf.org; Tue, 15 Feb 2005 18:37:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28635 for ; Tue, 15 Feb 2005 18:37:13 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Cav-0005UH-M6 for rtg-bfd@ietf.org; Tue, 15 Feb 2005 18:59:07 -0500 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 j1FNaaBm032172; Tue, 15 Feb 2005 15:36:36 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.201] (nimbus-bsr.juniper.net [172.16.12.201]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j1FNaOe09285; Tue, 15 Feb 2005 15:36:24 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <20050214172049.GE9306@nexthop.com> References: <20050214172049.GE9306@nexthop.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5480cd781621f2859e484a75f32bd052@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Tue, 15 Feb 2005 15:36:21 -0800 To: Jeffrey Haas X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org, dward@cisco.com Subject: Re: State machine diagram & alarm generation 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit On Feb 14, 2005, at 9:20 AM, Jeffrey Haas wrote: > Richard, > > On Sat, Feb 12, 2005 at 08:38:37AM -0000, richard.spencer@bt.com wrote: >> First of all, thank you for taking the time to clarify the state >> machine. Do you think it would be worthwhile adding a state machine >> diagram to the base document to provide clarification? > > I'll let the authors answer, but it sounds useful to me. :-) I can try to add some ASCII art, but it would probably be more straightforward to just add a brief paragraph describing the state machine, which is really quite simple. I'll give that a shot first. (Working on the next rev...) --Dave From rtg-bfd-bounces@ietf.org Wed Feb 16 07:41:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03030; Wed, 16 Feb 2005 07:41:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Opj-0002bI-2n; Wed, 16 Feb 2005 08:03:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1OPc-0001c7-Qb; Wed, 16 Feb 2005 07:36:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1OOI-0001IB-TZ for rtg-bfd@megatron.ietf.org; Wed, 16 Feb 2005 07:34:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02518 for ; Wed, 16 Feb 2005 07:34:49 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1OjX-0002Ia-8J for rtg-bfd@ietf.org; Wed, 16 Feb 2005 07:56:48 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 16 Feb 2005 04:45:58 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,88,1107763200"; d="scan'208"; a="614925336:sNHT20588984" Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1GCYFq8000313; Wed, 16 Feb 2005 04:34:16 -0800 (PST) Received: (from albright@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id EAA28292; Wed, 16 Feb 2005 04:34:15 -0800 (PST) Date: Wed, 16 Feb 2005 4:34:15 PST From: Bob Albrightson To: Dave Katz In-Reply-To: Your message of Tue, 15 Feb 2005 15:36:21 -0800 Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: rtg-bfd@ietf.org, Jeffrey Haas , dward@cisco.com Subject: Re: State machine diagram & alarm generation X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bob Albrightson List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 > > On Feb 14, 2005, at 9:20 AM, Jeffrey Haas wrote: > > > Richard, > > > > On Sat, Feb 12, 2005 at 08:38:37AM -0000, richard.spencer@bt.com wrote: > >> First of all, thank you for taking the time to clarify the state > >> machine. Do you think it would be worthwhile adding a state machine > >> diagram to the base document to provide clarification? > > > > I'll let the authors answer, but it sounds useful to me. :-) > > I can try to add some ASCII art, but it would probably be more > straightforward to just add a brief paragraph describing the state > machine, which is really quite simple. I'll give that a shot first. > (Working on the next rev...) > > --Dave > This is something I cooked up a while ago. Let me know if there are any issues with it. -bob BFD state diagram +------------+ Rx_IHY = 1 | | +--------------------------------------------->| UP | | | | | +------------+ | | ^ | | | +------------+ Detection +------------+ Rx_IHY=0 / | | | Expired | |<------------+ | | INIT |---------->| FAILING | | Rx_IHY = 1 | | | |-------------+ | +------------+ +------------+ Rx_IHY=0 \ | | ^ | | | | +------+ v | | Rx_IHY=1 +------------+ | | | +--------------------------------------------->| DOWN | Rx_IHY = 0 | | +------------+ From rtg-bfd-bounces@ietf.org Wed Feb 16 23:20:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08870; Wed, 16 Feb 2005 23:20:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1dUv-0005y8-EN; Wed, 16 Feb 2005 23:42:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1d7D-0005ld-Bs; Wed, 16 Feb 2005 23:18:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1cwE-0001r8-7O for rtg-bfd@megatron.ietf.org; Wed, 16 Feb 2005 23:06:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07846 for ; Wed, 16 Feb 2005 23:06:46 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1dHZ-0005eY-V7 for rtg-bfd@ietf.org; Wed, 16 Feb 2005 23:28:55 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j1H46iMT003923 for ; Wed, 16 Feb 2005 22:06:45 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id <1TWCHJXJ>; Thu, 17 Feb 2005 09:36:43 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D2123A1581@ii0015exch002u.iprc.lucent.com> From: "Gupta, Bikram Kumar (Bikram)" To: "'rtg-bfd@ietf.org'" Date: Thu, 17 Feb 2005 09:36:42 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: Need a copy of the draft: draft-ietf-bfd-base-0x.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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 > Hi, > Sorry for the wide distribution. > The draft: draft-ietf-bfd-base-01.txt has expired and so I can not > get a copy of it. I will be thankful if someone mails it across to > me. > > Regards, > Bikram. > From rtg-bfd-bounces@ietf.org Thu Feb 17 02:39:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19076; Thu, 17 Feb 2005 02:39:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1gbm-0002W1-Mv; Thu, 17 Feb 2005 03:01:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1g96-0000FX-Bw; Thu, 17 Feb 2005 02:32:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1g6n-0007Z1-8W for rtg-bfd@megatron.ietf.org; Thu, 17 Feb 2005 02:29:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18146 for ; Thu, 17 Feb 2005 02:29:56 -0500 (EST) From: richard.spencer@bt.com Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1gSB-0002HH-Fn for rtg-bfd@ietf.org; Thu, 17 Feb 2005 02:52:04 -0500 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Thu, 17 Feb 2005 07:31:04 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Feb 2005 07:31:04 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 17 Feb 2005 07:31:02 -0000 Message-ID: Thread-Topic: State machine diagram & alarm generation thread-index: AcUUJRzoggDrgu5+RC24a/gydMuXRwAmr5gu To: , X-OriginalArrivalTime: 17 Feb 2005 07:31:04.0524 (UTC) FILETIME=[A34360C0:01C514C2] X-Spam-Score: 0.3 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: base64 Cc: rtg-bfd@ietf.org, jhaas@nexthop.com, dward@cisco.com Subject: RE: State machine diagram & alarm generation 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: base64 Qm9iLA0KDQogDQoNClRoYW5rcywgSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gYWRkIHRo aXMgZGlhZ3JhbSB0byB0aGUgZHJhZnQuIE9uZSBtaW5vciBwb2ludCBpcyB0aGF0IHRoZSBhcnJv dyBiZXR3ZWVuIERvd24gYW5kIEluaXQgaXMgcG9pbnRpbmcgdG93YXJkcyBEb3duLCB0aGlzIHNo b3VsZCBiZSByZXZlcnNlZCB0byBkZXNjcmliZSB0aGUgc3RhdGUgY2hhbmdlIGZyb20gRG93biB0 byBJbml0IG9uIHJlY2VpcHQgb2YgYSBwYWNrZXQgd2l0aCBJSFkgPSAwIHJhdGhlciB0aGFuIHRo ZSBvdGhlciB3YXkgcm91bmQuIEFsc286DQoNCiANCg0KMS4gSSB0aGluayBpdCB3b3VsZCBiZSB3 b3J0aCBhZGRpbmcgdGhlIHRleHQgIk9yIERldGVjdGlvbiBFeHBpcmVkIiB3aGVyZSBpdCBzYXlz ICJSeF9JSFkgPSAwIiBhYm92ZSB0aGUgYXJyb3cgcG9pbnRpbmcgZnJvbSBVcCB0byBGYWlsaW5n ICh0byBkZXNjcmliZSB0aGUgc3RhdGUgY2hhbmdlIHRvIEZhaWxpbmcgZnJvbSBVcCBvbiBEZXRl Y3Rpb24gVGltZSBleHBpcmF0aW9uKS4NCg0KIA0KDQoyLiBJdCB3b3VsZCBiZSBnb29kIHRvIGhh dmUgYSBsb29wIGJhY2sgYXJyb3cgdG8vZnJvbSB0aGUgSW5pdCBzdGF0ZSBvbiByZWNlaXB0IG9m IEJGRCBwYWNrZXRzIHdpdGggSUhZID0gMCAoc2ltaWxhciB0byB0aGUgbG9vcCBvbiB0aGUgZmFp bGluZyBzdGF0ZSBmb3IgSUhZID0gMSkuDQoNCiANCg0KUmVnYXJkcywNCg0KUmljaGFyZA0KDQoJ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogcnRnLWJmZC1ib3VuY2VzQGlldGYu b3JnIG9uIGJlaGFsZiBvZiBCb2IgQWxicmlnaHRzb24gDQoJU2VudDogV2VkIDE2LzAyLzIwMDUg MDc6MzQgDQoJVG86IERhdmUgS2F0eiANCglDYzogcnRnLWJmZEBpZXRmLm9yZzsgSmVmZnJleSBI YWFzOyBkd2FyZEBjaXNjby5jb20gDQoJU3ViamVjdDogUmU6IFN0YXRlIG1hY2hpbmUgZGlhZ3Jh bSAmIGFsYXJtIGdlbmVyYXRpb24NCgkNCgkNCg0KCT4NCgk+IE9uIEZlYiAxNCwgMjAwNSwgYXQg OToyMCBBTSwgSmVmZnJleSBIYWFzIHdyb3RlOg0KCT4NCgk+ID4gUmljaGFyZCwNCgk+ID4NCgk+ ID4gT24gU2F0LCBGZWIgMTIsIDIwMDUgYXQgMDg6Mzg6MzdBTSAtMDAwMCwgcmljaGFyZC5zcGVu Y2VyQGJ0LmNvbSB3cm90ZToNCgk+ID4+IEZpcnN0IG9mIGFsbCwgdGhhbmsgeW91IGZvciB0YWtp bmcgdGhlIHRpbWUgdG8gY2xhcmlmeSB0aGUgc3RhdGUNCgk+ID4+IG1hY2hpbmUuIERvIHlvdSB0 aGluayBpdCB3b3VsZCBiZSB3b3J0aHdoaWxlIGFkZGluZyBhIHN0YXRlIG1hY2hpbmUNCgk+ID4+ IGRpYWdyYW0gdG8gdGhlIGJhc2UgZG9jdW1lbnQgdG8gcHJvdmlkZSBjbGFyaWZpY2F0aW9uPw0K CT4gPg0KCT4gPiBJJ2xsIGxldCB0aGUgYXV0aG9ycyBhbnN3ZXIsIGJ1dCBpdCBzb3VuZHMgdXNl ZnVsIHRvIG1lLiA6LSkNCgk+DQoJPiBJIGNhbiB0cnkgdG8gYWRkIHNvbWUgQVNDSUkgYXJ0LCBi dXQgaXQgd291bGQgcHJvYmFibHkgYmUgbW9yZQ0KCT4gc3RyYWlnaHRmb3J3YXJkIHRvIGp1c3Qg YWRkIGEgYnJpZWYgcGFyYWdyYXBoIGRlc2NyaWJpbmcgdGhlIHN0YXRlDQoJPiBtYWNoaW5lLCB3 aGljaCBpcyByZWFsbHkgcXVpdGUgc2ltcGxlLiAgSSdsbCBnaXZlIHRoYXQgYSBzaG90IGZpcnN0 LiANCgk+IChXb3JraW5nIG9uIHRoZSBuZXh0IHJldi4uLikNCgk+DQoJPiAtLURhdmUNCgk+DQoJ DQoJVGhpcyBpcyBzb21ldGhpbmcgSSBjb29rZWQgdXAgYSB3aGlsZSBhZ28uICBMZXQgbWUga25v dyBpZiB0aGVyZSBhcmUNCglhbnkgaXNzdWVzIHdpdGggaXQuDQoJDQoJIC1ib2INCgkNCgkNCgkN CgkgICAgICAgICAgICAgICAgICAgICAgICAgIEJGRCBzdGF0ZSBkaWFncmFtDQoJDQoJDQoJICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0t LS0tLS0tKw0KCSAgICAgICAgICAgICAgICAgICAgUnhfSUhZID0gMSAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgIHwNCgkgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPnwgICAgIFVQICAgICB8DQoJICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgfA0KCSAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LSsNCgkgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgIF4NCgkgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgIHwNCgkrLS0tLS0tLS0tLS0tKyBEZXRlY3Rpb24gKy0tLS0tLS0tLS0tLSsg ICBSeF9JSFk9MCAgIC8gICAgIHwNCgl8ICAgICAgICAgICAgfCAgRXhwaXJlZCAgfCAgICAgICAg ICAgIHw8LS0tLS0tLS0tLS0tKyAgICAgIHwNCgl8ICAgIElOSVQgICAgfC0tLS0tLS0tLS0+fCAg IEZBSUxJTkcgIHwgICAgICAgICAgICAgICAgICAgIHwgUnhfSUhZID0gMQ0KCXwgICAgICAgICAg ICB8ICAgICAgICAgICB8ICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0rICAgICAgfA0KCSstLS0t LS0tLS0tLS0rICAgICAgICAgICArLS0tLS0tLS0tLS0tKyAgIFJ4X0lIWT0wICAgXCAgICAgfA0K CSAgICAgIHwgICAgICAgICAgICAgICAgICAgICBeICAgICAgfCAgICAgICAgICAgICAgICAgIHwg ICAgfA0KCSAgICAgIHwgICAgICAgICAgICAgICAgICAgICArLS0tLS0tKyAgICAgICAgICAgICAg ICAgIHYgICAgfA0KCSAgICAgIHwgICAgICAgICAgICAgICAgICAgICBSeF9JSFk9MSAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLSsNCgkgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICB8DQoJICAgICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58ICAgIERPV04gICAgfA0KCSAgICAg ICAgICAgICAgICAgICAgUnhfSUhZID0gMCAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgIHwNCgkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0rDQoJDQoJDQoNCg== From rtg-bfd-bounces@ietf.org Thu Feb 17 04:24:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27858; Thu, 17 Feb 2005 04:24:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1iFV-00055L-Mt; Thu, 17 Feb 2005 04:47:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1hsq-0000HB-0F; Thu, 17 Feb 2005 04:23:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1hnr-0006l7-A9 for rtg-bfd@megatron.ietf.org; Thu, 17 Feb 2005 04:18:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27469 for ; Thu, 17 Feb 2005 04:18:29 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1i9G-0004xX-En for rtg-bfd@ietf.org; Thu, 17 Feb 2005 04:40:39 -0500 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 j1H9HwBm060601; Thu, 17 Feb 2005 01:17:58 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.201] (nimbus-bsr.juniper.net [172.16.12.201]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j1H9Hwe57775; Thu, 17 Feb 2005 01:17:58 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2039da8fe9047586a9d5883d5dcd4b3e@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 17 Feb 2005 01:17:55 -0800 To: Bikram Kumar (Bikram) Gupta X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: "'rtg-bfd@ietf.org'" Subject: (no subject) 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit I'm working on an updated draft. Should be out in a few days. --Dave On Feb 16, 2005, at 8:06 PM, Gupta, Bikram Kumar (Bikram) wrote: >> Hi, >> > Sorry for the wide distribution. > >> The draft: draft-ietf-bfd-base-01.txt has expired and so I can not >> get a copy of it. I will be thankful if someone mails it across to >> me. >> >> Regards, >> Bikram. >> > From rtg-bfd-bounces@ietf.org Thu Feb 17 05:01:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01160; Thu, 17 Feb 2005 05:01:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1iot-0005x5-Je; Thu, 17 Feb 2005 05:23:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1iRn-0004gy-Cw; Thu, 17 Feb 2005 04:59:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1iPT-0003vv-5K for rtg-bfd@megatron.ietf.org; Thu, 17 Feb 2005 04:57:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00681 for ; Thu, 17 Feb 2005 04:57:21 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1iks-0005r0-Ef for rtg-bfd@ietf.org; Thu, 17 Feb 2005 05:19:31 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 17 Feb 2005 01:57:27 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1H9uiuC008825; Thu, 17 Feb 2005 01:56:45 -0800 (PST) Received: from [81.254.5.100] (ams-clip-vpn-dhcp304.cisco.com [10.61.65.48]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APE81989; Thu, 17 Feb 2005 04:56:44 -0500 (EST) In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D2123A1581@ii0015exch002u.iprc.lucent.com> References: <6733C768256DEC42A72BAFEFA9CF06D2123A1581@ii0015exch002u.iprc.lucent.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Thu, 17 Feb 2005 10:56:44 +0100 To: "Gupta, Bikram Kumar (Bikram)" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: "'rtg-bfd@ietf.org'" , Jeffrey Haas Subject: Re: Need a copy of the draft: draft-ietf-bfd-base-0x.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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit I spoke with one of the co-chairs yesterday who is in the process of refreshing all of the BFD WG drafts. --Tom >> Hi, >> > Sorry for the wide distribution. > >> The draft: draft-ietf-bfd-base-01.txt has expired and so I can not >> get a copy of it. I will be thankful if someone mails it across to >> me. >> >> Regards, >> Bikram. >> > From rtg-bfd-bounces@ietf.org Thu Feb 17 06:17:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08438; Thu, 17 Feb 2005 06:17:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1k09-0007pq-Rm; Thu, 17 Feb 2005 06:39:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1jX7-0006fh-Kd; Thu, 17 Feb 2005 06:09:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1jVA-0005bQ-I0 for rtg-bfd@megatron.ietf.org; Thu, 17 Feb 2005 06:07:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07729 for ; Thu, 17 Feb 2005 06:07:18 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1jqa-0007aB-RL for rtg-bfd@ietf.org; Thu, 17 Feb 2005 06:29:30 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 17 Feb 2005 04:19:54 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,93,1107734400"; d="scan'208"; a="226233372:sNHT23566764" Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1HB6Uq8012189; Thu, 17 Feb 2005 03:06:30 -0800 (PST) Received: (from albright@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id DAA23378; Thu, 17 Feb 2005 03:06:34 -0800 (PST) Date: Thu, 17 Feb 2005 3:06:34 PST From: Bob Albrightson To: richard.spencer@bt.com In-Reply-To: Your message of Thu, 17 Feb 2005 07:31:02 -0000 Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: rtg-bfd@ietf.org, jhaas@nexthop.com, dkatz@juniper.net, dward@cisco.com Subject: RE: State machine diagram & alarm generation X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bob Albrightson List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 > Bob, > > > > Thanks, I think it would be useful to add this diagram to the > draft. One minor point is that the arrow between Down and Init is > pointing towards Down, this should be reversed to describe the state > change from Down to Init on receipt of a packet with IHY = 0 rather > than the other way round. Also: > > > > 1. I think it would be worth adding the text "Or Detection Expired" > where it says "Rx_IHY = 0" above the arrow pointing from Up to > Failing (to describe the state change to Failing from Up on > Detection Time expiration). > > > > 2. It would be good to have a loop back arrow to/from the Init state > on receipt of BFD packets with IHY = 0 (similar to the loop on the > failing state for IHY = 1). Thanks for the comments. Here is the new ascii art. -bob BFD state diagram Rx_IHY=1 +------+ | v +------------+ Rx_IHY = 1 | | +--------------------------------------------->| UP | | | | | Detection +------------+ | Expired | ^ | or | | +------------+ Detection +------------+ Rx_IHY=0 / | | | Expired | |<------------+ | | INIT |---------->| FAILING | | Rx_IHY = 1 | |--+ | |-------------+ | +------------+ | +------------+ Rx_IHY=0 \ | ^ ^ | ^ | | | | +------+ +------+ v | | Rx_IHY=0 Rx_IHY=1 +------------+ | | | +----------------------------------------------| DOWN | Rx_IHY = 0 | | +------------+ From rtg-bfd-bounces@ietf.org Thu Feb 17 07:30:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15329; Thu, 17 Feb 2005 07:30:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1l8v-0001Ee-8B; Thu, 17 Feb 2005 07:52:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1kjg-0003sd-Sx; Thu, 17 Feb 2005 07:26:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1kbN-0000bA-V8 for rtg-bfd@megatron.ietf.org; Thu, 17 Feb 2005 07:17:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14470 for ; Thu, 17 Feb 2005 07:17:47 -0500 (EST) From: richard.spencer@bt.com Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1kwo-0000vh-U6 for rtg-bfd@ietf.org; Thu, 17 Feb 2005 07:40:00 -0500 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Thu, 17 Feb 2005 12:18:55 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Feb 2005 12:18:54 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 17 Feb 2005 12:18:54 -0000 Message-ID: Thread-Topic: State machine diagram & alarm generation thread-index: AcUU4R23yx5rdpcySZqjtG2xlnW71wACawU1 To: X-OriginalArrivalTime: 17 Feb 2005 12:18:54.0795 (UTC) FILETIME=[D92599B0:01C514EA] X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: base64 Cc: rtg-bfd@ietf.org, jhaas@nexthop.com, dkatz@juniper.net, dward@cisco.com Subject: RE: State machine diagram & alarm generation 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: base64 VGhhbmtzIEJvYi4gDQpJdCBsb29rcyBnb29kIHRvIG1lLg0KIA0KUmljaGFyZA0KDQoJLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogQm9iIEFsYnJpZ2h0c29uIFttYWlsdG86YWxi cmlnaHRAY2lzY28uY29tXSANCglTZW50OiBUaHUgMTcvMDIvMjAwNSAwNjowNiANCglUbzogU3Bl bmNlcixSLFJpY2hhcmQsWERFNyBSIA0KCUNjOiBka2F0ekBqdW5pcGVyLm5ldDsgcnRnLWJmZEBp ZXRmLm9yZzsgamhhYXNAbmV4dGhvcC5jb207IGR3YXJkQGNpc2NvLmNvbSANCglTdWJqZWN0OiBS RTogU3RhdGUgbWFjaGluZSBkaWFncmFtICYgYWxhcm0gZ2VuZXJhdGlvbg0KCQ0KCQ0KDQoJPiBC b2IsDQoJPg0KCT4gDQoJPg0KCT4gVGhhbmtzLCBJIHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCB0 byBhZGQgdGhpcyBkaWFncmFtIHRvIHRoZQ0KCT4gZHJhZnQuIE9uZSBtaW5vciBwb2ludCBpcyB0 aGF0IHRoZSBhcnJvdyBiZXR3ZWVuIERvd24gYW5kIEluaXQgaXMNCgk+IHBvaW50aW5nIHRvd2Fy ZHMgRG93biwgdGhpcyBzaG91bGQgYmUgcmV2ZXJzZWQgdG8gZGVzY3JpYmUgdGhlIHN0YXRlDQoJ PiBjaGFuZ2UgZnJvbSBEb3duIHRvIEluaXQgb24gcmVjZWlwdCBvZiBhIHBhY2tldCB3aXRoIElI WSA9IDAgcmF0aGVyDQoJPiB0aGFuIHRoZSBvdGhlciB3YXkgcm91bmQuIEFsc286DQoJPg0KCT4g DQoJPg0KCT4gMS4gSSB0aGluayBpdCB3b3VsZCBiZSB3b3J0aCBhZGRpbmcgdGhlIHRleHQgIk9y IERldGVjdGlvbiBFeHBpcmVkIg0KCT4gd2hlcmUgaXQgc2F5cyAiUnhfSUhZID0gMCIgYWJvdmUg dGhlIGFycm93IHBvaW50aW5nIGZyb20gVXAgdG8NCgk+IEZhaWxpbmcgKHRvIGRlc2NyaWJlIHRo ZSBzdGF0ZSBjaGFuZ2UgdG8gRmFpbGluZyBmcm9tIFVwIG9uDQoJPiBEZXRlY3Rpb24gVGltZSBl eHBpcmF0aW9uKS4NCgk+DQoJPiANCgk+DQoJPiAyLiBJdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUg YSBsb29wIGJhY2sgYXJyb3cgdG8vZnJvbSB0aGUgSW5pdCBzdGF0ZQ0KCT4gb24gcmVjZWlwdCBv ZiBCRkQgcGFja2V0cyB3aXRoIElIWSA9IDAgKHNpbWlsYXIgdG8gdGhlIGxvb3Agb24gdGhlDQoJ PiBmYWlsaW5nIHN0YXRlIGZvciBJSFkgPSAxKS4NCgkNCglUaGFua3MgZm9yIHRoZSBjb21tZW50 cy4gIEhlcmUgaXMgdGhlIG5ldyBhc2NpaSBhcnQuDQoJDQoJIC1ib2INCgkNCgkgICAgICAgICAg ICAgICAgICAgICAgICAgIEJGRCBzdGF0ZSBkaWFncmFtDQoJDQoJDQoJICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSeF9JSFk9MQ0KCSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0t LSsNCgkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICB2DQoJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tKw0KCSAgICAgICAgICAgICAgICAgICAgUnhfSUhZID0g MSAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgIHwNCgkgICAgICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgICAgIFVQICAgICB8DQoJICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgfA0KCSAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERldGVj dGlvbiAgKy0tLS0tLS0tLS0tLSsNCgkgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgRXhwaXJlZCAgICB8ICAgIF4NCgkgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBvciAgICAgICB8ICAgIHwNCgkrLS0tLS0tLS0tLS0tKyBEZXRlY3Rp b24gKy0tLS0tLS0tLS0tLSsgICBSeF9JSFk9MCAgIC8gICAgIHwNCgl8ICAgICAgICAgICAgfCAg RXhwaXJlZCAgfCAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tKyAgICAgIHwNCgl8ICAgIElOSVQg ICAgfC0tLS0tLS0tLS0+fCAgIEZBSUxJTkcgIHwgICAgICAgICAgICAgICAgICAgIHwgUnhfSUhZ ID0gMQ0KCXwgICAgICAgICAgICB8LS0rICAgICAgICB8ICAgICAgICAgICAgfC0tLS0tLS0tLS0t LS0rICAgICAgfA0KCSstLS0tLS0tLS0tLS0rICB8ICAgICAgICArLS0tLS0tLS0tLS0tKyAgIFJ4 X0lIWT0wICAgXCAgICAgfA0KCSAgICAgIF4gIF4gICAgICB8ICAgICAgICAgICBeICAgICAgfCAg ICAgICAgICAgICAgICAgIHwgICAgfA0KCSAgICAgIHwgICstLS0tLS0rICAgICAgICAgICArLS0t LS0tKyAgICAgICAgICAgICAgICAgIHYgICAgfA0KCSAgICAgIHwgIFJ4X0lIWT0wICAgICAgICAg ICBSeF9JSFk9MSAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLSsNCgkgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICB8DQoJ ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18ICAg IERPV04gICAgfA0KCSAgICAgICAgICAgICAgICAgICAgUnhfSUhZID0gMCAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgIHwNCgkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0rDQoJDQoNCg== From rtg-bfd-bounces@ietf.org Thu Feb 17 18:45:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25725; Thu, 17 Feb 2005 18:45:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1vg0-0004n6-4o; Thu, 17 Feb 2005 19:07:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1uNJ-0004lL-Vh; Thu, 17 Feb 2005 17:43:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1u3R-0001ML-Hz for rtg-bfd@megatron.ietf.org; Thu, 17 Feb 2005 17:23:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16362 for ; Thu, 17 Feb 2005 17:23:23 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1uOx-0002U2-W7 for rtg-bfd@ietf.org; Thu, 17 Feb 2005 17:45:41 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 651662D551E; Thu, 17 Feb 2005 17:22:49 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 69249-01-31; Thu, 17 Feb 2005 17:22:45 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id B4C9D2D54F7; Thu, 17 Feb 2005 16:54:42 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j1HLsgv22061; Thu, 17 Feb 2005 16:54:42 -0500 (EST) Date: Thu, 17 Feb 2005 16:54:42 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Message-ID: <20050217215442.GR9306@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: David Ward Subject: Call for submissions for IETF 62 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 The BFD working group will be meeting at IETF 62. We have a one hour time slot. This is a call for agenda items. Please make sure you have a draft posted in the internet-drafts repository and draw the working group's attention to that draft via the mail list prior to the meeting. All current working group work items are expected to be refreshed prior to the meeting. -- Jeff Haas NextHop Technologies From rtg-bfd-bounces@ietf.org Mon Feb 21 03:14:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27730; Mon, 21 Feb 2005 03:14:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D393y-0001Bg-2f; Mon, 21 Feb 2005 03:37:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D38HG-0005iP-1u; Mon, 21 Feb 2005 02:46:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D37ky-0005NT-Ne for rtg-bfd@megatron.ietf.org; Mon, 21 Feb 2005 02:13:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14222 for ; Mon, 21 Feb 2005 02:13:23 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D387C-0008B8-76 for rtg-bfd@ietf.org; Mon, 21 Feb 2005 02:36:23 -0500 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 j1L7CpBm088981 for ; Sun, 20 Feb 2005 23:12:52 -0800 (PST) (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 j1L7Cpe13416 for ; Sun, 20 Feb 2005 23:12:51 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: "'rtg-bfd@ietf.org'" From: Dave Katz Date: Sun, 20 Feb 2005 23:12:51 -0800 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit I've posted updated specs for the BFD base, one hop, and multihop docs to the secretariat, just in the nick of time (as usual.) Hopefully I've satisfied all of the latest boilerplate requirements so the docs don't get rejected. Should show up in the next couple of days. --Dave1 (for Dave2) From rtg-bfd-bounces@ietf.org Mon Feb 21 20:54:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12937; Mon, 21 Feb 2005 20:54:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Pbs-0004Ed-PN; Mon, 21 Feb 2005 21:17:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3M4f-0000td-Pg; Mon, 21 Feb 2005 17:30:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3K7m-0000s0-Jf; Mon, 21 Feb 2005 15:25:46 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11108; Mon, 21 Feb 2005 15:25:45 -0500 (EST) Message-Id: <200502212025.PAA11108@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 21 Feb 2005 15:25:44 -0500 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-mpls-01.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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 --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-01.txt Pages : 10 Date : 2005-2-21 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-01.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-01.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-01.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: <2005-2-21151242.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-mpls-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-mpls-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-21151242.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Wed Feb 23 02:24:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18514; Wed, 23 Feb 2005 02:24:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3rFi-0006B5-Ft; Wed, 23 Feb 2005 02:48:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kgX-0004kT-13; Tue, 22 Feb 2005 19:47:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3glv-0007LX-8x; Tue, 22 Feb 2005 15:36:43 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16765; Tue, 22 Feb 2005 15:36:41 -0500 (EST) Message-Id: <200502222036.PAA16765@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Feb 2005 15:36:41 -0500 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-v4v6-1hop-01.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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 --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-01.txt Pages : 11 Date : 2005-2-22 This document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. It further describes the use of BFD with OSPFv2, OSPFv3, and IS-IS. 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-01.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-01.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-01.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: <2005-2-22155614.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-v4v6-1hop-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-v4v6-1hop-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22155614.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Wed Feb 23 02:29:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24628; Wed, 23 Feb 2005 02:29:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3rKP-0006Ip-Cx; Wed, 23 Feb 2005 02:53:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kgZ-0004l2-Dx; Tue, 22 Feb 2005 19:47:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3gm4-0007Li-Vh; Tue, 22 Feb 2005 15:36:53 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16786; Tue, 22 Feb 2005 15:36:50 -0500 (EST) Message-Id: <200502222036.PAA16786@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Feb 2005 15:36:50 -0500 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-multihop-01.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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 --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-01.txt Pages : 6 Date : 2005-2-22 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-01.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-01.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-01.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: <2005-2-22155620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-multihop-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-multihop-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22155620.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Wed Feb 23 02:34:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28952; Wed, 23 Feb 2005 02:34:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3rOu-0006Xu-Vr; Wed, 23 Feb 2005 02:57:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kgb-0004lW-Rf; Tue, 22 Feb 2005 19:47:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3gmH-0007Lu-4w; Tue, 22 Feb 2005 15:37:05 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16841; Tue, 22 Feb 2005 15:37:03 -0500 (EST) Message-Id: <200502222037.PAA16841@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Feb 2005 15:37:02 -0500 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-base-01.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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 --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-01.txt Pages : 43 Date : 2005-2-22 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-01.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-01.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-01.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: <2005-2-22155625.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-base-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-base-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22155625.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Wed Feb 23 20:05:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06149; Wed, 23 Feb 2005 20:05:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D47oG-0007MB-AK; Wed, 23 Feb 2005 20:28:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D47Q9-0008HG-Pk; Wed, 23 Feb 2005 20:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D47Q7-0008Ga-Mg for rtg-bfd@megatron.ietf.org; Wed, 23 Feb 2005 20:03:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05499 for ; Wed, 23 Feb 2005 20:03:55 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D47mt-000796-6J for rtg-bfd@ietf.org; Wed, 23 Feb 2005 20:27:33 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICE00L565OKD9@szxga01-in.huawei.com> for rtg-bfd@ietf.org; Thu, 24 Feb 2005 09:05:08 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICE002GD5OK21@szxga01-in.huawei.com> for rtg-bfd@ietf.org; Thu, 24 Feb 2005 09:05:08 +0800 (CST) Received: from z11024 ([10.110.49.48]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ICE0046I5PM9F@szxml02-in.huawei.com> for rtg-bfd@ietf.org; Thu, 24 Feb 2005 09:05:47 +0800 (CST) Date: Thu, 24 Feb 2005 09:05:50 +0800 From: zhaisuping To: "rtg-bfd@ietf.org" Message-id: <0ICE0046K5PM9F@szxml02-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Subject: welcome to comment on draft-suping-bfd-mpls-fecmismatch-00.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhaisuping@huawei.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable I have submitted a draft as= draft-suping-bfd-mpls-fecmismatch-00.txt, in which some changed= to BFD protocol is proposed. Any comments are welcome. thank you= in advance.=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1 Best Regards, zhaisuping@huawei.com Huawei Technologies Co., Ltd. Tel: +86-10-82882695 Fax: +86-10-82882537 2005-02-24 From rtg-bfd-bounces@ietf.org Wed Feb 23 20:30:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13931; Wed, 23 Feb 2005 20:30:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D48CN-0001Nw-Jo; Wed, 23 Feb 2005 20:53:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D41UU-0007uk-44; Wed, 23 Feb 2005 13:44:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D41US-0007uB-OV for rtg-bfd@megatron.ietf.org; Wed, 23 Feb 2005 13:44:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26471 for ; Wed, 23 Feb 2005 13:43:55 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D41r4-0004nl-IH for rtg-bfd@ietf.org; Wed, 23 Feb 2005 14:07:29 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 23 Feb 2005 11:58:17 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,110,1107734400"; d="scan'208"; a="228378082:sNHT22274192" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1NIhfq8008594; Wed, 23 Feb 2005 10:43:42 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-82.cisco.com [10.86.242.82]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id API39651; Wed, 23 Feb 2005 13:43:42 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <99c30923ede00099e967a65552e77c02@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Wed, 23 Feb 2005 13:43:40 -0500 To: "'rtg-bfd@ietf.org'" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: David Ward , Dave Katz Subject: Comments on draft-suping-bfd-mpls-fecmismatch-00.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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit I have reviewed draft-suping-bfd-mpls-fecmismatch-00.txt and have some comments regarding this draft. Editorial: The draft isn't well put together in that the document doesn't read very well, and the details of what it is trying to accomplish are scarce. Technical: The whole basis of the document is that of performing incoming FEC validation based on the premise that invalid packets can arrive and be processed at an incorrect router. There are two problems with this as specified in the draft. First, you already get FEC validation with BFD/MPLS by virtue of the fact that a session exists only to service a particular FEC. This session is bound to a unique session identification once established. For MPLS this is explained in the BFD/MPLS draft for bootstrapping sessions. Given that each session is set up for a particular FEC, if a router receives a packet for a BFD session that doesn't exist (or has been removed), the FEC is by virtue invalid and should be dropped/ignored (see the security sections in the BFD base drafts). The second problem I have with this approach is that if you disagree with my assumption that sessions are only set up for valid sessions, and believe that they can be falsely set up, this is where the security sections of the BFD base drafts come in. There are ways of doing the full "belts and suspenders" approach to setting up sessions and maintaining their ongoing validity which I think guarantees that things are established exactly and only exactly as desired, and stay that way. The final technical issue I have with the document is that it is based on ITU Y.1713, which is based on ITU recommendation Y.1711. If we take a close look at the scope section of the updated version of Y.1711, we will find that the protocol is limited to connection-oriented network constructs ONLY. For MPLS this means that it ONLY applies to MPLS-TE LSPs and possibly things that can ride over those LSPs (i.e.: pseudowires that use a TE LSP between PEs). It also means that since Y.1713 is based on Y.1711, it inherits its scoped limitations as well. Given the three technical issues I raised above, which I think are major and limiting, I don't see a good reason to go and modify the BFD header to accommodate this approach, as is what the draft further specifies. Even if points 1 and 2 are addressed, the fact that the scope of the approach outlined is severely limited, I can't see anything here that gives enough motivation for going and having to repair all of the existing implementations of BFD to facilitate it. --Tom From rtg-bfd-bounces@ietf.org Wed Feb 23 21:52:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13883; Wed, 23 Feb 2005 21:52:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D49Ta-0001wo-6s; Wed, 23 Feb 2005 22:15:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3z30-0006ty-3j; Wed, 23 Feb 2005 11:07:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3z2v-0006tf-UB for rtg-bfd@megatron.ietf.org; Wed, 23 Feb 2005 11:07:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03066 for ; Wed, 23 Feb 2005 11:07:20 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3zPX-0006Oo-ST for rtg-bfd@ietf.org; Wed, 23 Feb 2005 11:30:52 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 323972D4D18; Wed, 23 Feb 2005 11:07:13 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 74523-02-4; Wed, 23 Feb 2005 11:07:11 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E53D92D4D2F; Wed, 23 Feb 2005 11:07:11 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j1NG7AO18807; Wed, 23 Feb 2005 11:07:10 -0500 (EST) Date: Wed, 23 Feb 2005 11:07:10 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Message-ID: <20050223160710.GJ24296@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Subject: [Internet-Drafts@ietf.org: I-D ACTION:draft-suping-bfd-mpls-fecmismatch-00.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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e It would appear that at least 3 of our core documents have cleared the Internet-Drafts people: The base draft, single hop v4/v6, MPLS LSP. There is an independent submission targeted towards some changes to the BFD protocol. I would like to request that the working group take a first pass at commenting on this proposal. If WG discussion warrants it, we'll allocate a timeslot at the upcoming meeting for further discussion. ----- Forwarded message from Internet-Drafts@ietf.org ----- Date: Fri, 18 Feb 2005 15:20:55 -0500 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-suping-bfd-mpls-fecmismatch-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org X-Virus-Scanned: by amavisd-new at nexthop.com X-OriginalArrivalTime: 18 Feb 2005 21:04:54.0180 (UTC) FILETIME=[7E6B5640:01C515FD] A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BFD Extensions for MPLS FEC mismatch detection Author(s) : Z. Suping Filename : draft-suping-bfd-mpls-fecmismatch-00.txt Pages : 6 Date : 2005-2-18 BFD mechanism [BFD] was original designed to detect failures in communication with a forwarding plane next hop. BFD operates on top of any data protocol being forwarded between two systems. This document describes how to use the BFD mechanism for detecting the MPLS FEC mismatch. The proposal is based on the FEC mismatch mechanism of ITU-T Y.1713. The proposed solution covers the mpls network when use BFD as the fault detection mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-suping-bfd-mpls-fecmismatch-00.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-suping-bfd-mpls-fecmismatch-00.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-suping-bfd-mpls-fecmismatch-00.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. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ----- End forwarded message ----- -- Jeff Haas NextHop Technologies From rtg-bfd-bounces@ietf.org Wed Feb 23 21:54:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15314; Wed, 23 Feb 2005 21:54:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D49Vn-0002Fn-0g; Wed, 23 Feb 2005 22:17:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D41zB-0005u6-Ed; Wed, 23 Feb 2005 14:15:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D41zA-0005tk-Nu for rtg-bfd@megatron.ietf.org; Wed, 23 Feb 2005 14:15:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01864 for ; Wed, 23 Feb 2005 14:15:41 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D42Lo-0006QJ-Eu for rtg-bfd@ietf.org; Wed, 23 Feb 2005 14:39:14 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1NJFWn06567 for ; Wed, 23 Feb 2005 21:15:32 +0200 Date: Wed, 23 Feb 2005 21:15:32 +0200 (EET) From: Pekka Savola To: rtg-bfd@ietf.org In-Reply-To: <200502222036.PAA16786@ietf.org> Message-ID: References: <200502222036.PAA16786@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: ttl and authentication [Re: I-D ACTION:draft-ietf-bfd-multihop-01.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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Hi, On Tue, 22 Feb 2005 Internet-Drafts@ietf.org wrote: > Title : BFD for Multihop Paths > Author(s) : D. Katz, D. Ward > Filename : draft-ietf-bfd-multihop-01.txt > Pages : 6 > Date : 2005-2-22 There was one particularly unnerving change in -01: 5. TTL/Hop Count Issues If BFD authentication is not in use, all BFD Control packets for sessions operating according to this specification MUST be sent with a TTL or Hop Count value of 255. All received BFD Control packets that are demultiplexed to sessions operating according to this specification MUST be discarded if the received TTL or Hop Count is not equal to 255. A discussion of this mechanism can be found in [GTSM]. If BFD authentication is in use, any value of TTL/Hop Count MAY be used in transmitted packets, and received packets MUST NOT be discarded based on the received TTL/Hop Count. .. this is _not good_, depending on the definition of "BFD authentication is in use". If I interpret this correctly, the routers can not simply drop BFD session which are sent to the router with a bogus TTL and bogus authentication (e.g., wrong password) based on the TTL check? For single hop scenarios, I don't see the reason to omit checking for TTL or to send any other TTL than 255. Please elaborate or put it back in ASAP :). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rtg-bfd-bounces@ietf.org Wed Feb 23 22:48:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05654; Wed, 23 Feb 2005 22:48:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4AMV-0008B8-E1; Wed, 23 Feb 2005 23:12:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D428X-00075e-9B; Wed, 23 Feb 2005 14:25:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D428V-000752-QA for rtg-bfd@megatron.ietf.org; Wed, 23 Feb 2005 14:25:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02959 for ; Wed, 23 Feb 2005 14:25:13 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D42V4-0006jK-3E for rtg-bfd@ietf.org; Wed, 23 Feb 2005 14:48:46 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1NJP5G06807 for ; Wed, 23 Feb 2005 21:25:05 +0200 Date: Wed, 23 Feb 2005 21:25:05 +0200 (EET) From: Pekka Savola To: rtg-bfd@ietf.org In-Reply-To: <200502222036.PAA16765@ietf.org> Message-ID: References: <200502222036.PAA16765@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: other comments for single-hop bfd [Re: I-D ACTION:draft-ietf-bfd-v4v6-1hop-01.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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi, A couple of other comments for the single hop bfd spec: - the text for supporting single-hop static routes and eBGP was discussed previously on the list. This is not included in -01. Was this just forgotten (as the draft was submitted at the last minute), or was there a particular reason for excluding these ? - the last sentence of the following text is not factually correct: Note that it is possible in some failure scenarios for the network to be in a state such that the IGP comes up, but the BFD session cannot be established, and, more particularly, data cannot be forwarded. To avoid this situation, it would be beneficial to not allow the IGP to establish a neighbor/adjacency. However, this would preclude the operation of the IGP in an environment in which not all systems support BFD. .. in fact it would preclude the operation of the IGP in the particular BFD-enabled _interface_. The text seems to be implying that having BFD would be an IGP domain-wide toggle like IS-IS authentication. But in reality, it is an interface toggle, so this argument is irrelevant. Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rtg-bfd-bounces@ietf.org Thu Feb 24 01:01:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22851; Thu, 24 Feb 2005 01:01:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4CQf-0005SV-HZ; Thu, 24 Feb 2005 01:24:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D41hJ-0002NW-QW; Wed, 23 Feb 2005 13:57:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D41hH-0002Im-K8 for rtg-bfd@megatron.ietf.org; Wed, 23 Feb 2005 13:57:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28720 for ; Wed, 23 Feb 2005 13:57:12 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D423v-0005TC-Vw for rtg-bfd@ietf.org; Wed, 23 Feb 2005 14:20:44 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-4.cisco.com with ESMTP; 23 Feb 2005 10:57:08 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1NIv0ZV018246; Wed, 23 Feb 2005 10:57:01 -0800 (PST) Received: from cisco.com (tanyas-sb100.cisco.com [128.107.162.227]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BDZ87341; Wed, 23 Feb 2005 10:56:56 -0800 (PST) Message-ID: <421CD1F7.20507@cisco.com> Date: Wed, 23 Feb 2005 10:56:55 -0800 From: Tanya Shastri User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rtg-bfd@ietf.org Content-Type: multipart/mixed; boundary="------------040203090904090404000900" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: Tanya Shastri Subject: Session Deletion 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 This is a multi-part message in MIME format. --------------040203090904090404000900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Session deletion has not been mentioned explicitly in the draft. It is not clear to me whether Admin Down could be used for deletion. So I am not sure which of the following is correct: - Admin down should be treated as a transitionary state during session deletion (Putting a session in Admin Down leads to it being deleted). - Admin down is a state that a session may be held in. If Admin down is to be treated as a temporary state then the draft could include a description on how to transition out of AdminDown state to complete deletion of the session. "TABLE 1" below should be valid i.e. Transition out of Admin Down state or receiving IHY=0 from the other end or on Timer Expiry. Possible events are: Create, IHY=0, IHY=1, GoAdminDown(Delete), GoAdminUp TABLE 1: Finite State Machine Transition from Old State to New State, on the above events. (Interesting cells have a *). --------------------------------------------------------------------- New state -> |Deleted | Init | Failing | Down | UP | AdminDown| |(session| | | | | | Old state |does not| | | | | | | |exist) | | | | | | v | | | | | | | --------------------------------------------------------------------- Deleted | | | Create | | | | (adj does | | | | | | | not exist) | | | | | | | --------------------------------------------------------------------- Init | | IHY=0 |TimerExp | | IHY=1 | GoAdminDn| --------------------------------------------------------------------- Failing | | | Create | IHY=0 | | GoAdminDn| | | | IHY=1 | | | | --------------------------------------------------------------------- Down | | IHY=0 | | | IHY=1 | GoAdminDn| --------------------------------------------------------------------- Up | | | IHY=0 | | IHY=1 | GoAdminDn| | | | TimerExp| | | | --------------------------------------------------------------------- AdminDown |* IHY=0 | |GoAdminUp| | | | |TimerExp| | | | | IHY=1 | --------------------------------------------------------------------| If Admin down is to be treated as a state that a session may be held in (not just to transition to deleted state) then an extra state may be needed (Deleting) as shown in the state transition table below. A session in deleting state could behave similiar to if it were in AdminDown state (i.e. the diagnostic code could be set to Admin Down in outgoing BFD control packets). Possible events are: Create, IHY=0, IHY=1, Delete, GoAdminUp, GoAdminDown(GoAdDn) TABLE 2: Finite State Machine Transition from Old State to New State. -----------------------------------------------------------------------| New state->|Deleted | Init| Failing | Down | UP | Deleting | AdDn | |(session| | | | | | | Old state |does not| | | | | | | | |exist) | | | | | | | v | | | | | | | | -----------------------------------------------------------------------| Deleted | | | Create | | | |GoAdDn| (adj does | | | | | | | | not exist) | | | | | | | | -----------------------------------------------------------------------| Init | Delete |IHY=0|TimerExp | | IHY=1 | |GoAdDn| -----------------------------------------------------------------------| Failing | | | Create | IHY=0 | | Delete |GoAdDn| | | | IHY=1 | | | | | -----------------------------------------------------------------------| Down | Delete |IHY=0| | | IHY=1 | |GoAdDn| -----------------------------------------------------------------------| Up | | | IHY=0 | | IHY=1 | Delete |GoAdDn| | | | TimerExp| | | | | -----------------------------------------------------------------------| Deleting |* IHY=0 | |* Create | | |* IHY=1 | | |TimerExp| | | | | GoAdminDn| | -----------------------------------------------------------------------| AdminDown | | |GoAdminUp| | |* Delete |GoAdDn| -----------------------------------------------------------------------| Please clarify deletion of a session and which (if) one of the above approaches is correct. Also I think it would help to have a state transition table like the ones above or a state diagram (I guess that is in the works) to explain section 6.6.6 in the draft. Thanks, Tanya --------------040203090904090404000900 Content-Type: text/plain; name="bfd_session_delete.txt" Content-Disposition: inline; filename="bfd_session_delete.txt" Content-Transfer-Encoding: 7bit Hi, Session deletion has not been mentioned explicitly in the draft. It is not clear to me whether Admin Down could be used for deletion. I am not sure which of the following is correct: - Admin down should be treated as a transitionary state during session deletion (Putting a session in Admin Down leads to it being deleted). - Admin down is a state that a session may be held in If Admin down is to be treated as a temporary state then the draft could include a description on how to transition out of AdminDown state to complete deletion of the session. "TABLE 1" below should be valid i.e. Transition out of Admin Down state or receiving IHY=0 from the other end or on Timer Expiry. Possible events are: Create, IHY=0, IHY=1, GoAdminDown(Delete), GoAdminUp TABLE 1: Finite State Machine Transition from Old State to New State, on the above events. (Interesting cells have an asterix). --------------------------------------------------------------------- New state -> |Deleted | Init | Failing | Down | UP | AdminDown| |(session| | | | | | Old state |does not| | | | | | | |exist) | | | | | | v | | | | | | | --------------------------------------------------------------------- Deleted | | | Create | | | | (adj does | | | | | | | not exist) | | | | | | | --------------------------------------------------------------------- Init | | IHY=0 |TimerExp | | IHY=1 | GoAdminDn| --------------------------------------------------------------------- Failing | | | Create | IHY=0 | | GoAdminDn| | | | IHY=1 | | | | --------------------------------------------------------------------- Down | | IHY=0 | | | IHY=1 | GoAdminDn| --------------------------------------------------------------------- Up | | | IHY=0 | | IHY=1 | GoAdminDn| | | | TimerExp| | | | --------------------------------------------------------------------- AdminDown |* IHY=0 | |GoAdminUp| | | | |TimerExp| | | | | IHY=1 | --------------------------------------------------------------------| If Admin down is to be treated as a state that a session may be held in (not just to transition to deleted state) then an extra state may be needed (Deleting?) as shown in the state transition table below. A session in deleting state could behave similiar to if it were in AdminDown state (i.e. set the diag bits to indicate Admin down). Possible events are: Create, IHY=0, IHY=1, Delete, GoAdminUp, GoAdminDown(GoAdDn) Table 2: Finite State Machine Transition from Old State to New State. -----------------------------------------------------------------------| New state->|Deleted | Init| Failing | Down | UP | Deleting | AdDn | |(session| | | | | | | Old state |does not| | | | | | | | |exist) | | | | | | | v | | | | | | | | -----------------------------------------------------------------------| Deleted | | | Create | | | |GoAdDn| (adj does | | | | | | | | not exist) | | | | | | | | -----------------------------------------------------------------------| Init | Delete |IHY=0|TimerExp | | IHY=1 | |GoAdDn| -----------------------------------------------------------------------| Failing | | | Create | IHY=0 | | Delete |GoAdDn| | | | IHY=1 | | | | | -----------------------------------------------------------------------| Down | Delete |IHY=0| | | IHY=1 | |GoAdDn| -----------------------------------------------------------------------| Up | | | IHY=0 | | IHY=1 | Delete |GoAdDn| | | | TimerExp| | | | | -----------------------------------------------------------------------| Deleting |* IHY=0 | |* Create | | |* IHY=1 | | |TimerExp| | | | | GoAdminDn| | -----------------------------------------------------------------------| AdminDown | | |GoAdminUp| | |* Delete |GoAdDn| -----------------------------------------------------------------------| Please clarify deletion of a session and which (if) one of the above approaches is correct. Also I think it would help to have a state transition table like the ones above or a state diagram (I guess that is in the works) to explain section 6.6.6 in the draft. Thanks, Tanya --------------040203090904090404000900-- From rtg-bfd-bounces@ietf.org Thu Feb 24 01:01:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23000; Thu, 24 Feb 2005 01:01:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4CQz-0005UT-FE; Thu, 24 Feb 2005 01:25:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4BLE-0004aC-0Q; Thu, 24 Feb 2005 00:15:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3lKc-0001U9-FY for rtg-bfd@megatron.ietf.org; Tue, 22 Feb 2005 20:28:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12240 for ; Tue, 22 Feb 2005 19:11:25 -0500 (EST) From: richard.spencer@bt.com Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3kUL-0007V3-AB for rtg-bfd@ietf.org; Tue, 22 Feb 2005 19:34:49 -0500 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Wed, 23 Feb 2005 00:10:56 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 23 Feb 2005 00:10:56 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Feb 2005 00:10:55 -0000 Message-ID: Thread-Topic: Between schedule transmissions thread-index: AcUZO/qtYpqBIDm+QI+EdlioTAabSA== To: X-OriginalArrivalTime: 23 Feb 2005 00:10:56.0458 (UTC) FILETIME=[254ECAA0:01C5193C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: quoted-printable Subject: Between schedule transmissions 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable The base draft states that "A single BFD Control packet SHOULD be = transmitted between normally scheduled transmissions when the contents = of that packet would differ from those in the previously transmitted = packet in order to more rapidly communicate a change in state." In the case of state transitions from 'Down to Up or Init', and from 'Up = to Failing' it is obvious that a BFD packet should be sent immediately = (rather than waiting for the next scheduled transmission) because the = IHY variable changes. However, what about state changes form 'Init to = Up' and 'Failing to Down' where the IHY doesn't change? Do these result = in BFD packets being sent immediately, or does the system wait until the = next scheduled transmission? The answer to this question may be = dependant on the bfd.LocalDiag field, the draft states that = bfd.LocalDiag MUST be initialised to zero, and describes when it should = be changed to reflect failure conditions. However, there is no = information (or at least I can't find any) regarding when bfd.LocalDiag = should be reset to 0. The main reason behind asking this question is that following = restoration of a unidirectional failure, if a BFD packet is not sent = immediately following a state change from Failing to Down, then it would = appear to me that it would be possible that a BFD session may never come = back up and instead each side would loop through the Failing, Init, Down = states. To use an example, lets say that at T=3D0 seconds, the = unidirectional fault (A->B) is repaired, at this point node A is in the = Down state and Node B is in the Failing state (to keep things simple, in = this example one way delay =3D 100ms and processing time is not = included) - [A: Down, B: Failing] T=3D0: Connectivity in the direction A->B is restored T=3D0.1: B reaches its next scheduled BFD transmission slot and sends a = BFD packet to A T=3D0.2: A receives the BFD packet from A with IHY set to 0 and changes = from Down to Init [A: Init, B: Failing] T=3D0.2: A sends a BFD packet to B straight away T=3D0.3: B receives the BFD packet from A with IHY set to 1 and ignores = the packet (waits for IHY =3D 0) T=3D0.5: A reaches its next scheduled BFD transmission slot and sends a = BFD packet to B T=3D0.6: B receives the BFD packet from A with IHY set to 1 and ignores = the packet (waits for IHY =3D 0) T=3D1.1: B reaches its next scheduled BFD transmission slot and sends a = BFD packet to A T=3D1.2: A receives the BFD packet from B with IHY set to 0 and drops = the packet (waits for IHY =3D 1) T=3D1.5: A reaches its next scheduled BFD transmission slot and sends a = BFD packet to B T=3D1.6: B receives the BFD packet from A with IHY set to 1 and ignores = the packet (waits for IHY =3D 0) T=3D2.1: B reaches its next scheduled BFD transmission slot and sends a = BFD packet to A T=3D2.2: A receives the BFD packet from B with IHY set to 0 and drops = the packet (waits for IHY =3D 1) T=3D2.5: A reaches its next scheduled BFD transmission slot and sends a = BFD packet to B T=3D2.6: B receives the BFD packet from A with IHY set to 1 and ignores = the packet (waits for IHY =3D 0) T=3D3.1: B reaches its next scheduled BFD transmission slot and sends a = BFD packet to A T=3D3.2: A receives the BFD packet from B with IHY set to 0, drops the = packet, and changes from Init to Failing due to detection timeout [A: Failing, B: Failing] T=3D3.2: A sends a BFD packet to B straight away T=3D3.3: B receives the BFD packet from A with IHY set to 0 and changes = from Failing to Down [A: Failing, B: Down] T=3D3.5: A reaches its next scheduled BFD transmission slot and sends a = BFD packet to B T=3D3.6: B receives the BFD packet from A with IHY set to 0 and changes = from Down to Init [A: Failing, B: Init] T=3D3.6: B sends a BFD packet to A straight away T=3D3.7: A receives the BFD packet from B with IHY set to 1 and ignores = the packet (waits for IHY =3D 0) T=3D4.1: B reaches its next scheduled BFD transmission slot and sends a = BFD packet to A T=3D4.2: A receives the BFD packet from B with IHY set to 1 and ignores = the packet (waits for IHY =3D 0) T=3D4.5: A reaches its next scheduled BFD transmission slot and sends a = BFD packet to B T=3D4.6: B receives the BFD packet from A with IHY set to 0 and drops = the packet (waits for IHY =3D 1) T=3D5.1: B reaches its next scheduled BFD transmission slot and sends a = BFD packet to A T=3D5.2: A receives the BFD packet from B with IHY set to 1 and ignores = the packet (waits for IHY =3D 0) T=3D5.5: A reaches its next scheduled BFD transmission slot and sends a = BFD packet to B T=3D5.6: B receives the BFD packet from A with IHY set to 0 and drops = the packet (waits for IHY =3D 1) T=3D6.1: B reaches its next scheduled BFD transmission slot and sends a = BFD packet to A T=3D6.2: A receives the BFD packet from B with IHY set to 1 and ignores = the packet (waits for IHY =3D 0) T=3D6.5: A reaches its next scheduled BFD transmission slot and sends a = BFD packet to B T=3D6.6: B receives the BFD packet from A with IHY set to 0, drops the = packet, and changes from Init to Failing due to detection timeout [A: Failing, B: Failing] T=3D6.6: B sends a BFD packet to A straight away T=3D6.7: A receives the BFD packet from B with IHY set to 0 and changes = from Failing to Down [A: Down, B: Failing] This loop would continue indefinitely, however, the loop would be = avoided if a BFD packet was sent immediately following a state = transition from Failing to Down, i.e. - T=3D3.3: B receives the BFD packet from A with IHY set to 0 and changes = from Failing to Down [A: Failing, B: Down] T=3D3.3: B sends a BFD packet to A straight away T=3D3.4: A receives the BFD packet from B with IHY set to 0 and changes = from Failing to Down [A: Down, B: Down] T=3D3.4: A sends a BFD packet to A straight away T=3D3.5: B receives the BFD packet from A with IHY set to 0 and changes = from Down to Init [A: Down, B: Init] T=3D3.5: B sends a BFD packet to A straight away T=3D3.6: A receives the BFD packet from B with IHY set to 1 and changes = from Down to Up [A: Up, B: Init] T=3D3.6: A sends a BFD packet to A straight away T=3D3.7: B receives the BFD packet from A with IHY set to 1 and changes = from Init to Up [A: Up, B: Up] Perhaps I have missed something or there is a mistake in the scenario I = describe above. However, if not then it would appear to me that if BFD = packets are sent between scheduled transmissions for 'Down to Up or = Init', and 'Up to Failing' state transitions, then they must also be = sent following a state transition from 'Failing to Down' to avoid a loop = occurring.=20 Confirmation either way would be greatly appreciated. Thanks, Richard From rtg-bfd-bounces@ietf.org Thu Feb 24 01:16:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27976; Thu, 24 Feb 2005 01:16:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4CfQ-0006yf-Sn; Thu, 24 Feb 2005 01:40:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Bto-0000vF-Uy; Thu, 24 Feb 2005 00:50:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Btn-0000tI-Er for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 00:50:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19721 for ; Thu, 24 Feb 2005 00:50:51 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4CGd-0004Tt-GD for rtg-bfd@ietf.org; Thu, 24 Feb 2005 01:14:31 -0500 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 j1O5okBm019805; Wed, 23 Feb 2005 21:50:46 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j1O5oje13065; Wed, 23 Feb 2005 21:50:45 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: References: <200502222036.PAA16765@ietf.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0b49f300cadf3d470eaebe742db25983@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Wed, 23 Feb 2005 22:50:45 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: other comments for single-hop bfd [Re: I-D ACTION:draft-ietf-bfd-v4v6-1hop-01.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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit On Feb 23, 2005, at 12:25 PM, Pekka Savola wrote: > Hi, > > A couple of other comments for the single hop bfd spec: > > - the text for supporting single-hop static routes and eBGP was > discussed previously on the list. This is not included in -01. Was > this just forgotten (as the draft was submitted at the last minute), > or was there a particular reason for excluding these ? Brain fart; I had forgotten (the discussion was in July, and I'm reaching the age of senility.) It does raise the question of whether we want to continue to add text into this document for other protocols, or whether it would be worth having additional documents to cover them so that this one can be put to bed. I would prefer to avoid further significant technical changes to this doc and to have additional stuff be put into a separate one, in order to advance this stuff without too much more tinkering. This should probably be discussed in Minneapolis. > > - the last sentence of the following text is not factually correct: > > Note that it is possible in some failure scenarios for the network > to > be in a state such that the IGP comes up, but the BFD session cannot > be established, and, more particularly, data cannot be forwarded. > To avoid this situation, it would be beneficial to not allow the IGP > to establish a neighbor/adjacency. However, this would preclude the > operation of the IGP in an environment in which not all systems > support BFD. > > .. in fact it would preclude the operation of the IGP in the > particular BFD-enabled _interface_. The text seems to be implying > that having BFD would be an IGP domain-wide toggle like IS-IS > authentication. But in reality, it is an interface toggle, so this > argument is irrelevant. It is not irrelevant on multipoint media. Perhaps it would more correctly read "...preclude the *correct* operation of the IGP..." It's not that it makes the IGP completely fail, but it can create large-scale black holes if the topology is particularly unlucky. I could add the extra word if you feel strongly about it. --Dave From rtg-bfd-bounces@ietf.org Thu Feb 24 01:41:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07392; Thu, 24 Feb 2005 01:41:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4D3Z-0001Vw-W8; Thu, 24 Feb 2005 02:05:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Beb-0000YS-Pe; Thu, 24 Feb 2005 00:35:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4BeZ-0000Xt-OW for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 00:35:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14331 for ; Thu, 24 Feb 2005 00:35:08 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4C1P-0002nQ-Py for rtg-bfd@ietf.org; Thu, 24 Feb 2005 00:58:48 -0500 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 j1O5Z1Bm019749; Wed, 23 Feb 2005 21:35:02 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j1O5Z0e11659; Wed, 23 Feb 2005 21:35:00 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: References: <200502222036.PAA16786@ietf.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Date: Wed, 23 Feb 2005 22:34:59 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: ttl and authentication 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit On Feb 23, 2005, at 12:15 PM, Pekka Savola wrote: > If I interpret this correctly, the routers can not simply drop BFD > session which are sent to the router with a bogus TTL and bogus > authentication (e.g., wrong password) based on the TTL check? I should have been a bit more specific here. The intent was that an appropriately authenticated packet needn't be "authenticated" based on the TTL. I don't quite understand your concern; obviously if the packet fails authentication, it must be discarded, so it's not as though the MUST NOT language forces you to accept the packet. Whether this change is gratuitous or not is a separate issue; regardless, I don't see it as dangerous. I suppose "not good" could be equivalent to "gratuitous" but this doesn't rate an "ASAP." > > For single hop scenarios, I don't see the reason to omit checking for > TTL or to send any other TTL than 255. Please elaborate or put it > back in ASAP :). The reason I made this change is that the TTL hack isn't necessary when packets are authenticated, and I've never been thrilled with the TTL hack, and I'm concerned that the idea of "single hop" is somewhat fluid, so I wanted to make sure that BFD could work even if "single hop" and "TTL isn't decremented" aren't congruent. There is no specific case that I can think of that would make this fail (though there have been ideas floated over the years about reaching into encapsulated packets and decrementing the TTL) but it left me somewhat queasy. This is an incompatible change relative to the last draft, which also leaves me a bit queasy, but less queasy than the not making the change. If there are strong feelings that this shouldn't change, I am happy to remove it. I will make the language more specific in any case. --Dave From rtg-bfd-bounces@ietf.org Thu Feb 24 02:02:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17125; Thu, 24 Feb 2005 02:02:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4DOD-0003r7-7G; Thu, 24 Feb 2005 02:26:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Cz9-0001Wu-1g; Thu, 24 Feb 2005 02:00:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Cz7-0001Vw-NZ for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 02:00:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14909 for ; Thu, 24 Feb 2005 02:00:28 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4DLw-0003fx-Qf for rtg-bfd@ietf.org; Thu, 24 Feb 2005 02:24:06 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1O70Ee23475; Thu, 24 Feb 2005 09:00:14 +0200 Date: Thu, 24 Feb 2005 09:00:14 +0200 (EET) From: Pekka Savola To: Dave Katz In-Reply-To: Message-ID: References: <200502222036.PAA16786@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: rtg-bfd@ietf.org Subject: Re: ttl and authentication 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Wed, 23 Feb 2005, Dave Katz wrote: > On Feb 23, 2005, at 12:15 PM, Pekka Savola wrote: >> If I interpret this correctly, the routers can not simply drop BFD session >> which are sent to the router with a bogus TTL and bogus authentication >> (e.g., wrong password) based on the TTL check? > > I should have been a bit more specific here. The intent was that an > appropriately authenticated packet needn't be "authenticated" based on the > TTL. I don't quite understand your concern; obviously if the packet fails > authentication, it must be discarded, so it's not as though the MUST NOT > language forces you to accept the packet. The concern is which is done first: TTL check or authentication check. Compare the situation to BGP with MD5. Folks can easily DoS a router by sending bogus MD5-signed BGP packets to spend all the CPU's computational resources. Using TTL=255 check _first_ prevents this particular attack vector, except from the on-link neighbors. The same argument seems to apply here. Speaking as an operator who's using BFD, I will not be happy if the TTL is not checked first as this opens a resource exhaustion attack vector which could be easily prevented. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rtg-bfd-bounces@ietf.org Thu Feb 24 02:10:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23787; Thu, 24 Feb 2005 02:10:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4DVE-0004Xm-Ls; Thu, 24 Feb 2005 02:33:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4D5L-0007sM-Lq; Thu, 24 Feb 2005 02:06:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4D5I-0007ou-Ri for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 02:06:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20960 for ; Thu, 24 Feb 2005 02:06:51 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4DS8-0004B8-8y for rtg-bfd@ietf.org; Thu, 24 Feb 2005 02:30:28 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1O76dE23613; Thu, 24 Feb 2005 09:06:39 +0200 Date: Thu, 24 Feb 2005 09:06:39 +0200 (EET) From: Pekka Savola To: Dave Katz In-Reply-To: <0b49f300cadf3d470eaebe742db25983@juniper.net> Message-ID: References: <200502222036.PAA16765@ietf.org> <0b49f300cadf3d470eaebe742db25983@juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: rtg-bfd@ietf.org Subject: Re: other comments for single-hop bfd [Re: I-D ACTION:draft-ietf-bfd-v4v6-1hop-01.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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b On Wed, 23 Feb 2005, Dave Katz wrote: > It does raise the question of whether we want to continue to add text into > this document for other protocols, or whether it would be worth having > additional documents to cover them so that this one can be put to bed. I > would prefer to avoid further significant technical changes to this doc and > to have additional stuff be put into a separate one, in order to advance this > stuff without too much more tinkering. This should probably be discussed in > Minneapolis. Right. Obviously, I'm a proponent of putting it here (well, I asked if I should make it a separate draft back in July or so, but then it was felt ok to include it here). >> .. in fact it would preclude the operation of the IGP in the particular >> BFD-enabled _interface_. The text seems to be implying that having BFD >> would be an IGP domain-wide toggle like IS-IS authentication. But in >> reality, it is an interface toggle, so this argument is irrelevant. > > It is not irrelevant on multipoint media. Perhaps it would more correctly > read "...preclude the *correct* operation of the IGP..." It's not that it > makes the IGP completely fail, but it can create large-scale black holes if > the topology is particularly unlucky. I could add the extra word if you feel > strongly about it. No, this clarification would also be misleading. It would prevent the correct operation of the IGP *on that particular interface*. So, you must enable BFD on all the systems you have adjacencies to on a multipoint link. I'm not sure how common those multipoint links are (we certainly have only one with more than 1 neighbor with which we would like to run BFD; the most common are probably Ethernet IX's but folks don't run IGP there), so unless our setup differs radically from what's out there, this shouldn't be a problem. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rtg-bfd-bounces@ietf.org Thu Feb 24 02:26:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09359; Thu, 24 Feb 2005 02:26:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Dko-0004yL-LX; Thu, 24 Feb 2005 02:49:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4DNl-0006ay-9Y; Thu, 24 Feb 2005 02:25:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4DNi-0006Wo-SK for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 02:25:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09210 for ; Thu, 24 Feb 2005 02:25:53 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4DkX-0004xW-H2 for rtg-bfd@ietf.org; Thu, 24 Feb 2005 02:49:31 -0500 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 j1O7Ph975126; Wed, 23 Feb 2005 23:25:43 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j1O7Pbe23347; Wed, 23 Feb 2005 23:25:37 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <421CD1F7.20507@cisco.com> References: <421CD1F7.20507@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 24 Feb 2005 00:25:36 -0700 To: Tanya Shastri X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: Session Deletion 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Session deletion is an implementation detail that is outside the scope of the specification, as it does not affect interoperability (unless there's something I missed.) We have made a conscious decision to define the spec in a way that guarantees interoperability but says as little as possible about implementation, partly because I happen to believe that implementation details have no place in standards, and partly because people tend to read too much into them and adversely impact interoperability. --Dave On Feb 23, 2005, at 11:56 AM, Tanya Shastri wrote: > Hi, > > Session deletion has not been mentioned explicitly in the draft. From rtg-bfd-bounces@ietf.org Thu Feb 24 02:36:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11500; Thu, 24 Feb 2005 02:36:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4DuS-0005Jk-BT; Thu, 24 Feb 2005 02:59:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4DXL-0001Hc-FL; Thu, 24 Feb 2005 02:35:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4DXI-0001EH-85 for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 02:35:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11485 for ; Thu, 24 Feb 2005 02:35:46 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Du9-0005J7-CO for rtg-bfd@ietf.org; Thu, 24 Feb 2005 02:59:25 -0500 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 j1O7ZdBm020129; Wed, 23 Feb 2005 23:35:39 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j1O7Zce24284; Wed, 23 Feb 2005 23:35:38 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: References: <200502222036.PAA16786@ietf.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <35ed279cf9e5b6c559f3d843e7c8d7c3@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 24 Feb 2005 00:35:37 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: ttl and authentication 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit On Feb 24, 2005, at 12:00 AM, Pekka Savola wrote: > The concern is which is done first: TTL check or authentication check. > > Compare the situation to BGP with MD5. Folks can easily DoS a router > by sending bogus MD5-signed BGP packets to spend all the CPU's > computational resources. Using TTL=255 check _first_ prevents this > particular attack vector, except from the on-link neighbors. > > The same argument seems to apply here. Speaking as an operator who's > using BFD, I will not be happy if the TTL is not checked first as this > opens a resource exhaustion attack vector which could be easily > prevented. I guess I would counter that if the TTL check is the only thing protecting your infrastructure, then you have bigger problems. Filtering at the edge of your network has got to be the first line of defense. Certainly there have got to be similar opportunities to hose things with other protocols for which a TTL check will not help. --Dave From rtg-bfd-bounces@ietf.org Thu Feb 24 02:42:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12033; Thu, 24 Feb 2005 02:42:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4E0D-0005Rz-JI; Thu, 24 Feb 2005 03:05:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4DbA-0004oG-EZ; Thu, 24 Feb 2005 02:39:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Db7-0004ni-OX for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 02:39:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11793 for ; Thu, 24 Feb 2005 02:39:44 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Dxx-0005Oa-N7 for rtg-bfd@ietf.org; Thu, 24 Feb 2005 03:03:23 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1O7dX424348; Thu, 24 Feb 2005 09:39:33 +0200 Date: Thu, 24 Feb 2005 09:39:33 +0200 (EET) From: Pekka Savola To: Dave Katz In-Reply-To: <35ed279cf9e5b6c559f3d843e7c8d7c3@juniper.net> Message-ID: References: <200502222036.PAA16786@ietf.org> <35ed279cf9e5b6c559f3d843e7c8d7c3@juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: rtg-bfd@ietf.org Subject: Re: ttl and authentication 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Thu, 24 Feb 2005, Dave Katz wrote: >> The same argument seems to apply here. Speaking as an operator who's using >> BFD, I will not be happy if the TTL is not checked first as this opens a >> resource exhaustion attack vector which could be easily prevented. > > I guess I would counter that if the TTL check is the only thing protecting > your infrastructure, then you have bigger problems. Filtering at the edge of > your network has got to be the first line of defense. Certainly there have > got to be similar opportunities to hose things with other protocols for which > a TTL check will not help. That is correct, and in fact in our case, we do have filtering at the edge. However, it is not clear which packets routers implementing BFD will demultiplex. Are the BFD ports open to everyone -- i.e., are you requiring that all packets addressed to the any of the routers' addressed must be dropped at the borders (that's rather unreasonable approach IMHO)? What if you want to run BFD with eBGP and you cannot be protected with border filtering? All in all, if there is no strong reason to remove the TTL check, I'd strongly prefer to put it back in. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rtg-bfd-bounces@ietf.org Thu Feb 24 03:28:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15972; Thu, 24 Feb 2005 03:28:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Eit-0006QD-7L; Thu, 24 Feb 2005 03:51:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4EGj-0002B4-E8; Thu, 24 Feb 2005 03:22:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4EGf-0002Ao-5V for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 03:22:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15512 for ; Thu, 24 Feb 2005 03:22:39 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4EdW-0006Ib-Gn for rtg-bfd@ietf.org; Thu, 24 Feb 2005 03:46:18 -0500 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 j1O8MVBm020365; Thu, 24 Feb 2005 00:22:31 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j1O8MVe29773; Thu, 24 Feb 2005 00:22:31 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: References: <200502222036.PAA16765@ietf.org> <0b49f300cadf3d470eaebe742db25983@juniper.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <013cd11f3f5d864752b04b39dd462380@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 24 Feb 2005 01:22:30 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: other comments for single-hop bfd [Re: I-D ACTION:draft-ietf-bfd-v4v6-1hop-01.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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit On Feb 24, 2005, at 12:06 AM, Pekka Savola wrote: > On Wed, 23 Feb 2005, Dave Katz wrote: >> It does raise the question of whether we want to continue to add text >> into this document for other protocols, or whether it would be worth >> having additional documents to cover them so that this one can be put >> to bed. I would prefer to avoid further significant technical >> changes to this doc and to have additional stuff be put into a >> separate one, in order to advance this stuff without too much more >> tinkering. This should probably be discussed in Minneapolis. > > Right. Obviously, I'm a proponent of putting it here (well, I asked > if I should make it a separate draft back in July or so, but then it > was felt ok to include it here). I guess this was overtaken by my slothfulness. The question at hand now should be whether this document should be stalled for however long is necessary to incorporate it. Assuming that it would require another IETF meeting to approve moving the document along the standards track, then it would seem to me that we should separate it out (assuming that this version is otherwise acceptable, modulo editorial issues.) Perhaps the WG chairs can step in and outline the pros and cons here. My apologies for letting this stuff slip by. > >>> .. in fact it would preclude the operation of the IGP in the >>> particular BFD-enabled _interface_. The text seems to be implying >>> that having BFD would be an IGP domain-wide toggle like IS-IS >>> authentication. But in reality, it is an interface toggle, so this >>> argument is irrelevant. >> >> It is not irrelevant on multipoint media. Perhaps it would more >> correctly read "...preclude the *correct* operation of the IGP..." >> It's not that it makes the IGP completely fail, but it can create >> large-scale black holes if the topology is particularly unlucky. I >> could add the extra word if you feel strongly about it. > > No, this clarification would also be misleading. It would prevent the > correct operation of the IGP *on that particular interface*. So, you > must enable BFD on all the systems you have adjacencies to on a > multipoint link. Unfortunately, incorrect operation of the IGP on a single interface has network-wide implications (you can partition the network, for example.) Network-wide correctness is predicated on node-by-node (and interface-by-interface) correctness. > > I'm not sure how common those multipoint links are (we certainly have > only one with more than 1 neighbor with which we would like to run > BFD; the most common are probably Ethernet IX's but folks don't run > IGP there), so unless our setup differs radically from what's out > there, this shouldn't be a problem. It seems likely that someone will have a setup that differs from yours, either now or sometime in the future. --Dave From rtg-bfd-bounces@ietf.org Thu Feb 24 03:56:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19068; Thu, 24 Feb 2005 03:56:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4FAL-0007HJ-1b; Thu, 24 Feb 2005 04:20:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Em7-0005G4-Tc; Thu, 24 Feb 2005 03:55:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Em4-0005E5-Rq for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 03:55:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18930 for ; Thu, 24 Feb 2005 03:55:07 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4F8w-0007FG-K3 for rtg-bfd@ietf.org; Thu, 24 Feb 2005 04:18:47 -0500 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 j1O8so975686; Thu, 24 Feb 2005 00:54:52 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j1O8sie33295; Thu, 24 Feb 2005 00:54:44 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: References: <200502222036.PAA16786@ietf.org> <35ed279cf9e5b6c559f3d843e7c8d7c3@juniper.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 24 Feb 2005 01:54:44 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: ttl and authentication 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit On Feb 24, 2005, at 12:39 AM, Pekka Savola wrote: > However, it is not clear which packets routers implementing BFD will > demultiplex. Are the BFD ports open to everyone -- i.e., are you > requiring that all packets addressed to the any of the routers' > addressed must be dropped at the borders (that's rather unreasonable > approach IMHO)? What if you want to run BFD with eBGP and you cannot > be protected with border filtering? > > All in all, if there is no strong reason to remove the TTL check, I'd > strongly prefer to put it back in. > Let's put it a different way. On first principles, if you are only willing to accept cryptographically authenticated packets from good guys, then cryptographic authentication has absolutely no value and you shouldn't use it at all (in which case you will have the TTL check.) In general, there *must* be a spectrum of methods to protect against DoS attacks when cryptographic authentication is used (in any protocol), and these are likely to be adaptive and somewhat complex. BFD is *not* the only protocol with this issue, and given the direction things are going, there are only going to be more. The metaproblem here is that specifications and operations are distinct. When the spec says that you have to accept such packets, it is stated as such to provide a baseline of interoperability. At some level, operationally, authentication is about consciously avoiding interoperation. For example, in this case you could put a filter in place (outside of BFD) which discards all BFD packets received on the interface with TTL != 255. This is is entirely equivalent to dropping it in the implementation (and is probably preferable if you're worried about DoS attacks, particularly if you filter in hardware.) So is this somehow in violation of the spec as currently written? Similarly, if an implementation provides a knob that provides this behavior within BFD, is that implementation broken? I think we would agree that it is not. The role of the spec has to be to provide as wide a range of interoperability as possible. The MUST/MAY/SHOULD verbiage doesn't really give us the subtle gradations of meaning that are needed. What I really want to say here is that an implementation has to be capable of accepting such packets, not that it has to under all circumstances and configurations. I'm not sure how to say that. I'd be happy to entertain suggestions. Anyone who is familiar with my implementations knows that I view protocol specs liberally, so long as the box will interoperate fully with everybody else's. In this particular case I wouldn't hesitate to add a knob to provide the behavior you desire, and would do so with a clear conscience. I've always felt that the art of implementation is knowing what you can safely get away with. But that's just me. --Dave From rtg-bfd-bounces@ietf.org Thu Feb 24 04:35:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23823; Thu, 24 Feb 2005 04:35:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Flh-0008P1-7b; Thu, 24 Feb 2005 04:58:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4FO6-0002sb-Gu; Thu, 24 Feb 2005 04:34:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4FNw-0002rY-EH for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 04:34:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23750 for ; Thu, 24 Feb 2005 04:34:14 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Fko-0008NZ-6G for rtg-bfd@ietf.org; Thu, 24 Feb 2005 04:57:54 -0500 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 j1O9Y5976121; Thu, 24 Feb 2005 01:34:05 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j1O9Y0e38288; Thu, 24 Feb 2005 01:34:00 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <79da1061521c9ba26c851a01b84fc5f8@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 24 Feb 2005 02:33:59 -0700 To: richard.spencer@bt.com X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: Between schedule transmissions 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit The loop is persistent only if you can guarantee that one system will always send two packets prior to receiving one from the other guy. This guarantee is hard to make unless the implementation always explicitly sends two packets back-to-back (and if an implementation does this, your suggestion will not change the outcome.) Everything after that is probabilistic. If this situation occurs, one side will time out of Init state and try again. Then the dice are rolled once more. The change you suggest may reduce the odds of this occurring somewhat, although it is worth noting that it is the "extra" packet that causes the problem in the first place, and additional "extra" packets may exacerbate the situation instead. Note also that as the latency on the link increases, your change is less likely to work, as it is predicated on the opposite case, namely that exactly one packet is guaranteed to be sent, and one sent in return (a round trip time), prior to the second packet being sent. The sedate rate at which packets are sent when the session isn't Up helps improve the odds as well. I think there is no way out of this conundrum, particularly if the packet transmit rates are different on each side (getting rid of the "extra" packets entirely wouldn't even help.) Distributed state establishment is a sloppy business. One thing you point out is that the text is not clear as to when the state variables are to be initialized; the answer is that they are initialized once when the session is created, and never again (the protocol machinery will tinker with the state as necessary as the session goes up and down.) I'll add a little text to that effect. --Dave On Feb 22, 2005, at 5:10 PM, richard.spencer@bt.com wrote: > In the case of state transitions from 'Down to Up or Init', and from > 'Up to Failing' it is obvious that a BFD packet should be sent > immediately (rather than waiting for the next scheduled transmission) > because the IHY variable changes. However, what about state changes > form 'Init to Up' and 'Failing to Down' where the IHY doesn't change? > Do these result in BFD packets being sent immediately, or does the > system wait until the next scheduled transmission? The answer to this > question may be dependant on the bfd.LocalDiag field, the draft states > that bfd.LocalDiag MUST be initialised to zero, and describes when it > should be changed to reflect failure conditions. However, there is no > information (or at least I can't find any) regarding when > bfd.LocalDiag should be reset to 0. From rtg-bfd-bounces@ietf.org Thu Feb 24 07:32:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11041; Thu, 24 Feb 2005 07:32:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4IXn-0003xQ-ES; Thu, 24 Feb 2005 07:56:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4IAd-0003bW-Po; Thu, 24 Feb 2005 07:32:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4IAb-0003WB-Tb for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 07:32:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11007 for ; Thu, 24 Feb 2005 07:32:40 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4IXV-0003ws-JJ for rtg-bfd@ietf.org; Thu, 24 Feb 2005 07:56:21 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j1OCWVq16235 for ; Thu, 24 Feb 2005 07:32:31 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1JJLRH2V>; Thu, 24 Feb 2005 07:32:32 -0500 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE03192D67@zcarhxm2.corp.nortel.com> From: "David Allan" To: "'Thomas D. Nadeau'" , "'rtg-bfd@ietf.org'" Date: Thu, 24 Feb 2005 07:32:28 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: "'David Ward'" , "'Dave Katz'" Subject: RE: Comments on draft-suping-bfd-mpls-fecmismatch-00.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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi Tom: The final technical issue I have with the document > is that it is based on ITU Y.1713, which is based on > ITU recommendation Y.1711. If we take a close look at > the scope section of the updated version of Y.1711, > we will find that the protocol is limited to > connection-oriented network constructs ONLY. For MPLS this > means that it ONLY applies to MPLS-TE LSPs and possibly > things that can ride over those LSPs (i.e.: pseudowires that > use a TE LSP between PEs). It also means that since Y.1713 > is based on Y.1711, it inherits its scoped limitations as well. This part of the analysis is flawed ....1713 is not limited to P2P, it only uses general PDU design common to 1711. it was designed primarily for LDP but like 1711 had problems with PHP, which in this application would not be an issue. (session ID stunt doubles for the label). The FEC filter in 1713 which only needs to be ANDed with the receiver expected value would be very consistent with the minimalist approach in BFD. I had already considered proposing this to eliminate the need for a periodic VCCV-PING to check the control plane binding. And it would be more authoritative than hoping that you did not have collisions in the session discriminator space in conjunction with leakage... Dave > > > > > > From rtg-bfd-bounces@ietf.org Thu Feb 24 10:11:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29864; Thu, 24 Feb 2005 10:11:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4L0n-0008H8-Hi; Thu, 24 Feb 2005 10:34:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Kd3-00043L-Vl; Thu, 24 Feb 2005 10:10:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Kd2-000436-B4 for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 10:10:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29678 for ; Thu, 24 Feb 2005 10:10:10 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Kzt-0008El-VV for rtg-bfd@ietf.org; Thu, 24 Feb 2005 10:33:53 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 24 Feb 2005 10:09:59 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1OF9vhF006592; Thu, 24 Feb 2005 10:09:57 -0500 (EST) Received: from [161.44.71.183] ([161.44.71.183]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APJ02281; Thu, 24 Feb 2005 10:09:56 -0500 (EST) In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BE03192D67@zcarhxm2.corp.nortel.com> References: <87AC5F88F03E6249AEA68D40BD3E00BE03192D67@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <039e2f820b364afe0510e22f3d803503@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Thu, 24 Feb 2005 10:09:41 -0500 To: "David Allan" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: "'rtg-bfd@ietf.org'" , "'David Ward'" , "'Dave Katz'" Subject: Re: Comments on draft-suping-bfd-mpls-fecmismatch-00.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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit On Feb 24, 2005, at 7:32 AM, David Allan wrote: > > Hi Tom: > > > > The final technical issue I have with the document >> is that it is based on ITU Y.1713, which is based on >> ITU recommendation Y.1711. If we take a close look at >> the scope section of the updated version of Y.1711, >> we will find that the protocol is limited to >> connection-oriented network constructs ONLY. For MPLS this >> means that it ONLY applies to MPLS-TE LSPs and possibly >> things that can ride over those LSPs (i.e.: pseudowires that >> use a TE LSP between PEs). It also means that since Y.1713 >> is based on Y.1711, it inherits its scoped limitations as well. > > This part of the analysis is flawed ....1713 is not limited > to P2P, it only uses general PDU design common to 1711. it > was designed primarily for LDP but like 1711 had problems > with PHP, which in this application would not be an issue. > (session ID stunt doubles for the label). > > The FEC filter in 1713 which only needs to be ANDed with the > receiver expected value would be very consistent with the > minimalist approach in BFD. I had already considered > proposing this to eliminate the need for a periodic VCCV-PING > to check the control plane binding. And it would be more > authoritative than hoping that you did not have collisions in > the session discriminator space in conjunction with leakage... One of my points was that the filter is unnecessary (even if it would work). That seems like a more minimalist approach to me. :P --Tom > > Dave > > >> >>> >>> >> From rtg-bfd-bounces@ietf.org Thu Feb 24 11:13:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09105; Thu, 24 Feb 2005 11:13:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4LzJ-0001xf-Dp; Thu, 24 Feb 2005 11:37:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Lag-000846-EK; Thu, 24 Feb 2005 11:11:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Lae-00082s-9S for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 11:11:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08761 for ; Thu, 24 Feb 2005 11:11:45 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4LxY-0001qa-OS for rtg-bfd@ietf.org; Thu, 24 Feb 2005 11:35:30 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j1OGBYJ02318 for ; Thu, 24 Feb 2005 11:11:35 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1JJLR3KZ>; Thu, 24 Feb 2005 11:11:34 -0500 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE03192D6F@zcarhxm2.corp.nortel.com> From: "David Allan" To: "'Thomas D. Nadeau'" Date: Thu, 24 Feb 2005 11:11:28 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: "'rtg-bfd@ietf.org'" , "'David Ward'" , "'Dave Katz'" Subject: RE: Comments on draft-suping-bfd-mpls-fecmismatch-00.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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 > One of my points was that the filter is unnecessary > (even if it would work). Amusing piece of FUD... > That seems like a more minimalist > approach to me. :P The suggestion would permit the elimination of " It may be desirable to use LSP-Ping additionally for periodic diagnostics in addition to BFD for fault detection on the same PW [BFDMPLS]." from VCCV as it could be condensed into one transaction.... Same applies to the phrase " BFD cannot be used for verifying the MPLS control plane against the data plane. " in BFD for MPLS LSPs... Dave > > --Tom > > > > > > Dave > > > > > >> > >>> > >>> > >> > > From rtg-bfd-bounces@ietf.org Thu Feb 24 11:37:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13299; Thu, 24 Feb 2005 11:37:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4MMf-00039A-UY; Thu, 24 Feb 2005 12:01:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Lvf-0004hz-Mf; Thu, 24 Feb 2005 11:33:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Lve-0004hD-9P for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 11:33:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12584 for ; Thu, 24 Feb 2005 11:33:27 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4MIZ-0002y0-VM for rtg-bfd@ietf.org; Thu, 24 Feb 2005 11:57:12 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 24 Feb 2005 08:31:10 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,114,1107763200"; d="scan'208"; a="163164395:sNHT490872754" Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1OGSWuC014600; Thu, 24 Feb 2005 08:28:32 -0800 (PST) Received: (from wardd@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id KAA08956; Thu, 24 Feb 2005 10:28:32 -0600 (CST) Date: Thu, 24 Feb 2005 10:28:32 -0600 From: David Ward To: Dave Katz , dward@cisco.com Message-ID: <20050224102832.G4790@cfcentral.cisco.com> References: <200502222036.PAA16765@ietf.org> <0b49f300cadf3d470eaebe742db25983@juniper.net> <013cd11f3f5d864752b04b39dd462380@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <013cd11f3f5d864752b04b39dd462380@juniper.net>; from dkatz@juniper.net on Thu, Feb 24, 2005 at 01:22:30AM -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: rtg-bfd@ietf.org, Pekka Savola Subject: Re: other comments for single-hop bfd [Re: I-D ACTION:draft-ietf-bfd-v4v6-1hop-01.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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Dave, et al - There should be a simple, 'how to bootstrap a BFD session and what to do when you rx a BFD event' doc. The pros are that we don't have to increment this doc every time we think about another protocol to interact w/ BFD, the cons are that it is just about all contained in this doc. There are some nuances of IGP interaction but, for the most part protocols/applications that want to be dependent on BFD as a forwarding failure detection, will have very generic interactions. I am hoping that the new draft will be very, very short and not call out each and every application, scenario or potential usage. If we keep it generic, we can get it through the process much more quickly. If a protocol or application actually has specific needs (e.g. LSPping), then it deserves it's own draft/spec. I think Dave and I can crank this out very quickly. -DWard On Thu, Feb 24, 2005 at 01:22:30AM -0700, Dave Katz wrote: > > On Feb 24, 2005, at 12:06 AM, Pekka Savola wrote: > > > On Wed, 23 Feb 2005, Dave Katz wrote: > >> It does raise the question of whether we want to continue to add text > >> into this document for other protocols, or whether it would be worth > >> having additional documents to cover them so that this one can be put > >> to bed. I would prefer to avoid further significant technical > >> changes to this doc and to have additional stuff be put into a > >> separate one, in order to advance this stuff without too much more > >> tinkering. This should probably be discussed in Minneapolis. > > > > Right. Obviously, I'm a proponent of putting it here (well, I asked > > if I should make it a separate draft back in July or so, but then it > > was felt ok to include it here). > > I guess this was overtaken by my slothfulness. The question at hand > now should be whether this document should be stalled for however long > is necessary to incorporate it. Assuming that it would require another > IETF meeting to approve moving the document along the standards track, > then it would seem to me that we should separate it out (assuming that > this version is otherwise acceptable, modulo editorial issues.) > Perhaps the WG chairs can step in and outline the pros and cons here. > My apologies for letting this stuff slip by. From rtg-bfd-bounces@ietf.org Thu Feb 24 13:06:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24527; Thu, 24 Feb 2005 13:06:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Nl1-0005pO-ES; Thu, 24 Feb 2005 13:30:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4NMI-0006Ck-S7; Thu, 24 Feb 2005 13:05:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4NMG-0006Ca-HC for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 13:05:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24325 for ; Thu, 24 Feb 2005 13:05:01 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.198]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4NjA-0005lV-9Z for rtg-bfd@ietf.org; Thu, 24 Feb 2005 13:28:47 -0500 Received: by rproxy.gmail.com with SMTP id a41so352739rng for ; Thu, 24 Feb 2005 10:05:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=cRVLGtmBcK0fnNCozi9UidQbkV3fHs/Wfmaw1HsUxZpf8D9YV9rXK3POLkoMs+x+ikgujWMs0Z1yO1tn5EFmiHB5Gnb61eF8XlVAvVSpC594lUyk4EZNWFmfuQmINIBofbTd55lVxakjPyy9o3ogTf1SKew3LE7JYTUk1eq7NHY= Received: by 10.38.81.64 with SMTP id e64mr216721rnb; Thu, 24 Feb 2005 10:05:00 -0800 (PST) Received: by 10.38.125.34 with HTTP; Thu, 24 Feb 2005 10:05:00 -0800 (PST) Message-ID: <9e31186f05022410056f28802a@mail.gmail.com> Date: Thu, 24 Feb 2005 19:05:00 +0100 From: Carlos Garcia Braschi To: rtg-bfd@ietf.org In-Reply-To: <421e097a.13076f0b.1ec7.2193SMTPIN_ADDED@mx.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <421e097a.13076f0b.1ec7.2193SMTPIN_ADDED@mx.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Subject: Re: other comments for single-hop bfd X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Carlos Garcia Braschi List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit On Thu, 24 Feb 2005 09:06:02 -0800 (PST), rtg-bfd-request@ietf.org wrote: > Message: 5 > Date: Thu, 24 Feb 2005 10:28:32 -0600 > From: David Ward > Subject: Re: other comments for single-hop bfd [Re: I-D > ACTION:draft-ietf-bfd-v4v6-1hop-01.txt] > To: Dave Katz , dward@cisco.com > Cc: rtg-bfd@ietf.org, Pekka Savola > Message-ID: <20050224102832.G4790@cfcentral.cisco.com> > Content-Type: text/plain; charset=us-ascii > > Dave, et al - > > There should be a simple, 'how to bootstrap a BFD session and what to do > when you rx a BFD event' doc. The pros are that we don't have to increment > this doc every time we think about another protocol to interact w/ BFD, the > cons are that it is just about all contained in this doc. There are some > nuances of IGP interaction but, for the most part protocols/applications that > want to be dependent on BFD as a forwarding failure detection, will have > very generic interactions. > > I am hoping that the new draft will be very, very short and not call out > each and every application, scenario or potential usage. If we keep it > generic, we can get it through the process much more quickly. If a protocol > or application actually has specific needs (e.g. LSPping), then it deserves > it's own draft/spec. I think Dave and I can crank this out very quickly. > Seems like a good approach, although I'd favor publishing (in the same or other drafts) the specific application of BFD 1hop to the specific cases known today, OSPF, IS-IS, BGP, and static routes. The text seems to exist already for most of them, and having a separate draft for the nuances of each one of them seems to be quite messy. And not having them seems to leave a door open for incompatible implementaions... Carlos. > -DWard > From rtg-bfd-bounces@ietf.org Thu Feb 24 13:23:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26090; Thu, 24 Feb 2005 13:23:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4O16-0006DC-Qo; Thu, 24 Feb 2005 13:47:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4NdZ-0005bW-Qg; Thu, 24 Feb 2005 13:22:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4NdX-0005bN-Tk for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 13:22:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26007 for ; Thu, 24 Feb 2005 13:22:52 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4O0T-0006CB-4k for rtg-bfd@ietf.org; Thu, 24 Feb 2005 13:46:38 -0500 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 j1OIMgBm024934; Thu, 24 Feb 2005 10:22:42 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j1OIMge12417; Thu, 24 Feb 2005 10:22:42 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <9e31186f05022410056f28802a@mail.gmail.com> References: <421e097a.13076f0b.1ec7.2193SMTPIN_ADDED@mx.gmail.com> <9e31186f05022410056f28802a@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 24 Feb 2005 11:22:41 -0700 To: Carlos Garcia Braschi X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: other comments for single-hop 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit >> I am hoping that the new draft will be very, very short and not >> call out >> each and every application, scenario or potential usage. If we keep it >> generic, we can get it through the process much more quickly. If a >> protocol >> or application actually has specific needs (e.g. LSPping), then it >> deserves >> it's own draft/spec. I think Dave and I can crank this out very >> quickly. >> > > Seems like a good approach, although I'd favor publishing (in the same > or other drafts) the specific application of BFD 1hop to the specific > cases known today, OSPF, IS-IS, BGP, and static routes. > > The text seems to exist already for most of them, and having a > separate draft for the nuances of each one of them seems to be quite > messy. And not having them seems to leave a door open for incompatible > implementaions... The problem is that folding it into the 1hop spec will delay progressing that spec for another four months, whereas we should be able to go to last call soon if we keep it separate. Frankly, I think there's very little to say about the interworking of BFD with other protocols, and almost no opportunity for interoperability problems (since for the most part the spec will say "if BFD goes down, do the appropriate teardown procedure in the protocol".) I forsee a few SHOULDs and not much else. --Dave From rtg-bfd-bounces@ietf.org Thu Feb 24 13:37:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27660; Thu, 24 Feb 2005 13:37:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4OEb-0006bx-GA; Thu, 24 Feb 2005 14:01:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4NrE-0000Ei-99; Thu, 24 Feb 2005 13:37:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4NrD-0000Ec-Qp for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 13:37:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27639 for ; Thu, 24 Feb 2005 13:36:59 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4OE9-0006Zx-46 for rtg-bfd@ietf.org; Thu, 24 Feb 2005 14:00:46 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id B77DD2D4AB2 for ; Thu, 24 Feb 2005 13:36:44 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18662-01-42 for ; Thu, 24 Feb 2005 13:36:40 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9BB982D4AB7 for ; Thu, 24 Feb 2005 13:33:17 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j1OIXHo28924 for rtg-bfd@ietf.org; Thu, 24 Feb 2005 13:33:17 -0500 (EST) Date: Thu, 24 Feb 2005 13:33:17 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Message-ID: <20050224183317.GQ24296@nexthop.com> References: <421e097a.13076f0b.1ec7.2193SMTPIN_ADDED@mx.gmail.com> <9e31186f05022410056f28802a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: Re: other comments for single-hop 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Thu, Feb 24, 2005 at 11:22:41AM -0700, Dave Katz wrote: > Frankly, I think there's very little to say about the interworking of > BFD with other protocols, and almost no opportunity for > interoperability problems (since for the most part the spec will say > "if BFD goes down, do the appropriate teardown procedure in the > protocol".) I forsee a few SHOULDs and not much else. I would tend to agree. Also, it's likely that it would be up to each WG to specify how their protocol utilizes BFD. > --Dave -- Jeff Haas NextHop Technologies From rtg-bfd-bounces@ietf.org Thu Feb 24 13:40:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28046; Thu, 24 Feb 2005 13:40:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4OHQ-0006fT-PP; Thu, 24 Feb 2005 14:04:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Nri-0000Rh-FZ; Thu, 24 Feb 2005 13:37:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Nrh-0000Ra-Lh for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 13:37:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27678 for ; Thu, 24 Feb 2005 13:37:30 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4OEc-0006af-Ug for rtg-bfd@ietf.org; Thu, 24 Feb 2005 14:01:16 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1OIb8206565; Thu, 24 Feb 2005 20:37:08 +0200 Date: Thu, 24 Feb 2005 20:37:08 +0200 (EET) From: Pekka Savola To: Dave Katz In-Reply-To: Message-ID: References: <421e097a.13076f0b.1ec7.2193SMTPIN_ADDED@mx.gmail.com> <9e31186f05022410056f28802a@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: rtg-bfd@ietf.org, Carlos Garcia Braschi Subject: Re: other comments for single-hop 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Thu, 24 Feb 2005, Dave Katz wrote: > The problem is that folding it into the 1hop spec will delay progressing that > spec for another four months, whereas we should be able to go to last call > soon if we keep it separate. There is procedurally no need to wait for the face-to-face meetings to go to last call. It's (procedurally) entirely fine to revise the 1hop draft with BGP and static routes immediately after Minneapolis, and fire off a WG last call a week after that. The chairs should judge the appropriate procedures, of course, but the spec getting delayed is (IMHO) not a concern here. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rtg-bfd-bounces@ietf.org Thu Feb 24 13:46:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28764; Thu, 24 Feb 2005 13:46:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4OMv-0006rw-DL; Thu, 24 Feb 2005 14:09:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Nzc-0004L8-6q; Thu, 24 Feb 2005 13:45:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Nzb-0004Il-Jx for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 13:45:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28694 for ; Thu, 24 Feb 2005 13:45:40 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4OMX-0006qY-Le for rtg-bfd@ietf.org; Thu, 24 Feb 2005 14:09:26 -0500 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 j1OIjVBm025165; Thu, 24 Feb 2005 10:45:32 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j1OIjUe16860; Thu, 24 Feb 2005 10:45:30 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: References: <421e097a.13076f0b.1ec7.2193SMTPIN_ADDED@mx.gmail.com> <9e31186f05022410056f28802a@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3b9fedc880c034cc9a24b9238a9b9854@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 24 Feb 2005 11:45:29 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org, Carlos Garcia Braschi Subject: Re: other comments for single-hop 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit On Feb 24, 2005, at 11:37 AM, Pekka Savola wrote: > On Thu, 24 Feb 2005, Dave Katz wrote: >> The problem is that folding it into the 1hop spec will delay >> progressing that spec for another four months, whereas we should be >> able to go to last call soon if we keep it separate. > > There is procedurally no need to wait for the face-to-face meetings to > go to last call. > > It's (procedurally) entirely fine to revise the 1hop draft with BGP > and static routes immediately after Minneapolis, and fire off a WG > last call a week after that. > > The chairs should judge the appropriate procedures, of course, but the > spec getting delayed is (IMHO) not a concern here. Fine with me if true. Less typing on my part. If the WG chairs could advise on parliamentary procedure that would be most appreciated. --Dave From rtg-bfd-bounces@ietf.org Thu Feb 24 14:06:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00935; Thu, 24 Feb 2005 14:06:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Ogy-0007OL-Aq; Thu, 24 Feb 2005 14:30:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4OJR-0006RD-Qi; Thu, 24 Feb 2005 14:06:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4OJQ-0006R6-MU for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 14:06:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00739 for ; Thu, 24 Feb 2005 14:06:11 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4OgM-0007Mx-M8 for rtg-bfd@ietf.org; Thu, 24 Feb 2005 14:29:55 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 511FD2D4ED7; Thu, 24 Feb 2005 14:06:02 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23232-01-43; Thu, 24 Feb 2005 14:05:58 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id F05A52D48D1; Thu, 24 Feb 2005 14:02:47 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j1OJ2lQ29062; Thu, 24 Feb 2005 14:02:47 -0500 (EST) Date: Thu, 24 Feb 2005 14:02:47 -0500 From: Jeffrey Haas To: Dave Katz Message-ID: <20050224190247.GR24296@nexthop.com> References: <421e097a.13076f0b.1ec7.2193SMTPIN_ADDED@mx.gmail.com> <9e31186f05022410056f28802a@mail.gmail.com> <3b9fedc880c034cc9a24b9238a9b9854@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3b9fedc880c034cc9a24b9238a9b9854@juniper.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: rtg-bfd@ietf.org, Carlos Garcia Braschi , Pekka Savola Subject: Re: other comments for single-hop 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 On Thu, Feb 24, 2005 at 11:45:29AM -0700, Dave Katz wrote: > >The chairs should judge the appropriate procedures, of course, but the > >spec getting delayed is (IMHO) not a concern here. > > Fine with me if true. Less typing on my part. If the WG chairs could > advise on parliamentary procedure that would be most appreciated. The business of the Working Group takes place on the mailing list. The primary purpose of our meetings is to try to hash out issues that take too much bandwidth to convey simply on a mailing list. Several issues related to the most recent drafts have been raised on the mailing list. It would be to the authors' benefit to summarize the issues and the relevant responses as part of their presentations during the meeting. This helps us with last call issues. As for the static route/eBGP single hop items, placing them in the base document is probably fine. Static routes seem to be a reasonably simple case. I'm vaguely concerned about BGP with regards to third party nexthops. While this is unusual in practice (since most eBGP is over p2p links) the protocol allows for it. There's also the question as to whether or not we have a BFD session to cover the transport session, one for each discovered BGP Nexthop that is determined to be resolvable (if different than the endpoints for the transport session). There's the further question as to how we handle the same issues when doing multihop eBGP or whether we should worry about this case at all. My personal inclination is that BGP has enough issues to warrant a mini-draft. In all cases, when we involve a particular protocol that isn't BFD, we require consensus with the group that owns the protocol. This further entangles us in last call issues. > --Dave -- Jeff Haas NextHop Technologies From rtg-bfd-bounces@ietf.org Thu Feb 24 16:42:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24932; Thu, 24 Feb 2005 16:42:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Qkb-0005CV-8Y; Thu, 24 Feb 2005 16:42:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Qhp-0007IF-Nz; Thu, 24 Feb 2005 16:39:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Qhm-0007Hz-B1 for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 16:39:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24732 for ; Thu, 24 Feb 2005 16:39:28 -0500 (EST) 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.33) id 1D4Qhl-00057z-4Y for rtg-bfd@ietf.org; Thu, 24 Feb 2005 16:39:30 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 24 Feb 2005 13:51:00 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1OLdHuC025329; Thu, 24 Feb 2005 13:39:17 -0800 (PST) Received: from swallow-mac.cisco.com ([161.44.74.242]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APJ42754; Thu, 24 Feb 2005 16:39:15 -0500 (EST) Received: by swallow-mac.cisco.com (Postfix, from userid 501) id 4EFBC22B87D; Thu, 24 Feb 2005 16:40:18 -0500 (EST) Received: from cisco.com (localhost [127.0.0.1]) by swallow-mac.cisco.com (Postfix) with ESMTP id 2D0ED22B874; Thu, 24 Feb 2005 16:40:18 -0500 (EST) To: zhaisuping@huawei.com From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1; GNU Emacs 21.2.1 Date: Thu, 24 Feb 2005 16:40:17 -0500 Message-Id: <20050224214018.4EFBC22B87D@swallow-mac.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: rtg-bfd@ietf.org Subject: draft-suping-bfd-mpls-fecmismatch-00 questions 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Zhai - I'm having a difficult time trying to figure out what problem this solves and how it is proposed to be employed. Of the current proposed MPLS apps for BFD there's VCCV and LSP-Ping initiated BFD sessions. In both cases the FEC binding is established before the BFD session comes up. You have Source and Destination IP addresses as well as the pair of discriminators. This is sufficient to ensure that any BFD packet you might accidentally intercept is unique. So what extra value comes from the filter??? ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From rtg-bfd-bounces@ietf.org Thu Feb 24 20:33:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17634; Thu, 24 Feb 2005 20:33:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4UM8-0002D8-OE; Thu, 24 Feb 2005 20:33:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4UKz-0006F8-Oy; Thu, 24 Feb 2005 20:32:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4UKx-0006F0-Je for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 20:32:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17552 for ; Thu, 24 Feb 2005 20:32:09 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4UKx-0002BU-3Z for rtg-bfd@ietf.org; Thu, 24 Feb 2005 20:32:13 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICG00LLT1OG2T@szxga02-in.huawei.com> for rtg-bfd@ietf.org; Fri, 25 Feb 2005 09:33:52 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICG00KM21OG1I@szxga02-in.huawei.com> for rtg-bfd@ietf.org; Fri, 25 Feb 2005 09:33:52 +0800 (CST) Received: from z11024 ([10.110.49.48]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ICG007FL1SV0Z@szxml01-in.huawei.com>; Fri, 25 Feb 2005 09:36:32 +0800 (CST) Date: Fri, 25 Feb 2005 09:33:50 +0800 From: zhaisuping To: George Swallow , "rtg-bfd@ietf.org" Message-id: <0ICG007FM1SW0Z@szxml01-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7BIT Subject: Re: draft-suping-bfd-mpls-fecmismatch-00 questions X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhaisuping@huawei.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7BIT welcome to comments. please see the inline below. >Zhai - > >I'm having a difficult time trying to figure out what problem this >solves and how it is proposed to be employed. > >Of the current proposed MPLS apps for BFD there's VCCV and LSP-Ping >initiated BFD sessions. In both cases the FEC binding is established >before the BFD session comes up. You have Source and Destination IP >addresses as well as the pair of discriminators. This is sufficient to >ensure that any BFD packet you might accidentally intercept is unique. >So what extra value comes from the filter??? > 1.Although FEC binding is established before the BFD session comes up, but as in BFD session, the descriminators can be changed anytime, so some inconsistence can happen. 2. If the BFD is used to verify the data plane connectivity in mpls network, the LSP-Ping or VCCV must be used to check the control plane binding. If the FEC filter is used then the BFD session can do this work, and it would be more authoritative than hoping that you did not have collisions in the session discriminator space in conjunction with leakage... From rtg-bfd-bounces@ietf.org Fri Feb 25 09:49:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22206; Fri, 25 Feb 2005 09:49:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4gmw-0002Zg-0a; Fri, 25 Feb 2005 09:49:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gmB-0003Xl-5R; Fri, 25 Feb 2005 09:49:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gm8-0003SB-8u for rtg-bfd@megatron.ietf.org; Fri, 25 Feb 2005 09:49:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22166 for ; Fri, 25 Feb 2005 09:49:01 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4gmD-0002Yy-JI for rtg-bfd@ietf.org; Fri, 25 Feb 2005 09:49:12 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 25 Feb 2005 10:03:00 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,117,1107752400"; d="scan'208"; a="38428975:sNHT19604618" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1PEmlhF017896; Fri, 25 Feb 2005 09:48:48 -0500 (EST) Received: from swallow-mac.cisco.com (che-vpn-cluster-2-90.cisco.com [10.86.242.90]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APJ85408; Fri, 25 Feb 2005 09:48:46 -0500 (EST) Received: by swallow-mac.cisco.com (Postfix, from userid 501) id 593FD22C94E; Fri, 25 Feb 2005 09:49:46 -0500 (EST) Received: from cisco.com (localhost [127.0.0.1]) by swallow-mac.cisco.com (Postfix) with ESMTP id D119E22C92E; Fri, 25 Feb 2005 09:49:46 -0500 (EST) To: zhaisuping@huawei.com In-reply-to: Your message of "Fri, 25 Feb 2005 09:33:50 +0800." <0ICG007FM1SW0Z@szxml01-in.huawei.com> From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1; GNU Emacs 21.2.1 Date: Fri, 25 Feb 2005 09:49:45 -0500 Message-Id: <20050225144946.593FD22C94E@swallow-mac.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "rtg-bfd@ietf.org" Subject: Re: draft-suping-bfd-mpls-fecmismatch-00 questions 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 > 1.Although FEC binding is established before the BFD session > comes up, but as in BFD session, the descriminators can be > changed anytime, so some inconsistence can happen. But only the system that is demultiplexing (receiving) can change the discriminator so how would an inconsistency happen? Please give a senario! > 2. If the BFD is used to verify the data plane connectivity in > mpls network, the LSP-Ping or VCCV must be used to check the > control plane binding. If the FEC filter is used then the BFD > session can do this work, and it would be more authoritative than > hoping that you did not have collisions in the session > discriminator space in conjunction with leakage... Again, the receiving system is receiving based on IP address and demultiplexing based on it's own assigned discriminator. So how do "collisions" occur? ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From rtg-bfd-bounces@ietf.org Fri Feb 25 10:03:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23993; Fri, 25 Feb 2005 10:03:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4h0f-0002wy-5k; Fri, 25 Feb 2005 10:04:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gxI-000421-4E; Fri, 25 Feb 2005 10:00:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gxG-00041q-9B for rtg-bfd@megatron.ietf.org; Fri, 25 Feb 2005 10:00:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23488 for ; Fri, 25 Feb 2005 10:00:31 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4gxN-0002pQ-Un for rtg-bfd@ietf.org; Fri, 25 Feb 2005 10:00:43 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 3F0AC2D5099; Fri, 25 Feb 2005 10:00:19 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09836-01-82; Fri, 25 Feb 2005 10:00:14 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 286F22D5283; Fri, 25 Feb 2005 09:29:39 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j1PETbA03770; Fri, 25 Feb 2005 09:29:37 -0500 (EST) Date: Fri, 25 Feb 2005 09:29:37 -0500 From: Jeffrey Haas To: zhaisuping Message-ID: <20050225142936.GA3743@nexthop.com> References: <0ICG007FM1SW0Z@szxml01-in.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0ICG007FM1SW0Z@szxml01-in.huawei.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "rtg-bfd@ietf.org" Subject: Re: draft-suping-bfd-mpls-fecmismatch-00 questions 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Zhai, On Fri, Feb 25, 2005 at 09:33:50AM +0800, zhaisuping wrote: > 2. If the BFD is used to verify the data plane connectivity in > mpls network, the LSP-Ping or VCCV must be used to check the > control plane binding. If the FEC filter is used then the BFD > session can do this work, and it would be more authoritative than > hoping that you did not have collisions in the session > discriminator space in conjunction with leakage... BFD is meant for detecting whether or not bi-directional forwarding is working. LSP-Ping can use BFD to verify that connectivity is continuous. Wouldn't LSP-Ping (or VCCV) be a more appropriate place to do this filter verification? -- Jeff Haas NextHop Technologies From rtg-bfd-bounces@ietf.org Fri Feb 25 10:13:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25623; Fri, 25 Feb 2005 10:13:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4hAO-0003BQ-Dk; Fri, 25 Feb 2005 10:14:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4h8c-0006wt-2R; Fri, 25 Feb 2005 10:12:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4h8Z-0006we-VQ for rtg-bfd@megatron.ietf.org; Fri, 25 Feb 2005 10:12:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25370 for ; Fri, 25 Feb 2005 10:12:13 -0500 (EST) 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.33) id 1D4h8h-00039X-NX for rtg-bfd@ietf.org; Fri, 25 Feb 2005 10:12:25 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 25 Feb 2005 07:23:55 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1PFBtq8018275; Fri, 25 Feb 2005 07:11:56 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-214.cisco.com [10.86.240.214]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APJ87361; Fri, 25 Feb 2005 10:12:01 -0500 (EST) In-Reply-To: <0ICG007FM1SW0Z@szxml01-in.huawei.com> References: <0ICG007FM1SW0Z@szxml01-in.huawei.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <95729101fdd0a191b3e775f24a482edc@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Fri, 25 Feb 2005 10:12:01 -0500 To: zhaisuping@huawei.com X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: "rtg-bfd@ietf.org" Subject: Re: draft-suping-bfd-mpls-fecmismatch-00 questions 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit On Feb 24, 2005, at 8:33 PM, zhaisuping wrote: > welcome to comments. please see the inline below. >> Zhai - >> >> I'm having a difficult time trying to figure out what problem this >> solves and how it is proposed to be employed. >> >> Of the current proposed MPLS apps for BFD there's VCCV and LSP-Ping >> initiated BFD sessions. In both cases the FEC binding is established >> before the BFD session comes up. You have Source and Destination IP >> addresses as well as the pair of discriminators. This is sufficient >> to >> ensure that any BFD packet you might accidentally intercept is unique. >> So what extra value comes from the filter??? >> > > 1.Although FEC binding is established before the BFD session > comes up, but as in BFD session, the descriminators can be > changed anytime, so some inconsistence can happen. In practice I don't see how this can happen given that the sessions are bound by unique IP addresses, session discriminators (and optional security). Can you be more specific about this failure scenario? > 2. If the BFD is used to verify the data plane connectivity in > mpls network, the LSP-Ping or VCCV must be used to check the > control plane binding. If the FEC filter is used then the BFD > session can do this work, and it would be more authoritative than > hoping that you did not have collisions in the session > discriminator space in conjunction with leakage... Again, please be more specific about how you think the use of the tools as specified today will not work. --Tom From rtg-bfd-bounces@ietf.org Fri Feb 25 10:59:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02709; Fri, 25 Feb 2005 10:59:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4hsB-0004tQ-3s; Fri, 25 Feb 2005 10:59:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4hrH-0005xk-Gg; Fri, 25 Feb 2005 10:58:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4hrG-0005uq-EP for rtg-bfd@megatron.ietf.org; Fri, 25 Feb 2005 10:58:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02635 for ; Fri, 25 Feb 2005 10:58:24 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4hrO-0004rx-MI for rtg-bfd@ietf.org; Fri, 25 Feb 2005 10:58:36 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1PFw0n01982; Fri, 25 Feb 2005 17:58:06 +0200 Date: Fri, 25 Feb 2005 17:58:00 +0200 (EET) From: Pekka Savola To: Jeffrey Haas In-Reply-To: <20050224190247.GR24296@nexthop.com> Message-ID: References: <421e097a.13076f0b.1ec7.2193SMTPIN_ADDED@mx.gmail.com> <9e31186f05022410056f28802a@mail.gmail.com> <3b9fedc880c034cc9a24b9238a9b9854@juniper.net> <20050224190247.GR24296@nexthop.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: rtg-bfd@ietf.org, Carlos Garcia Braschi , Dave Katz Subject: Re: other comments for single-hop 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 On Thu, 24 Feb 2005, Jeffrey Haas wrote: > I'm vaguely concerned about BGP with regards to third party nexthops. > While this is unusual in practice (since most eBGP is over p2p > links) the protocol allows for it. There's also the question as to > whether or not we have a BFD session to cover the transport session, > one for each discovered BGP Nexthop that is determined to be resolvable > (if different than the endpoints for the transport session). There's > the further question as to how we handle the same issues when doing > multihop eBGP or whether we should worry about this case at all. > > My personal inclination is that BGP has enough issues to warrant a > mini-draft. Well, I'm not sure if I'm concerned about these, but I see these as potential items for debate. In my opinion, I see the following as obvious: - BFD session is between BGP peers, not between nexthops (that could be even used to perform a DoS attack on 3rd parties, as it could trigger initiating BFD sessions to random destinations). I.e., if you use 3rd party nexthops, you're on your own for validating that the 3rd party nexthop stays up -- as with BGP. BGP doesn't have Hello's to 3rd party nexthops either, why should BFD? - we are only addressing single-hop eBGP here (1hop document) (though the only obvious difference I see is that you can't use TTL=255 check here) - I'm also not all that concerned about review delays. I mean, this already has to go through two WGs (OSPF, IS-IS). What's third to the mix? That said, I'm not strongly objecting to putting BGP in a separate document, just as long as there is a framework what the document should look like. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rtg-bfd-bounces@ietf.org Fri Feb 25 12:07:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08468; Fri, 25 Feb 2005 12:07:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4iwc-0006Ir-Ul; Fri, 25 Feb 2005 12:08:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4inW-0005UC-Np; Fri, 25 Feb 2005 11:58:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4inV-0005U2-7o for rtg-bfd@megatron.ietf.org; Fri, 25 Feb 2005 11:58:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07751 for ; Fri, 25 Feb 2005 11:58:34 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4ine-00067Q-3v for rtg-bfd@ietf.org; Fri, 25 Feb 2005 11:58:47 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 25 Feb 2005 08:53:01 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,117,1107763200"; d="scan'208"; a="163680884:sNHT4553338500" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1PGqIwP008474; Fri, 25 Feb 2005 08:52:21 -0800 (PST) Received: from swallow-mac.cisco.com (che-vpn-cluster-2-90.cisco.com [10.86.242.90]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APJ96907; Fri, 25 Feb 2005 11:52:14 -0500 (EST) Received: by swallow-mac.cisco.com (Postfix, from userid 501) id 274AD22CDB4; Fri, 25 Feb 2005 11:53:15 -0500 (EST) Received: from cisco.com (localhost [127.0.0.1]) by swallow-mac.cisco.com (Postfix) with ESMTP id E502622CD94; Fri, 25 Feb 2005 11:53:15 -0500 (EST) To: Jeffrey Haas In-reply-to: Your message of "Fri, 25 Feb 2005 09:29:37 EST." <20050225142936.GA3743@nexthop.com> From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1; GNU Emacs 21.2.1 Date: Fri, 25 Feb 2005 11:53:14 -0500 Message-Id: <20050225165315.274AD22CDB4@swallow-mac.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: "rtg-bfd@ietf.org" Subject: Re: draft-suping-bfd-mpls-fecmismatch-00 questions 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 > Wouldn't LSP-Ping (or VCCV) be a more appropriate place to do this > filter verification? LSP-Ping does a verification on the FEC itself, so a filter would add nothing. VCCV is not a protocol. Just a little sideband for sending IP packets down a pseudowire so that you can run LSP-Ping, BFD, etc. between the two ends. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From rtg-bfd-bounces@ietf.org Fri Feb 25 15:44:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00052; Fri, 25 Feb 2005 15:44:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4mKU-0002iv-PN; Fri, 25 Feb 2005 15:44:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4mHB-0002UT-1J; Fri, 25 Feb 2005 15:41:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4mH9-0002Ri-GX for rtg-bfd@megatron.ietf.org; Fri, 25 Feb 2005 15:41:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29702 for ; Fri, 25 Feb 2005 15:41:25 -0500 (EST) 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.33) id 1D4mHK-0002e9-Lh for rtg-bfd@ietf.org; Fri, 25 Feb 2005 15:41:39 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 25 Feb 2005 12:53:09 -0800 Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1PKfEZV020521; Fri, 25 Feb 2005 12:41:14 -0800 (PST) Received: (from wardd@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA25628; Fri, 25 Feb 2005 14:41:12 -0600 (CST) Date: Fri, 25 Feb 2005 14:41:12 -0600 From: David Ward To: Dave Katz Message-ID: <20050225144112.A23756@cfcentral.cisco.com> References: <421e097a.13076f0b.1ec7.2193SMTPIN_ADDED@mx.gmail.com> <9e31186f05022410056f28802a@mail.gmail.com> <3b9fedc880c034cc9a24b9238a9b9854@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3b9fedc880c034cc9a24b9238a9b9854@juniper.net>; from dkatz@juniper.net on Thu, Feb 24, 2005 at 11:45:29AM -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: rtg-bfd@ietf.org, Carlos Garcia Braschi , Pekka Savola Subject: Re: other comments for single-hop 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d I am still of the opinion that a generic draft is of greater utility to cover the next round of protocols that want to bootstrap a BFD session. We can go to last call on the list after we have a discussion period. Although requiring more typing, let's go w/ a 'generic interaction' draft. I know of implementations that exist today that allow for more than IGP, static and EBGP bootstrapping ... I think that if we just focus on including these two in the 1-hop draft, it simply isn't going to close (with or w/o the ability to LC after MSP) due to a 'me too' problem w/ other protocols. -DWard On Thu, Feb 24, 2005 at 11:45:29AM -0700, Dave Katz wrote: > > On Feb 24, 2005, at 11:37 AM, Pekka Savola wrote: > > > On Thu, 24 Feb 2005, Dave Katz wrote: > >> The problem is that folding it into the 1hop spec will delay > >> progressing that spec for another four months, whereas we should be > >> able to go to last call soon if we keep it separate. > > > > There is procedurally no need to wait for the face-to-face meetings to > > go to last call. > > > > It's (procedurally) entirely fine to revise the 1hop draft with BGP > > and static routes immediately after Minneapolis, and fire off a WG > > last call a week after that. > > > > The chairs should judge the appropriate procedures, of course, but the > > spec getting delayed is (IMHO) not a concern here. > > Fine with me if true. Less typing on my part. If the WG chairs could > advise on parliamentary procedure that would be most appreciated. > > --Dave From rtg-bfd-bounces@ietf.org Fri Feb 25 20:40:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23048; Fri, 25 Feb 2005 20:40:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4qwz-0008R8-Re; Fri, 25 Feb 2005 20:40:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4qwF-0001Rp-0f; Fri, 25 Feb 2005 20:40:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4qwC-0001Rk-4U for rtg-bfd@megatron.ietf.org; Fri, 25 Feb 2005 20:40:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23024 for ; Fri, 25 Feb 2005 20:40:05 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4qwN-0008QD-Ld for rtg-bfd@ietf.org; Fri, 25 Feb 2005 20:40:22 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICH00A3GWPS1S@szxga02-in.huawei.com> for rtg-bfd@ietf.org; Sat, 26 Feb 2005 09:41:52 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICH00EQOWPSFA@szxga02-in.huawei.com> for rtg-bfd@ietf.org; Sat, 26 Feb 2005 09:41:52 +0800 (CST) Received: from z11024 ([10.110.49.48]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ICH00M6RWPNRF@szxml02-in.huawei.com>; Sat, 26 Feb 2005 09:41:48 +0800 (CST) Date: Sat, 26 Feb 2005 09:41:49 +0800 From: zhaisuping To: George Swallow , "rtg-bfd@ietf.org" Message-id: <0ICH00M6UWPNRF@szxml02-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7BIT Subject: Re: Re: draft-suping-bfd-mpls-fecmismatch-00 questions X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhaisuping@huawei.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7BIT Hi, all The purpose of FEC filter in BFD is to detect the consistence of the control plane and data plane. So that in the MPLS network, just running the BFD session(LSP-Ping is not needed) is enough for the defect detection. Or else such tools as LSP-Ping is needed because the BFD session can't detect the inconsistence of the control plane and data plane. In the section 2 of the draft, there is description of the problem the draft want to solve. >> Wouldn't LSP-Ping (or VCCV) be a more appropriate place to do this >> filter verification? > >LSP-Ping does a verification on the FEC itself, so a filter would add >nothing. > >VCCV is not a protocol. Just a little sideband for sending IP packets >down a pseudowire so that you can run LSP-Ping, BFD, etc. between the >two ends. > >....George > >======================================================================== >George Swallow Cisco Systems (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 From rtg-bfd-bounces@ietf.org Sat Feb 26 09:16:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03087; Sat, 26 Feb 2005 09:16:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D52kU-0004Fc-Ed; Sat, 26 Feb 2005 09:16:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D52jU-0002Vj-6v; Sat, 26 Feb 2005 09:15:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D52jS-0002T9-9M for rtg-bfd@megatron.ietf.org; Sat, 26 Feb 2005 09:15:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03065 for ; Sat, 26 Feb 2005 09:15:44 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D52jm-0004Ev-SY for rtg-bfd@ietf.org; Sat, 26 Feb 2005 09:16:08 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 26 Feb 2005 07:30:40 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,118,1107734400"; d="scan'208"; a="229555369:sNHT24597580" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1QEFPuC027203; Sat, 26 Feb 2005 06:15:26 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-214.cisco.com [10.86.240.214]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APK50411; Sat, 26 Feb 2005 09:15:26 -0500 (EST) In-Reply-To: <0ICH00M6UWPNRF@szxml02-in.huawei.com> References: <0ICH00M6UWPNRF@szxml02-in.huawei.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <82b48ee320e24671ca27050d4b5cc86a@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Sat, 26 Feb 2005 09:15:25 -0500 To: zhaisuping@huawei.com X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: "rtg-bfd@ietf.org" Subject: Re: draft-suping-bfd-mpls-fecmismatch-00 questions 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit On Feb 25, 2005, at 8:41 PM, zhaisuping wrote: > Hi, all > The purpose of FEC filter in BFD is to detect the consistence of > the control plane and data plane. So that in the MPLS network, just > running the BFD session(LSP-Ping is not needed) is enough for the > defect detection. Or else such tools as LSP-Ping is needed because > the BFD session can't detect the inconsistence of the control plane > and data plane. There are cases where BFD/MPLS will work and return a positive result, but the LSP is actually broken. If you run LSP ping, this will certainly detect (and report) the failure. This is why a combination of both tools is necessary. BFD with or without your FEC filter will not solve all of the problems alone. --Tom > In the section 2 of the draft, there is description of the > problem the draft want to solve. >>> Wouldn't LSP-Ping (or VCCV) be a more appropriate place to do this >>> filter verification? > > >> >> LSP-Ping does a verification on the FEC itself, so a filter would add >> nothing. >> >> VCCV is not a protocol. Just a little sideband for sending IP packets >> down a pseudowire so that you can run LSP-Ping, BFD, etc. between the >> two ends. >> >> ....George >> >> ====================================================================== >> == >> George Swallow Cisco Systems (978) >> 936-1398 >> 1414 Massachusetts Avenue >> Boxborough, MA 01719 > From rtg-bfd-bounces@ietf.org Sat Feb 26 11:26:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13965; Sat, 26 Feb 2005 11:26:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D54mQ-0006c4-4x; Sat, 26 Feb 2005 11:26:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D54kY-0004gH-Sb; Sat, 26 Feb 2005 11:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D54kX-0004fo-6g for rtg-bfd@megatron.ietf.org; Sat, 26 Feb 2005 11:25:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13891 for ; Sat, 26 Feb 2005 11:24:58 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D54ks-0006a9-TE for rtg-bfd@ietf.org; Sat, 26 Feb 2005 11:25:24 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 26 Feb 2005 09:39:56 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,118,1107734400"; d="scan'208"; a="229572413:sNHT18746832" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1QGOjuC018382; Sat, 26 Feb 2005 08:24:46 -0800 (PST) Received: from swallow-mac.cisco.com (che-vpn-cluster-2-90.cisco.com [10.86.242.90]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APK52191; Sat, 26 Feb 2005 11:24:46 -0500 (EST) Received: by swallow-mac.cisco.com (Postfix, from userid 501) id 7489022F1E0; Sat, 26 Feb 2005 11:25:49 -0500 (EST) Received: from cisco.com (localhost [127.0.0.1]) by swallow-mac.cisco.com (Postfix) with ESMTP id 5399B22F1D7; Sat, 26 Feb 2005 11:25:49 -0500 (EST) To: zhaisuping@huawei.com In-reply-to: Your message of "Sat, 26 Feb 2005 09:41:49 +0800." <0ICH00M6UWPNRF@szxml02-in.huawei.com> From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1; GNU Emacs 21.2.1 Date: Sat, 26 Feb 2005 11:25:48 -0500 Message-Id: <20050226162549.7489022F1E0@swallow-mac.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: "rtg-bfd@ietf.org" Subject: Re: draft-suping-bfd-mpls-fecmismatch-00 questions 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 > In the section 2 of the draft, there is description of the > problem the draft want to solve. I assume you mean this: "The result is that the LDP label is popped in the core of the network, and the popping LSR may attempt to forward the application label." I'm not particularly persuaded by this example. A properly designed router would *not* forward the application label! ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From rtg-bfd-bounces@ietf.org Sun Feb 27 10:51:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07549; Sun, 27 Feb 2005 10:51:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5Qi0-0008QK-Q7; Sun, 27 Feb 2005 10:51:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Qf7-0006zo-UO; Sun, 27 Feb 2005 10:48:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Qf4-0006zZ-QG for rtg-bfd@megatron.ietf.org; Sun, 27 Feb 2005 10:48:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07413 for ; Sun, 27 Feb 2005 10:48:48 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5Qfc-0008N3-V7 for rtg-bfd@ietf.org; Sun, 27 Feb 2005 10:49:26 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 27 Feb 2005 09:03:57 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,119,1107734400"; d="scan'208"; a="229724522:sNHT20379358" Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1RFmWq8002314; Sun, 27 Feb 2005 07:48:33 -0800 (PST) Received: (from wardd@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA02220; Sun, 27 Feb 2005 09:48:29 -0600 (CST) Date: Sun, 27 Feb 2005 09:48:29 -0600 From: David Ward To: zhaisuping Message-ID: <20050227094829.M23756@cfcentral.cisco.com> References: <0ICH00M6UWPNRF@szxml02-in.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0ICH00M6UWPNRF@szxml02-in.huawei.com>; from zhaisuping@huawei.com on Sat, Feb 26, 2005 at 09:41:49AM +0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: "rtg-bfd@ietf.org" Subject: Re: Re: draft-suping-bfd-mpls-fecmismatch-00 questions 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Unfort., what you write is 180 degrees opposite from the charter of the BFD WG and the philosophy of how the protocol is to function. BFD is not to check the consistency of the forwarding and control plane. We do not want to take this protocol into the realm of control plane failure detection system (as there are many better protocols or protocol machinery for that) but, focus on forwarding failure detection that can send alarms, event notification, diags, etc up the stack. -DWard On Sat, Feb 26, 2005 at 09:41:49AM +0800, zhaisuping wrote: > Hi, all > The purpose of FEC filter in BFD is to detect the consistence of > the control plane and data plane. So that in the MPLS network, just > running the BFD session(LSP-Ping is not needed) is enough for the > defect detection. Or else such tools as LSP-Ping is needed because > the BFD session can't detect the inconsistence of the control plane > and data plane. > In the section 2 of the draft, there is description of the > problem the draft want to solve. > >> Wouldn't LSP-Ping (or VCCV) be a more appropriate place to do this > >> filter verification? > > > > > >LSP-Ping does a verification on the FEC itself, so a filter would add > >nothing. > > > >VCCV is not a protocol. Just a little sideband for sending IP packets > >down a pseudowire so that you can run LSP-Ping, BFD, etc. between the > >two ends. > > > >....George > > > >======================================================================== > >George Swallow Cisco Systems (978) 936-1398 > > 1414 Massachusetts Avenue > > Boxborough, MA 01719 From rtg-bfd-bounces@ietf.org Sun Feb 27 16:23:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05478; Sun, 27 Feb 2005 16:23:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5VtU-0006Ch-Ox; Sun, 27 Feb 2005 16:24:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Vrm-000502-5v; Sun, 27 Feb 2005 16:22:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Vrk-0004uj-0q for rtg-bfd@megatron.ietf.org; Sun, 27 Feb 2005 16:22:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05401 for ; Sun, 27 Feb 2005 16:21:54 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5Vs2-0006BV-1l for rtg-bfd@ietf.org; Sun, 27 Feb 2005 16:22:34 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j1RLLhi09389 for ; Sun, 27 Feb 2005 16:21:44 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1JJLSV4Y>; Sun, 27 Feb 2005 16:21:44 -0500 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE03192DA0@zcarhxm2.corp.nortel.com> From: "David Allan" To: "'David Ward'" , zhaisuping Date: Sun, 27 Feb 2005 16:21:39 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: rtg-bfd@ietf.org Subject: RE: Re: draft-suping-bfd-mpls-fecmismatch-00 questions 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 It is not detecting a control plane failure, it is detecting inconsistencies in forwarding such that synch between control and data plane has been lost.. connectivity to somewhere exists but is not necessarily correct...IMO that is still a data plane problem... Dave > -----Original Message----- > From: rtg-bfd-bounces@ietf.org > [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of David Ward > Sent: Sunday, February 27, 2005 10:48 AM > To: zhaisuping > Cc: rtg-bfd@ietf.org > Subject: Re: Re: draft-suping-bfd-mpls-fecmismatch-00 questions > > > Unfort., what you write is 180 degrees opposite from the > charter of the BFD WG and the philosophy of how the protocol > is to function. BFD is not to check the consistency of the > forwarding and control plane. We do not want to > take this protocol into the realm of control plane failure > detection system (as there are many better protocols or > protocol machinery for that) but, focus on forwarding > failure detection that can send alarms, event notification, > diags, etc up the stack. > > > -DWard > > > > On Sat, Feb 26, 2005 at 09:41:49AM +0800, zhaisuping wrote: > > Hi, all > > The purpose of FEC filter in BFD is to detect the consistence of > > the control plane and data plane. So that in the MPLS network, just > > running the BFD session(LSP-Ping is not needed) is enough for the > > defect detection. Or else such tools as LSP-Ping is needed because > > the BFD session can't detect the inconsistence of the control plane > > and data plane. > > In the section 2 of the draft, there is description of the > > problem the draft want to solve. > > >> Wouldn't LSP-Ping (or VCCV) be a more appropriate place > to do this > > >> filter verification? > > > > > > > > > >LSP-Ping does a verification on the FEC itself, so a > filter would add > > >nothing. > > > > > >VCCV is not a protocol. Just a little sideband for sending IP > > >packets down a pseudowire so that you can run LSP-Ping, BFD, etc. > > >between the two ends. > > > > > >....George > > > > > > >============================================================= > =========== > > >George Swallow Cisco Systems > (978) 936-1398 > > > 1414 Massachusetts Avenue > > > Boxborough, MA 01719 > > > From rtg-bfd-bounces@ietf.org Sun Feb 27 17:28:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09386; Sun, 27 Feb 2005 17:28:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5Wuc-0007D2-N9; Sun, 27 Feb 2005 17:29:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Wt6-0000Et-Os; Sun, 27 Feb 2005 17:27:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Wt4-0000Eh-Fs for rtg-bfd@megatron.ietf.org; Sun, 27 Feb 2005 17:27:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09337 for ; Sun, 27 Feb 2005 17:27:40 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5Wth-0007CM-4Q for rtg-bfd@ietf.org; Sun, 27 Feb 2005 17:28:21 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 27 Feb 2005 15:42:53 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,120,1107734400"; d="scan'208"; a="229768679:sNHT21097912" Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1RMRPuC015398; Sun, 27 Feb 2005 14:27:25 -0800 (PST) Received: (from wardd@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA16674; Sun, 27 Feb 2005 16:27:26 -0600 (CST) Date: Sun, 27 Feb 2005 16:27:26 -0600 From: David Ward To: David Allan Message-ID: <20050227162726.U23756@cfcentral.cisco.com> References: <87AC5F88F03E6249AEA68D40BD3E00BE03192DA0@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BE03192DA0@zcarhxm2.corp.nortel.com>; from dallan@nortel.com on Sun, Feb 27, 2005 at 04:21:39PM -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: rtg-bfd@ietf.org, "'David Ward'" Subject: Re: Re: draft-suping-bfd-mpls-fecmismatch-00 questions 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 David - In these cases, it would be best if the violating node sent the proper diag code and said that their forwarding plane was insane. We don't want this protocol resonsbile for checking up to 4B FIB entries to see if they are installed correctly. To take this to a logical end, we would have to check all addrs in all AF/SAF and all potential mismatches. The node itself has to take some responsiblity when possible. When it is not possible, e.g. GR, BFD can help detect some failures. If this problem is as we seem to agree a control plane programming issue, an OAM protocol seems more applicable at config time. -DWard On Sun, Feb 27, 2005 at 04:21:39PM -0500, David Allan wrote: > It is not detecting a control plane failure, it is detecting inconsistencies > in forwarding such that synch between control and data plane has been lost.. > connectivity to somewhere exists but is not necessarily correct...IMO that > is still a data plane problem... > > Dave > > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org > > [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of David Ward > > Sent: Sunday, February 27, 2005 10:48 AM > > To: zhaisuping > > Cc: rtg-bfd@ietf.org > > Subject: Re: Re: draft-suping-bfd-mpls-fecmismatch-00 questions > > > > > > Unfort., what you write is 180 degrees opposite from the > > charter of the BFD WG and the philosophy of how the protocol > > is to function. BFD is not to check the consistency of the > > forwarding and control plane. We do not want to > > take this protocol into the realm of control plane failure > > detection system (as there are many better protocols or > > protocol machinery for that) but, focus on forwarding > > failure detection that can send alarms, event notification, > > diags, etc up the stack. > > > > > > -DWard > > > > > > > > On Sat, Feb 26, 2005 at 09:41:49AM +0800, zhaisuping wrote: > > > Hi, all > > > The purpose of FEC filter in BFD is to detect the consistence of > > > the control plane and data plane. So that in the MPLS network, just > > > running the BFD session(LSP-Ping is not needed) is enough for the > > > defect detection. Or else such tools as LSP-Ping is needed because > > > the BFD session can't detect the inconsistence of the control plane > > > and data plane. > > > In the section 2 of the draft, there is description of the > > > problem the draft want to solve. > > > >> Wouldn't LSP-Ping (or VCCV) be a more appropriate place > > to do this > > > >> filter verification? > > > > > > > > > > > > > >LSP-Ping does a verification on the FEC itself, so a > > filter would add > > > >nothing. > > > > > > > >VCCV is not a protocol. Just a little sideband for sending IP > > > >packets down a pseudowire so that you can run LSP-Ping, BFD, etc. > > > >between the two ends. > > > > > > > >....George > > > > > > > > > >============================================================= > > =========== > > > >George Swallow Cisco Systems > > (978) 936-1398 > > > > 1414 Massachusetts Avenue > > > > Boxborough, MA 01719 > > > > > > From rtg-bfd-bounces@ietf.org Mon Feb 28 00:11:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10657; Mon, 28 Feb 2005 00:11:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5dD1-0005cI-CG; Mon, 28 Feb 2005 00:12:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5dAM-0006AB-5s; Mon, 28 Feb 2005 00:09:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5dAK-0006A0-C4 for rtg-bfd@megatron.ietf.org; Mon, 28 Feb 2005 00:09:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10409 for ; Mon, 28 Feb 2005 00:09:53 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5dAz-0005aB-Jf for rtg-bfd@ietf.org; Mon, 28 Feb 2005 00:10:38 -0500 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 j1S59M912902; Sun, 27 Feb 2005 21:09:22 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j1S596e94232; Sun, 27 Feb 2005 21:09:06 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BE03192DA0@zcarhxm2.corp.nortel.com> References: <87AC5F88F03E6249AEA68D40BD3E00BE03192DA0@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <279a0de18203a2859504f1d68dd91a1e@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Sun, 27 Feb 2005 22:09:04 -0700 To: "David Allan" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org, "'David Ward'" Subject: Re: draft-suping-bfd-mpls-fecmismatch-00 questions 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit For what it's worth, we made a very conscious decision to keep media-specific information out of BFD, and so far at least have been successful. The intent of BFD is to provide a pure liveness mechanism, which can operate at a very wide range of time constants, and is independent of media- and application-specific state and configuration management functions (which are typically intertwined, e.g., IGP Hellos.) BFD is intended to run along side the media-specific protocols, given that BFD has no discovery mechanism, and depends on such protocols (or, perish the thought, static configuration.) Further, most media-specific functions can either be made event-driven, or operate in a different magnitude of time than BFD, and as such are not appropriate to be carried in every packet, perhaps many times per second. --Dave From rtg-bfd-bounces@ietf.org Mon Feb 28 03:36:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18900; Mon, 28 Feb 2005 03:36:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5gOy-0000nz-BY; Mon, 28 Feb 2005 03:37:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5gL3-0007V8-40; Mon, 28 Feb 2005 03:33:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5gKl-0007Tp-9M for rtg-bfd@megatron.ietf.org; Mon, 28 Feb 2005 03:32:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18606 for ; Mon, 28 Feb 2005 03:32:53 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5gLQ-0000jI-Ok for rtg-bfd@ietf.org; Mon, 28 Feb 2005 03:33:38 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICM009WF51J1Q@szxga01-in.huawei.com> for rtg-bfd@ietf.org; Mon, 28 Feb 2005 16:32:08 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICM00AR751JHH@szxga01-in.huawei.com> for rtg-bfd@ietf.org; Mon, 28 Feb 2005 16:32:07 +0800 (CST) Received: from z11024 ([10.110.49.48]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ICM00AIQ52OH4@szxml02-in.huawei.com> for rtg-bfd@ietf.org; Mon, 28 Feb 2005 16:32:49 +0800 (CST) Date: Mon, 28 Feb 2005 16:32:45 +0800 From: zhaisuping To: "rtg-bfd@ietf.org" Message-id: <0ICM00AIV52PH4@szxml02-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Subject: help about the BIP16 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhaisuping@huawei.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Hi, all, I want to implement the BIP16 of Y.1711, who can give me a= example implementation of the BIP16? thank you in= advance.=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1 Best Regards, zhaisuping@huawei.com Huawei Technologies Co., Ltd. Tel: +86-10-82882695 Fax: +86-10-82882537 2005-02-28 From rtg-bfd-bounces@ietf.org Mon Feb 28 15:48:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05981; Mon, 28 Feb 2005 15:48:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rpd-0000HW-Ms; Mon, 28 Feb 2005 15:49:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rmJ-0004z3-7b; Mon, 28 Feb 2005 15:46:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rmG-0004yT-Bq for rtg-bfd@megatron.ietf.org; Mon, 28 Feb 2005 15:46:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05463 for ; Mon, 28 Feb 2005 15:46:02 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rn1-00005x-3V for rtg-bfd@ietf.org; Mon, 28 Feb 2005 15:46:54 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j1SKjiY24810 for ; Mon, 28 Feb 2005 15:45:44 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1JJLTKKX>; Mon, 28 Feb 2005 15:45:45 -0500 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE03192DA6@zcarhxm2.corp.nortel.com> From: "David Allan" To: "'David Ward'" Date: Mon, 28 Feb 2005 15:45:36 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: rtg-bfd@ietf.org Subject: RE: Re: draft-suping-bfd-mpls-fecmismatch-00 questions 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 HI Dave: > In these cases, it would be best if the violating node sent the > proper diag code and said that their forwarding plane was > insane. We would not need a means of detecting it if the node simply knew ;-) > We don't want this protocol resonsbile for checking > up to 4B FIB entries ???? not understanding the reqirement > to see if they > are installed correctly. To take this to a logical end, we > would have to check all addrs in all AF/SAF and all potential > mismatches. The node itself has to take some responsiblity > when possible. When it is not possible, e.g. > GR, BFD can help detect some failures. The suggestion is to check that the FEC associated with an LSP running BFD via an additional token...the concern being primarily corruption of forwarding at intermediate nodes... IMO not needed if we are discussing a p2p PHY link, as misdirection to a different BFD termination and collisions in the dsicriminator space are highly unlikely. Question is how often can you be sure when all is said and done, it truly was just a PHY... rgds Dave > > If this problem is as we seem to agree a control plane > programming issue, an OAM protocol seems more applicable at > config time. > > -DWard > > On Sun, Feb 27, 2005 at 04:21:39PM -0500, David Allan wrote: > > It is not detecting a control plane failure, it is detecting > > inconsistencies in forwarding such that synch between > control and data > > plane has been lost.. connectivity to somewhere exists but is not > > necessarily correct...IMO that is still a data plane problem... > > > > Dave > > > > > -----Original Message----- > > > From: rtg-bfd-bounces@ietf.org > > > [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of David Ward > > > Sent: Sunday, February 27, 2005 10:48 AM > > > To: zhaisuping > > > Cc: rtg-bfd@ietf.org > > > Subject: Re: Re: draft-suping-bfd-mpls-fecmismatch-00 questions > > > > > > > > > Unfort., what you write is 180 degrees opposite from the > > > charter of the BFD WG and the philosophy of how the protocol > > > is to function. BFD is not to check the consistency of the > > > forwarding and control plane. We do not want to > > > take this protocol into the realm of control plane failure > > > detection system (as there are many better protocols or > > > protocol machinery for that) but, focus on forwarding > > > failure detection that can send alarms, event notification, > > > diags, etc up the stack. > > > > > > > > > -DWard > > > > > > > > > > > > On Sat, Feb 26, 2005 at 09:41:49AM +0800, zhaisuping wrote: > > > > Hi, all > > > > The purpose of FEC filter in BFD is to detect the > consistence of > > > > the control plane and data plane. So that in the MPLS network, > > > > just running the BFD session(LSP-Ping is not needed) is > enough for > > > > the defect detection. Or else such tools as LSP-Ping is needed > > > > because the BFD session can't detect the inconsistence of the > > > > control plane and data plane. In the section 2 of the > draft, there > > > > is description of the problem the draft want to solve. > > > > >> Wouldn't LSP-Ping (or VCCV) be a more appropriate place > > > to do this > > > > >> filter verification? > > > > > > > > > > > > > > > > > >LSP-Ping does a verification on the FEC itself, so a > > > filter would add > > > > >nothing. > > > > > > > > > >VCCV is not a protocol. Just a little sideband for sending IP > > > > >packets down a pseudowire so that you can run > LSP-Ping, BFD, etc. > > > > >between the two ends. > > > > > > > > > >....George > > > > > > > > > > > > >============================================================= > > > =========== > > > > >George Swallow Cisco Systems > > > (978) 936-1398 > > > > > 1414 Massachusetts Avenue > > > > > Boxborough, MA 01719 > > > > > > > > > > > From rtg-bfd-bounces@ietf.org Mon Feb 28 15:54:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06501; Mon, 28 Feb 2005 15:54:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rur-0000RE-O9; Mon, 28 Feb 2005 15:54:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rtg-0000NA-54; Mon, 28 Feb 2005 15:53:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rte-0000LX-Fl for rtg-bfd@megatron.ietf.org; Mon, 28 Feb 2005 15:53:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06423 for ; Mon, 28 Feb 2005 15:53:40 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5ruS-0000Pa-R1 for rtg-bfd@ietf.org; Mon, 28 Feb 2005 15:54:33 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 28 Feb 2005 14:07:58 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,124,1107734400"; d="scan'208"; a="230093204:sNHT4397892602" Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1SKqOZV025859; Mon, 28 Feb 2005 12:52:25 -0800 (PST) Received: (from wardd@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA24330; Mon, 28 Feb 2005 14:52:24 -0600 (CST) Date: Mon, 28 Feb 2005 14:52:24 -0600 From: David Ward To: David Allan Message-ID: <20050228145224.J21093@cfcentral.cisco.com> References: <87AC5F88F03E6249AEA68D40BD3E00BE03192DA6@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BE03192DA6@zcarhxm2.corp.nortel.com>; from dallan@nortel.com on Mon, Feb 28, 2005 at 03:45:36PM -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: rtg-bfd@ietf.org, "'David Ward'" Subject: Re: Re: draft-suping-bfd-mpls-fecmismatch-00 questions 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 David - On Mon, Feb 28, 2005 at 03:45:36PM -0500, David Allan wrote: > HI Dave: > > > In these cases, it would be best if the violating node sent the > > proper diag code and said that their forwarding plane was > > insane. > > We would not need a means of detecting it if the node simply knew ;-) > Since this is config time, the device can check vs assuming that neighboring nodes will bail it out. If you don't trust your neighbor in the network to program the FEC or anything into it's FIB correctly; BFD isn't going to be able to help. > > > We don't want this protocol resonsbile for checking > > up to 4B FIB entries > > ???? not understanding the reqirement The logical end to the twisting of BFD's architecture is to have to check the validity of up to 4B IPv4 addrs (extend to V6, FEC, and anything else that can be programmed into a Forwarding Information Base). This is a very bad place to go. > > > to see if they > > are installed correctly. To take this to a logical end, we > > would have to check all addrs in all AF/SAF and all potential > > mismatches. The node itself has to take some responsiblity > > when possible. When it is not possible, e.g. > > GR, BFD can help detect some failures. > > The suggestion is to check that the FEC associated with an LSP running BFD > via an additional token...the concern being primarily corruption of This I understand > forwarding at intermediate nodes... IMO not needed if we are discussing a > p2p PHY link, as misdirection to a different BFD termination and collisions > in the dsicriminator space are highly unlikely. Question is how often can > you be sure when all is said and done, it truly was just a PHY... BFD won't be able to tell you what is actually broken. OAM thingies do this. -DWard > > rgds > Dave > > > > > If this problem is as we seem to agree a control plane > > programming issue, an OAM protocol seems more applicable at > > config time. > > > > -DWard > > > > On Sun, Feb 27, 2005 at 04:21:39PM -0500, David Allan wrote: > > > It is not detecting a control plane failure, it is detecting > > > inconsistencies in forwarding such that synch between > > control and data > > > plane has been lost.. connectivity to somewhere exists but is not > > > necessarily correct...IMO that is still a data plane problem... > > > > > > Dave > > > > > > > -----Original Message----- > > > > From: rtg-bfd-bounces@ietf.org > > > > [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of David Ward > > > > Sent: Sunday, February 27, 2005 10:48 AM > > > > To: zhaisuping > > > > Cc: rtg-bfd@ietf.org > > > > Subject: Re: Re: draft-suping-bfd-mpls-fecmismatch-00 questions > > > > > > > > > > > > Unfort., what you write is 180 degrees opposite from the > > > > charter of the BFD WG and the philosophy of how the protocol > > > > is to function. BFD is not to check the consistency of the > > > > forwarding and control plane. We do not want to > > > > take this protocol into the realm of control plane failure > > > > detection system (as there are many better protocols or > > > > protocol machinery for that) but, focus on forwarding > > > > failure detection that can send alarms, event notification, > > > > diags, etc up the stack. > > > > > > > > > > > > -DWard > > > > > > > > > > > > > > > > On Sat, Feb 26, 2005 at 09:41:49AM +0800, zhaisuping wrote: > > > > > Hi, all > > > > > The purpose of FEC filter in BFD is to detect the > > consistence of > > > > > the control plane and data plane. So that in the MPLS network, > > > > > just running the BFD session(LSP-Ping is not needed) is > > enough for > > > > > the defect detection. Or else such tools as LSP-Ping is needed > > > > > because the BFD session can't detect the inconsistence of the > > > > > control plane and data plane. In the section 2 of the > > draft, there > > > > > is description of the problem the draft want to solve. > > > > > >> Wouldn't LSP-Ping (or VCCV) be a more appropriate place > > > > to do this > > > > > >> filter verification? > > > > > > > > > > > > > > > > > > > > > >LSP-Ping does a verification on the FEC itself, so a > > > > filter would add > > > > > >nothing. > > > > > > > > > > > >VCCV is not a protocol. Just a little sideband for sending IP > > > > > >packets down a pseudowire so that you can run > > LSP-Ping, BFD, etc. > > > > > >between the two ends. > > > > > > > > > > > >....George > > > > > > > > > > > > > > > >============================================================= > > > > =========== > > > > > >George Swallow Cisco Systems > > > > (978) 936-1398 > > > > > > 1414 Massachusetts Avenue > > > > > > Boxborough, MA 01719 > > > > > > > > > > > > > > > > From rtg-bfd-bounces@ietf.org Mon Feb 28 15:59:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06967; Mon, 28 Feb 2005 15:59:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rze-0000XJ-MC; Mon, 28 Feb 2005 15:59:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rxW-0002Uh-P5; Mon, 28 Feb 2005 15:57:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rxV-0002Uc-Pl for rtg-bfd@megatron.ietf.org; Mon, 28 Feb 2005 15:57:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06902 for ; Mon, 28 Feb 2005 15:57:39 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5ryJ-0000Vs-7V for rtg-bfd@ietf.org; Mon, 28 Feb 2005 15:58:32 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j1SKvSB29800 for ; Mon, 28 Feb 2005 15:57:28 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1JJLTKXC>; Mon, 28 Feb 2005 15:57:28 -0500 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE03192DA7@zcarhxm2.corp.nortel.com> From: "David Allan" To: "'David Ward'" Date: Mon, 28 Feb 2005 15:57:18 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: rtg-bfd@ietf.org Subject: RE: Re: draft-suping-bfd-mpls-fecmismatch-00 questions 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 > > > forwarding at intermediate nodes... IMO not needed if we are > > discussing a p2p PHY link, as misdirection to a different BFD > > termination and collisions in the dsicriminator space are highly > > unlikely. Question is how often can you be sure when all is > said and > > done, it truly was just a PHY... > > BFD won't be able to tell you what is actually broken. OAM > thingies do this. Agreed, goal is to simply know so you can follow up... > > -DWard > > > > > rgds > > Dave > > > > > > > > If this problem is as we seem to agree a control plane > > > programming issue, an OAM protocol seems more applicable at > > > config time. > > > > > > -DWard > > > > > > On Sun, Feb 27, 2005 at 04:21:39PM -0500, David Allan wrote: > > > > It is not detecting a control plane failure, it is detecting > > > > inconsistencies in forwarding such that synch between > > > control and data > > > > plane has been lost.. connectivity to somewhere exists > but is not > > > > necessarily correct...IMO that is still a data plane problem... > > > > > > > > Dave > > > > > > > > > -----Original Message----- > > > > > From: rtg-bfd-bounces@ietf.org > [mailto:rtg-bfd-bounces@ietf.org] > > > > > On Behalf Of David Ward > > > > > Sent: Sunday, February 27, 2005 10:48 AM > > > > > To: zhaisuping > > > > > Cc: rtg-bfd@ietf.org > > > > > Subject: Re: Re: draft-suping-bfd-mpls-fecmismatch-00 > questions > > > > > > > > > > > > > > > Unfort., what you write is 180 degrees opposite from > the charter > > > > > of the BFD WG and the philosophy of how the protocol is to > > > > > function. BFD is not to check the consistency of the > forwarding > > > > > and control plane. We do not want to take this > protocol into the > > > > > realm of control plane failure detection system (as there are > > > > > many better protocols or protocol machinery for that) but, > > > > > focus on forwarding failure detection that can send alarms, > > > > > event notification, diags, etc up the stack. > > > > > > > > > > > > > > > -DWard > > > > > > > > > > > > > > > > > > > > On Sat, Feb 26, 2005 at 09:41:49AM +0800, zhaisuping wrote: > > > > > > Hi, all > > > > > > The purpose of FEC filter in BFD is to detect the > > > consistence of > > > > > > the control plane and data plane. So that in the > MPLS network, > > > > > > just running the BFD session(LSP-Ping is not needed) is > > > enough for > > > > > > the defect detection. Or else such tools as > LSP-Ping is needed > > > > > > because the BFD session can't detect the > inconsistence of the > > > > > > control plane and data plane. In the section 2 of the > > > draft, there > > > > > > is description of the problem the draft want to solve. > > > > > > >> Wouldn't LSP-Ping (or VCCV) be a more appropriate place > > > > > to do this > > > > > > >> filter verification? > > > > > > > > > > > > > > > > > > > > > > > > > >LSP-Ping does a verification on the FEC itself, so a > > > > > filter would add > > > > > > >nothing. > > > > > > > > > > > > > >VCCV is not a protocol. Just a little sideband > for sending > > > > > > >IP packets down a pseudowire so that you can run > > > LSP-Ping, BFD, etc. > > > > > > >between the two ends. > > > > > > > > > > > > > >....George > > > > > > > > > > > > > > > > > > >============================================================= > > > > > =========== > > > > > > >George Swallow Cisco Systems > > > > > (978) 936-1398 > > > > > > > 1414 Massachusetts Avenue > > > > > > > Boxborough, MA 01719 > > > > > > > > > > > > > > > > > > > > > > > From rtg-bfd-bounces@ietf.org Mon Feb 28 16:09:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07980; Mon, 28 Feb 2005 16:09:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5s9X-0000u9-Ax; Mon, 28 Feb 2005 16:10:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5s4k-0004me-OG; Mon, 28 Feb 2005 16:05:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5s4k-0004mZ-0V for rtg-bfd@megatron.ietf.org; Mon, 28 Feb 2005 16:05:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07528 for ; Mon, 28 Feb 2005 16:05:08 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5s5X-0000oB-Hr for rtg-bfd@ietf.org; Mon, 28 Feb 2005 16:06:00 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 48D202D49E2; Mon, 28 Feb 2005 16:01:01 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 42635-01-30; Mon, 28 Feb 2005 16:01:00 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 07A122D4990; Mon, 28 Feb 2005 16:01:00 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j1SL0xS23536; Mon, 28 Feb 2005 16:00:59 -0500 (EST) Date: Mon, 28 Feb 2005 16:00:59 -0500 From: Jeffrey Haas To: David Allan Message-ID: <20050228210059.GH3743@nexthop.com> References: <87AC5F88F03E6249AEA68D40BD3E00BE03192DA7@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BE03192DA7@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: rtg-bfd@ietf.org, "'David Ward'" Subject: Re: Re: draft-suping-bfd-mpls-fecmismatch-00 questions 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Mon, Feb 28, 2005 at 03:57:18PM -0500, David Allan wrote: > > BFD won't be able to tell you what is actually broken. OAM > > thingies do this. > > Agreed, goal is to simply know so you can follow up... Then wouldn't it be best to BFD for what it is good at, namely checking that forwarding is working, and then use another mechanism to clean house when something fails? By analogy, one doesn't extend ICMP to check your interface configuration because you want to add this to your ping. (Then again, seeing such a thing proposed in the IPv6 working groups wouldn't shock me at all. :-) -- Jeff Haas NextHop Technologies From rtg-bfd-bounces@ietf.org Mon Feb 28 16:53:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12087; Mon, 28 Feb 2005 16:53:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5sqj-0001m7-0C; Mon, 28 Feb 2005 16:54:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5snb-00084u-Qf; Mon, 28 Feb 2005 16:51:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5snY-00084k-Pd for rtg-bfd@megatron.ietf.org; Mon, 28 Feb 2005 16:51:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11898 for ; Mon, 28 Feb 2005 16:51:26 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5soL-0001jw-RV for rtg-bfd@ietf.org; Mon, 28 Feb 2005 16:52:20 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 28 Feb 2005 14:05:08 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,125,1107763200"; d="scan'208"; a="617000540:sNHT21898948" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1SLpAq8016029; Mon, 28 Feb 2005 13:51:10 -0800 (PST) Received: from [10.83.15.56] (rtp-tnadeau-vpn7.cisco.com [10.83.15.56]) by flask.cisco.com (MOS 3.4.6-GR) with SMTP id APL40856; Mon, 28 Feb 2005 16:51:12 -0500 (EST) In-Reply-To: <20050228210059.GH3743@nexthop.com> References: <87AC5F88F03E6249AEA68D40BD3E00BE03192DA7@zcarhxm2.corp.nortel.com> <20050228210059.GH3743@nexthop.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3454d16e68a567be1090ccc531124b47@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Mon, 28 Feb 2005 16:51:10 -0500 To: Jeffrey Haas X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org, "'David Ward'" Subject: Re: draft-suping-bfd-mpls-fecmismatch-00 questions 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: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit On Feb 28, 2005, at 4:00 PM, Jeffrey Haas wrote: > On Mon, Feb 28, 2005 at 03:57:18PM -0500, David Allan wrote: >>> BFD won't be able to tell you what is actually broken. OAM >>> thingies do this. >> >> Agreed, goal is to simply know so you can follow up... > > Then wouldn't it be best to BFD for what it is good at, namely checking > that forwarding is working, and then use another mechanism to clean > house when something fails? I explained in my first posting on this draft that there already exist mechanisms that can be used to confirm the consistency of the sessions. There is no need for another mechanism, IMO. --Tom > > By analogy, one doesn't extend ICMP to check your interface > configuration > because you want to add this to your ping. > > (Then again, seeing such a thing proposed in the IPv6 working groups > wouldn't shock me at all. :-) > > > -- > Jeff Haas > NextHop Technologies >