From exim@www1.ietf.org Tue Jan 20 18:46:14 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01788 for ; Tue, 20 Jan 2004 18:46:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj5Z5-0000F9-Lh for rtg-bfd-archive@odin.ietf.org; Tue, 20 Jan 2004 18:45:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0KNjlCb000915 for rtg-bfd-archive@odin.ietf.org; Tue, 20 Jan 2004 18:45:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj5Z4-0000EP-Og for rtg-bfd-web-archive@optimus.ietf.org; Tue, 20 Jan 2004 18:45:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01776 for ; Tue, 20 Jan 2004 18:45:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj5Z1-00069j-00 for rtg-bfd-web-archive@ietf.org; Tue, 20 Jan 2004 18:45:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj5Y6-000676-00 for rtg-bfd-web-archive@ietf.org; Tue, 20 Jan 2004 18:44:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aj5XL-000644-00 for rtg-bfd-web-archive@ietf.org; Tue, 20 Jan 2004 18:43:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj5XN-0008GN-5h; Tue, 20 Jan 2004 18:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aj5X7-0008AN-2L for rtg-bfd@optimus.ietf.org; Tue, 20 Jan 2004 18:43:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01678 for ; Tue, 20 Jan 2004 18:43:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj5Wz-00062O-00 for rtg-bfd@ietf.org; Tue, 20 Jan 2004 18:43:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj5W2-000604-00 for rtg-bfd@ietf.org; Tue, 20 Jan 2004 18:42:39 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Aj5VK-0005yI-00 for rtg-bfd@ietf.org; Tue, 20 Jan 2004 18:41:54 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aj5VH-000HHJ-0m; Tue, 20 Jan 2004 23:41:51 +0000 Date: Tue, 20 Jan 2004 15:41:09 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5993463413.20040120154109@psg.com> To: Pekka Savola CC: dkatz@juniper.net, dward@cisco.com, rtg-bfd@ietf.org Subject: Re: Comments on the BFD drafts In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-bfd-admin@ietf.org Errors-To: rtg-bfd-admin@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: RTG Area: Bidirectional Forwarding Detection DT List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks Pekka! CC'ing rtg-bfd@ietf.org for archival purposes. I will also put them in the tracker. Dave's, could you guys please put a line in the abstract of all BFD-related docs asking to send comments to the above address? Peka, some answers inline below, leaving the rest to the authors. Saturday, January 10, 2004, 11:42:12 AM, Pekka Savola wrote: > Hi, > (Cc:ing Alex, as he's watching according to the I-D tracker :-) > I got around to reviewing both the Bidirectional Forwarding Documents > (BFD) drafts. I believe this is important work, and we have already > deployed some software which supports this and intend to test and > enable it soon. > What's the plan for progressing the work? Individual submissions, > existing WG(s), or starting a new WG? The option of a separate WG has been discussed. At this point we don't see nearly enough activity on the mailing list to warrant one. The work will most likely progress as individual. > The drafts state Category as Informational, but I think this > definitely should be Standards Track! Agreed, > I also note that there is an IPR claim in the document, but the claim > has not been recorded in IETF IPR database (should fix ASAP). Which > part of the specification(s) does this IPR pertain to? Yes, this should be fixed. Dave's, please ask your companies to submit statements to the IETF secretariat. Thanks. Alex > Ok, down to the comments... > draft-katz-ward-bfd-01.txt: > =========================== ==>> I personally fail to see a lot of usefulness for the "new > and shiny features", Polling and (especially) Demand mode. This seems > to add a lot of complexity. Could you elaborate why these are useful > (apart for dial up/down links which is IMO something that shouldn't be > forced down the throat all the vendors) ==>> ToC needed ==>> you don't have any references in the document, at least [KEYWORDS] is > used but not added. > Pure asynchronous mode is advantageous in that it requires half as > many packets to achieve a particular detection time as does the Echo > function. It is also used when the Echo function cannot be supported > for some reason. > The Echo function has the advantage of truly testing only the > forwarding path on the remote system, which may reduce round-trip > jitter and thus allow more aggressive detection times, as well as > potentially detecting some classes of failure that might not > otherwise be detected. ==>> It seems that there is a conflict here, "pure asynch .. requires > half as many packets" and "echo function.. may allow more aggressive > detection times". > By definition, with half as many packets, you will always be able to > use more aggressive detection times that with double the number of > packets! > ... > A diagnostic code specifying the local system's reason for the > last transition of the session from Up to some other state. > Values are: > 0 -- No Diagnostic > 1 -- Control Detection Time Expired > 2 -- Echo Function Failed > 3 -- Neighbor Signaled Session Down > 4 -- Forwarding Plane Reset > 5 -- Path Down > 6 -- Concatenated Path Down > 7 -- Administratively Down ==>> 8-15 are still free, right? ==>> should one add "15 -- Other Reason" ? > (This also may need some reorganization, as commented earlier, as > "Echo Function Failed" seems to lose the diagnostics and valueble > information if you're using echo function.) > Poll (P) > If set, the transmitting system requesting verification of > connectivity, or of a parameter change. ==>> these flags should also describe the trivial case of flags being > unset. Applies to many flags. ==>> s/requesting/is requesting/? > Length > Length of the BFD Control packet, in bytes. ==>> Wouldn't it be nicer to use the units of 8 bytes (due to > alignment, and to reduce the number of unnecessary info)? With the > current Length, using the units of 64 bits would allow one to specify > longer lengths (up to 2040), which might help if you want to, at some > point, send e.g. extra data along with the packets (e.g., to notice if > longer packets fail even if the shorter ones work). > However, I'm not 100% sure this is needed, as you could accomplish the > same with setting the size of Echo packets, if needed. > ... > If the session goes down, the transmission of Echo packets (if any) > ceases, and the transmission of Control packets goes back to the slow > rate. > 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. ==>> Doesn't this cause problems if the other end is in Passive > mode? > Once the remote end echos back the local discriminator, all further ==>> s/echos/echoes/ > When a system is using the Echo function, it is advantageous to > choose a sedate transmission rate for Control packets, since the job > of detection is being handled by the Echo packets. This can be ==>> s/sedate/slow/ (if you want to use simpler language, doesn't > matter to me :) ==>> s/the job of detection/the liveness detection/ (a bit more formal > language :-) > When a system is said to have "the Echo function active," it refers > to that system sending BFD Echo packets (and thus implies that the > session is Up and the other system has signalled its willingness to > loop back Echo packets.) ==>> reword this to be similar as "Demand active", below, like: > When a system is said to have "the Echo function active," it means > the system is sending BFD Echo packets, implying that the > session is Up and the other system has signalled its willingness to > loop back Echo packets. > ... > If bfd.DetectMult is equal to 1, the interval between transmitted BFD > Control packets MUST be no more than 90% of the negotiated > transmission interval, and MUST be no less than 75% of the negotiated > transmission interval. This is to ensure that, on the remote system, > the calculated DetectTime does not pass prior to the receipt of the > next BFD Control packet. ==>> I do not understand why "no less than 75%" rule exists there, this > doesn't seem to have anything to do with the above DetectTime > reasoning? (of course, it might make sense otherwise.) > (1,000,000 microseconds.) This is intended to ensure that the > bandwidth consumed by down BFD sessions is negligible, particularly ==>> s/by down/by downed/ (or BFP sessions that are down) > system, multiplied by the agreed transmit interval (the greater of > bfd.RequiredMinRxInterval and the last received Desired Min TX > Interval.) The Detect Mult value is (roughly speaking, due to ==>> You mix the bfd.XXXX and "spelled out" terms ("Desired Min TX > Interval"). Use just one of them, e.g. by replacing the latter one by > bfd.DesiredMinTxInterval. (The same happens elsewhere as well.) > 6.5.5. Detecting Failures with the Echo Function > When the Echo function is active and a sufficient number of Echo > packets have not arrived as they should, the session has gone > down--the local system MUST set bfd.SessionState to Failing, > bfd.RemoteHeard to zero, and bfd.LocalDiag to 2 (The Echo Function > Failed.) ==>> I do not believe there has been an explicit specification how what > the sufficient number of Echo packets is. Note that the previous > section used MinTX/MinRX Intervals, and as there is a separate Echo > interval -- so it doesn't apply as is at least. ==>> wouldn't it be useful to use the similar diagnostic codes for Echo > failures than control packet failures? It seems you'll lose > information about the possible causes of the loss of connectivity if > you use Echo function? > 6.5.6. Reception of BFD Control Packets > When a BFD Control packet is received, the following procedure MUST > be followed, in the order specified: > If the version number is not correct (0), the packet MUST be > discarded. ==>> What is the proposed backward compatibility mechanism? Run each > version of BFD on all the links, and try to connect starting from the > highest supported version, etc. ? > If the version number is not correct (0), the packet MUST be > discarded. ==>> should it be spelled out that s/discard/silently discard/ ? > If the value of bfd.RemoteDiscr is zero, set it to the value of My > Discriminator. > If the Required Min Echo RX Interval field is zero, the > transmission of Echo packets, if any, MUST cease. ==>> please unify the style, as commented previously.. > Security Considerations > When BFD is run over network layer protocols, a significant denial- > of-service risk is created, as BFD packets may be trivial to spoof. > When the session is directly connected across a single link, the TTL > MUST be set to the maximum on transmit, and checked to be equal to > the maximum value on reception (and the packet dropped if this is not > the case.) ==>> this is fine (though you should spell out that this also applies > to Hop Limit if IPv6 is used) ==>> You should clarify what you refer to with the "more difficult" > BFD. MPLS network? Network with tunnels? A BFD-using protocol which > establishes adjacencies over multiple hops (e.g. IBGP, even though > that's a bad example)? > If BFD is run across multiple hops, some alternative > mechanism MUST be used. One option would be to ensure that the > network addresses used for BFD are not routable outside of the > infrastructure in which BFD is running (and assuming there are no > users connected within that network.) ==>> I strongly object to that proposition. First, this seems like a > recommendation to use private addresses. If it's not, you're assuming > that the operators would use specific addresses for these purposes and > block them at the border. But that would hinder the other uses of the > interface addresses (i.e., it's operationally impossible), and more > importantly, the BFD mechanism has not way to ensure that this > checking has in fact been configured by the operator. > Another option would be to > filter all packets carrying BFD's UDP ports at the edges of the > network. ==>> This is bad as well, because it could hinder the transited > traffic. However, if this was coupled by edge-based access-lists w/ > IP addresses and ports, the tradeoffs might be acceptable. However > this still has a number of problems, as discussed above. >> Still another option would be to use cryptographic methods, >> though this is not likely to allow for very short detection times. ==>> Too bad! :-) > draft-katz-ward-bfd-v4v6-1hop-00.txt: > ===================================== ==>> you should include the support for static routing. That would > likely be extremely useful (as you can't run an IGP between the > operator and the customer, and the link is very often an Ethernet > variant, which doesn't provide good link state change notifications). > I've already worked out some details in my head, and this should be > rather simple. ==>> You don't discuss the case what happens if you run IS-IS for IPv4 > only, and OSPFv3 -- or IS-IS for IPv6 only and OSPFv2 on the same > links, as dual-stack infrastructure. What about OSPFv2+OSPFv3 for that > matter? These are common deployment scenarios, and we run one of > these as well. Would you have two sessions between the nodes on each > link (one for each network-layer protocol used) or one? > Abstract > This document describes the use of the Bidirectional Forwarding > Detection protocol [BFD] over IPv4 and IPv6 for single IP hops. It > further describes the use of BFD with OSPFv2 [OSPFv2], OSPFv3 > [OSPFv3], and ISIS [ISIS]. ==>> please don't put references in the abstract! ==>> btw, use "IS-IS" rather than "ISIS" :-) > 1. Introduction > One very desirable application for BFD is to track IPv4 and IPv6 > connectivity between directly-connected systems. This could be used > to supplant the detection mechanisms in ISIS and OSPF, or to monitor > router-host connectivity, among other applications. ==>> note that the BFD document explicitly discusses it as a mechanism > between "forwarding engines", which seems to exlude router-host > connectivity (which could be useful). Maybe the main BFD document > could use a bit of rewording? > The source address MUST be > chosen in such a way as to preclude the remote system from generating > ICMP Redirect messages (in particular, the source address MUST NOT be > part of the subnet bound to the interface over which the BFD Echo > packet is being transmitted.) ==>> the last sentence is not clear -- does the MUST NOT apply to what > must not be done (i.e., cause the generation of ICMP redirects) or > what must be done? :-). When you think about it, it's obvious but the > wording is crap :-). > 4.1. BFD for IPv4 > 4.2. BFD for IPv6 ==>> there seems to be no need to restate the same things twice. > Combine these in one section, and state the differences where > applicable. > 5. TTL Issues ==>> with IPv6 this is called Hop Limit. > On an unnumbered point-to-point link, the source address of a BFD > Control packet MUST NOT be used to identify the session. This means > that the initial BFD packet MUST be accepted with any source address, > and that subsequent BFD packets MUST be demultiplexed solely by the > My Discriminator field (as is always the case.) This allows the > source address to change if necessary. ==>> this has security issues, especially if TTL=255 check was not in > place. Why this is not serious in this specific scenario should be > described in the security considerations. From exim@www1.ietf.org Wed Jan 21 04:33:25 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13680 for ; Wed, 21 Jan 2004 04:33:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjEjJ-00065z-4J for rtg-bfd-archive@odin.ietf.org; Wed, 21 Jan 2004 04:32:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0L9WvD5023427 for rtg-bfd-archive@odin.ietf.org; Wed, 21 Jan 2004 04:32:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjEjI-00065k-HC for rtg-bfd-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 04:32:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13669 for ; Wed, 21 Jan 2004 04:32:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjEjF-0000ze-00 for rtg-bfd-web-archive@ietf.org; Wed, 21 Jan 2004 04:32:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjEiI-0000y3-00 for rtg-bfd-web-archive@ietf.org; Wed, 21 Jan 2004 04:31:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjEhS-0000wb-00 for rtg-bfd-web-archive@ietf.org; Wed, 21 Jan 2004 04:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjEhR-0005pe-JI; Wed, 21 Jan 2004 04:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjEgS-0005lI-R0 for rtg-bfd@optimus.ietf.org; Wed, 21 Jan 2004 04:30:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13635 for ; Wed, 21 Jan 2004 04:29:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjEgP-0000ut-00 for rtg-bfd@ietf.org; Wed, 21 Jan 2004 04:29:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjEfS-0000t4-00 for rtg-bfd@ietf.org; Wed, 21 Jan 2004 04:29:00 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1AjEew-0000qn-00 for rtg-bfd@ietf.org; Wed, 21 Jan 2004 04:28: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 i0L9RmBm036515; Wed, 21 Jan 2004 01:27:49 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i0L9RFh57011; Wed, 21 Jan 2004 01:27:15 -0800 (PST) (envelope-from dkatz@juniper.net) Date: Wed, 21 Jan 2004 02:27:11 -0700 Subject: Re: Comments on the BFD drafts Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: dward@cisco.com, , rtg-bfd@ietf.org, Dave Katz To: Pekka Savola From: Dave Katz In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 7bit Sender: rtg-bfd-admin@ietf.org Errors-To: rtg-bfd-admin@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: RTG Area: Bidirectional Forwarding Detection DT List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit First, thanks for doing such a thorough review. We haven't had very many of those. > The drafts state Category as Informational, but I think this > definitely should be Standards Track! If we can find a way to progress the work without it being bogged down forever, and without it becoming watered down by the legions of folks that would like to change it, I don't have any objection. My experience over the years does not give me a lot of hope. I'm leaving the sociopolitical aspects to dward (I quit going to the IETF some time ago, too many years of committees...) > > I also note that there is an IPR claim in the document, but the claim > has not been recorded in IETF IPR database (should fix ASAP). Which > part of the specification(s) does this IPR pertain to? I'll get this straightened out soon. I would expect cheap and nondiscriminatory licensing, since the authors really would like everyone to play. > ==> I personally fail to see a lot of usefulness for the "new > and shiny features", Polling and (especially) Demand mode. This seems > to add a lot of complexity. Could you elaborate why these are useful > (apart for dial up/down links which is IMO something that shouldn't be > forced down the throat all the vendors) Polling is necessary for correctness when the time constants are being changed (in particular, when one end decides to start transmitting less often than it had been previously.) Think about what would happen otherwise if the round trip time was greater than the detection time. Demand mode is useful if you're using Echo mode in both directions, but its primary purpose is to address the needs of mass fan-in devices. In particular, the IPSec folks had their own liveness proposal on the table that was particular to IPSec, and which included this feature (as apparently there are large fan-in IPSec gateways) and so this feature is included in order to attempt to avoid Yet Another Hello Protocol for IPSec. Note that the implementation of Demand mode is not mandatory; you simply never advertise the D bit and the other side cannot tell whether you don't have the code or you simply don't feel like doing it for some reason. This may limit the places a particular implementation can be used, but that's just product differentiation. I'm not sure what you're referring to about forcing anything down anybody's throat... > > ==> ToC needed Noted. > > ==> you don't have any references in the document, at least [KEYWORDS] > is > used but not added. Not sure what we should be referencing; suggestions are welcome. > > Pure asynchronous mode is advantageous in that it requires half as > many packets to achieve a particular detection time as does the Echo > function. It is also used when the Echo function cannot be > supported > for some reason. > > The Echo function has the advantage of truly testing only the > forwarding path on the remote system, which may reduce round-trip > jitter and thus allow more aggressive detection times, as well as > potentially detecting some classes of failure that might not > otherwise be detected. > > ==> It seems that there is a conflict here, "pure asynch .. requires > half as many packets" and "echo function.. may allow more aggressive > detection times". > > By definition, with half as many packets, you will always be able to > use more aggressive detection times that with double the number of > packets! Apples and oranges. Pure async requires half the packets as (symmetric) echo mode for the same detection time. The point about echo mode is that, because it may decrease jitter, more aggressive packet rates could be used without falsely declaring a link failure. It is certainly *not* the case "by definition" that you will "always" be able to be more aggressive, because the two operational modes may be very different in their processing. > > ... > > A diagnostic code specifying the local system's reason for the > last transition of the session from Up to some other state. > Values are: > > 0 -- No Diagnostic > 1 -- Control Detection Time Expired > 2 -- Echo Function Failed > 3 -- Neighbor Signaled Session Down > 4 -- Forwarding Plane Reset > 5 -- Path Down > 6 -- Concatenated Path Down > 7 -- Administratively Down > > ==> 8-15 are still free, right? > ==> should one add "15 -- Other Reason" ? Yes, they're still free; however I don't see any semantic distinction between "No Diagnostic" and "Other Reason"; either way the session went down, so there's definitely some reason that is not in the list of well defined reasons. > > (This also may need some reorganization, as commented earlier, as > "Echo Function Failed" seems to lose the diagnostics and valueble > information if you're using echo function.) The intent is that "Echo Function Failed" is equivalent to "Control Detection Time Expired" so the semantic content should be the same. > > Poll (P) > > If set, the transmitting system requesting verification of > connectivity, or of a parameter change. > > ==> these flags should also describe the trivial case of flags being > unset. Applies to many flags. Fair enough. > > ==> s/requesting/is requesting/? Yep. > > Length > > Length of the BFD Control packet, in bytes. > > ==> Wouldn't it be nicer to use the units of 8 bytes (due to > alignment, and to reduce the number of unnecessary info)? With the > current Length, using the units of 64 bits would allow one to specify > longer lengths (up to 2040), which might help if you want to, at some > point, send e.g. extra data along with the packets (e.g., to notice if > longer packets fail even if the shorter ones work). This was purposeful; one of the goals of the protocol is to keep the packets short and simple. We're resisting efforts to add extra stuff, the urge for which seems to be almost universal. In any case, trying to detect packet length-dependent problems in a link is not a goal (and there are fewer and fewer media that even have this characteristic.) We're trying to keep this protocol universal and media-type independent. If it ever really has to get longer, we can always bump the version number. > > However, I'm not 100% sure this is needed, as you could accomplish the > same with setting the size of Echo packets, if needed. True, if Echo packets are supported and sensible in the application (LAN switches are very careful *not* to echo packets, so you can't use Echo mode in that case.) > > ... > > If the session goes down, the transmission of Echo packets (if any) > ceases, and the transmission of Control packets goes back to the > slow > rate. > > 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. > > ==> Doesn't this cause problems if the other end is in Passive > mode? No, because the remote discriminator is not cleared, only the H bit. The Passive role is specifically to deal with the case where there may be multiple sessions and the remote discriminator isn't yet known (so the incoming packets can't be demuxed to the right session.) > > Once the remote end echos back the local discriminator, all further > > ==> s/echos/echoes/ Thanks. > > When a system is using the Echo function, it is advantageous to > choose a sedate transmission rate for Control packets, since the job > of detection is being handled by the Echo packets. This can be > > ==> s/sedate/slow/ (if you want to use simpler language, doesn't > matter to me :) I rather like "sedate" as it has broader connotations (relaxed, unhurried.) > ==> s/the job of detection/the liveness detection/ (a bit more formal > language :-) Fair enough. > > When a system is said to have "the Echo function active," it refers > to that system sending BFD Echo packets (and thus implies that the > session is Up and the other system has signalled its willingness to > loop back Echo packets.) > > ==> reword this to be similar as "Demand active", below, like: > > When a system is said to have "the Echo function active," it means > the system is sending BFD Echo packets, implying that the > session is Up and the other system has signalled its willingness to > loop back Echo packets. OK. > > ... > > If bfd.DetectMult is equal to 1, the interval between transmitted > BFD > Control packets MUST be no more than 90% of the negotiated > transmission interval, and MUST be no less than 75% of the > negotiated > transmission interval. This is to ensure that, on the remote > system, > the calculated DetectTime does not pass prior to the receipt of the > next BFD Control packet. > > ==> I do not understand why "no less than 75%" rule exists there, this > doesn't seem to have anything to do with the above DetectTime > reasoning? (of course, it might make sense otherwise.) This is the 25% jitter; normal packets must be sent at no more than 100% nor less than 75% of the negotiated interval. > > (1,000,000 microseconds.) This is intended to ensure that the > bandwidth consumed by down BFD sessions is negligible, particularly > > ==> s/by down/by downed/ (or BFP sessions that are down) OK. > > system, multiplied by the agreed transmit interval (the greater of > bfd.RequiredMinRxInterval and the last received Desired Min TX > Interval.) The Detect Mult value is (roughly speaking, due to > > ==> You mix the bfd.XXXX and "spelled out" terms ("Desired Min TX > Interval"). Use just one of them, e.g. by replacing the latter one by > bfd.DesiredMinTxInterval. (The same happens elsewhere as well.) No, these are not the same things. The bfd.XXX references refer to the contents of the state block. The "spelled out" terms refer to the fields in a received packet, which may or may not have been copied into the state block. > > 6.5.5. Detecting Failures with the Echo Function > > When the Echo function is active and a sufficient number of Echo > packets have not arrived as they should, the session has gone > down--the local system MUST set bfd.SessionState to Failing, > bfd.RemoteHeard to zero, and bfd.LocalDiag to 2 (The Echo Function > Failed.) > > ==> I do not believe there has been an explicit specification how what > the sufficient number of Echo packets is. Note that the previous > section used MinTX/MinRX Intervals, and as there is a separate Echo > interval -- so it doesn't apply as is at least. No, there is very specifically *no* specification as to how the Echo function works, as this is a purely local matter. The system may count packets, it might track time, it might look at sequence numbers, or anything else that might be dreamt up by an implementor. > > ==> wouldn't it be useful to use the similar diagnostic codes for Echo > failures than control packet failures? It seems you'll lose > information about the possible causes of the loss of connectivity if > you use Echo function? There is only one diagnostic code that denotes the fact that control packets stopped coming, so the Echo function is the same in this respect. The other diagnostics are either informational about the sending system, or are part of the BFD state machine and are invariant with respect to the use or non-use of Echo. (For instance, if one system detects a failure by the lack of either type of packet and tears down the session, the other system will respond with "Neighbor Signaled Session Down." > > 6.5.6. Reception of BFD Control Packets > > When a BFD Control packet is received, the following procedure MUST > be followed, in the order specified: > > If the version number is not correct (0), the packet MUST be > discarded. > > ==> What is the proposed backward compatibility mechanism? Run each > version of BFD on all the links, and try to connect starting from the > highest supported version, etc. ? It's outside of the scope of this spec. If we ever end up bumping the version number, we could include verbiage in that document that spells it out, but the only real correctness issue is to make sure that you don't end up running two sessions (one per version) that represents the same link. There would be no requirement for backward compatibility (though it certainly would not be precluded) as supporting multiple versions is a vendor choice. If the previous version has a large deployed base, it would be in a vendor's best interest to do so, but I am generally against requiring anything in a protocol unless it is *really* necessary. (My experience is that, counterintuitively, more MUSTs make interoperability harder.) > If the version number is not correct (0), the packet MUST be > discarded. > > ==> should it be spelled out that s/discard/silently discard/ ? As opposed to what? There is no mechanism in the protocol for announcing this event to the world, and an implementation may indeed want to complain loudly to network management or something. > > If the value of bfd.RemoteDiscr is zero, set it to the value of > My > Discriminator. > > If the Required Min Echo RX Interval field is zero, the > transmission of Echo packets, if any, MUST cease. > > ==> please unify the style, as commented previously.. I'll try. > > Security Considerations > > When BFD is run over network layer protocols, a significant denial- > of-service risk is created, as BFD packets may be trivial to spoof. > When the session is directly connected across a single link, the TTL > MUST be set to the maximum on transmit, and checked to be equal to > the maximum value on reception (and the packet dropped if this is > not > the case.) > > ==> this is fine (though you should spell out that this also applies > to Hop Limit if IPv6 is used) Fair enough. > > ==> You should clarify what you refer to with the "more difficult" > BFD. MPLS network? Network with tunnels? A BFD-using protocol which > establishes adjacencies over multiple hops (e.g. IBGP, even though > that's a bad example)? I'm not sure what you're referring to here. If you are referring to the conditions for which the TTL hack won't work, it's the converse of the case where it does work--anything where BFD traverses more than a single network layer hop. > > If BFD is run across multiple hops, some alternative > mechanism MUST be used. One option would be to ensure that the > network addresses used for BFD are not routable outside of the > infrastructure in which BFD is running (and assuming there are no > users connected within that network.) > > ==> I strongly object to that proposition. First, this seems like a > recommendation to use private addresses. If it's not, you're assuming > that the operators would use specific addresses for these purposes and > block them at the border. But that would hinder the other uses of the > interface addresses (i.e., it's operationally impossible), and more > importantly, the BFD mechanism has not way to ensure that this > checking has in fact been configured by the operator. There is nothing to stop an operator from assigning both public and private addresses to interfaces and only accepting BFD packets addressed to the private address space, for instance. In any case, this language is not normative; it's just attempting to list alternatives other than cryptographic methods. However, if an operator really wanted to use private addressing internally to their network, they're free to do so. Furthermore, it is not possible in any protocol to guarantee that the operator hasn't misconfigured their network. Guarantees of operational correctness are *way* outside the scope of the specification. > > Another option would > be to > filter all packets carrying BFD's UDP ports at the edges of the > network. > > ==> This is bad as well, because it could hinder the transited > traffic. However, if this was coupled by edge-based access-lists w/ > IP addresses and ports, the tradeoffs might be acceptable. However > this still has a number of problems, as discussed above. See above. These are viable choices (from the perspective of BFD security) if someone wishes to use them. If using them would hose their networks in some other way, then perhaps the operators might not want to use them. There's plenty of this sort of thing happening now in brute-force attempts to deal with viruses, for instance. (Having said all that, I agree that this probably isn't the best way to attack the problem, and is unnecessary if operators are vigilant about edge filtering for packets destined to internal addresses, which they really ought to be already or they're in a whole lot of danger.) > >> Still another option would be to use cryptographic methods, >> though this is not likely to allow for very short detection times. > > ==> Too bad! :-) Yeah, this gets at the heart of the problem, at least until crypto stuff gets cheap enough and fast enough to put in simple hardware. At this point, there is a tension between fast detection and crypto, at least for boxes cheaper than ours. ;-) > > draft-katz-ward-bfd-v4v6-1hop-00.txt: > ===================================== > > ==> you should include the support for static routing. That would > likely be extremely useful (as you can't run an IGP between the > operator and the customer, and the link is very often an Ethernet > variant, which doesn't provide good link state change notifications). > I've already worked out some details in my head, and this should be > rather simple. Yep, there's a lot of call for this, I'll add something, though it will require some careful wordsmithing to get across the point without referring to specific system implementations. Keep in mind that this is not really subject to standardization, since it's purely an internal matter. > > ==> You don't discuss the case what happens if you run IS-IS for IPv4 > only, and OSPFv3 -- or IS-IS for IPv6 only and OSPFv2 on the same > links, as dual-stack infrastructure. What about OSPFv2+OSPFv3 for that > matter? These are common deployment scenarios, and we run one of > these as well. Would you have two sessions between the nodes on each > link (one for each network-layer protocol used) or one? The base spec is clear (or it should be) that there is one session per data protocol at the layer at which it is running (so in the network layer case, one for v4 and one for v6.) A little bit of language in this spec should make that clearer. There should be a bit of language saying that the interaction between BFD and adjacencies should be based on the data protocol (so a v4 BFD failure should shoot down OSPFv2 and ISIS-for-v4 adjacencies, etc.) If I recall the v6 extensions for ISIS (I implemented them, but it's been a long time) we'll have to do a bit more weasel wording, to the effect that if, say a v4 BFD session fails, the routing protocol shouldn't advertise adjacency for that data protocol. This should hold for v4 in OSPFv3, if anybody ever bothers to do that. We also need language talking about the interaction with graceless restart in both protocols. > > Abstract > > This document describes the use of the Bidirectional Forwarding > Detection protocol [BFD] over IPv4 and IPv6 for single IP hops. It > further describes the use of BFD with OSPFv2 [OSPFv2], OSPFv3 > [OSPFv3], and ISIS [ISIS]. > > ==> please don't put references in the abstract! OK. > > ==> btw, use "IS-IS" rather than "ISIS" :-) At least I didn't say "Intermediate System to Intermediate System Intradomain Routeing Protocol." > > 1. Introduction > > One very desirable application for BFD is to track IPv4 and IPv6 > connectivity between directly-connected systems. This could be used > to supplant the detection mechanisms in ISIS and OSPF, or to monitor > router-host connectivity, among other applications. > > ==> note that the BFD document explicitly discusses it as a mechanism > between "forwarding engines", which seems to exlude router-host > connectivity (which could be useful). Maybe the main BFD document > could use a bit of rewording? Yeah, a few more weasel words would help. > > The source address MUST be > chosen in such a way as to preclude the remote system from > generating > ICMP Redirect messages (in particular, the source address MUST NOT > be > part of the subnet bound to the interface over which the BFD Echo > packet is being transmitted.) > > ==> the last sentence is not clear -- does the MUST NOT apply to what > must not be done (i.e., cause the generation of ICMP redirects) or > what must be done? :-). When you think about it, it's obvious but the > wording is crap :-). I think the wording is unambiguous, given the parentheses. You're more than welcome to suggest alternative text, however. "Crap," hrmph. I like to think of the words as "pearls." ;-) > > 4.1. BFD for IPv4 > 4.2. BFD for IPv6 > > ==> there seems to be no need to restate the same things twice. > Combine these in one section, and state the differences where > applicable. I get paid by the word. ;-) I don't think it would make it any clearer to combine them. > > 5. TTL Issues > > ==> with IPv6 this is called Hop Limit. Thanks. I guess they didn't subscribe to the IETF tradition of preserving our investment in terminology. ;-) > > On an unnumbered point-to-point link, the source address of a BFD > Control packet MUST NOT be used to identify the session. This means > that the initial BFD packet MUST be accepted with any source > address, > and that subsequent BFD packets MUST be demultiplexed solely by the > My Discriminator field (as is always the case.) This allows the > source address to change if necessary. > > ==> this has security issues, especially if TTL=255 check was not in > place. Why this is not serious in this specific scenario should be > described in the security considerations. There are no additional security issues caused by this, since the source address can be spoofed if you can just get the packet there. Since this document is for the single hop case (and explicitly calls out the TTL hack), what happens in the multihop case is not relevant here. Thanks again for your extensive comments and thorough reading. --Dave From exim@www1.ietf.org Wed Jan 21 16:14:02 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08859 for ; Wed, 21 Jan 2004 16:14:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPfJ-0004up-M8 for rtg-bfd-archive@odin.ietf.org; Wed, 21 Jan 2004 16:13:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LLDXUu018891 for rtg-bfd-archive@odin.ietf.org; Wed, 21 Jan 2004 16:13:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPfJ-0004uc-EQ for rtg-bfd-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 16:13:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08854 for ; Wed, 21 Jan 2004 16:13:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPfH-0001uL-00 for rtg-bfd-web-archive@ietf.org; Wed, 21 Jan 2004 16:13:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPeL-0001r9-00 for rtg-bfd-web-archive@ietf.org; Wed, 21 Jan 2004 16:12:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjPdv-0001nY-00 for rtg-bfd-web-archive@ietf.org; Wed, 21 Jan 2004 16:12:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPdp-0004jT-Fv; Wed, 21 Jan 2004 16:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjPdA-0004Yd-4m for rtg-bfd@optimus.ietf.org; Wed, 21 Jan 2004 16:11:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08701 for ; Wed, 21 Jan 2004 16:11:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPd8-0001le-00 for rtg-bfd@ietf.org; Wed, 21 Jan 2004 16:11:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjPcE-0001jX-00 for rtg-bfd@ietf.org; Wed, 21 Jan 2004 16:10:24 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjPbQ-0001fR-00 for rtg-bfd@ietf.org; Wed, 21 Jan 2004 16:09:33 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0LL8ji24475; Wed, 21 Jan 2004 23:08:45 +0200 Date: Wed, 21 Jan 2004 23:08:45 +0200 (EET) From: Pekka Savola To: Dave Katz cc: dward@cisco.com, , Subject: Re: Comments on the BFD drafts In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-bfd-admin@ietf.org Errors-To: rtg-bfd-admin@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: RTG Area: Bidirectional Forwarding Detection DT List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, Responses inline. On Wed, 21 Jan 2004, Dave Katz wrote: > First, thanks for doing such a thorough review. We haven't had very > many of those. > > > The drafts state Category as Informational, but I think this > > definitely should be Standards Track! > > If we can find a way to progress the work without it being bogged down > forever, and without it becoming watered down by the legions of folks > that would like to change it, I don't have any objection. My > experience over the years does not give me a lot of hope. I'm leaving > the sociopolitical aspects to dward (I quit going to the IETF some time > ago, too many years of committees...) I don't think there is a significant difference of the pass-through time whether it's Standards Track or Informational. It *is* still possible to push through standards track documents in 6 months :-). The kitchen sink effect should be avoided, of course. However, it takes some insight to see the "required changes" from "non-essential extensions". > > I also note that there is an IPR claim in the document, but the claim > > has not been recorded in IETF IPR database (should fix ASAP). Which > > part of the specification(s) does this IPR pertain to? > > I'll get this straightened out soon. I would expect cheap and > nondiscriminatory licensing, since the authors really would like > everyone to play. I'd like RF licensing because that's cleanest, but if that's not an option... > > ==> I personally fail to see a lot of usefulness for the "new > > and shiny features", Polling and (especially) Demand mode. This seems > > to add a lot of complexity. Could you elaborate why these are useful > > (apart for dial up/down links which is IMO something that shouldn't be > > forced down the throat all the vendors) > > Polling is necessary for correctness when the time constants are being > changed (in particular, when one end decides to start transmitting less > often than it had been previously.) Think about what would happen > otherwise if the round trip time was greater than the detection time. OK; I had low-latency links in mind, but I guess something like this would be useful in e.g. trans-{atlantic,pacific} and other links where the RTT is a lot higher than the desired detection interval. > Demand mode is useful if you're using Echo mode in both directions, but > its primary purpose is to address the needs of mass fan-in devices. In > particular, the IPSec folks had their own liveness proposal on the > table that was particular to IPSec, and which included this feature (as > apparently there are large fan-in IPSec gateways) and so this feature > is included in order to attempt to avoid Yet Another Hello Protocol for > IPSec. Right. > Note that the implementation of Demand mode is not mandatory; > you simply never advertise the D bit and the other side cannot tell > whether you don't have the code or you simply don't feel like doing it > for some reason. This may limit the places a particular implementation > can be used, but that's just product differentiation. I'm not sure > what you're referring to about forcing anything down anybody's throat... Maybe you have a more pragmatic approach at the standards, so that the vendors only implement parts of a spec which interest them (and their customers). I guess this is mostly the case. However, I'd rather see that the specs are split into digestible pieces (like, "BFD On-Demand Signalling") and the vendors should implement the base protocol, and those which are interested in Foo functionality, can then implement the extensions specified separately. For those which don't think they need Demand mode, could more easily leave it out (or come back at it at phase 2 of the implementation, or whatever). Being modular (within reason, of course), also specification-wise, is a good thing :-). > > > > ==> you don't have any references in the document, at least > > [KEYWORDS] is used but not added. > > Not sure what we should be referencing; suggestions are welcome. You refer to RFC 2119 with [KEYWORDS], so you should at least reference RFC 2119 :-). You could add a normative reference to GSTM, which was already approved, as this seems to depend heavily on its security. You could add an informational reference to the IPsec demand more spec. But well.. I guess I can't figure out much else at the moment :-) > > Pure asynchronous mode is advantageous in that it requires half as > > many packets to achieve a particular detection time as does the Echo > > function. It is also used when the Echo function cannot be > > supported > > for some reason. > > > > The Echo function has the advantage of truly testing only the > > forwarding path on the remote system, which may reduce round-trip > > jitter and thus allow more aggressive detection times, as well as > > potentially detecting some classes of failure that might not > > otherwise be detected. > > > > ==> It seems that there is a conflict here, "pure asynch .. requires > > half as many packets" and "echo function.. may allow more aggressive > > detection times". > > > > By definition, with half as many packets, you will always be able to > > use more aggressive detection times that with double the number of > > packets! > > Apples and oranges. Pure async requires half the packets as > (symmetric) echo mode for the same detection time. The point about > echo mode is that, because it may decrease jitter, more aggressive > packet rates could be used without falsely declaring a link failure. > It is certainly *not* the case "by definition" that you will "always" > be able to be more aggressive, because the two operational modes may be > very different in their processing. Maybe the distinction should be spelled out a bit more? I assume with "jitter reduction" you're referring to the cost of processing the BFD packets on CPU, leading to potential jitter and delays if the CPU is overloaded (assuming bfd control function is implemented in CPU but echo function might also be implemented in hardware). Or are you just referring to the simplicity of the BFD echo function (and the associated processing)? > > A diagnostic code specifying the local system's reason for the > > last transition of the session from Up to some other state. > > Values are: > > > > 0 -- No Diagnostic > > 1 -- Control Detection Time Expired > > 2 -- Echo Function Failed > > 3 -- Neighbor Signaled Session Down > > 4 -- Forwarding Plane Reset > > 5 -- Path Down > > 6 -- Concatenated Path Down > > 7 -- Administratively Down > > > > ==> 8-15 are still free, right? > > ==> should one add "15 -- Other Reason" ? > > Yes, they're still free; Might not hurt to state that explicitly. > however I don't see any semantic distinction > between "No Diagnostic" and "Other Reason"; either way the session > went down, so there's definitely some reason that is not in the list of > well defined reasons. I guess I view the distinction mainly as that the box implements. For example, if you didn't bother to implement (or report) Diagnostic codes even if you were able to dig them up you could report "No Diagnostic". However, if there was some weird error (currently unspecified, maybe), and one implemented all the reasons, one could use like "Other Reason". I don't feel strongly about this but operationally I'd like to be able to distinguish "no, I don't want to tell you any diagnostics or I don't support that" from "whoops -- something really weird happened". > > (This also may need some reorganization, as commented earlier, as > > "Echo Function Failed" seems to lose the diagnostics and valueble > > information if you're using echo function.) > > The intent is that "Echo Function Failed" is equivalent to "Control > Detection Time Expired" so the semantic content should be the same. One related section: ---- Specific diagnostic codes are provided for two scenarios. If signalling is received from outside BFD that the underlying path has failed, an implementation MAY adminstratively disable the session with the diagnostic Path Down. If the path being monitored by BFD is concatenated with other paths, it may be desirable to administratively bring down the BFD session when a concatenated path fails (as a way of propagating the failure indication.) In this case, an implementation MAY administratively disable the BFD session with the diagnostic Concatenated Path Down. Other scenarios MAY use the diagnostic Administratively Down. ---- .. do these diagnostics refer to the *local* errors only? That is, you don't signal them to your BFD peer? (Naturally, there will probably be a huge problem of actually delivering the diagnostic through :-). So, if the only way to disable a link is either through Echo function failure or Control Det. Time Expired, there is no problem, except maybe in the case where a link is malfunctioning in one direction but working in the other (in which case the BFD peer could signal, "hey, I haven't heard anything from you in a while!). > > Length > > > > Length of the BFD Control packet, in bytes. > > > > ==> Wouldn't it be nicer to use the units of 8 bytes (due to > > alignment, and to reduce the number of unnecessary info)? With the > > current Length, using the units of 64 bits would allow one to specify > > longer lengths (up to 2040), which might help if you want to, at some > > point, send e.g. extra data along with the packets (e.g., to notice if > > longer packets fail even if the shorter ones work). > > This was purposeful; one of the goals of the protocol is to keep the > packets short and simple. We're resisting efforts to add extra stuff, > the urge for which seems to be almost universal. > > In any case, trying to detect packet length-dependent problems in a > link is not a goal (and there are fewer and fewer media that even have > this characteristic.) We're trying to keep this protocol universal and > media-type independent. > > If it ever really has to get longer, we can always bump the version > number. I can agree with this. Our ATM interfaces (which have multiple times shown this misbehaviour -- small packets work but larger ones fail) are getting scarce anyway. > > ... > > > > If the session goes down, the transmission of Echo packets (if any) > > ceases, and the transmission of Control packets goes back to the > > slow > > rate. > > > > 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. > > > > ==> Doesn't this cause problems if the other end is in Passive > > mode? > > No, because the remote discriminator is not cleared, only the H bit. > The Passive role is specifically to deal with the case where there may > be multiple sessions and the remote discriminator isn't yet known (so > the incoming packets can't be demuxed to the right session.) OK. > > If bfd.DetectMult is equal to 1, the interval between transmitted > > BFD > > Control packets MUST be no more than 90% of the negotiated > > transmission interval, and MUST be no less than 75% of the > > negotiated > > transmission interval. This is to ensure that, on the remote > > system, > > the calculated DetectTime does not pass prior to the receipt of the > > next BFD Control packet. > > > > ==> I do not understand why "no less than 75%" rule exists there, this > > doesn't seem to have anything to do with the above DetectTime > > reasoning? (of course, it might make sense otherwise.) > > This is the 25% jitter; normal packets must be sent at no more than > 100% nor less than 75% of the negotiated interval. Right, I see that. But my point was that there doesn't seem to be any technical reason to forbid processing the received packets if they happened to be sent a little bit faster than agreed to. Or do you want to ensure that both parties conform to the values which have been agreed to, and don't just modify them on their own? If so, maybe this needs to be spelled out a bit more. > > system, multiplied by the agreed transmit interval (the greater of > > bfd.RequiredMinRxInterval and the last received Desired Min TX > > Interval.) The Detect Mult value is (roughly speaking, due to > > > > ==> You mix the bfd.XXXX and "spelled out" terms ("Desired Min TX > > Interval"). Use just one of them, e.g. by replacing the latter one by > > bfd.DesiredMinTxInterval. (The same happens elsewhere as well.) > > No, these are not the same things. The bfd.XXX references refer to the > contents of the state block. The "spelled out" terms refer to the > fields in a received packet, which may or may not have been copied into > the state block. Ok, obviously I missed the point about the difference, and got very confused. Maybe this is something that could be clarified a bit more? > > 6.5.5. Detecting Failures with the Echo Function > > > > When the Echo function is active and a sufficient number of Echo > > packets have not arrived as they should, the session has gone > > down--the local system MUST set bfd.SessionState to Failing, > > bfd.RemoteHeard to zero, and bfd.LocalDiag to 2 (The Echo Function > > Failed.) > > > > ==> I do not believe there has been an explicit specification how what > > the sufficient number of Echo packets is. Note that the previous > > section used MinTX/MinRX Intervals, and as there is a separate Echo > > interval -- so it doesn't apply as is at least. > > No, there is very specifically *no* specification as to how the Echo > function works, as this is a purely local matter. The system may count > packets, it might track time, it might look at sequence numbers, or > anything else that might be dreamt up by an implementor. If Echo function could really be looking at the packets, tracking time or looking at sequence numbers, it's seems like a huge misnomer -- I got the impression that you send a packet, the peer reflects it and you receive it back. How the reflection is done is left unspecified which is probably fine. I guess this is something that needs significant clarification -- anything that is left unspecified has to be specified in some detail that people understand what's being left unspecified :-) [[ EDIT: ]] After reading through to section 4.1 and 4.2 of the v4v6-1hop BFD document, I start to realize which kind of "echo" service you had in mind: I associate echo with "UDP echo" service, you as sending a packet in such a fashion that it gets forwarded back at you. This requires a lot of clarification, I think. This kind of "forward-back" routing might break the very common ingress filtering mechanisms, though -- e.g., if a customer has put in a filter "discard all incoming packets from the ISP which use my addresses" (well, maybe not necessarily, depends of thr strictness of the filter, if the P-t-P address is from the ISP's address block) unless there is an exception, correct? This warrants a special mention, I think? > > ==> wouldn't it be useful to use the similar diagnostic codes for Echo > > failures than control packet failures? It seems you'll lose > > information about the possible causes of the loss of connectivity if > > you use Echo function? > > There is only one diagnostic code that denotes the fact that control > packets stopped coming, so the Echo function is the same in this > respect. The other diagnostics are either informational about the > sending system, or are part of the BFD state machine and are invariant > with respect to the use or non-use of Echo. (For instance, if one > system detects a failure by the lack of either type of packet and tears > down the session, the other system will respond with "Neighbor Signaled > Session Down." OK. > > 6.5.6. Reception of BFD Control Packets > > > > When a BFD Control packet is received, the following procedure MUST > > be followed, in the order specified: > > > > If the version number is not correct (0), the packet MUST be > > discarded. > > > > ==> What is the proposed backward compatibility mechanism? Run each > > version of BFD on all the links, and try to connect starting from the > > highest supported version, etc. ? > > It's outside of the scope of this spec. If we ever end up bumping the > version number, we could include verbiage in that document that spells > it out, but the only real correctness issue is to make sure that you > don't end up running two sessions (one per version) that represents the > same link. There would be no requirement for backward compatibility > (though it certainly would not be precluded) as supporting multiple > versions is a vendor choice. If the previous version has a large > deployed base, it would be in a vendor's best interest to do so, but I > am generally against requiring anything in a protocol unless it is > *really* necessary. (My experience is that, counterintuitively, more > MUSTs make interoperability harder.) Yep, I wouldn't want to require anything at this stage -- just add a cautionary paragraph about the consequences of versioning scheme. > > If the version number is not correct (0), the packet MUST be > > discarded. > > > > ==> should it be spelled out that s/discard/silently discard/ ? > > As opposed to what? There is no mechanism in the protocol for > announcing this event to the world, and an implementation may indeed > want to complain loudly to network management or something. The term "silently discard" is often used to refer to dropping the packet without an ICMP message (but taking no stance on what's reported internally). Kind of like spelling out the obvious difference between "discard" and "reject with an ICMP message". Not sure whether it makes worth spelling out here, though.. but I'm pretty sure this issue will come up later in the review as this is kind of a "check-list item". > > ==> You should clarify what you refer to with the "more difficult" > > BFD. MPLS network? Network with tunnels? A BFD-using protocol which > > establishes adjacencies over multiple hops (e.g. IBGP, even though > > that's a bad example)? > > I'm not sure what you're referring to here. If you are referring to > the conditions for which the TTL hack won't work, it's the converse of > the case where it does work--anything where BFD traverses more than a > single network layer hop. You use the terms, "network-layer" and "a signle link" -- how do these relate in a network where something employing virtual topologies like MPLS or tunneled networks? Not probably a huge issue, but just something that struct me as being slightly ambiguous. > > If BFD is run across multiple hops, some alternative > > mechanism MUST be used. One option would be to ensure that the > > network addresses used for BFD are not routable outside of the > > infrastructure in which BFD is running (and assuming there are no > > users connected within that network.) > > > > ==> I strongly object to that proposition. First, this seems like a > > recommendation to use private addresses. If it's not, you're assuming > > that the operators would use specific addresses for these purposes and > > block them at the border. But that would hinder the other uses of the > > interface addresses (i.e., it's operationally impossible), and more > > importantly, the BFD mechanism has not way to ensure that this > > checking has in fact been configured by the operator. > > There is nothing to stop an operator from assigning both public and > private addresses to interfaces and only accepting BFD packets > addressed to the private address space, for instance. In any case, > this language is not normative; it's just attempting to list > alternatives other than cryptographic methods. However, if an operator > really wanted to use private addressing internally to their network, > they're free to do so. Right, but this seems to hint at a recommendation for the private addressing use, which has significant drawbacks which should be spelled out more. > Furthermore, it is not possible in any protocol to guarantee that the > operator hasn't misconfigured their network. Guarantees of operational > correctness are *way* outside the scope of the specification. Of course, but it would be desirable that protocols would default to a mode (unless explicitly configured otherwise) which includes the guarantees (e.g., require the TTL=255). In the security considerations, it would also seem to be appropriate spell out which measures must be taken by the operator to secure the protocol usage, and which measures are (or can be taken) by the protocol itself to ensure the security. > > Another option would > > be to > > filter all packets carrying BFD's UDP ports at the edges of the > > network. > > > > ==> This is bad as well, because it could hinder the transited > > traffic. However, if this was coupled by edge-based access-lists w/ > > IP addresses and ports, the tradeoffs might be acceptable. However > > this still has a number of problems, as discussed above. > > See above. These are viable choices (from the perspective of BFD > security) if someone wishes to use them. If using them would hose > their networks in some other way, then perhaps the operators might not > want to use them. There's plenty of this sort of thing happening now > in brute-force attempts to deal with viruses, for instance. (Having > said all that, I agree that this probably isn't the best way to attack > the problem, and is unnecessary if operators are vigilant about edge > filtering for packets destined to internal addresses, which they really > ought to be already or they're in a whole lot of danger.) Yep -- I think we agree in principle, but I'd like to see longer discussion of those options, because one could interpret them as an advice (which you certainly don't want it to be). Maybe I could try to cook up some text if we agree about the rest and I understand what you mean with the network-layer/single-link scenarios.. > >> Still another option would be to use cryptographic methods, > >> though this is not likely to allow for very short detection times. > > > > ==> Too bad! :-) > > Yeah, this gets at the heart of the problem, at least until crypto > stuff gets cheap enough and fast enough to put in simple hardware. At > this point, there is a tension between fast detection and crypto, at > least for boxes cheaper than ours. ;-) Right; what I was trying to say was, if you need to deploy this in the scenario where you need heavy crypto, the very short detection times are probably NOT your number one concern :-) > > draft-katz-ward-bfd-v4v6-1hop-00.txt: > > ===================================== > > > > ==> you should include the support for static routing. That would > > likely be extremely useful (as you can't run an IGP between the > > operator and the customer, and the link is very often an Ethernet > > variant, which doesn't provide good link state change notifications). > > I've already worked out some details in my head, and this should be > > rather simple. > > Yep, there's a lot of call for this, I'll add something, though it will > require some careful wordsmithing to get across the point without > referring to specific system implementations. Keep in mind that this > is not really subject to standardization, since it's purely an internal > matter. Yep, this very likely requires some serious thinking wrt. wording. However, I'm not 100% sure this does not require standardization as such. To make the "static-route BFD" mechanisms work, there seems to be a requirement to specify at least certain details of the way it works (e.g., how it picks the addresses, where does it expect a response from, how it deals with IPv6 route pointing to a global address if the BFD packet would come from a link-local and not global, etc.) -- if for nothing else, to ensure this stuff interoperates. > > ==> You don't discuss the case what happens if you run IS-IS for IPv4 > > only, and OSPFv3 -- or IS-IS for IPv6 only and OSPFv2 on the same > > links, as dual-stack infrastructure. What about OSPFv2+OSPFv3 for that > > matter? These are common deployment scenarios, and we run one of > > these as well. Would you have two sessions between the nodes on each > > link (one for each network-layer protocol used) or one? > > The base spec is clear (or it should be) that there is one session per > data protocol at the layer at which it is running (so in the network > layer case, one for v4 and one for v6.) A little bit of language in > this spec should make that clearer. Yep. > There should be a bit of language saying that the interaction between > BFD and adjacencies should be based on the data protocol (so a v4 BFD > failure should shoot down OSPFv2 and ISIS-for-v4 adjacencies, etc.) Yep, this seems like the intended result :-) > If > I recall the v6 extensions for ISIS (I implemented them, but it's been > a long time) we'll have to do a bit more weasel wording, to the effect > that if, say a v4 BFD session fails, the routing protocol shouldn't > advertise adjacency for that data protocol. This should hold for v4 in > OSPFv3, if anybody ever bothers to do that. Yes, this is a slight problem. I think IS-IS is basically IP-independent at the network-layer, as the adjacencies aren't between IP addresses but CLNS addresses representing a node. But should be doable. Of course -- it might also be attractive, with congruent v4/v6 dual-stack topologies -- that if you only use one protocol (e.g., IS-IS) for both v4 and v6, BFD would only check one of them and not both. But fiddling that may not be worth the trouble. > We also need language talking about the interaction with graceless > restart in both protocols. Yes. > > ==> btw, use "IS-IS" rather than "ISIS" :-) > > At least I didn't say "Intermediate System to Intermediate System > Intradomain Routeing Protocol." ;-) > > 1. Introduction > > > > One very desirable application for BFD is to track IPv4 and > > IPv6 > > connectivity between directly-connected systems. This could be used > > to supplant the detection mechanisms in ISIS and OSPF, or to monitor > > router-host connectivity, among other applications. > > > > ==> note that the BFD document explicitly discusses it as a mechanism > > between "forwarding engines", which seems to exlude router-host > > connectivity (which could be useful). Maybe the main BFD document > > could use a bit of rewording? > > Yeah, a few more weasel words would help. Yep :-) > > The source address MUST be > > chosen in such a way as to preclude the remote system from > > generating > > ICMP Redirect messages (in particular, the source address MUST NOT > > be > > part of the subnet bound to the interface over which the BFD Echo > > packet is being transmitted.) > > > > ==> the last sentence is not clear -- does the MUST NOT apply to what > > must not be done (i.e., cause the generation of ICMP redirects) or > > what must be done? :-). When you think about it, it's obvious but the > > wording is crap :-). > > I think the wording is unambiguous, given the parentheses. You're more > than welcome to suggest alternative text, however. "Crap," hrmph. I > like to think of the words as "pearls." ;-) Sure. See below. > > > > 4.1. BFD for IPv4 > > 4.2. BFD for IPv6 > > > > ==> there seems to be no need to restate the same things twice. > > Combine these in one section, and state the differences where > > applicable. > > I get paid by the word. ;-) I hope that doesn't also apply to the code ;-) > I don't think it would make it any clearer to combine them. Hmm.. I disagree a bit. I had an immediate reaction "so, what's the difference of these protocols?" and didn't get an immediate answer. Let me suggest: 4.1. BFD for IPv4 or IPv6 The use of BFD is identical whether it is encapsulated in an IPv4 or IPv6 datagram. Within an IP packet, BFD Control packets MUST be transmitted in UDP packets with destination port 3784. The source port MUST be in the range 49152 through 65535. The same UDP source port number MUST be used for all BFD Control packets associated with a particular session. The source port number SHOULD be unique among all BFD sessions on the system. If more than 16384 BFD sessions are simultaneously active, UDP source port numbers MAY be reused on multiple sessions, but the number of distinct uses of the same UDP source port number SHOULD be minimized. An implementation MAY use the UDP port source number to aid in demultiplexing incoming BFD Control packets, but ultimately the mechanisms in [BFD] MUST be used to demultiplex incoming packets to the proper session. BFD Echo packets are transmitted in UDP packets with destination UDP port 3785 in an IP packet. The setting of the UDP source port is outside the scope of this specification. The source and destination addresses MUST both be associated with the local system. The destination address MUST be chosen in such a way as to cause the remote system to forward the packet back to the local system. The source address MUST be chosen in such a way (e.g., by using an address of the on-link subnet) that the remote system will not generate ICMP Redirect messages. There was one sentence which was missing in v6 and one in v4. I don't think that was intentional, but not sure.. > > 5. TTL Issues > > > > ==> with IPv6 this is called Hop Limit. > > Thanks. I guess they didn't subscribe to the IETF tradition of > preserving our investment in terminology. ;-) Right. The folks wanted to get remembered _somehow_ I think ;-) > > On an unnumbered point-to-point link, the source address of a BFD > > Control packet MUST NOT be used to identify the session. This means > > that the initial BFD packet MUST be accepted with any source > > address, > > and that subsequent BFD packets MUST be demultiplexed solely by the > > My Discriminator field (as is always the case.) This allows the > > source address to change if necessary. > > > > ==> this has security issues, especially if TTL=255 check was not in > > place. Why this is not serious in this specific scenario should be > > described in the security considerations. > > There are no additional security issues caused by this, since the > source address can be spoofed if you can just get the packet there. > Since this document is for the single hop case (and explicitly calls > out the TTL hack), what happens in the multihop case is not relevant > here. Well, I'd still try to do something about it, in case some poor fool copies this document over to multihop, e.g. add to the end: (Note that this kind of model allowing the source address to change could be dangerous in a multihop scenario or if the TTL=255 check was not used.) (or something similar in the sec cons) -- it just shows one has considered the issue, and spelling security considerations out is always a good way to speed up a draft in the IETF process ;-) -- 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 exim@www1.ietf.org Thu Jan 22 17:36:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15878 for ; Thu, 22 Jan 2004 17:36:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjnQd-0000Xc-5B for rtg-bfd-archive@odin.ietf.org; Thu, 22 Jan 2004 17:35:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MMZxuu002079 for rtg-bfd-archive@odin.ietf.org; Thu, 22 Jan 2004 17:35:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjnQc-0000XS-Tj for rtg-bfd-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 17:35:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15866 for ; Thu, 22 Jan 2004 17:35:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjnQV-0001vG-00 for rtg-bfd-web-archive@ietf.org; Thu, 22 Jan 2004 17:35:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjnHj-0000s9-00 for rtg-bfd-web-archive@ietf.org; Thu, 22 Jan 2004 17:26:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajn7e-0000Fe-00 for rtg-bfd-web-archive@ietf.org; Thu, 22 Jan 2004 17:16:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajn7J-0007nz-SN; Thu, 22 Jan 2004 17:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEBNU-0003WI-Om for rtg-bfd@optimus.ietf.org; Mon, 27 Oct 2003 12:42:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27064 for ; Mon, 27 Oct 2003 12:41:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEBNT-00013I-00 for rtg-bfd@ietf.org; Mon, 27 Oct 2003 12:42:03 -0500 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 1AEBNR-00012u-00 for rtg-bfd@ietf.org; Mon, 27 Oct 2003 12:42:02 -0500 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h9RHfO010933 for rtg-bfd@ietf.org; Mon, 27 Oct 2003 18:41:24 +0100 Date: Mon, 27 Oct 2003 18:41:24 +0100 From: Hannes Gredler To: rtg-bfd@ietf.org Subject: tcpdump support for BFD Message-ID: <20031027174124.GA10868@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: rtg-bfd-admin@ietf.org Errors-To: rtg-bfd-admin@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: RTG Area: Bidirectional Forwarding Detection DT List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 hi guys, the CVS version of tcpdump http://www.tcpdump.org now supports BFD Control Packets as per draft-katz-ward-bfd-01.txt; source is located at: http://cvs.tcpdump.org/cgi-bin/cvsweb/tcpdump/print-bfd.c /hannes From exim@www1.ietf.org Fri Jan 23 04:42:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21797 for ; Fri, 23 Jan 2004 04:42:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajxpf-0000Sm-BT for rtg-bfd-archive@odin.ietf.org; Fri, 23 Jan 2004 04:42:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0N9gVKA001773 for rtg-bfd-archive@odin.ietf.org; Fri, 23 Jan 2004 04:42:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajxpe-0000SW-W4 for rtg-bfd-web-archive@optimus.ietf.org; Fri, 23 Jan 2004 04:42:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21681 for ; Fri, 23 Jan 2004 04:42:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajxpc-0002Hs-00 for rtg-bfd-web-archive@ietf.org; Fri, 23 Jan 2004 04:42:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajxno-0001ux-00 for rtg-bfd-web-archive@ietf.org; Fri, 23 Jan 2004 04:40:38 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjxlK-0001Nk-00 for rtg-bfd-web-archive@ietf.org; Fri, 23 Jan 2004 04:38:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjxlK-0008Ry-ML; Fri, 23 Jan 2004 04:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajxkv-0008MQ-1G for rtg-bfd@optimus.ietf.org; Fri, 23 Jan 2004 04:37:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20923 for ; Fri, 23 Jan 2004 04:37:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajxks-0001H3-00 for rtg-bfd@ietf.org; Fri, 23 Jan 2004 04:37:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajxi4-0000f3-00 for rtg-bfd@ietf.org; Fri, 23 Jan 2004 04:34:42 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajxeq-0007iS-00 for rtg-bfd@ietf.org; Fri, 23 Jan 2004 04:31:21 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0N9UEj15445 for ; Fri, 23 Jan 2004 11:30:14 +0200 Date: Fri, 23 Jan 2004 11:30:14 +0200 (EET) From: Pekka Savola To: rtg-bfd@ietf.org Subject: BFD and eBGP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-bfd-admin@ietf.org Errors-To: rtg-bfd-admin@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: RTG Area: Bidirectional Forwarding Detection DT List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, As I proposed BFD for static routes, it struck me (now that we suffered a small outage due to eBGP timeout :-) that eBGP would profit *enermously* from BFD. You usually don't run other routing protocols on such links, so if the physical link doesn't provide link-state notifications, you're pretty much down to very long BGP timeouts if the link fails. Something to add to the draft-katz-ward-bfd-v4v6-1hop-00.txt document, only describing non-multihop case? (It's pretty trivial as well, because you don't even have to figure which addresses to use between the BGP session endpoints..) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings