From rtg-bfd-bounces@ietf.org Mon Apr 02 10:02:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYN6H-0004qI-28; Mon, 02 Apr 2007 10:01:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYN6G-0004qD-75 for rtg-bfd@ietf.org; Mon, 02 Apr 2007 10:01:36 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYN6D-0003GL-Nv for rtg-bfd@ietf.org; Mon, 02 Apr 2007 10:01:36 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Apr 2007 10:01:33 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l32E1X6A015323; Mon, 2 Apr 2007 10:01:33 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l32E1WGv023521; Mon, 2 Apr 2007 14:01:33 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 10:01:25 -0400 Received: from [10.83.15.52] ([10.83.15.52]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 10:01:24 -0400 In-Reply-To: References: <3D93D8A8-F2CD-4F5D-BA37-5A2489E2C3DA@cisco.com> <29C50044-05B4-412E-B0D8-4B1B6F38672F@juniper.net> <448453AC-AAC4-4924-8BF2-87AC85907252@juniper.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5B807F72-EEB9-4D11-91E3-4798187CAABB@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Mon, 2 Apr 2007 10:01:18 -0400 To: Naiming Shen X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 14:01:24.0639 (UTC) FILETIME=[6677D2F0:01C7752F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8148; t=1175522493; x=1176386493; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=20=22Thomas=20D.=20Nadeau=22=20 |Subject:=20Re=3A=20I-D=20ACTION=3Adraft-shen-bfd-intf-p2p-nbr-00.txt=20 |Sender:=20 |To:=20Naiming=20Shen=20; bh=7FYuzbgVIp12pjDWlVyYnVRFdvA2Fxdm0CAsRCTpay4=; b=Ktj/idHR/2f6rOpj5xKbHEqPF8ENBHU5kRJDB7Ep+H07Rq1wd9dD9qZQweGTXefDPwZDDm94 5lMxzkj3ciOwzdjHopzM8pEvWnzLNVolL2cvLkAn0b41wonoOf+ct0Kv; Authentication-Results: rtp-dkim-2; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: rtg-bfd@ietf.org, Dave Katz Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-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: , Errors-To: rtg-bfd-bounces@ietf.org On Mar 30, 2007:9:29 PM, at 9:29 PM, Naiming Shen wrote: > > On Mar 30, 2007, at 5:52 PM, Dave Katz wrote: > >> >> On Mar 30, 2007, at 4:01 PM, Naiming Shen wrote: >> >>>> >>>> But secondly, there is a self-referential problem. What you'd >>>> *really* like to do on a BFD failure is to take down the failing >>>> protocol and keep it down until the BFD session resumes. But >>>> you can't do this if BFD is running on top of that failing >>>> protocol (which it will be) which thus requires the "special >>>> flag" hack and only temporarily taking down the protocol. The >>>> fate-sharing implications of this are more serious, because it >>>> is possible to get false positives in some cases when the data >>>> protocol has failed. Imagine, for example, running ISIS with >>>> this method. If IPv4 fails, the BFD session goes down, the >>>> interface flaps for five seconds, and then is reenabled. At >>>> that point ISIS will happily come back up and report IP >>>> reachability even though it doesn't exist. You can bet that >>>> folks who have not yet implemented BFD will be tempted to do this. >>> >>> >>> If you are talking about sharing fate between ipv4 bfd and ISIS >>> is a problem, then I agree, >>> this scheme is only meant for sharing fate among protocols, it >>> should not be used >>> if this assumption is not true. But using ISIS to carry IP >>> information itself is violating this >>> principle;-) don't know who to blame, although it's not a BFD issue. >> >> I guess my point is that you need to be very explicit about what >> works and what doesn't. It's certainly the case that, without the >> presence of BFD, ISIS will do Bad Things if IP forwarding breaks, >> since it will continue to advertise IP connectivity. But the >> whole point of BFD is to sense data protocol connectivity and >> provide that (presumably useful) information to other parts of a >> system. If BFD is providing information directly to ISIS, it can >> withdraw IP connectivity (or tear down the adjacency if need be) >> and keep it that way until connectivity is restored. If ISIS >> relied on this scheme, and IP connectivity failed (but datalink >> connectivity remained), the ISIS adjacency would flap, and then >> ISIS would proceed to black hole traffic. > > Even in the normal BFD interacting with ISIS(for ipv4), I would > think it can also do this > black holing. Since ipv4 bfd session is flapping, and datalink > layer is fine, and ISIS > packets is going through ok, hellos are happy. ISIS will bring up > the adjacency, and > then register with bfd, and bfd later failed again, which will > bring down the ISIS session. > I fail to see the difference between the two schemes. A simple example of how this can be broken is that if you consider a distributed router, where you run ISIS on the routing processor, and BFD on specialized hardware down on a line card. While the line card's hardware could continue to send/receive BFD packets, the ISIS process on the RP could crash or get wedged, and cause it to ignore routing updates. If the routing protocol timers are sufficiently high (usually on the order of minutes or even hours), then no one will know until this timer goes off. > >> I think you need to specifically disallow this mechanism for cases >> like this, namely, applications that will continue to run even >> with the failure of a data protocol, but whose correct operation >> requires that data protocol. (Note that this sentence describes >> both ISIS and static routes.) >> >> OSPFv3 is another interesting example if you're running BFD in >> this configuration only over IPv4. If there is a v4 failure, >> OSPFv3 will flap unnecessarily. This gets back to the IPv4 == >> everything fate sharing that is at the heart of the way you've >> specified it, and which I think is an unnecessary restriction. A >> number of systems (including the one I'm most familiar with these >> days) has an interface hierarchy that includes the data protocol. >> Such systems are likely better served by having, say, separate v4 >> and v6 BFD sessions and flapping the appropriate data protocol up/ >> down status in the face of a BFD session failure. This would >> allow the OSPFv3 case to run unmolested when v4 died. I would >> suggest to at least offer this up as a MAY when you discuss the >> fate sharing implications of this mechanism, since it should be >> essentially no more work to implement if the system is already >> built this way. > > Sure. There can be an configuration option for bring down the whole > thing or bring > down the data protocol part if the platform supports that. > > Even though from architecture wise, the separation of bfds is > clean, ipv4 controls the > ipv4 protocols and ipv6 controls the ipv6 protocols. there are > still much to be desired > from implementation point of angle. On many routers BFD packets > going out not really > through the exact data packets forwarding path or the packets are > sent out from the > same software process, be it v6 or v6. So the argument of data > separation is rather > mood. And I'm yet to see a case BFD session down is actually caused > by the layer 3 > lookup engine which is only responsible for ipv4;-) I would rather > do the re-route > altogether though if we know one of the data plane is already in > trouble. Right. Just look at the example I gave above. Even if you run the ISIS process on the line card's CPU, if BFD is run in special LC hardware outside of the CPU, that constitutes two disjoint forwarding IP stacks; BFD will only be testing its own. > >> >>>> >>>> In light of this, my preference would be for all of the verbiage >>>> about static routes and dynamic protocols and special fiags to >>>> be removed. In place of this, add text that is very specific >>>> about the fate-sharing implications of this mechanism as >>>> outlined above, and point out that any application of BFD that >>>> does not automatically share fate with the data protocol over >>>> which BFD is running (such as ISIS or static routes) MUST have >>>> some form of explicit interaction with BFD in order to avoid >>>> false positives, and leave it at that. The "special bit" hack >>>> is orthogonal to this mechanism; it could just as well have >>>> been specified in the generic spec (and would have been just as >>>> inappropriate there.) >>> >>> I think the dynamic and static difference still needs to be >>> mentioned, although should not >>> be directly linked with a 'special flag' for the static routing. >> >> But I think the "difference" here is fundamental--as soon as you >> have any special case communication between BFD and a part of the >> system, you've basically discarded the point of the draft (if I >> understand it) which is to be able to leverage BFD without >> changing your "clients" to specifically use it. What you're >> specifying here is functionally *exactly* the same as what the >> generic spec talks about for static routes and other non-protocol >> applications, and only muddies the spec, IMHO. > > only the UP->Down portion is different between the two schemes. the > rest is the same. > but the bring down itself is different from the point of dynamic or > static. > >> >> Why not just say that this mechanism only provides a way of more >> rapidly taking down applications that would otherwise go down >> eventually and which will stay down on their own until the path is >> healed (namely, control protocols), and leave statics out of it >> altogether? > > Maybe you have a point. I'll think about that. I agree with Katz here. The point of this draft should be to suggest that this approach AUGMENT the normal routing hellos, as well as existing ifUp/Down mechanisms inside your box. --Tom > > thanks. > - Naiming > >> >> >> --Dave From rtg-bfd-bounces@ietf.org Mon Apr 02 13:14:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQ71-00081O-FY; Mon, 02 Apr 2007 13:14:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQ70-00080x-T1 for rtg-bfd@ietf.org; Mon, 02 Apr 2007 13:14:34 -0400 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.43) id 1HYQ6z-00021V-6H for rtg-bfd@ietf.org; Mon, 02 Apr 2007 13:14:34 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2007 10:14:33 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l32HEWDF011498; Mon, 2 Apr 2007 10:14:32 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l32HENZh002350; Mon, 2 Apr 2007 17:14:32 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 10:14:30 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 10:14:29 -0700 In-Reply-To: <5B807F72-EEB9-4D11-91E3-4798187CAABB@cisco.com> References: <3D93D8A8-F2CD-4F5D-BA37-5A2489E2C3DA@cisco.com> <29C50044-05B4-412E-B0D8-4B1B6F38672F@juniper.net> <448453AC-AAC4-4924-8BF2-87AC85907252@juniper.net> <5B807F72-EEB9-4D11-91E3-4798187CAABB@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <078305F4-C44D-4853-8C96-23FF3E2338E2@cisco.com> Content-Transfer-Encoding: 7bit From: Naiming Shen Date: Mon, 2 Apr 2007 10:14:27 -0700 To: "Thomas D. Nadeau" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 17:14:29.0778 (UTC) FILETIME=[5FBFBF20:01C7754A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8932; t=1175534072; x=1176398072; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=naiming@cisco.com; z=From:=20Naiming=20Shen=20 |Subject:=20Re=3A=20I-D=20ACTION=3Adraft-shen-bfd-intf-p2p-nbr-00.txt=20 |Sender:=20; bh=Z88pGm6X33zucw0Kp0J7TL2azGybRFVnJCpez/4VqaE=; b=EeeGZgRcLezNAuGDqDxKGwAy520AxKRewStJXRLAGRzkLU/Wa5awiJot1my0jPdDjrszaRBc 1l1YzN9kWMPQSP2YgRAx2ybtFh8KHbqO7FrXclq9O53p8kaRf+tqFaLP; Authentication-Results: sj-dkim-3; header.From=naiming@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: rtg-bfd@ietf.org, Dave Katz Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-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: , Errors-To: rtg-bfd-bounces@ietf.org Thomas, On Apr 2, 2007, at 7:01 AM, Thomas D. Nadeau wrote: > > On Mar 30, 2007:9:29 PM, at 9:29 PM, Naiming Shen wrote: > >> >> On Mar 30, 2007, at 5:52 PM, Dave Katz wrote: >> >>> >>> On Mar 30, 2007, at 4:01 PM, Naiming Shen wrote: >>> >>>>> >>>>> But secondly, there is a self-referential problem. What you'd >>>>> *really* like to do on a BFD failure is to take down the >>>>> failing protocol and keep it down until the BFD session >>>>> resumes. But you can't do this if BFD is running on top of >>>>> that failing protocol (which it will be) which thus requires >>>>> the "special flag" hack and only temporarily taking down the >>>>> protocol. The fate-sharing implications of this are more >>>>> serious, because it is possible to get false positives in some >>>>> cases when the data protocol has failed. Imagine, for example, >>>>> running ISIS with this method. If IPv4 fails, the BFD session >>>>> goes down, the interface flaps for five seconds, and then is >>>>> reenabled. At that point ISIS will happily come back up and >>>>> report IP reachability even though it doesn't exist. You can >>>>> bet that folks who have not yet implemented BFD will be tempted >>>>> to do this. >>>> >>>> >>>> If you are talking about sharing fate between ipv4 bfd and ISIS >>>> is a problem, then I agree, >>>> this scheme is only meant for sharing fate among protocols, it >>>> should not be used >>>> if this assumption is not true. But using ISIS to carry IP >>>> information itself is violating this >>>> principle;-) don't know who to blame, although it's not a BFD >>>> issue. >>> >>> I guess my point is that you need to be very explicit about what >>> works and what doesn't. It's certainly the case that, without >>> the presence of BFD, ISIS will do Bad Things if IP forwarding >>> breaks, since it will continue to advertise IP connectivity. But >>> the whole point of BFD is to sense data protocol connectivity and >>> provide that (presumably useful) information to other parts of a >>> system. If BFD is providing information directly to ISIS, it can >>> withdraw IP connectivity (or tear down the adjacency if need be) >>> and keep it that way until connectivity is restored. If ISIS >>> relied on this scheme, and IP connectivity failed (but datalink >>> connectivity remained), the ISIS adjacency would flap, and then >>> ISIS would proceed to black hole traffic. >> >> Even in the normal BFD interacting with ISIS(for ipv4), I would >> think it can also do this >> black holing. Since ipv4 bfd session is flapping, and datalink >> layer is fine, and ISIS >> packets is going through ok, hellos are happy. ISIS will bring up >> the adjacency, and >> then register with bfd, and bfd later failed again, which will >> bring down the ISIS session. >> I fail to see the difference between the two schemes. > > A simple example of how this can be broken is that if you > consider a distributed router, where you run ISIS on the routing > processor, and BFD on specialized hardware down on a line card. > While the line card's hardware could continue to send/receive > BFD packets, the ISIS process on the RP could crash or get wedged, > and cause it to ignore routing updates. If the routing protocol > timers are sufficiently high (usually on the order of minutes or > even hours), then no one will know until this timer goes off. > >> >>> I think you need to specifically disallow this mechanism for >>> cases like this, namely, applications that will continue to run >>> even with the failure of a data protocol, but whose correct >>> operation requires that data protocol. (Note that this sentence >>> describes both ISIS and static routes.) >>> >>> OSPFv3 is another interesting example if you're running BFD in >>> this configuration only over IPv4. If there is a v4 failure, >>> OSPFv3 will flap unnecessarily. This gets back to the IPv4 == >>> everything fate sharing that is at the heart of the way you've >>> specified it, and which I think is an unnecessary restriction. A >>> number of systems (including the one I'm most familiar with these >>> days) has an interface hierarchy that includes the data >>> protocol. Such systems are likely better served by having, say, >>> separate v4 and v6 BFD sessions and flapping the appropriate data >>> protocol up/down status in the face of a BFD session failure. >>> This would allow the OSPFv3 case to run unmolested when v4 died. >>> I would suggest to at least offer this up as a MAY when you >>> discuss the fate sharing implications of this mechanism, since it >>> should be essentially no more work to implement if the system is >>> already built this way. >> >> Sure. There can be an configuration option for bring down the >> whole thing or bring >> down the data protocol part if the platform supports that. >> >> Even though from architecture wise, the separation of bfds is >> clean, ipv4 controls the >> ipv4 protocols and ipv6 controls the ipv6 protocols. there are >> still much to be desired >> from implementation point of angle. On many routers BFD packets >> going out not really >> through the exact data packets forwarding path or the packets are >> sent out from the >> same software process, be it v6 or v6. So the argument of data >> separation is rather >> mood. And I'm yet to see a case BFD session down is actually >> caused by the layer 3 >> lookup engine which is only responsible for ipv4;-) I would rather >> do the re-route >> altogether though if we know one of the data plane is already in >> trouble. > > Right. Just look at the example I gave above. Even if you run the > ISIS > process on the line card's CPU, if BFD is run in special LC > hardware outside > of the CPU, that constitutes two disjoint forwarding IP stacks; BFD > will only > be testing its own. > >> >>> >>>>> >>>>> In light of this, my preference would be for all of the >>>>> verbiage about static routes and dynamic protocols and special >>>>> fiags to be removed. In place of this, add text that is very >>>>> specific about the fate-sharing implications of this mechanism >>>>> as outlined above, and point out that any application of BFD >>>>> that does not automatically share fate with the data protocol >>>>> over which BFD is running (such as ISIS or static routes) MUST >>>>> have some form of explicit interaction with BFD in order to >>>>> avoid false positives, and leave it at that. The "special bit" >>>>> hack is orthogonal to this mechanism; it could just as well >>>>> have been specified in the generic spec (and would have been >>>>> just as inappropriate there.) >>>> >>>> I think the dynamic and static difference still needs to be >>>> mentioned, although should not >>>> be directly linked with a 'special flag' for the static routing. >>> >>> But I think the "difference" here is fundamental--as soon as you >>> have any special case communication between BFD and a part of the >>> system, you've basically discarded the point of the draft (if I >>> understand it) which is to be able to leverage BFD without >>> changing your "clients" to specifically use it. What you're >>> specifying here is functionally *exactly* the same as what the >>> generic spec talks about for static routes and other non-protocol >>> applications, and only muddies the spec, IMHO. >> >> only the UP->Down portion is different between the two schemes. >> the rest is the same. >> but the bring down itself is different from the point of dynamic >> or static. >> >>> >>> Why not just say that this mechanism only provides a way of more >>> rapidly taking down applications that would otherwise go down >>> eventually and which will stay down on their own until the path >>> is healed (namely, control protocols), and leave statics out of >>> it altogether? >> >> Maybe you have a point. I'll think about that. > > I agree with Katz here. The point of this draft should be to > suggest that > this approach AUGMENT the normal routing hellos, as well as > existing ifUp/Down > mechanisms inside your box. I agree the intf UP->Down signal is the key of this draft; but as I pointed out in the previous email, there is also an important difference in the bring-up stage in terms of non-protocol services, that the bfd session state is condensed into an intf-based indication, which is very easy for implementation. Since those services looking at the intf state anyway, to augment with tins intf- p2p bfd, is just simply a one-line diff to those services. thanks. - Naiming > > --Tom > > > >> >> thanks. >> - Naiming >> >>> >>> >>> --Dave > From rtg-bfd-bounces@ietf.org Mon Apr 02 13:22:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQEN-0007Ix-RB; Mon, 02 Apr 2007 13:22:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQEM-0007Ir-2s for rtg-bfd@ietf.org; Mon, 02 Apr 2007 13:22:10 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQEJ-0003L0-E4 for rtg-bfd@ietf.org; Mon, 02 Apr 2007 13:22:10 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2007 10:22:07 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l32HM6hp020257; Mon, 2 Apr 2007 10:22:06 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l32HM0wv012204; Mon, 2 Apr 2007 17:22:06 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 13:22:03 -0400 Received: from [10.83.15.52] ([10.83.15.52]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 13:22:03 -0400 In-Reply-To: <078305F4-C44D-4853-8C96-23FF3E2338E2@cisco.com> References: <3D93D8A8-F2CD-4F5D-BA37-5A2489E2C3DA@cisco.com> <29C50044-05B4-412E-B0D8-4B1B6F38672F@juniper.net> <448453AC-AAC4-4924-8BF2-87AC85907252@juniper.net> <5B807F72-EEB9-4D11-91E3-4798187CAABB@cisco.com> <078305F4-C44D-4853-8C96-23FF3E2338E2@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4528727A-E25E-4C47-9EEA-F996C61F4DD2@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Mon, 2 Apr 2007 13:21:58 -0400 To: Naiming Shen X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 17:22:03.0381 (UTC) FILETIME=[6E1E1250:01C7754B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9482; t=1175534526; x=1176398526; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=20=22Thomas=20D.=20Nadeau=22=20 |Subject:=20Re=3A=20I-D=20ACTION=3Adraft-shen-bfd-intf-p2p-nbr-00.txt=20 |Sender:=20; bh=oBRCZMTHhXUv5hiBchQW72FD6tPSSQLw2VLc20Cht/w=; b=PyXsq/I4lwrSy1B+Qj00S5s1G34Df3WiOL8ri5dIcjIf37ZaCSBsWcPGxsokIAyK/7Uqs3hs Ktu7m1715ouZhMdkYIZo4kjw4+HUfOfnnAbeBff2EcBQvVSa8ph++bqYKdBOckPA/R4qHKK1yQ TQiqDZN8LVTZcAvOmtm1EHkM4=; Authentication-Results: sj-dkim-1; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: rtg-bfd@ietf.org, Dave Katz Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-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: , Errors-To: rtg-bfd-bounces@ietf.org On Apr 2, 2007:1:14 PM, at 1:14 PM, Naiming Shen wrote: > Thomas, > > On Apr 2, 2007, at 7:01 AM, Thomas D. Nadeau wrote: > >> >> On Mar 30, 2007:9:29 PM, at 9:29 PM, Naiming Shen wrote: >> >>> >>> On Mar 30, 2007, at 5:52 PM, Dave Katz wrote: >>> >>>> >>>> On Mar 30, 2007, at 4:01 PM, Naiming Shen wrote: >>>> >>>>>> >>>>>> But secondly, there is a self-referential problem. What you'd >>>>>> *really* like to do on a BFD failure is to take down the >>>>>> failing protocol and keep it down until the BFD session >>>>>> resumes. But you can't do this if BFD is running on top of >>>>>> that failing protocol (which it will be) which thus requires >>>>>> the "special flag" hack and only temporarily taking down the >>>>>> protocol. The fate-sharing implications of this are more >>>>>> serious, because it is possible to get false positives in some >>>>>> cases when the data protocol has failed. Imagine, for >>>>>> example, running ISIS with this method. If IPv4 fails, the >>>>>> BFD session goes down, the interface flaps for five seconds, >>>>>> and then is reenabled. At that point ISIS will happily come >>>>>> back up and report IP reachability even though it doesn't >>>>>> exist. You can bet that folks who have not yet implemented >>>>>> BFD will be tempted to do this. >>>>> >>>>> >>>>> If you are talking about sharing fate between ipv4 bfd and ISIS >>>>> is a problem, then I agree, >>>>> this scheme is only meant for sharing fate among protocols, it >>>>> should not be used >>>>> if this assumption is not true. But using ISIS to carry IP >>>>> information itself is violating this >>>>> principle;-) don't know who to blame, although it's not a BFD >>>>> issue. >>>> >>>> I guess my point is that you need to be very explicit about what >>>> works and what doesn't. It's certainly the case that, without >>>> the presence of BFD, ISIS will do Bad Things if IP forwarding >>>> breaks, since it will continue to advertise IP connectivity. >>>> But the whole point of BFD is to sense data protocol >>>> connectivity and provide that (presumably useful) information to >>>> other parts of a system. If BFD is providing information >>>> directly to ISIS, it can withdraw IP connectivity (or tear down >>>> the adjacency if need be) and keep it that way until >>>> connectivity is restored. If ISIS relied on this scheme, and IP >>>> connectivity failed (but datalink connectivity remained), the >>>> ISIS adjacency would flap, and then ISIS would proceed to black >>>> hole traffic. >>> >>> Even in the normal BFD interacting with ISIS(for ipv4), I would >>> think it can also do this >>> black holing. Since ipv4 bfd session is flapping, and datalink >>> layer is fine, and ISIS >>> packets is going through ok, hellos are happy. ISIS will bring up >>> the adjacency, and >>> then register with bfd, and bfd later failed again, which will >>> bring down the ISIS session. >>> I fail to see the difference between the two schemes. >> >> A simple example of how this can be broken is that if you >> consider a distributed router, where you run ISIS on the routing >> processor, and BFD on specialized hardware down on a line card. >> While the line card's hardware could continue to send/receive >> BFD packets, the ISIS process on the RP could crash or get wedged, >> and cause it to ignore routing updates. If the routing protocol >> timers are sufficiently high (usually on the order of minutes or >> even hours), then no one will know until this timer goes off. >> >>> >>>> I think you need to specifically disallow this mechanism for >>>> cases like this, namely, applications that will continue to run >>>> even with the failure of a data protocol, but whose correct >>>> operation requires that data protocol. (Note that this sentence >>>> describes both ISIS and static routes.) >>>> >>>> OSPFv3 is another interesting example if you're running BFD in >>>> this configuration only over IPv4. If there is a v4 failure, >>>> OSPFv3 will flap unnecessarily. This gets back to the IPv4 == >>>> everything fate sharing that is at the heart of the way you've >>>> specified it, and which I think is an unnecessary restriction. >>>> A number of systems (including the one I'm most familiar with >>>> these days) has an interface hierarchy that includes the data >>>> protocol. Such systems are likely better served by having, say, >>>> separate v4 and v6 BFD sessions and flapping the appropriate >>>> data protocol up/down status in the face of a BFD session >>>> failure. This would allow the OSPFv3 case to run unmolested >>>> when v4 died. I would suggest to at least offer this up as a >>>> MAY when you discuss the fate sharing implications of this >>>> mechanism, since it should be essentially no more work to >>>> implement if the system is already built this way. >>> >>> Sure. There can be an configuration option for bring down the >>> whole thing or bring >>> down the data protocol part if the platform supports that. >>> >>> Even though from architecture wise, the separation of bfds is >>> clean, ipv4 controls the >>> ipv4 protocols and ipv6 controls the ipv6 protocols. there are >>> still much to be desired >>> from implementation point of angle. On many routers BFD packets >>> going out not really >>> through the exact data packets forwarding path or the packets are >>> sent out from the >>> same software process, be it v6 or v6. So the argument of data >>> separation is rather >>> mood. And I'm yet to see a case BFD session down is actually >>> caused by the layer 3 >>> lookup engine which is only responsible for ipv4;-) I would >>> rather do the re-route >>> altogether though if we know one of the data plane is already in >>> trouble. >> >> Right. Just look at the example I gave above. Even if you run the >> ISIS >> process on the line card's CPU, if BFD is run in special LC >> hardware outside >> of the CPU, that constitutes two disjoint forwarding IP stacks; >> BFD will only >> be testing its own. >> >>> >>>> >>>>>> >>>>>> In light of this, my preference would be for all of the >>>>>> verbiage about static routes and dynamic protocols and special >>>>>> fiags to be removed. In place of this, add text that is very >>>>>> specific about the fate-sharing implications of this mechanism >>>>>> as outlined above, and point out that any application of BFD >>>>>> that does not automatically share fate with the data protocol >>>>>> over which BFD is running (such as ISIS or static routes) MUST >>>>>> have some form of explicit interaction with BFD in order to >>>>>> avoid false positives, and leave it at that. The "special >>>>>> bit" hack is orthogonal to this mechanism; it could just as >>>>>> well have been specified in the generic spec (and would have >>>>>> been just as inappropriate there.) >>>>> >>>>> I think the dynamic and static difference still needs to be >>>>> mentioned, although should not >>>>> be directly linked with a 'special flag' for the static routing. >>>> >>>> But I think the "difference" here is fundamental--as soon as you >>>> have any special case communication between BFD and a part of >>>> the system, you've basically discarded the point of the draft >>>> (if I understand it) which is to be able to leverage BFD without >>>> changing your "clients" to specifically use it. What you're >>>> specifying here is functionally *exactly* the same as what the >>>> generic spec talks about for static routes and other non- >>>> protocol applications, and only muddies the spec, IMHO. >>> >>> only the UP->Down portion is different between the two schemes. >>> the rest is the same. >>> but the bring down itself is different from the point of dynamic >>> or static. >>> >>>> >>>> Why not just say that this mechanism only provides a way of more >>>> rapidly taking down applications that would otherwise go down >>>> eventually and which will stay down on their own until the path >>>> is healed (namely, control protocols), and leave statics out of >>>> it altogether? >>> >>> Maybe you have a point. I'll think about that. >> >> I agree with Katz here. The point of this draft should be to >> suggest that >> this approach AUGMENT the normal routing hellos, as well as >> existing ifUp/Down >> mechanisms inside your box. > > I agree the intf UP->Down signal is the key of this draft; but as I > pointed out > in the previous email, there is also an important difference in the > bring-up stage > in terms of non-protocol services, that the bfd session state is > condensed into > an intf-based indication, which is very easy for implementation. > Since those > services looking at the intf state anyway, to augment with tins > intf-p2p bfd, > is just simply a one-line diff to those services. Precisely. If it is condensed into functions like the following, I think we are on the same page. Note the subtlety of the ifUp state and how you get there. if (oldIfUp && bfdUP ) ifUp(); if (oldIfDown || bfdDown) ifDown(); --Tom > > thanks. > - Naiming > >> >> --Tom >> >> >> >>> >>> thanks. >>> - Naiming >>> >>>> >>>> >>>> --Dave >> > From rtg-bfd-bounces@ietf.org Tue Apr 03 11:50:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYlGx-0008AX-TZ; Tue, 03 Apr 2007 11:50:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYlGv-0008AG-T2 for rtg-bfd@ietf.org; Tue, 03 Apr 2007 11:50:13 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYlGt-0007hy-Q9 for rtg-bfd@ietf.org; Tue, 03 Apr 2007 11:50:13 -0400 Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 04 Apr 2007 10:18:22 +0530 X-IronPort-AV: i="4.14,366,1170613800"; d="scan'208"; a="77698611:sNHT68292588" Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l33Fo7K0016055 for ; Tue, 3 Apr 2007 23:50:07 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l33Fo2jO013830 for ; Tue, 3 Apr 2007 15:50:07 GMT Received: from xmb-hkg-416.apac.cisco.com ([64.104.123.88]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 23:50:00 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Apr 2007 23:49:50 +0800 Message-ID: <35912544FC930E49BF20EF16C3EF2765021A004E@xmb-hkg-416.apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.txt Thread-Index: Acd2B7btnJE7PXGiTHCxVqspu1Eflw== From: "Miya Kohno \(mkohno\)" To: X-OriginalArrivalTime: 03 Apr 2007 15:50:00.0886 (UTC) FILETIME=[BCDDF560:01C77607] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1880; t=1175615407; x=1176479407; c=relaxed/simple; s=hkgdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mkohno@cisco.com; z=From:=20=22Miya=20Kohno=20\(mkohno\)=22=20 |Subject:=20Re=3A=20I-D=20ACTION=3Adraft-shen-bfd-intf-p2p-nbr-00.txt=20 |Sender:=20; bh=ZYMnkQ+Gxo7aJZ9ql3aVtjEFlEfCZgReh8W/kY5ACs4=; b=PQqQWAV3u8PkmNplGQ/c+ADCRND/8PmK0mvx8MxTGvcYXA6z74hkxVHFHwudkGrti/OproVl +n8QhB1cnSAMR4Ro6MD6XSqn3kBn2Y4gdlZGbQLUDZjj1R7MNGtl50bKyVDYZ9H1nlHkTr/XmV DZxZCpJEVBNeXrb36mJoUBpw8=; Authentication-Results: hkg-dkim-2; header.From=mkohno@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-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: , Errors-To: rtg-bfd-bounces@ietf.org Hi, On Apr 2, 2007:1:14 PM, at 1:14 PM, Naiming Shen wrote: > I agree the intf UP->Down signal is the key of this draft; but as I pointed out > in the previous email, there is also an important difference in the bring-up stage > in terms of non-protocol services, that the bfd session state is condensed into > an intf-based indication, which is very easy for implementation. Since those > services looking at the intf state anyway, to augment with tins intf-p2p bfd, > is just simply a one-line diff to those services. I think the protocol-agnostic nature is more the essence of the draft, rather than the interface UP->Down. I've been thinking that, assuming the primary goal of BFD is to detect the (un)liveness of underlying layer when it cannot generate/propagate its fault status, it should not necessarily be tightly coupled with L3 protocols... The protocol-agnostic nature would be very much suitable for static, TE FRR/local protection and global path restoration/ protection (by detecting-node generating PATH error to headend), which don't have a direct upperlayer protocol peer. It could also be applicable for the OSPFv3 prefixes, when it shares the same topology as OSPFv2. In fact, the single topology is pretty much common in v4/v6 dual stack deployment, so separately running BFDv6 session could be viewed as an unnecessary overhead.=20 A concern would be that bringing down the interface might be too aggressive, depending on various situations.=20 So how about including a less aggressive way ? i.e. 1) BFD session is to be associated with each p2p interface, not L3 protocol. 2) each protocol instance register itself as a BFD client 3) BFD clients should be notfiied in case of BFD session timeout 1) is only a bit new by the draft. But 2) and 3) is the same as the existing implementation. Miya From rtg-bfd-bounces@ietf.org Tue Apr 03 18:42:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYrhL-0004IF-IV; Tue, 03 Apr 2007 18:41:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYrhJ-0004Gr-Ux for rtg-bfd@ietf.org; Tue, 03 Apr 2007 18:41:53 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYrhI-0000k8-Mg for rtg-bfd@ietf.org; Tue, 03 Apr 2007 18:41:53 -0400 Received: from unknown (HELO emailsmtp55.jnpr.net) ([172.24.18.132]) by borg.juniper.net with ESMTP; 03 Apr 2007 15:41:53 -0700 X-IronPort-AV: i="4.14,366,1170662400"; d="scan'208"; a="701937732:sNHT30851900" Received: from electron.jnpr.net ([172.24.15.21]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 15:41:52 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Apr 2007 15:41:51 -0700 Message-ID: <5EB31780BD297F46812C8F495FA08F620B9E952D@electron.jnpr.net> In-Reply-To: <460DA338.4020505@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.txt Thread-Index: AcdzJtORCHReh25UQ9Cofjd/BWDyegDGU12A From: "Nitin Bahadur" To: "Naiming Shen" X-OriginalArrivalTime: 03 Apr 2007 22:41:52.0403 (UTC) FILETIME=[46143630:01C77641] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: rtg-bfd@ietf.org Subject: RE: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-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: , Errors-To: rtg-bfd-bounces@ietf.org > > Also, with the draft you are tying in the concept of a link failure to a > > bfd session failure...which might not necessarily be true. BFD sessions > > might fail due to firewall filters, IP packet handling errors. You would > > need more tools to tell the customer/operator that the link is *actually > > not down* and it's BFD that has marked the link as down. >=20 > to be honest, generate an meaningful error message saying 'intf-p2p bfd > brought down intf' will probably do for most of the customers. I would be happy if you can note in the draft that the bfd session failure does not necessarily mean that the physical link/connectivity is down and bfd should not be used in place of link-layer OAM mechanisms. Comments by Dave Katz & Tom Nadeau seem to have addressed all other issues. Thanks Nitin From rtg-bfd-bounces@ietf.org Thu Apr 05 04:27:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZNIv-0002tN-5p; Thu, 05 Apr 2007 04:26:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZNIu-0002tF-C9 for rtg-bfd@ietf.org; Thu, 05 Apr 2007 04:26:48 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZNIs-0001ON-0i for rtg-bfd@ietf.org; Thu, 05 Apr 2007 04:26:48 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 05 Apr 2007 01:26:45 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l358QjCQ004991 for ; Thu, 5 Apr 2007 01:26:45 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l358QcZv014996 for ; Thu, 5 Apr 2007 08:26:45 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 01:23:31 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 01:23:31 -0700 In-Reply-To: <35912544FC930E49BF20EF16C3EF2765021A004E@xmb-hkg-416.apac.cisco.com> References: <35912544FC930E49BF20EF16C3EF2765021A004E@xmb-hkg-416.apac.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Naiming Shen Date: Thu, 5 Apr 2007 01:23:28 -0700 To: "Miya Kohno \(mkohno\)" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 05 Apr 2007 08:23:31.0573 (UTC) FILETIME=[B204B250:01C7775B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2357; t=1175761605; x=1176625605; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=naiming@cisco.com; z=From:=20Naiming=20Shen=20 |Subject:=20Re=3A=20I-D=20ACTION=3Adraft-shen-bfd-intf-p2p-nbr-00.txt=20 |Sender:=20; bh=FBRIwLmvxWiL5m7MY/b8WRG7hw7XRzPwgxZOaMb7THk=; b=LOKtQZNW8ukZIs1qNPd0uvXTL2jTi2Oav9vtULd7332djtI3bumMiIyi2LbiMP8c6lyQ12aH KMi+NGB41TJjnUfSC6N7VdG2seiS+jZWv4RzwtdcMixShwiynmHStMjs/ieTf2VX4CdJWDBhn8 Z8c3Qtf9Ev8noWtOMc/0F7NLQ=; Authentication-Results: sj-dkim-1; header.From=naiming@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: rtg-bfd@ietf.org Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-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: , Errors-To: rtg-bfd-bounces@ietf.org Hi Miya, On Apr 3, 2007, at 8:49 AM, Miya Kohno ((mkohno)) wrote: > Hi, > > On Apr 2, 2007:1:14 PM, at 1:14 PM, Naiming Shen wrote: >> I agree the intf UP->Down signal is the key of this draft; but as I > pointed out >> in the previous email, there is also an important difference in the > bring-up stage >> in terms of non-protocol services, that the bfd session state is > condensed into >> an intf-based indication, which is very easy for implementation. >> Since > those >> services looking at the intf state anyway, to augment with tins > intf-p2p bfd, >> is just simply a one-line diff to those services. > > I think the protocol-agnostic nature is more the essence of the draft, > rather than the interface UP->Down. > > I've been thinking that, assuming the primary goal of BFD is to detect > the (un)liveness of underlying layer when it cannot generate/propagate > its fault status, it should not necessarily be tightly coupled with L3 > protocols... > > The protocol-agnostic nature would be very much suitable for > static, TE > FRR/local protection and global path restoration/ protection (by > detecting-node generating PATH error to headend), which don't have a > direct upperlayer protocol peer. It could also be applicable for the > OSPFv3 prefixes, when it shares the same topology as OSPFv2. In fact, > the single topology is pretty much common in v4/v6 dual stack > deployment, so separately running BFDv6 session could be viewed as an > unnecessary overhead. > > A concern would be that bringing down the interface might be too > aggressive, depending on various situations. > > So how about including a less aggressive way ? i.e. > > 1) BFD session is to be associated with each p2p interface, not L3 > protocol. As long as we are looking at the p2p or p2p-over-lan interfaces, then I don't see anything wrong with the 'aggressive' way of shutting down the interface. > 2) each protocol instance register itself as a BFD client > 3) BFD clients should be notfiied in case of BFD session timeout But by shutting down the interface, we don't have to do any of the above, which was the original intention of the draft. thanks. - Naiming > > 1) is only a bit new by the draft. But 2) and 3) is the same as the > existing implementation. > > Miya > > From rtg-bfd-bounces@ietf.org Thu Apr 05 04:28:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZNKl-0004U6-9z; Thu, 05 Apr 2007 04:28:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZNKk-0004Ty-UV for rtg-bfd@ietf.org; Thu, 05 Apr 2007 04:28:42 -0400 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.43) id 1HZNKj-0001hW-KW for rtg-bfd@ietf.org; Thu, 05 Apr 2007 04:28:42 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 05 Apr 2007 01:28:42 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l358Sebw007343; Thu, 5 Apr 2007 01:28:40 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l358SeMF018082; Thu, 5 Apr 2007 08:28:40 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 01:28:40 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 01:28:40 -0700 In-Reply-To: <5EB31780BD297F46812C8F495FA08F620B9E952D@electron.jnpr.net> References: <5EB31780BD297F46812C8F495FA08F620B9E952D@electron.jnpr.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Naiming Shen Date: Thu, 5 Apr 2007 01:28:37 -0700 To: "Nitin Bahadur" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 05 Apr 2007 08:28:40.0475 (UTC) FILETIME=[6A2366B0:01C7775C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1188; t=1175761721; x=1176625721; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=naiming@cisco.com; z=From:=20Naiming=20Shen=20 |Subject:=20Re=3A=20I-D=20ACTION=3Adraft-shen-bfd-intf-p2p-nbr-00.txt |Sender:=20; bh=/fWQIXnkPQ5xwQSkHvX4FlojH8MGxPZqt6VqZY2lgrI=; b=GFMcntDJX2J6G1+WxDXF3lPF0ZQJ35i8mOZploEyaCopyGk0BOdMsr8KVguyU7QKhqE+MByb pYSc6S8r3oLiITHYc5hkTbBNGR8AYd12GYNRvjRcAUJTfYFvEGc6N0Ee; Authentication-Results: sj-dkim-2; header.From=naiming@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: rtg-bfd@ietf.org Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-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: , Errors-To: rtg-bfd-bounces@ietf.org On Apr 3, 2007, at 3:41 PM, Nitin Bahadur wrote: > > >>> Also, with the draft you are tying in the concept of a link failure > to a >>> bfd session failure...which might not necessarily be true. BFD > sessions >>> might fail due to firewall filters, IP packet handling errors. You > would >>> need more tools to tell the customer/operator that the link is > *actually >>> not down* and it's BFD that has marked the link as down. >> >> to be honest, generate an meaningful error message saying 'intf-p2p > bfd >> brought down intf' will probably do for most of the customers. > > I would be happy if you can note in the draft that the bfd session > failure does not necessarily mean that the physical link/ > connectivity is > down and bfd should not be used in place of link-layer OAM mechanisms. For the first one, I can add that it does not mean the physical link has to be down; the second one, this draft does not claim to replace the OAM functionality. this draft is only trying to be the BFD with a simple scheme. thanks. - Naiming > > Comments by Dave Katz & Tom Nadeau seem to have addressed all other > issues. > > Thanks > Nitin From rtg-bfd-bounces@ietf.org Thu Apr 05 09:28:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZS0m-0007ra-Jc; Thu, 05 Apr 2007 09:28:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZS0k-0007pL-Nh for rtg-bfd@ietf.org; Thu, 05 Apr 2007 09:28:22 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZS0j-0007GG-26 for rtg-bfd@ietf.org; Thu, 05 Apr 2007 09:28:22 -0400 Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 06 Apr 2007 07:47:06 +0530 X-IronPort-AV: i="4.14,378,1170613800"; d="scan'208"; a="77872412:sNHT86987168" Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l35DSHrk020196 for ; Thu, 5 Apr 2007 21:28:17 +0800 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l35DSHjO022819 for ; Thu, 5 Apr 2007 13:28:17 GMT Received: from xmb-hkg-416.apac.cisco.com ([64.104.123.88]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 21:28:16 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Apr 2007 21:28:13 +0800 Message-ID: <35912544FC930E49BF20EF16C3EF2765021A085E@xmb-hkg-416.apac.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.txt Thread-Index: Acd3W7N8qPdlDtTXTQ2xjRa4CHS3/QAGZCjQ References: <35912544FC930E49BF20EF16C3EF2765021A004E@xmb-hkg-416.apac.cisco.com> From: "Miya Kohno \(mkohno\)" To: "Naiming Shen \(naiming\)" X-OriginalArrivalTime: 05 Apr 2007 13:28:16.0470 (UTC) FILETIME=[44AA8F60:01C77786] Authentication-Results: hkg-dkim-1; header.From=mkohno@cisco.com; dkim=neutral ( ssp=~; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: rtg-bfd@ietf.org Subject: RE: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-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: , Errors-To: rtg-bfd-bounces@ietf.org Hi Naiming, I felt shutting down the interface might be too aggressive, because there is a case that fast-detection/fast-convergence, which could conflict with the stability or fault tolerance (GR/NSF..), is not always preferable.=20 But it's true we run BFD only because we want the fast convergence. :) A concern would be the case that multiple protocol instances share an interface and one of the instances doesn't want the fast convergence while others do. That's why I still think it'd be beneficial if each protocol instance can select to register or not. But then it requires an additional development for each client protocols, while your proposal that bring down the interface doesn't. So I agree that there are cases where your proposal is useful.=20 Miya > -----Original Message----- > From: Naiming Shen (naiming)=20 > Sent: Thursday, April 05, 2007 5:23 PM > To: Miya Kohno (mkohno) > Cc: rtg-bfd@ietf.org > Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.txt=20 >=20 > Hi Miya, >=20 > On Apr 3, 2007, at 8:49 AM, Miya Kohno ((mkohno)) wrote: >=20 > > Hi, > > > > On Apr 2, 2007:1:14 PM, at 1:14 PM, Naiming Shen wrote: > >> I agree the intf UP->Down signal is the key of this draft; but as I > > pointed out > >> in the previous email, there is also an important difference in the > > bring-up stage > >> in terms of non-protocol services, that the bfd session state is > > condensed into > >> an intf-based indication, which is very easy for implementation. =20 > >> Since > > those > >> services looking at the intf state anyway, to augment with tins > > intf-p2p bfd, > >> is just simply a one-line diff to those services. > > > > I think the protocol-agnostic nature is more the essence of=20 > the draft,=20 > > rather than the interface UP->Down. > > > > I've been thinking that, assuming the primary goal of BFD=20 > is to detect=20 > > the (un)liveness of underlying layer when it cannot=20 > generate/propagate=20 > > its fault status, it should not necessarily be tightly=20 > coupled with L3=20 > > protocols... > > > > The protocol-agnostic nature would be very much suitable=20 > for static,=20 > > TE FRR/local protection and global path restoration/ protection (by=20 > > detecting-node generating PATH error to headend), which=20 > don't have a=20 > > direct upperlayer protocol peer. It could also be applicable for the > > OSPFv3 prefixes, when it shares the same topology as=20 > OSPFv2. In fact,=20 > > the single topology is pretty much common in v4/v6 dual stack=20 > > deployment, so separately running BFDv6 session could be=20 > viewed as an=20 > > unnecessary overhead. > > > > A concern would be that bringing down the interface might be too=20 > > aggressive, depending on various situations. > > > > So how about including a less aggressive way ? i.e. > > > > 1) BFD session is to be associated with each p2p=20 > interface, not L3=20 > > protocol. >=20 > As long as we are looking at the p2p or p2p-over-lan=20 > interfaces, then I don't see anything wrong with the=20 > 'aggressive' way of shutting down the interface. >=20 > > 2) each protocol instance register itself as a BFD client > > 3) BFD clients should be notfiied in case of BFD session timeout >=20 > But by shutting down the interface, we don't have to do any=20 > of the above, which was the original intention of the draft. >=20 > thanks. > - Naiming >=20 > > > > 1) is only a bit new by the draft. But 2) and 3) is the same as the=20 > > existing implementation. > > > > Miya > > > > >=20 >=20 From rtg-bfd-bounces@ietf.org Mon Apr 09 03:57:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Haojs-0003X9-DJ; Mon, 09 Apr 2007 03:56:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Haojr-0003X4-0J for rtg-bfd@ietf.org; Mon, 09 Apr 2007 03:56:35 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Haojp-0000Kj-Jp for rtg-bfd@ietf.org; Mon, 09 Apr 2007 03:56:34 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 09 Apr 2007 00:56:33 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l397uWG9027604 for ; Mon, 9 Apr 2007 00:56:32 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l397uNEi010212 for ; Mon, 9 Apr 2007 07:56:27 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 00:56:22 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 00:56:22 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <4528727A-E25E-4C47-9EEA-F996C61F4DD2@cisco.com> References: <3D93D8A8-F2CD-4F5D-BA37-5A2489E2C3DA@cisco.com> <29C50044-05B4-412E-B0D8-4B1B6F38672F@juniper.net> <448453AC-AAC4-4924-8BF2-87AC85907252@juniper.net> <5B807F72-EEB9-4D11-91E3-4798187CAABB@cisco.com> <078305F4-C44D-4853-8C96-23FF3E2338E2@cisco.com> <4528727A-E25E-4C47-9EEA-F996C61F4DD2@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6CF5DBD6-27D5-4CA5-92D6-35F939030FEB@cisco.com> Content-Transfer-Encoding: 7bit From: Naiming Shen Date: Mon, 9 Apr 2007 00:56:21 -0700 To: rtg-bfd@ietf.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 Apr 2007 07:56:22.0679 (UTC) FILETIME=[90C63270:01C77A7C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=524; t=1176105393; x=1176969393; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=naiming@cisco.com; z=From:=20Naiming=20Shen=20 |Subject:=20Re=3A=20I-D=20ACTION=3Adraft-shen-bfd-intf-p2p-nbr-00.txt=20 |Sender:=20; bh=WRtrnE6i+VU3uZIxkJ1/r/if0qPTake6hEAW6Cs2DXc=; b=DInu+XQYOXbzMrCMvm9boDvsjJOW326MGvmLMzeoojz5VxeGvBAioCxtkudMLrEqoUTgW3YS J5dbz4ycqKY/u2yaVSFGwQkwNa0BJ2YNsxOgi8d78pSjmML0VoXg5m0OIDinsC6OHB9ymzYWR+ QipTUw9pOdSs/KxqGSzci/Ook=; Authentication-Results: sj-dkim-1; header.From=naiming@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-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: , Errors-To: rtg-bfd-bounces@ietf.org Just to add one more thing that, even though this draft does not change anything in terms of BFD base spec, but this scheme does generate unique error conditions, such as detection of multiple peers over a point-to- point interface. If the implementation does bring the session down, it needs to report this with a new DIAG code to reflect this error. Although the detection mechanism is out side the scope of this document. Thanks to the folks brought this to my attention. Will fix. thanks. - Naiming From rtg-bfd-bounces@ietf.org Mon Apr 09 13:16:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaxSx-0000J4-Ol; Mon, 09 Apr 2007 13:15:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaxSx-0000Iw-AX for rtg-bfd@ietf.org; Mon, 09 Apr 2007 13:15:43 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaxSw-0003H5-2q for rtg-bfd@ietf.org; Mon, 09 Apr 2007 13:15:43 -0400 Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by kremlin.juniper.net with ESMTP; 09 Apr 2007 10:15:40 -0700 X-IronPort-AV: i="4.14,388,1170662400"; d="scan'208"; a="683980095:sNHT41700172" Received: from electron.jnpr.net ([172.24.15.21]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 10:15:39 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Apr 2007 10:15:41 -0700 Message-ID: <5EB31780BD297F46812C8F495FA08F620B9E9C03@electron.jnpr.net> In-Reply-To: <6CF5DBD6-27D5-4CA5-92D6-35F939030FEB@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.txt Thread-Index: Acd6fNIRN7Eb0nZ4REKqRwTQcXnB9wATaGKw From: "Nitin Bahadur" To: "Naiming Shen" , X-OriginalArrivalTime: 09 Apr 2007 17:15:39.0329 (UTC) FILETIME=[B218A310:01C77ACA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: RE: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-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: , Errors-To: rtg-bfd-bounces@ietf.org If you add a new diag-code, then you either need to do it to the base spec or make your spec Standards track...I prefer the former. Nitin > -----Original Message----- > From: Naiming Shen [mailto:naiming@cisco.com] > Sent: Monday, April 09, 2007 12:56 AM > To: rtg-bfd@ietf.org > Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.txt >=20 >=20 > Just to add one more thing that, even though this draft does not change > anything in terms of BFD base spec, but this scheme does generate unique > error conditions, such as detection of multiple peers over a point-to- > point > interface. If the implementation does bring the session down, it > needs to > report this with a new DIAG code to reflect this error. Although the > detection > mechanism is out side the scope of this document. Thanks to the folks > brought this to my attention. Will fix. >=20 > thanks. > - Naiming From rtg-bfd-bounces@ietf.org Mon Apr 09 13:28:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaxfW-0000Lb-8y; Mon, 09 Apr 2007 13:28:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Haxdw-0007ne-VG for rtg-bfd@ietf.org; Mon, 09 Apr 2007 13:27:04 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaxcK-0005C3-4l for rtg-bfd@ietf.org; Mon, 09 Apr 2007 13:25:25 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 09 Apr 2007 10:25:23 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l39HPNNK030409; Mon, 9 Apr 2007 10:25:23 -0700 Received: from [128.107.130.83] (naiming-linux.cisco.com [128.107.130.83]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l39HPNwn004025; Mon, 9 Apr 2007 17:25:23 GMT Message-ID: <461A7703.9040400@cisco.com> Date: Mon, 09 Apr 2007 10:25:23 -0700 From: Naiming Shen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nitin Bahadur References: <5EB31780BD297F46812C8F495FA08F620B9E9C03@electron.jnpr.net> In-Reply-To: <5EB31780BD297F46812C8F495FA08F620B9E9C03@electron.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1043; t=1176139523; x=1177003523; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=naiming@cisco.com; z=From:=20Naiming=20Shen=20 |Subject:=20Re=3A=20I-D=20ACTION=3Adraft-shen-bfd-intf-p2p-nbr-00.txt |Sender:=20; bh=qqAM2iGjasbhkgE/HkiLkJzTOICoLq2ANtN7Xppgiqo=; b=VTtrNF6V+sWOYIP2yxx7+SDyNQtAM3fUR0Iz2trGp3kxHUAF+2uUqQP+mG2FBMOYicch+BGt jHGgHT+SL0PykvT0847AUzbSnuS2nmX/+15b2DLCbfp4/zq0RubAxa/p; Authentication-Results: sj-dkim-5; header.From=naiming@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: rtg-bfd@ietf.org Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-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: , Errors-To: rtg-bfd-bounces@ietf.org Nitin, Nitin Bahadur said the following on 04/09/2007 10:15 AM: > If you add a new diag-code, then you either need to do it to the base > spec or make your spec Standards track...I prefer the former. Same here. thanks. - Naiming > > Nitin > > >>-----Original Message----- >>From: Naiming Shen [mailto:naiming@cisco.com] >>Sent: Monday, April 09, 2007 12:56 AM >>To: rtg-bfd@ietf.org >>Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.txt >> >> >>Just to add one more thing that, even though this draft does not > > change > >>anything in terms of BFD base spec, but this scheme does generate > > unique > >>error conditions, such as detection of multiple peers over a point-to- >>point >>interface. If the implementation does bring the session down, it >>needs to >>report this with a new DIAG code to reflect this error. Although the >>detection >>mechanism is out side the scope of this document. Thanks to the folks >>brought this to my attention. Will fix. >> >>thanks. >>- Naiming