From rtg-bfd-bounces@ietf.org Tue Mar 1 07:34:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18674; Tue, 1 Mar 2005 07:34:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D66ax-0001lm-NT; Tue, 01 Mar 2005 07:35:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D66Yc-0005h3-Iv; Tue, 01 Mar 2005 07:32:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D66YZ-0005gy-Jl for rtg-bfd@megatron.ietf.org; Tue, 01 Mar 2005 07:32:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18616 for ; Tue, 1 Mar 2005 07:32:52 -0500 (EST) From: richard.spencer@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D66ZW-0001kR-Bc for rtg-bfd@ietf.org; Tue, 01 Mar 2005 07:33:54 -0500 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Tue, 1 Mar 2005 12:32:44 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 1 Mar 2005 12:32:41 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Mar 2005 12:32:40 -0000 Message-ID: Thread-Topic: draft-suping-bfd-mpls-fecmismatch-00 questions thread-index: AcUd370tyiKWdz4PTHeC/zDvx1YZ5AAajVGw To: , X-OriginalArrivalTime: 01 Mar 2005 12:32:41.0053 (UTC) FILETIME=[C29790D0:01C51E5A] X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org Subject: RE: draft-suping-bfd-mpls-fecmismatch-00 questions X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Suping Zhai, Dave, >From what I understand, the purpose of the FEC filter is to verify that = the FEC for incoming traffic matches an egress FEC for the corresponding = LSP. This verification is performed by comparing the FEC filter in the = received BFD packet with the egress FEC filter for the LSP concerned. So = in basic terms, if we receive a packet with a FEC of 10.2.10.1, we check = that the egress LSP has been set up to forward traffic for FEC 10.2.10.1 = (although the check uses a filter that represents 10.2.10.1 rather than = the FEC itself). Is my understanding here correct? Other things I would like to understand are: 1. Is the check just performed at client/server sink termination points = (i.e. points in the network where a label is popped), or does the check = take place at connection/flow points as well (i.e. points in the network = where labels are swapped)? 2. Does this function support L1/L2 FECs as well as IP address FECs? = e.g. where the FEC for a PW is an Ethernet VLAN/port or an ATM VCI/VPI? 3. Does the FEC filter detect defects that LSP ping can't? Or does it = provide the same functionality (or subset of functionality) but because = it is less processing intensive it can be used at more frequent time = intervals? There is obviously a need to detect data/control plane inconsistencies, = and therefore the FEC filter is a useful function. However, is there = likely to be a processing hit, i.e. a reduction in the number of BFD = sessions I can support? If not, then from an operators perspective, if I = can switch on BFD and it will detect these defects "for free" then this = would be a desirable addition to BFD. Saying that, looking at things from a vendors perspective, if this = function can already be performed using LSP ping, then I guess spending = time/money adding this function into BFD comes down to determining how = often we need to check for these defects, i.e. LSP ping minutes, BFD = seconds. I guess that only time will tell how frequently these types of = defects occur based on operational experience. Regards, Richard > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org]On > Behalf Of Thomas D. Nadeau > Sent: 28 February 2005 21:51 > To: Jeffrey Haas > Cc: rtg-bfd@ietf.org; 'David Ward' > Subject: Re: draft-suping-bfd-mpls-fecmismatch-00 questions >=20 >=20 >=20 > On Feb 28, 2005, at 4:00 PM, Jeffrey Haas wrote: >=20 > > On Mon, Feb 28, 2005 at 03:57:18PM -0500, David Allan wrote: > >>> BFD won't be able to tell you what is actually broken. OAM > >>> thingies do this. > >> > >> Agreed, goal is to simply know so you can follow up... > > > > Then wouldn't it be best to BFD for what it is good at,=20 > namely checking > > that forwarding is working, and then use another mechanism to clean > > house when something fails? >=20 > I explained in my first posting on this draft that there > already exist mechanisms that can be used to confirm the > consistency of the sessions. There is no need for another > mechanism, IMO. >=20 > --Tom >=20 >=20 >=20 > > > > By analogy, one doesn't extend ICMP to check your interface=20 > > configuration > > because you want to add this to your ping. > > > > (Then again, seeing such a thing proposed in the IPv6 working groups > > wouldn't shock me at all. :-) > > > > > > --=20 > > Jeff Haas > > NextHop Technologies > > >=20 >=20 From rtg-bfd-bounces@ietf.org Tue Mar 1 09:30:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29143; Tue, 1 Mar 2005 09:30:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D68Pn-0004Z5-Ta; Tue, 01 Mar 2005 09:32:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D68Mn-0004EH-Hk; Tue, 01 Mar 2005 09:28:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D68Ml-0004E4-Do for rtg-bfd@megatron.ietf.org; Tue, 01 Mar 2005 09:28:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28999 for ; Tue, 1 Mar 2005 09:28:50 -0500 (EST) From: richard.spencer@bt.com Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D68Nj-0004WX-AH for rtg-bfd@ietf.org; Tue, 01 Mar 2005 09:29:51 -0500 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Tue, 1 Mar 2005 14:28:19 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 1 Mar 2005 14:28:13 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Mar 2005 14:28:12 -0000 Message-ID: Thread-Topic: Exiting loss of connectivity state thread-index: AcUearq6Ks2YGb4rSUa8ibc1DJc2Mw== To: X-OriginalArrivalTime: 01 Mar 2005 14:28:13.0280 (UTC) FILETIME=[E6857600:01C51E6A] X-Spam-Score: 0.3 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Subject: Exiting loss of connectivity state X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable According to the current base draft "The Detect Mult value is (roughly = speaking, due to jitter) the number of packets that have to be missed in = a row to declare the session to be down." So, if the TX Interval is 1sec = and the Detect Mult is 3 (in both directions), and a unidirectional = failure occurs in the direction A->B, then: - B will declare the session down (roughly speaking, due to jitter) = after non receipt of BFD packets over a 3 second period. - A will declare the session down after the time it takes B to detect = the failure (about 3 secs in this example) and then send a BFD packet to = A with I Hear You 0 and Local Diag 1. This approach is consistent with other OAM mechanisms, i.e. by = configuring the TX Interval to be 1sec and the Detect Mult to be 3, the = loss of connectivity state is entered after non-receipt of packets over = a 3sec period. However, how long does it take for a BFD session to be = declared up again after connectivity has been restored, i.e. what is the = exit criteria for the loss of connectivity state?=20 Other OAM mechanisms use exit criteria that is consistent with the entry = criteria, i.e. the loss of connectivity state is exited after receiving = the expected number of OAM packets over a 3 second period. In BFDs case, = the time taken and number of packets TX/RX required to transition from = the Down/Failing/Init state to the Up state is dependant on the current = session states at the time connectivity is restored, and how quickly an = implementation sends BFD packets (i.e. whether or not between schedule = BFD sessions are sent and for which state changes). I have worked = through a few scenarios, and depending on the variables, it could take a = less than a second or several seconds for a session to come back up = again (or a session might not ever come back up under specific = conditions based on discussions on a previous thread "Re: Between = schedule transmissions"). MPLS BFD has been proposed as a connection verification tool for MPLS = LSPs. It seems to me that the current BFD draft allows an operator to = determine when connectivity has been lost (i.e. following detection = timeout) but does not allow operators to determine with any certainty = if/when connectivity has been restored. This information is important in = checking that SLAs are being met, i.e. how long connectivity has been = lost for. This information is also important for protection switching as = the backup path may be expensive to use or may not have sufficient = resource for all traffic (i.e. lower priority traffic is dropped), and = therefore we need to switch back over to the primary as soon as possible = after connectivity has been restored. It appears to me that extensive work will need to be carried out by = operators in analysing different failure scenarios in order to determine = what the effect of sessions being declared back up at different time = periods will be, and to ensure that the probability of BFD sessions not = coming back up at all is as close to zero as possible. Testing will be = particularly important where BFD sessions are used across multiple = levels of hierarchy (e.g. a BFD session could be declared up at a client = layer before a BFD session at server layer), and also in multivendor = environments where implementations may or may not send between schedule = transmissions for different state transitions. Does anyone have any comments/solutions regarding this problem? Thanks, Richard From rtg-bfd-bounces@ietf.org Tue Mar 1 10:22:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05238; Tue, 1 Mar 2005 10:22:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D69DU-0005s2-GX; Tue, 01 Mar 2005 10:23:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D69BB-0006D8-M1; Tue, 01 Mar 2005 10:20:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D69B9-0006Cm-7l for rtg-bfd@megatron.ietf.org; Tue, 01 Mar 2005 10:20:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05037 for ; Tue, 1 Mar 2005 10:20:53 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D69C7-0005ow-HD for rtg-bfd@ietf.org; Tue, 01 Mar 2005 10:21:55 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j21FKhZ21485 for ; Tue, 1 Mar 2005 10:20:43 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1JJLTX3C>; Tue, 1 Mar 2005 10:20:42 -0500 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE03192DAD@zcarhxm2.corp.nortel.com> From: "David Allan" To: "'richard.spencer@bt.com'" , zhaisuping@huawei.com Date: Tue, 1 Mar 2005 10:20:33 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: rtg-bfd@ietf.org Subject: RE: draft-suping-bfd-mpls-fecmismatch-00 questions X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Hi Richard: > From what I understand, the purpose of the FEC filter is to > verify that the FEC for incoming traffic matches an egress > FEC for the corresponding LSP. This verification is performed > by comparing the FEC filter in the received BFD packet with > the egress FEC filter for the LSP concerned. So in basic > terms, if we receive a packet with a FEC of 10.2.10.1, we > check that the egress LSP has been set up to forward traffic > for FEC 10.2.10.1 (although the check uses a filter that > represents 10.2.10.1 rather than the FEC itself). Is my > understanding here correct? Yes, correct on both counts, the filter is simply a common "control plane independent" encoding of the FEC. > 1. Is the check just performed at client/server sink > termination points (i.e. points in the network where a label > is popped), or does the check take place at connection/flow > points as well (i.e. points in the network where labels are swapped)? As there is no concept of a MIP in MPLS, it is only sink termination points... > 2. Does this function support L1/L2 FECs as well as IP > address FECs? e.g. where the FEC for a PW is an Ethernet > VLAN/port or an ATM VCI/VPI? 1713 has a place holder for encoding rules, but as the PW FECs were not finalized at the time of publishing, an addemdum would be required (if those rules were adopted). Not a big deal... > 3. Does the FEC filter detect defects that LSP ping can't? Or > does it provide the same functionality (or subset of > functionality) but because it is less processing intensive it > can be used at more frequent time intervals? Provides subset of functionality at a much lower processing cost... (no traceroute, no FEC stack, simply a pairwise relationship). Answers the question "Does LSP function at egress correspond to LSP function at ingress". Note that this is stateless in that the egress does not maintain per ingress state for this check.... > > There is obviously a need to detect data/control plane > inconsistencies, and therefore the FEC filter is a useful > function. However, is there likely to be a processing hit, > i.e. a reduction in the number of BFD sessions I can support? > If not, then from an operators perspective, if I can switch > on BFD and it will detect these defects "for free" then this > would be a desirable addition to BFD. Processing is AND one field with the inverse of the other, (est. 16 assembler instructions for an 8 bit processor...) and if result is non zero, there is a fault. Of course if I code it in Java....;-). It was as close to free as it could be made... > > Saying that, looking at things from a vendors perspective, if > this function can already be performed using LSP ping, then I > guess spending time/money adding this function into BFD comes > down to determining how often we need to check for these > defects, i.e. LSP ping minutes, BFD seconds. I guess that > only time will tell how frequently these types of defects > occur based on operational experience. And the relative cost of PING when used proactively... cheers Dave > > Regards, > Richard > > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org]On > > Behalf Of Thomas D. Nadeau > > Sent: 28 February 2005 21:51 > > To: Jeffrey Haas > > Cc: rtg-bfd@ietf.org; 'David Ward' > > Subject: Re: draft-suping-bfd-mpls-fecmismatch-00 questions > > > > > > > > On Feb 28, 2005, at 4:00 PM, Jeffrey Haas wrote: > > > > > On Mon, Feb 28, 2005 at 03:57:18PM -0500, David Allan wrote: > > >>> BFD won't be able to tell you what is actually broken. OAM > > >>> thingies do this. > > >> > > >> Agreed, goal is to simply know so you can follow up... > > > > > > Then wouldn't it be best to BFD for what it is good at, > > namely checking > > > that forwarding is working, and then use another > mechanism to clean > > > house when something fails? > > > > I explained in my first posting on this draft that > there already > > exist mechanisms that can be used to confirm the consistency of the > > sessions. There is no need for another mechanism, IMO. > > > > --Tom > > > > > > > > > > > > By analogy, one doesn't extend ICMP to check your interface > > > configuration > > > because you want to add this to your ping. > > > > > > (Then again, seeing such a thing proposed in the IPv6 > working groups > > > wouldn't shock me at all. :-) > > > > > > > > > -- > > > Jeff Haas > > > NextHop Technologies > > > > > > > > > From rtg-bfd-bounces@ietf.org Tue Mar 1 12:10:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18040; Tue, 1 Mar 2005 12:10:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6AuR-0000Qc-6Z; Tue, 01 Mar 2005 12:11:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6AsL-00058G-V4; Tue, 01 Mar 2005 12:09:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6AsK-00057w-MF for rtg-bfd@megatron.ietf.org; Tue, 01 Mar 2005 12:09:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17854 for ; Tue, 1 Mar 2005 12:09:34 -0500 (EST) From: richard.spencer@bt.com Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6AtK-0000OB-2r for rtg-bfd@ietf.org; Tue, 01 Mar 2005 12:10:38 -0500 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Tue, 1 Mar 2005 17:09:26 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 1 Mar 2005 17:09:26 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Mar 2005 17:09:26 -0000 Message-ID: Thread-Topic: Ability to detect swapped/merged LSPs thread-index: AcUegUChKJrpkS1TSXOkt6KOkb4hjg== To: X-OriginalArrivalTime: 01 Mar 2005 17:09:26.0539 (UTC) FILETIME=[6C3BA5B0:01C51E81] X-Spam-Score: 0.3 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Subject: Ability to detect swapped/merged LSPs X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable >From the current base draft "If the Your Discriminator field is nonzero, = it MUST be used to select the session with which this BFD packet is = associated. If no session is found, the packet MUST be discarded." If a node receives a BFD packet with a Discriminator field that it = doesn't have a session for then there is a problem somewhere in the = network, so why is the packet simply dropped and no further action = taken? If we get a swapped LSP (e.g. due to a corrupted forwarding table or = configuration error) then all BFD packets received for the corresponding = session will be dropped and the session will be declared down as a = detection timeout will occur. However, if we get a merging defect where = a node receives both valid BFD packets in addition to invalid BFD = packets then this defect will not be detected. In both cases, traffic is being forwarded onto the wrong destination and = therefore these defects need to be detected and appropriate actions = taken, e.g. raise an alarm and inform the LSP source (using the = appropriate BFD status code) that a defect has occurred so that the = source can stop forwarding packets or switch over to an alternative path = if one exists. I know that the idea behind the BFD draft is to keep it as simple as = possible, but speaking as an operator, I would consider these defects to = be just as important as loss of connectivity defects. They might not = occur as frequently but are potentially more dangerous, e.g. I don't = want to unknowingly be sending packets from customer As network to = customer Bs network.=20 By adding new processing rules and status codes, both of these defects = could be detected using BFD. An alternative would be to use LSP ping but = it would not provide the same defect detection speed, i.e. an LSP might = only get tested using LSP pings every 30mins or maybe every hour in a = large network with hundreds of thousands of PWs/LSPs, as opposed to BFD = packets that can be sent every second. Does anyone have any arguments for/against adding the ability to detect = these defects into BFD? Thanks, Richard From rtg-bfd-bounces@ietf.org Tue Mar 1 12:54:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22237; Tue, 1 Mar 2005 12:54:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Bas-0001Tt-1m; Tue, 01 Mar 2005 12:55:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6BXN-00076r-WB; Tue, 01 Mar 2005 12:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6BXM-00076m-If for rtg-bfd@megatron.ietf.org; Tue, 01 Mar 2005 12:52:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21948 for ; Tue, 1 Mar 2005 12:51:57 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6BYM-0001Ph-4b for rtg-bfd@ietf.org; Tue, 01 Mar 2005 12:53:02 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 01 Mar 2005 11:07:30 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,127,1107734400"; d="scan'208"; a="230385076:sNHT23779302" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j21HphuC008593; Tue, 1 Mar 2005 09:51:44 -0800 (PST) Received: from [10.83.15.56] (rtp-tnadeau-vpn7.cisco.com [10.83.15.56]) by flask.cisco.com (MOS 3.4.6-GR) with SMTP id APM00822; Tue, 1 Mar 2005 12:51:45 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <43a86f27afff2648d38c6f82d5ea7789@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Date: Tue, 1 Mar 2005 12:51:44 -0500 To: richard.spencer@bt.com X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: Ability to detect swapped/merged LSPs X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit >> From the current base draft "If the Your Discriminator field is >> nonzero, it MUST be used to select the session with which this BFD >> packet is associated. If no session is found, the packet MUST be >> discarded." > > If a node receives a BFD packet with a Discriminator field that it > doesn't have a session for then there is a problem somewhere in the > network, so why is the packet simply dropped and no further action > taken? The packet is discarded, but the device can certainly take note of it. It just has to make sure this will not result in a DoS attack on the device. > If we get a swapped LSP (e.g. due to a corrupted forwarding table or > configuration error) then all BFD packets received for the > corresponding session will be dropped and the session will be declared > down as a detection timeout will occur. However, if we get a merging > defect where a node receives both valid BFD packets in addition to > invalid BFD packets then this defect will not be detected. Hi Richard, The defect will be detected in both cases due to the fact that the BFD session ID information at the receiver should be incorrect. Lets consider both cases: 1) Correct LSP, but corrupted BFD session parameters. This is the case you describe above. It is easily handled by virtue of BFD session parameter mismatch. 2) Incorrect LSP due to corrupted TFIB, but the payload remains intact and thus valid BFD session parameters. In this case the packet might make it to an LSR that happens to have BFD running. If it does, the BFD session information will not match with the source/destination. Thus, that should be detected as a failure since that node will not respond. The only case I think can't be detected with just BFD is the case where the mis-merged LSP happens to swap to a label that gets you to the correct destination LSR, albeit with the wrong label stack, and thus over the wrong last bit of the LSP. In this case, since the BFD information is valid, this MIGHT work okay, but not in all cases. For instance, if the end node is a PE for L3 or L2 VPN/PWs (i.e.: in VCCV), the application label will also be bound to the BFD session, and thus will fail. So there seems to be some unlikely corner cases where the basic mechanism can fail. The good news is that in all cases, if you just run LSP ping "every now and then", you can detect all of these corner cases as well due to the diag. processing in LSP ping. --Tom > In both cases, traffic is being forwarded onto the wrong destination > and therefore these defects need to be detected and appropriate > actions taken, e.g. raise an alarm and inform the LSP source (using > the appropriate BFD status code) that a defect has occurred so that > the source can stop forwarding packets or switch over to an > alternative path if one exists. > > I know that the idea behind the BFD draft is to keep it as simple as > possible, but speaking as an operator, I would consider these defects > to be just as important as loss of connectivity defects. They might > not occur as frequently but are potentially more dangerous, e.g. I > don't want to unknowingly be sending packets from customer As network > to customer Bs network. > > By adding new processing rules and status codes, both of these defects > could be detected using BFD. An alternative would be to use LSP ping > but it would not provide the same defect detection speed, i.e. an LSP > might only get tested using LSP pings every 30mins or maybe every hour > in a large network with hundreds of thousands of PWs/LSPs, as opposed > to BFD packets that can be sent every second. > > Does anyone have any arguments for/against adding the ability to > detect these defects into BFD? > > Thanks, > Richard > > > > > > > > > > From rtg-bfd-bounces@ietf.org Tue Mar 1 13:21:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24419; Tue, 1 Mar 2005 13:21:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6C0a-00022s-I2; Tue, 01 Mar 2005 13:22:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ByH-0003Ge-Pb; Tue, 01 Mar 2005 13:19:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ByG-0003GZ-UI for rtg-bfd@megatron.ietf.org; Tue, 01 Mar 2005 13:19:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24337 for ; Tue, 1 Mar 2005 13:19:45 -0500 (EST) Received: from staple.laurelnetworks.com ([63.94.127.68] ident=nobody) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6BzE-00020w-Gh for rtg-bfd@ietf.org; Tue, 01 Mar 2005 13:20:50 -0500 Received: from postit.laurelnetworks.com (postit.laurelnetworks.com [63.94.127.21]) by staple.laurelnetworks.com (Laurel/Laurel) with ESMTP id j21IGdGJ025712; Tue, 1 Mar 2005 13:16:39 -0500 Received: from cnogradi-linux.dhcp.pit.laurelnetworks.com (cnogradi-linux.dhcp.pit.laurelnetworks.com [10.0.19.158]) by postit.laurelnetworks.com (Laurel/Laurel) with ESMTP id j21IGcFS027970; Tue, 1 Mar 2005 13:16:39 -0500 From: Chris Nogradi Organization: Laurel Networks To: Dave Katz , David Ward Date: Tue, 1 Mar 2005 13:16:07 -0500 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200503011316.07593.cnogradi@laurelnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: IGPs and BFD X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit I have a few questions about the new sections (7.4.1 and 7.4.2) that have been added to the single hop IP document: In section 7.4.1 'OSPF has a "planned" restart mechanism, in which the restarting system notifies its neighbors that it is about to perform a restart. In this situation, if a BFD session fails while the neighbor is performing a graceful restart, the graceful restart SHOULD be allowed to complete and the topology change should not be made visible to the network as outlined in section 7.3.' I am not sure what is meant by the "topology change" as I do not see any wording in section 7.3 discussing a topology change that is NOT made visible to the network. Should this instead say: "... and the topology change as outlined in section 7.3 should not be made visible to the network."? In section 7.4.2 'If a planned restart is about to place, the restarting system MAY change the BFD timing parameters on a temporary basis in such a way as to make the Detection Time greater than or equal to the ISIS adjacency timeout. This will provide the restarting system the same opportunity to enter Graceful Restart as it would have without BFD. In this case, the restarted system SHOULD avoid sending any BFD Control packets until there is a high likelihood that its neighbors know it is performing a Graceful Restart, since the neighbors will tear down their BFD sessions when those sessions restart.' If I am understanding this correctly, it would seem that if multiple routing protocols are sharing the same BFD session to the peer, the solution presented here would not work. I am also confused as to what is meant by "...since the neighbors will tear down their BFD sessions when those sessions restart." By the way there seems to be a missing word in the beginning of this paragraph: "If a planned restart is about to TAKE place,..." Thanks From rtg-bfd-bounces@ietf.org Tue Mar 1 13:38:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25932; Tue, 1 Mar 2005 13:38:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6CHI-0002Mg-If; Tue, 01 Mar 2005 13:39:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6CFC-00069w-Ru; Tue, 01 Mar 2005 13:37:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6CFC-00069q-Bj for rtg-bfd@megatron.ietf.org; Tue, 01 Mar 2005 13:37:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25876 for ; Tue, 1 Mar 2005 13:37:15 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6CGB-0002LB-13 for rtg-bfd@ietf.org; Tue, 01 Mar 2005 13:38:20 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D6BB42D4DCC; Tue, 1 Mar 2005 13:37:06 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 73269-01-85; Tue, 1 Mar 2005 13:37:03 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 4FC982D5033; Tue, 1 Mar 2005 12:55:44 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j21Htha00775; Tue, 1 Mar 2005 12:55:43 -0500 (EST) Date: Tue, 1 Mar 2005 12:55:43 -0500 From: Jeffrey Haas To: richard.spencer@bt.com Message-ID: <20050301175543.GN3743@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: rtg-bfd@ietf.org Subject: Re: Ability to detect swapped/merged LSPs X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Richard, I wont claim to be a MPLS expert, but I'm struck by the following: On Tue, Mar 01, 2005 at 05:09:26PM -0000, richard.spencer@bt.com wrote: > If we get a swapped LSP (e.g. due to a corrupted forwarding table or configuration error) then all BFD packets received for the corresponding session will be dropped and the session will be declared down as a detection timeout will occur. However, if we get a merging defect where a node receives both valid BFD packets in addition to invalid BFD packets then this defect will not be detected. > > In both cases, traffic is being forwarded onto the wrong destination and therefore these defects need to be detected and appropriate actions taken, e.g. raise an alarm and inform the LSP source (using the appropriate BFD status code) that a defect has occurred so that the source can stop forwarding packets or switch over to an alternative path if one exists. If we are receiving some other node's traffic due to forwarding corruption in the network, then wouldn't: a. The intended target of the session time out the session after the appropriate interval? b. The node that is accidentally receiving the traffic may be potentially unable to respond due to the inherent unidirectionality of an LSP? (In other words, the case where we do not have an LSP that would permit us to respond.) > By adding new processing rules and status codes, both of these defects could be detected using BFD. An alternative would be to use LSP ping but it would not provide the same defect detection speed, i.e. an LSP might only get tested using LSP pings every 30mins or maybe every hour in a large network with hundreds of thousands of PWs/LSPs, as opposed to BFD packets that can be sent every second. It's probably worth reminding people that a session for BFD for MPLS LSPs must be bootstrapped using LSP-Ping. Upon failure of a BFD session, it's very reasonable to use LSP-Ping not only to reinitialize (or attempt to reinitialize) the BFD session, but also do further troubleshooting. > Richard -- Jeff Haas NextHop Technologies From rtg-bfd-bounces@ietf.org Tue Mar 1 14:11:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29805; Tue, 1 Mar 2005 14:11:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6CnR-0003Y0-Qn; Tue, 01 Mar 2005 14:12:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Cl2-0005jY-5t; Tue, 01 Mar 2005 14:10:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Cl1-0005jP-74 for rtg-bfd@megatron.ietf.org; Tue, 01 Mar 2005 14:10:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29675 for ; Tue, 1 Mar 2005 14:10:08 -0500 (EST) From: richard.spencer@bt.com Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Cm1-0003W7-GW for rtg-bfd@ietf.org; Tue, 01 Mar 2005 14:11:13 -0500 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Tue, 1 Mar 2005 19:10:01 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 1 Mar 2005 19:10:01 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Mar 2005 19:10:00 -0000 Message-ID: Thread-Topic: Ability to detect swapped/merged LSPs thread-index: AcUeh1tlNAqxXy3mTiatex7dKSXq7QAAroKw To: X-OriginalArrivalTime: 01 Mar 2005 19:10:01.0293 (UTC) FILETIME=[447B7FD0:01C51E92] X-Spam-Score: 0.3 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org Subject: RE: Ability to detect swapped/merged LSPs X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: quoted-printable Tom, Thanks for your response. Having thought about the defects again I agree = that both will be detected, if BFD packets are being sent to the wrong = place then you're going to get a detection timeout somewhere, regardless = of whether the LSPs are swapped or merged. The only downside to the BFD approach is that in both cases the defect = code will just be "1 -- Control Detection Time Expired", i.e. BFD will = not provide any indication of what the defect might be. Saying that, the = main point is that the problem will be detected, other tools such as LSP = ping can be used to diagnose and locate the problem. Regards, Richard > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: 01 March 2005 17:52 > To: Spencer,R,Richard,XDE73 R > Cc: rtg-bfd@ietf.org > Subject: Re: Ability to detect swapped/merged LSPs >=20 >=20 >=20 > >> From the current base draft "If the Your Discriminator field is=20 > >> nonzero, it MUST be used to select the session with which this BFD=20 > >> packet is associated. If no session is found, the packet MUST be=20 > >> discarded." > > > > If a node receives a BFD packet with a Discriminator field that it=20 > > doesn't have a session for then there is a problem somewhere in the=20 > > network, so why is the packet simply dropped and no further action=20 > > taken? >=20 > The packet is discarded, but the device can certainly=20 > take note of it.=20 > It > just has to make sure this will not result in a DoS attack on the=20 > device. >=20 > > If we get a swapped LSP (e.g. due to a corrupted forwarding=20 > table or=20 > > configuration error) then all BFD packets received for the=20 > > corresponding session will be dropped and the session will=20 > be declared=20 > > down as a detection timeout will occur. However, if we get=20 > a merging=20 > > defect where a node receives both valid BFD packets in addition to=20 > > invalid BFD packets then this defect will not be detected. >=20 > Hi Richard, >=20 > The defect will be detected in both cases due to the=20 > fact that the BFD > session ID information at the receiver should be incorrect. Lets=20 > consider both > cases: >=20 > 1) Correct LSP, but corrupted BFD session parameters. >=20 > This is the case you describe above. It is easily=20 > handled by virtue > of BFD session parameter mismatch. >=20 > 2) Incorrect LSP due to corrupted TFIB, but the payload remains > intact and thus valid BFD session parameters. >=20 > In this case the packet might make it to an LSR that=20 > happens to have=20 > BFD running. > If it does, the BFD session information will not match with the=20 > source/destination. > Thus, that should be detected as a failure since that=20 > node will not=20 > respond. > The only case I think can't be detected with just BFD=20 > is the case where > the mis-merged LSP happens to swap to a label that gets=20 > you to the=20 > correct destination LSR, albeit with the wrong label=20 > stack, and thus=20 > over the > wrong last bit of the LSP. In this case, since the BFD=20 > information is=20 > valid, > this MIGHT work okay, but not in all cases. For=20 > instance, if the end=20 > node is > a PE for L3 or L2 VPN/PWs (i.e.: in VCCV), the=20 > application label will=20 > also be bound to > the BFD session, and thus will fail. So there seems to be some=20 > unlikely corner cases > where the basic mechanism can fail. The good news is=20 > that in all=20 > cases, if you just > run LSP ping "every now and then", you can detect all=20 > of these corner=20 > cases > as well due to the diag. processing in LSP ping. > =09 > --Tom >=20 >=20 > > In both cases, traffic is being forwarded onto the wrong=20 > destination=20 > > and therefore these defects need to be detected and appropriate=20 > > actions taken, e.g. raise an alarm and inform the LSP source (using=20 > > the appropriate BFD status code) that a defect has occurred so that=20 > > the source can stop forwarding packets or switch over to an=20 > > alternative path if one exists. > > > > I know that the idea behind the BFD draft is to keep it as=20 > simple as=20 > > possible, but speaking as an operator, I would consider=20 > these defects=20 > > to be just as important as loss of connectivity defects. They might=20 > > not occur as frequently but are potentially more dangerous, e.g. I=20 > > don't want to unknowingly be sending packets from customer=20 > As network=20 > > to customer Bs network. > > > > By adding new processing rules and status codes, both of=20 > these defects=20 > > could be detected using BFD. An alternative would be to use=20 > LSP ping=20 > > but it would not provide the same defect detection speed,=20 > i.e. an LSP=20 > > might only get tested using LSP pings every 30mins or maybe=20 > every hour=20 > > in a large network with hundreds of thousands of PWs/LSPs,=20 > as opposed=20 > > to BFD packets that can be sent every second. > > > > Does anyone have any arguments for/against adding the ability to=20 > > detect these defects into BFD? > > > > Thanks, > > Richard > > > > > > > > > > > > > > > > > > > > >=20 From rtg-bfd-bounces@ietf.org Tue Mar 1 14:18:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00318; Tue, 1 Mar 2005 14:18:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Ctj-0003fH-Ch; Tue, 01 Mar 2005 14:19:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6CqG-0006nJ-Uw; Tue, 01 Mar 2005 14:15:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6CqG-0006nE-3P for rtg-bfd@megatron.ietf.org; Tue, 01 Mar 2005 14:15:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00016 for ; Tue, 1 Mar 2005 14:15:33 -0500 (EST) From: richard.spencer@bt.com Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6CrG-0003c1-Iu for rtg-bfd@ietf.org; Tue, 01 Mar 2005 14:16:38 -0500 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Tue, 1 Mar 2005 19:15:26 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 1 Mar 2005 19:15:26 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Mar 2005 19:15:25 -0000 Message-ID: Thread-Topic: Ability to detect swapped/merged LSPs thread-index: AcUeja0mV6WQ4yTtRm+h1P3WkrpmzgABI4cA To: X-OriginalArrivalTime: 01 Mar 2005 19:15:26.0308 (UTC) FILETIME=[0634DA40:01C51E93] X-Spam-Score: 0.3 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org Subject: RE: Ability to detect swapped/merged LSPs X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Jeff, Yes I agree, if BFD packets are being sent to the wrong place then we'll = get a detection timeout and LSP ping can then be used to locate and = diagnose the problem. Regards, Richard > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@nexthop.com] > Sent: 01 March 2005 17:56 > To: Spencer,R,Richard,XDE73 R > Cc: rtg-bfd@ietf.org > Subject: Re: Ability to detect swapped/merged LSPs >=20 >=20 > Richard, >=20 > I wont claim to be a MPLS expert, but I'm struck by the following: >=20 > On Tue, Mar 01, 2005 at 05:09:26PM -0000,=20 > richard.spencer@bt.com wrote: > > If we get a swapped LSP (e.g. due to a corrupted forwarding=20 > table or configuration error) then all BFD packets received=20 > for the corresponding session will be dropped and the session=20 > will be declared down as a detection timeout will occur.=20 > However, if we get a merging defect where a node receives=20 > both valid BFD packets in addition to invalid BFD packets=20 > then this defect will not be detected. > >=20 > > In both cases, traffic is being forwarded onto the wrong=20 > destination and therefore these defects need to be detected=20 > and appropriate actions taken, e.g. raise an alarm and inform=20 > the LSP source (using the appropriate BFD status code) that a=20 > defect has occurred so that the source can stop forwarding=20 > packets or switch over to an alternative path if one exists. >=20 > If we are receiving some other node's traffic due to forwarding > corruption in the network, then wouldn't: > a. The intended target of the session time out the session after the > appropriate interval? > b. The node that is accidentally receiving the traffic may be=20 > potentially > unable to respond due to the inherent unidirectionality of an LSP? > (In other words, the case where we do not have an LSP that would > permit us to respond.) >=20 > > By adding new processing rules and status codes, both of=20 > these defects could be detected using BFD. An alternative=20 > would be to use LSP ping but it would not provide the same=20 > defect detection speed, i.e. an LSP might only get tested=20 > using LSP pings every 30mins or maybe every hour in a large=20 > network with hundreds of thousands of PWs/LSPs, as opposed to=20 > BFD packets that can be sent every second. >=20 > It's probably worth reminding people that a session for BFD for > MPLS LSPs must be bootstrapped using LSP-Ping. >=20 > Upon failure of a BFD session, it's very reasonable to use=20 > LSP-Ping not > only to reinitialize (or attempt to reinitialize) the BFD session, but > also do further troubleshooting. >=20 > > Richard >=20 > --=20 > Jeff Haas=20 > NextHop Technologies >=20 From rtg-bfd-bounces@ietf.org Wed Mar 2 15:27:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22894; Wed, 2 Mar 2005 15:27:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6aSw-0001lm-Uh; Wed, 02 Mar 2005 15:29:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6aHe-0000bL-VS; Wed, 02 Mar 2005 15:17:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6aHd-0000bG-Hj for rtg-bfd@megatron.ietf.org; Wed, 02 Mar 2005 15:17:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21442 for ; Wed, 2 Mar 2005 15:17:22 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6aIp-0001NE-QW for rtg-bfd@ietf.org; Wed, 02 Mar 2005 15:18:41 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j22KHB960278; Wed, 2 Mar 2005 12:17:11 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j22KH6e38145; Wed, 2 Mar 2005 12:17:06 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <200503011316.07593.cnogradi@laurelnetworks.com> References: <200503011316.07593.cnogradi@laurelnetworks.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <10335f84073f38c02840514d87f4e473@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Wed, 2 Mar 2005 13:17:05 -0700 To: Chris Nogradi X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org, David Ward Subject: Re: IGPs and BFD X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit On Mar 1, 2005, at 11:16 AM, Chris Nogradi wrote: > I am not sure what is meant by the "topology change" as I do not see > any > wording in section 7.3 discussing a topology change that is NOT made > visible > to the network. Should this instead say: "... and the topology change > as > outlined in section 7.3 should not be made visible to the network."? Yes, that was what I meant. I'll rework the language. > > If I am understanding this correctly, it would seem that if multiple > routing > protocols are sharing the same BFD session to the peer, the solution > presented here would not work. If the control plane is restarting and multiple protocols are relying on BFD, those multiple protocols are all either going to have GR mechanisms or they are going to suffer adjacency failure. In the case of OSPF and ISIS, when both have GR available, this scheme will work (I think) because OSPF will use its GR mechanism and ignore the eventual BFD session failure. > > I am also confused as to what is meant by "...since the neighbors will > tear > down their BFD sessions when those sessions restart." Since the restarting system has no BFD state (since it is sharing the restarted control plane fate with the protocol), the restarting system will cause all of the BFD sessions with its neighbors to fail as soon as it sends any packets (since the packets will show that its BFD sessions are down.) By delaying sending any BFD packets until the GR mechanism has started, the inevitable BFD session flaps will be ignored. > > By the way there seems to be a missing word in the beginning of this > paragraph: "If a planned restart is about to TAKE place,..." Noted, thanks. --Dave From rtg-bfd-bounces@ietf.org Wed Mar 2 15:43:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24636; Wed, 2 Mar 2005 15:43:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6ai1-0002CB-GP; Wed, 02 Mar 2005 15:44:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6agY-0007J8-3e; Wed, 02 Mar 2005 15:43:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6agW-0007J3-5F for rtg-bfd@megatron.ietf.org; Wed, 02 Mar 2005 15:43:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24611 for ; Wed, 2 Mar 2005 15:43:06 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6ahk-0002BZ-8Z for rtg-bfd@ietf.org; Wed, 02 Mar 2005 15:44:24 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j22Kgx960556 for ; Wed, 2 Mar 2005 12:42:59 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j22Kgre42691 for ; Wed, 2 Mar 2005 12:42:53 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <0036571b21c6f5db0c588591b0426735@juniper.net> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "'rtg-bfd@ietf.org'" From: Dave Katz Date: Wed, 2 Mar 2005 13:42:53 -0700 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Subject: BFD State Machine X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Richard Spencer's comments made me put on my thinking cap for awhile, and I've come to the conclusion that the BFD state machine as specified is flawed. It has (at least) the following issues: Sessions could come up faster Unidirectional failures require a timeout of INIT state to restore service Service restoration is probabilistic Dissimilar timer values during session establishment can cause permanent deadlock The first is a little unhappy, but not too bad. The second and third are ugly, but not fatal; the session will come up eventually. The fourth is fatal as currently spec'ed--if one side has a transmit interval of one second and the other has a transmit interval of five seconds, the session will enter the deadlock loop that Richard pointed out. This is fixable by requiring that the same value be sent for Desired TX and Required RX while not in Up state, but that's ugly too. The heart of the problem is this--there are two symmetric wait states in the state machine, but there is insufficient state passed in the protocol (only one bit) to communicate what's happening. The IHU bit tells you only that the other system is in one of two states. The symmetry in the protocol, combined with the state ambiguity, causes the deadlock opportunity. After some hemming and hawing, Dave2 and I have decided that we should bite the bullet and change the protocol. This will require an incompatible change and a bump of the version number. The change is fairly simple; rather than communicate a single bit of state information (IHU), instead communicate the current state. As we move an extra bit of state into the protocol, this allows us to remove a state from the state machine. The new scheme fixes all of the above problems; as a matter of fact the unidrectional failure case ends up taking one less packet to come up than the bidirectional failure case. Since the state is carried in the protocol, every state change causes a change in packet contents, which in turn triggers an "extra" packet to be transmitted, so the sessions can come up rapidly, but safely, and in as deterministic a manner as is possible in networking. It also takes one less packet in each direction to come up. Given that this document hasn't even made proposed standard yet, and given that, as far as I know, I'm the only one with deployed code on which customers rely, I am not going to attempt to document any kind of interoperability or version negotiation scheme. Version 0 should simply be discarded and replaced with Version 1. I'm going to spin the document, which will appear after the IETF meeting (as the I-D sluice is blocked until after the meeting.) Dave2 will make a presentation at the meeting describing the changes. Below is the new state machine. It is pretty straightforward; the notations on the arcs are the neighbor's state as signalled in received BFD packets (plus the detection timer expiration.) I think this is much more transparent than the last one in terms of being able to intuit the mechanism and its side effects. This should be sufficient for the motivated to analyze and pick apart. Comments and brickbats to the list, please. All this goes to show that protocol design is a subtle art... --Dave +--+ | | UP | V DOWN +------+ INIT +------------| |------------+ | | DOWN | | | +-------->| |<--------+ | | | +------+ | | | | | | | | | | | | DOWN,| | | |TIMER TIMER| | V | | V +------+ +------+ +----| | | |----+ DOWN| | INIT |--------------------->| UP | |INIT, UP +--->| | INIT, UP | |<---+ +------+ +------+ From rtg-bfd-bounces@ietf.org Thu Mar 3 14:09:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02618; Thu, 3 Mar 2005 14:09:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6vif-0000mz-W9; Thu, 03 Mar 2005 14:10:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6vfz-0008In-L9; Thu, 03 Mar 2005 14:07:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6vfy-0008Ib-1u for rtg-bfd@megatron.ietf.org; Thu, 03 Mar 2005 14:07:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02487 for ; Thu, 3 Mar 2005 14:07:56 -0500 (EST) Received: from paperclip.laurelnetworks.com ([63.94.127.69] ident=nobody) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6vhN-0000kp-NQ for rtg-bfd@ietf.org; Thu, 03 Mar 2005 14:09:26 -0500 Received: from notepad.laurelnetworks.com (notepad.laurelnetworks.com [63.94.127.20]) by paperclip.laurelnetworks.com (Laurel/Laurel) with ESMTP id j23J7uU4012478; Thu, 3 Mar 2005 14:07:56 -0500 Received: from cnogradi-linux.dhcp.pit.laurelnetworks.com (cnogradi-linux.dhcp.pit.laurelnetworks.com [10.0.19.158]) by notepad.laurelnetworks.com (Laurel/Laurel) with ESMTP id j23J7ttL027139; Thu, 3 Mar 2005 14:07:56 -0500 From: Chris Nogradi Organization: Laurel Networks To: Dave Katz Date: Thu, 3 Mar 2005 14:07:24 -0500 User-Agent: KMail/1.6.2 References: <0036571b21c6f5db0c588591b0426735@juniper.net> In-Reply-To: <0036571b21c6f5db0c588591b0426735@juniper.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503031407.24669.cnogradi@laurelnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Cc: "'rtg-bfd@ietf.org'" Subject: Re: BFD State Machine X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Dave, Since all implementations of BFD that I have observed use a one packet per second sedate rate, I never noticed the fact that the draft specified this as the MINIMUM interval. If fact when you described a possible solution for the deadlock, requiring the Desired TX and Required RX to match during negotiations, the thought occurred to me that you were suggesting that the Required RX value should be used during negotiations. For instance, suppose that an implementation uses a one second sedate rate but the peer implementation is advertising a three second Required RX value. Should this Required RX value be used instead of the one second interval during negotiations? I suppose that since the peer's Desired Tx/Multiplier pair is used to determine the detection time used during the negotiation while in the init state, the Required RX time should also be honored during this time. I guess the confusion arises from the fact that when the session is being negotiated, the time values are used without requiring a poll sequence (poll/final). However, when the session is up, timer value changes must be communicated using a poll sequence (poll/final). BTW, assuming that an original draft implementation uses a fixed sedate rate, it would seem that it would not run into the deadlock problem unless it has to interoperate with an implementation using a different rate. Is this true? Any clarification in these matters is much appreciated, Thanks, Chris On Wednesday 02 March 2005 15:42, Dave Katz wrote: > Richard Spencer's comments made me put on my thinking cap for awhile, > and I've come to the conclusion that the BFD state machine as specified > is flawed. It has (at least) the following issues: > > Sessions could come up faster > > Unidirectional failures require a timeout of INIT state to restore > service > > Service restoration is probabilistic > > Dissimilar timer values during session establishment can cause > permanent deadlock > > The first is a little unhappy, but not too bad. The second and third > are ugly, but not fatal; the session will come up eventually. The > fourth is fatal as currently spec'ed--if one side has a transmit > interval of one second and the other has a transmit interval of five > seconds, the session will enter the deadlock loop that Richard pointed > out. This is fixable by requiring that the same value be sent for > Desired TX and Required RX while not in Up state, but that's ugly too. > > The heart of the problem is this--there are two symmetric wait states > in the state machine, but there is insufficient state passed in the > protocol (only one bit) to communicate what's happening. The IHU bit > tells you only that the other system is in one of two states. The > symmetry in the protocol, combined with the state ambiguity, causes the > deadlock opportunity. > > After some hemming and hawing, Dave2 and I have decided that we should > bite the bullet and change the protocol. This will require an > incompatible change and a bump of the version number. The change is > fairly simple; rather than communicate a single bit of state > information (IHU), instead communicate the current state. > > As we move an extra bit of state into the protocol, this allows us to > remove a state from the state machine. The new scheme fixes all of the > above problems; as a matter of fact the unidrectional failure case > ends up taking one less packet to come up than the bidirectional > failure case. Since the state is carried in the protocol, every state > change causes a change in packet contents, which in turn triggers an > "extra" packet to be transmitted, so the sessions can come up rapidly, > but safely, and in as deterministic a manner as is possible in > networking. It also takes one less packet in each direction to come > up. > > Given that this document hasn't even made proposed standard yet, and > given that, as far as I know, I'm the only one with deployed code on > which customers rely, I am not going to attempt to document any kind of > interoperability or version negotiation scheme. Version 0 should > simply be discarded and replaced with Version 1. > > I'm going to spin the document, which will appear after the IETF > meeting (as the I-D sluice is blocked until after the meeting.) Dave2 > will make a presentation at the meeting describing the changes. > > Below is the new state machine. It is pretty straightforward; the > notations on the arcs are the neighbor's state as signalled in received > BFD packets (plus the detection timer expiration.) I think this is > much more transparent than the last one in terms of being able to > intuit the mechanism and its side effects. This should be sufficient > for the motivated to analyze and pick apart. Comments and brickbats to > the list, please. > > All this goes to show that protocol design is a subtle art... > > --Dave > > +--+ > > | | UP > | > | V > > DOWN +------+ INIT > +------------| |------------+ > > | | DOWN | | > | > | +-------->| |<--------+ | > | > | | +------+ | | > | | > | | > | | DOWN,| | > | |TIMER TIMER| | > > V | | V > +------+ +------+ > +----| | | |----+ > DOWN| | INIT |--------------------->| UP | |INIT, UP > +--->| | INIT, UP | |<---+ > +------+ +------+ From rtg-bfd-bounces@ietf.org Thu Mar 3 15:02:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07623; Thu, 3 Mar 2005 15:02:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6wXx-00020I-DV; Thu, 03 Mar 2005 15:03:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6wVm-0000Q1-Gn; Thu, 03 Mar 2005 15:01:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6wVl-0000Pw-1w for rtg-bfd@megatron.ietf.org; Thu, 03 Mar 2005 15:01:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07465 for ; Thu, 3 Mar 2005 15:01:27 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6wXB-0001y8-6C for rtg-bfd@ietf.org; Thu, 03 Mar 2005 15:02:57 -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 j23K1JBm097359; Thu, 3 Mar 2005 12:01:19 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j23K1He58547; Thu, 3 Mar 2005 12:01:17 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <200503031407.24669.cnogradi@laurelnetworks.com> References: <0036571b21c6f5db0c588591b0426735@juniper.net> <200503031407.24669.cnogradi@laurelnetworks.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 3 Mar 2005 13:01:16 -0700 To: Chris Nogradi X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: "'rtg-bfd@ietf.org'" Subject: Re: BFD State Machine X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit On Mar 3, 2005, at 12:07 PM, Chris Nogradi wrote: > Dave, > > Since all implementations of BFD that I have observed use a one packet > per > second sedate rate, I never noticed the fact that the draft specified > this as > the MINIMUM interval. If fact when you described a possible solution > for > the deadlock, requiring the Desired TX and Required RX to match during > negotiations, the thought occurred to me that you were suggesting that > the > Required RX value should be used during negotiations. For instance, > suppose > that an implementation uses a one second sedate rate but the peer > implementation is advertising a three second Required RX value. Should > this > Required RX value be used instead of the one second interval during > negotiations? Yes, the parameters always apply, even during session bringup. In the case you specify, the local transmitter would be required to send at 3 second intervals. My workaround hack ensures that, during session bringup, both sides are transmitting at the same rate (since each side advertises the same value for TX and RX, then they will converge on the larger value and both will transmit at that rate.) But that's overtaken by events now; the new state machine is much cleaner, I think (though the silence has been deafening thus far.) > I suppose that since the peer's Desired Tx/Multiplier pair is > used to determine the detection time used during the negotiation while > in the > init state, the Required RX time should also be honored during this > time. Yes, all the timing parameters and procedures apply at all times. > I > guess the confusion arises from the fact that when the session is being > negotiated, the time values are used without requiring a poll sequence > (poll/final). However, when the session is up, timer value changes > must be > communicated using a poll sequence (poll/final). Hmm, this is not the case; if the spec is confusing on that aspect, please let me know what led you to that conclusion. It is true that a true Demand Mode Poll Sequence requires you to be in Up state, but the verbiage in 6.7.3 talks about what to do when Demand Mode is not active (which it would not be during session establishment.) I should probably point out in the text that this applies at all times, though it is less of an issue in session establishment, since the session is already down (the mechanism is designed to avoid dropping the session if the parameters change on the fly.) It's also the case that the advertised values are unlikely to change during session bringup, except during the transition to Up state. > > BTW, assuming that an original draft implementation uses a fixed > sedate rate, > it would seem that it would not run into the deadlock problem unless > it has > to interoperate with an implementation using a different rate. Is > this true? There should be no permanent deadlock condition, yes. You may run into probabilistic difficulties (recoverable from the timer firing in Init state) but it should eventually come up. However, I am pushing hard for completely deprecating the original version. I've already worked up the spec changes, and they're really quite minor. It would be a Really Good Idea to not ship version 0, to avoid having to deal with compatibility issues (at least I'm the one suffering the most by this, so there is justice after all.) --Dave From rtg-bfd-bounces@ietf.org Thu Mar 3 15:41:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13383; Thu, 3 Mar 2005 15:41:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6x9t-0002wS-BW; Thu, 03 Mar 2005 15:42:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6x5o-0007HW-OM; Thu, 03 Mar 2005 15:38:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6x5n-0007HR-Ji for rtg-bfd@megatron.ietf.org; Thu, 03 Mar 2005 15:38:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13071 for ; Thu, 3 Mar 2005 15:38:41 -0500 (EST) Received: from paperclip.laurelnetworks.com ([63.94.127.69] ident=nobody) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6x7B-0002sB-IK for rtg-bfd@ietf.org; Thu, 03 Mar 2005 15:40:12 -0500 Received: from notepad.laurelnetworks.com (notepad.laurelnetworks.com [63.94.127.20]) by paperclip.laurelnetworks.com (Laurel/Laurel) with ESMTP id j23KcZOe013127; Thu, 3 Mar 2005 15:38:35 -0500 Received: from cnogradi-linux.dhcp.pit.laurelnetworks.com (cnogradi-linux.dhcp.pit.laurelnetworks.com [10.0.19.158]) by notepad.laurelnetworks.com (Laurel/Laurel) with ESMTP id j23KcZbY028188; Thu, 3 Mar 2005 15:38:35 -0500 From: Chris Nogradi Organization: Laurel Networks To: Dave Katz Date: Thu, 3 Mar 2005 15:38:04 -0500 User-Agent: KMail/1.6.2 References: <0036571b21c6f5db0c588591b0426735@juniper.net> <200503031407.24669.cnogradi@laurelnetworks.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200503031538.04663.cnogradi@laurelnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable Cc: "'rtg-bfd@ietf.org'" Subject: Re: BFD State Machine X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable On Thursday 03 March 2005 15:01, Dave Katz wrote: > On Mar 3, 2005, at 12:07 PM, Chris Nogradi wrote: > > Dave, > > > > Since all implementations of BFD that I have observed use a one packet > > per > > second sedate rate, I never noticed the fact that the draft specified > > this as > > the MINIMUM interval. If fact when you described a possible solution > > for > > the deadlock, requiring the Desired TX and Required RX to match during > > negotiations, the thought occurred to me that you were suggesting that > > the > > Required RX value should be used during negotiations. For instance, > > suppose > > that an implementation uses a one second sedate rate but the peer > > implementation is advertising a three second Required RX value. Should > > this > > Required RX value be used instead of the one second interval during > > negotiations? > > Yes, the parameters always apply, even during session bringup. In the > case you specify, the local transmitter would be required to send at 3 > second intervals. > > My workaround hack ensures that, during session bringup, both sides are > transmitting at the same rate (since each side advertises the same > value for TX and RX, then they will converge on the larger value and > both will transmit at that rate.) But that's overtaken by events now; > the new state machine is much cleaner, I think (though the silence has > been deafening thus far.) > > > I suppose that since the peer's Desired Tx/Multiplier pair is > > used to determine the detection time used during the negotiation while > > in the > > init state, the Required RX time should also be honored during this > > time. > > Yes, all the timing parameters and procedures apply at all times. > > > I > > guess the confusion arises from the fact that when the session is being > > negotiated, the time values are used without requiring a poll sequence > > (poll/final). However, when the session is up, timer value changes > > must be > > communicated using a poll sequence (poll/final). > > Hmm, this is not the case; if the spec is confusing on that aspect, > please let me know what led you to that conclusion. It is true that a > true Demand Mode Poll Sequence requires you to be in Up state, but the > verbiage in 6.7.3 talks about what to do when Demand Mode is not active > (which it would not be during session establishment.) I should > probably point out in the text that this applies at all times, though > it is less of an issue in session establishment, since the session is > already down (the mechanism is designed to avoid dropping the session > if the parameters change on the fly.) It's also the case that the > advertised values are unlikely to change during session bringup, except > during the transition to Up state. > I guess the confusion arose as a result of your response to a previous=20 question of mine below: > > > > 2. =A0While I am not sure that the document specifically states this, i= t=20 > > appears > > to me that the poll and final bits should only be set when in the up=20 > > state? > Yep. =A0Originally the P/F bits were only used when Demand Mode was=20 > active, which can only happen in Up state. =A0However, we leveraged P/F=20 > for parameter changes. =A0This should only apply in Up state. =A0Will be= =20 > fixed... Which lead me to believe that section 6.7.3, since it deals with P/F bits, = did=20 not apply during negotiations. As you pointed out, the main purpose for th= e=20 P/F sequence is to ensure we do not drop the session during the parameters= =20 changes. So it would seem unnecessary (and mostly cumbersome) to require t= he=20 use of these flags during negotiations. As far as the unlikeliness of=20 changing the timing parameters during negotiations, I would imagine that it= =20 may be possible for an implementation to choose to use a back off algorithm= =20 during session establishment (similar to the one you use in your=20 implementation for the high speed parameters). =20 > > BTW, assuming that an original draft implementation uses a fixed > > sedate rate, > > it would seem that it would not run into the deadlock problem unless > > it has > > to interoperate with an implementation using a different rate. Is > > this true? > > There should be no permanent deadlock condition, yes. You may run into > probabilistic difficulties (recoverable from the timer firing in Init > state) but it should eventually come up. However, I am pushing hard > for completely deprecating the original version. I've already worked > up the spec changes, and they're really quite minor. It would be a > Really Good Idea to not ship version 0, to avoid having to deal with > compatibility issues (at least I'm the one suffering the most by this, > so there is justice after all.) > > --Dave From rtg-bfd-bounces@ietf.org Thu Mar 3 16:46:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18861; Thu, 3 Mar 2005 16:46:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6yAq-0004N1-Gw; Thu, 03 Mar 2005 16:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6y7z-0000Zz-Cx; Thu, 03 Mar 2005 16:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6y7w-0000ZY-Rr for rtg-bfd@megatron.ietf.org; Thu, 03 Mar 2005 16:45:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18703 for ; Thu, 3 Mar 2005 16:44:58 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6y9N-0004LS-W6 for rtg-bfd@ietf.org; Thu, 03 Mar 2005 16:46:30 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 03 Mar 2005 17:00:08 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,133,1107752400"; d="scan'208"; a="39188759:sNHT21940652" Received: from mira-kan-a.cisco.com (IDENT:mirapoint@mira-kan-a.cisco.com [161.44.201.17]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j23LimjI008175; Thu, 3 Mar 2005 16:44:49 -0500 (EST) Received: from cisco.com (che-vpn-cluster-1-125.cisco.com [10.86.240.125]) by mira-kan-a.cisco.com (MOS 3.4.6-GR) with ESMTP id ABL66206; Thu, 3 Mar 2005 13:44:46 -0800 (PST) Message-ID: <4227854E.60803@cisco.com> Date: Thu, 03 Mar 2005 16:44:46 -0500 From: Reshad Rahman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Katz References: <0036571b21c6f5db0c588591b0426735@juniper.net> In-Reply-To: <0036571b21c6f5db0c588591b0426735@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: "'rtg-bfd@ietf.org'" Subject: Re: BFD State Machine X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Has the AdminDown state been removed? Regards, Reshad. Dave Katz wrote: > Richard Spencer's comments made me put on my thinking cap for awhile, > and I've come to the conclusion that the BFD state machine as > specified is flawed. It has (at least) the following issues: > > Sessions could come up faster > > Unidirectional failures require a timeout of INIT state to restore > service > > Service restoration is probabilistic > > Dissimilar timer values during session establishment can cause > permanent deadlock > > The first is a little unhappy, but not too bad. The second and third > are ugly, but not fatal; the session will come up eventually. The > fourth is fatal as currently spec'ed--if one side has a transmit > interval of one second and the other has a transmit interval of five > seconds, the session will enter the deadlock loop that Richard pointed > out. This is fixable by requiring that the same value be sent for > Desired TX and Required RX while not in Up state, but that's ugly too. > > The heart of the problem is this--there are two symmetric wait states > in the state machine, but there is insufficient state passed in the > protocol (only one bit) to communicate what's happening. The IHU bit > tells you only that the other system is in one of two states. The > symmetry in the protocol, combined with the state ambiguity, causes > the deadlock opportunity. > > After some hemming and hawing, Dave2 and I have decided that we should > bite the bullet and change the protocol. This will require an > incompatible change and a bump of the version number. The change is > fairly simple; rather than communicate a single bit of state > information (IHU), instead communicate the current state. > > As we move an extra bit of state into the protocol, this allows us to > remove a state from the state machine. The new scheme fixes all of > the above problems; as a matter of fact the unidrectional failure > case ends up taking one less packet to come up than the bidirectional > failure case. Since the state is carried in the protocol, every state > change causes a change in packet contents, which in turn triggers an > "extra" packet to be transmitted, so the sessions can come up rapidly, > but safely, and in as deterministic a manner as is possible in > networking. It also takes one less packet in each direction to come up. > > Given that this document hasn't even made proposed standard yet, and > given that, as far as I know, I'm the only one with deployed code on > which customers rely, I am not going to attempt to document any kind > of interoperability or version negotiation scheme. Version 0 should > simply be discarded and replaced with Version 1. > > I'm going to spin the document, which will appear after the IETF > meeting (as the I-D sluice is blocked until after the meeting.) Dave2 > will make a presentation at the meeting describing the changes. > > Below is the new state machine. It is pretty straightforward; the > notations on the arcs are the neighbor's state as signalled in > received BFD packets (plus the detection timer expiration.) I think > this is much more transparent than the last one in terms of being able > to intuit the mechanism and its side effects. This should be > sufficient for the motivated to analyze and pick apart. Comments and > brickbats to the list, please. > > All this goes to show that protocol design is a subtle art... > > --Dave > > +--+ > | | UP > | V > DOWN +------+ INIT > +------------| |------------+ > | | DOWN | | > | +-------->| |<--------+ | > | | +------+ | | > | | | | > | | | | > | | DOWN,| | > | |TIMER TIMER| | > V | | V > +------+ +------+ > +----| | | |----+ > DOWN| | INIT |--------------------->| UP | |INIT, UP > +--->| | INIT, UP | |<---+ > +------+ +------+ From rtg-bfd-bounces@ietf.org Thu Mar 3 16:59:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19732; Thu, 3 Mar 2005 16:59:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6yNb-0004bl-HN; Thu, 03 Mar 2005 17:01:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6yIR-0001tz-RR; Thu, 03 Mar 2005 16:55:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6yIQ-0001tr-75 for rtg-bfd@megatron.ietf.org; Thu, 03 Mar 2005 16:55:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19456 for ; Thu, 3 Mar 2005 16:55:47 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6yJq-0004WE-Ky for rtg-bfd@ietf.org; Thu, 03 Mar 2005 16:57:20 -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 j23LtdBm098240; Thu, 3 Mar 2005 13:55:39 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j23Ltde80252; Thu, 3 Mar 2005 13:55:39 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <200503031538.04663.cnogradi@laurelnetworks.com> References: <0036571b21c6f5db0c588591b0426735@juniper.net> <200503031407.24669.cnogradi@laurelnetworks.com> <200503031538.04663.cnogradi@laurelnetworks.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Dave Katz Date: Thu, 3 Mar 2005 14:55:38 -0700 To: Chris Nogradi X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: "'rtg-bfd@ietf.org'" Subject: Re: BFD State Machine X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable On Mar 3, 2005, at 1:38 PM, Chris Nogradi wrote: > I guess the confusion arose as a result of your response to a previous > question of mine below: > >>> >>> 2. =A0While I am not sure that the document specifically states = this,=20 >>> it >>> appears >>> to me that the poll and final bits should only be set when in the up >>> state? > >> Yep. =A0Originally the P/F bits were only used when Demand Mode was >> active, which can only happen in Up state. =A0However, we leveraged = P/F >> for parameter changes. =A0This should only apply in Up state. =A0Will = be >> fixed... > > Which lead me to believe that section 6.7.3, since it deals with P/F=20= > bits, did > not apply during negotiations. As you pointed out, the main purpose=20= > for the > P/F sequence is to ensure we do not drop the session during the=20 > parameters > changes. So it would seem unnecessary (and mostly cumbersome) to=20 > require the > use of these flags during negotiations. As far as the unlikeliness of > changing the timing parameters during negotiations, I would imagine=20 > that it > may be possible for an implementation to choose to use a back off=20 > algorithm > during session establishment (similar to the one you use in your > implementation for the high speed parameters). Oh, well there's the problem! You've discovered my multiple=20 personality disorder. ;-) I guess I should make up my mind, hm. I'm of two minds on this (obviously.) On the one hand, doing the P/F=20 stuff during session bringup (where it's unlikely to happen anyhow) is=20= mildly pointless. On the other hand, it is probably more code to *not*=20= do this during session establishment. I'll see if I can put in a MAY=20 in a way that works, and people can implement it either way. --Dave= From rtg-bfd-bounces@ietf.org Thu Mar 3 17:00:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19777; Thu, 3 Mar 2005 17:00:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6yOT-0004cF-7L; Thu, 03 Mar 2005 17:02:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6yK7-00027C-ON; Thu, 03 Mar 2005 16:57:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6yK6-000277-Rs for rtg-bfd@megatron.ietf.org; Thu, 03 Mar 2005 16:57:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19606 for ; Thu, 3 Mar 2005 16:57:32 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6yLX-0004YS-AQ for rtg-bfd@ietf.org; Thu, 03 Mar 2005 16:59:04 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j23LvO975106; Thu, 3 Mar 2005 13:57:24 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j23LvIe80512; Thu, 3 Mar 2005 13:57:19 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <4227854E.60803@cisco.com> References: <0036571b21c6f5db0c588591b0426735@juniper.net> <4227854E.60803@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <948bf86b24afd7513ffda5204b7a489a@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 3 Mar 2005 14:57:18 -0700 To: Reshad Rahman X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: "'rtg-bfd@ietf.org'" Subject: Re: BFD State Machine X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit On Mar 3, 2005, at 2:44 PM, Reshad Rahman wrote: > Has the AdminDown state been removed? > > Regards, > Reshad. No, I just left it out of the picture for clarity. AdminDown state is entered from any state via administrative action, and exits to Down state via administrative action. Receipt of AdminDown goes to Down state regardless of the previous state. This will be clear in the updated spec. --Dave From rtg-bfd-bounces@ietf.org Thu Mar 3 17:17:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21503; Thu, 3 Mar 2005 17:17:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6yep-00052x-GL; Thu, 03 Mar 2005 17:19:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ybo-0005kh-Q7; Thu, 03 Mar 2005 17:15:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ybn-0005kZ-GX for rtg-bfd@megatron.ietf.org; Thu, 03 Mar 2005 17:15:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21290 for ; Thu, 3 Mar 2005 17:15:48 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6ydD-00050D-U0 for rtg-bfd@ietf.org; Thu, 03 Mar 2005 17:17:21 -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 j23MFfBm098405; Thu, 3 Mar 2005 14:15:41 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j23MFee84740; Thu, 3 Mar 2005 14:15:40 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: References: <0036571b21c6f5db0c588591b0426735@juniper.net> <200503031407.24669.cnogradi@laurelnetworks.com> <200503031538.04663.cnogradi@laurelnetworks.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5d2cc4aa914cc318078541737b170807@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 3 Mar 2005 15:15:40 -0700 To: Dave Katz X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: "'rtg-bfd@ietf.org'" Subject: Re: BFD State Machine X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit On Mar 3, 2005, at 2:55 PM, Dave Katz wrote: Ah, to heck with it, trying to shoehorn a MAY into this makes the spec too ugly. I've left it with requiring the P/F thing when in Up state. Note however that there is no admonition against sending the P bit outside of Up state, and the remote end is always required to reply with F, so there's nothing to stop anyone from doing so if they feel like it. --Dave > Oh, well there's the problem! You've discovered my multiple > personality disorder. ;-) I guess I should make up my mind, hm. > I'm of two minds on this (obviously.) On the one hand, doing the P/F > stuff during session bringup (where it's unlikely to happen anyhow) is > mildly pointless. On the other hand, it is probably more code to > *not* do this during session establishment. I'll see if I can put in > a MAY in a way that works, and people can implement it either way. > > --Dave > > From rtg-bfd-bounces@ietf.org Wed Mar 9 16:30:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22259; Wed, 9 Mar 2005 16:30:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D98nv-0003Ng-Eo; Wed, 09 Mar 2005 16:33:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D98ja-0008LB-Jw; Wed, 09 Mar 2005 16:28:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D98jX-0008L6-1h for rtg-bfd@megatron.ietf.org; Wed, 09 Mar 2005 16:28:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22004 for ; Wed, 9 Mar 2005 16:28:44 -0500 (EST) Received: from paperclip.laurelnetworks.com ([63.94.127.69] ident=nobody) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D98mB-0003KZ-OG for rtg-bfd@ietf.org; Wed, 09 Mar 2005 16:31:33 -0500 Received: from notepad.laurelnetworks.com (notepad.laurelnetworks.com [63.94.127.20]) by paperclip.laurelnetworks.com (Laurel/Laurel) with ESMTP id j29LSZN7009037; Wed, 9 Mar 2005 16:28:35 -0500 Received: from cnogradi-linux.dhcp.pit.laurelnetworks.com (cnogradi-linux.dhcp.pit.laurelnetworks.com [10.0.19.158]) by notepad.laurelnetworks.com (Laurel/Laurel) with ESMTP id j29LSO8i027779; Wed, 9 Mar 2005 16:28:29 -0500 From: Chris Nogradi Organization: Laurel Networks To: Dave Katz Date: Wed, 9 Mar 2005 16:27:43 -0500 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200503091627.43247.cnogradi@laurelnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: "'rtg-bfd@ietf.org'" Subject: BFD for IGPs X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Dave, With regards to the "BFD for IPv4 and IPv6 (Single Hop)" draft, I was wondering if you could clarify what is meant in the 1st paragraph of section 7.3 by, "... but the protocols must share a common topology,..."? It is not clear to me if you are referring to the routing protocol (IS-IS) advertising multiple data protocols (IPv4 or IPv6) sharing a common topology or if you are referring to the routing protocols (IS-IS and OSPF) sharing a common BFD session. If you mean the former, are you saying that only one BFD session should be created for both data protocols? Or are you saying that a session would be created for each data protocol but a failure in either would cause both to be considered down? Also in the the second paragraph of the same section, I am not sure what is meant by "... the failing data protocol SHOULD no longer be advertised in Hello packets in order to signal a lack of connectivity for the protocol." Are you saying that the router would no longer advertise supporting the failed data protocol in its Hellos? Would this not affect other routers on a multiaccess network since we are still capable of supporting that data protocol? Thanks, Chris From rtg-bfd-bounces@ietf.org Wed Mar 9 16:34:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22945; Wed, 9 Mar 2005 16:34:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D98sC-0003ZT-GV; Wed, 09 Mar 2005 16:37:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D98lh-0000EW-HN; Wed, 09 Mar 2005 16:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D98lg-0000ER-L8 for rtg-bfd@megatron.ietf.org; Wed, 09 Mar 2005 16:31:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22324 for ; Wed, 9 Mar 2005 16:30:58 -0500 (EST) Received: from paperclip.laurelnetworks.com ([63.94.127.69] ident=nobody) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D98oK-0003OU-UO for rtg-bfd@ietf.org; Wed, 09 Mar 2005 16:33:46 -0500 Received: from notepad.laurelnetworks.com (notepad.laurelnetworks.com [63.94.127.20]) by paperclip.laurelnetworks.com (Laurel/Laurel) with ESMTP id j29LUt3N009082 for ; Wed, 9 Mar 2005 16:30:55 -0500 Received: from cnogradi-linux.dhcp.pit.laurelnetworks.com (cnogradi-linux.dhcp.pit.laurelnetworks.com [10.0.19.158]) by notepad.laurelnetworks.com (Laurel/Laurel) with ESMTP id j29LUtSa027822 for ; Wed, 9 Mar 2005 16:30:55 -0500 From: Chris Nogradi Organization: Laurel Networks Date: Wed, 9 Mar 2005 16:30:15 -0500 User-Agent: KMail/1.6.2 To: rtg-bfd@ietf.org MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503091630.15207.cnogradi@laurelnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: Fwd: BFD for IGPs X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Dave, With regards to the "BFD for IPv4 and IPv6 (Single Hop)" draft, I was wondering if you could clarify what is meant in the 1st paragraph of section 7.3 by, "... but the protocols must share a common topology,..."? It is not clear to me if you are referring to the routing protocol (IS-IS) advertising multiple data protocols (IPv4 or IPv6) sharing a common topology or if you are referring to the routing protocols (IS-IS and OSPF) sharing a common BFD session. If you mean the former, are you saying that only one BFD session should be created for both data protocols? Or are you saying that a session would be created for each data protocol but a failure in either would cause both to be considered down? Also in the the second paragraph of the same section, I am not sure what is meant by "... the failing data protocol SHOULD no longer be advertised in Hello packets in order to signal a lack of connectivity for the protocol." Are you saying that the router would no longer advertise supporting the failed data protocol in its Hellos? Would this not affect other routers on a multiaccess network since we are still capable of supporting that data protocol? Thanks, Chris ------------------------------------------------------- From rtg-bfd-bounces@ietf.org Wed Mar 9 18:16:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02049; Wed, 9 Mar 2005 18:16:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9ASl-0005ml-Od; Wed, 09 Mar 2005 18:19:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9APY-0007Ax-QB; Wed, 09 Mar 2005 18:16:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9APY-0007As-3o for rtg-bfd@megatron.ietf.org; Wed, 09 Mar 2005 18:16:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01984 for ; Wed, 9 Mar 2005 18:16:13 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9ASD-0005lv-Hy for rtg-bfd@ietf.org; Wed, 09 Mar 2005 18:19:03 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j29NG4965612; Wed, 9 Mar 2005 15:16:04 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j29NFwe27057; Wed, 9 Mar 2005 15:15:58 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <200503091627.43247.cnogradi@laurelnetworks.com> References: <200503091627.43247.cnogradi@laurelnetworks.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <67fdb7192b3e8c4d9252f8f9a0140cd8@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Wed, 9 Mar 2005 16:17:19 -0700 To: Chris Nogradi X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: "'rtg-bfd@ietf.org'" Subject: Re: BFD for IGPs X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit On Mar 9, 2005, at 2:27 PM, Chris Nogradi wrote: > Dave, > > With regards to the "BFD for IPv4 and IPv6 (Single Hop)" draft, I was > wondering if you could clarify what is meant in the 1st paragraph of > section > 7.3 by, "... but the protocols must share a common topology,..."? It > is not > clear to me if you are referring to the routing protocol (IS-IS) > advertising > multiple data protocols (IPv4 or IPv6) sharing a common topology or if > you > are referring to the routing protocols (IS-IS and OSPF) sharing a > common BFD > session. I was speaking of the data protocols sharing a routing topology. There are some multiprotocol routing protocol variants that can calculate only a single topology for use by all data protocols. In that case, if one data protocol fails, you are faced with either tearing down connectivity for all protocols (bad) or black-holing traffic for the failed protocol (worse.) So in this case you tear down the IGP neighbor so that all data protocols reroute. > If you mean the former, are you saying that only one BFD session > should be created for both data protocols? Or are you saying that a > session > would be created for each data protocol but a failure in either would > cause > both to be considered down? The latter, more specifically, the failure of one BFD session would cause the IGP to consider both data protocols to be down. Remember that every data protocol gets its own BFD session, as BFD is testing the *data* path. The point of these paragraphs is to define how those sessions interact with the control plane. > > Also in the the second paragraph of the same section, I am not sure > what is > meant by "... the failing data protocol SHOULD no longer be advertised > in > Hello packets in order to signal a lack of connectivity for the > protocol." > Are you saying that the router would no longer advertise supporting the > failed data protocol in its Hellos? Would this not affect other > routers on a > multiaccess network since we are still capable of supporting that data > protocol? Other routing protocol variants can calculate different topologies for each protocol. In this case the response to a failing BFD session is to stop advertising the data protocol in hellos, which will cause the topology of the failed protocol to be recalculated, and only that protocol reroutes. In a multiaccess network, this will typically mean that the router in question will be bypassed for that particular data protocol, even if it still has working paths to other routers. This is an inherent limitation of the way the routing protocols model multiaccess networks, namely, that full connectivity is guaranteed. If full connectivity is not present, things fall apart in ugly ways. Fixing this is outside of the scope of BFD. ;-) I will flesh all this out a little bit in the spec. --Dave From rtg-bfd-bounces@ietf.org Thu Mar 10 16:25:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08336; Thu, 10 Mar 2005 16:25:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9VCu-0000ET-3H; Thu, 10 Mar 2005 16:28:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9V9R-0006Lb-EU; Thu, 10 Mar 2005 16:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9V9P-0006LT-Gr for rtg-bfd@megatron.ietf.org; Thu, 10 Mar 2005 16:24:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08288 for ; Thu, 10 Mar 2005 16:24:56 -0500 (EST) Received: from paperclip.laurelnetworks.com ([63.94.127.69] ident=nobody) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9VCE-0000Do-Fo for rtg-bfd@ietf.org; Thu, 10 Mar 2005 16:27:57 -0500 Received: from notepad.laurelnetworks.com (notepad.laurelnetworks.com [63.94.127.20]) by paperclip.laurelnetworks.com (Laurel/Laurel) with ESMTP id j2ALOlGJ017994; Thu, 10 Mar 2005 16:24:47 -0500 Received: from cnogradi-linux.dhcp.pit.laurelnetworks.com (cnogradi-linux.dhcp.pit.laurelnetworks.com [10.0.19.158]) by notepad.laurelnetworks.com (Laurel/Laurel) with ESMTP id j2ALOl4q010564; Thu, 10 Mar 2005 16:24:47 -0500 From: Chris Nogradi Organization: Laurel Networks To: Dave Katz Date: Thu, 10 Mar 2005 16:24:04 -0500 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200503101624.04503.cnogradi@laurelnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Session IP address changes X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Dave, the base BFD draft in section 6.3 paragraph 3 suggests that a BFD peer could decide to change its IP address and that this change would be transparent to the running BFD session since it is demultiplexing based on the discriminator. However, it would seem that the receiving node would have to react to this change by sending all BFD packet for this session to the new address in order to guarantee that the session does not go down. If this is the case, it would seem that it would be beneficial to require nodes to send a BFD packet with the new address as soon as it is changed to ensure that the peer is quickly made aware of the change. It would also be important to document in the packet reception processing the point at which the new address should start being used (I assume at the same time the peer discriminator is set). One scenario I would think that would benefit from this is for IS-IS neighbors. For OSPF and eBGP, the session staying up in the event of an IP address change, should not matter as the adjacencies will be torn down anyway. But in the case of static routes, if the address of the peer changes, the BFD session should go down. Seeing that this is the case, it would seem appropriate to only allow the IP address change when ALL routing protocols using the BFD session support it or don't care. What do you think? Thanks, Chris From rtg-bfd-bounces@ietf.org Thu Mar 10 18:00:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17140; Thu, 10 Mar 2005 18:00:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Wgv-0004o2-JM; Thu, 10 Mar 2005 18:03:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9WcO-0006Cf-GD; Thu, 10 Mar 2005 17:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9WcM-0006Ca-Px for rtg-bfd@megatron.ietf.org; Thu, 10 Mar 2005 17:58:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16945 for ; Thu, 10 Mar 2005 17:58:55 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9WfF-0004e8-Ua for rtg-bfd@ietf.org; Thu, 10 Mar 2005 18:01:58 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j2AMwm979335; Thu, 10 Mar 2005 14:58:48 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2AMwhe73482; Thu, 10 Mar 2005 14:58:43 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <200503101624.04503.cnogradi@laurelnetworks.com> References: <200503101624.04503.cnogradi@laurelnetworks.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 10 Mar 2005 15:58:47 -0700 To: Chris Nogradi X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: Session IP address changes X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit This scenario was intended to deal with the particular case of running BFD on an unnumbered IP interface, where the source address of packets may be unpredictable and may change, but there is nothing amiss with the BFD session. Since there was this possibility in the particular case, it became useful to generalize it. Note that you're referring to the base spec; it says nothing about IP or the interactions with particular protocols or the address to which packets are sent; these are issues for the application specs. All it says is that received packets must be demuxed solely by the Your Discr field, which is all that it should say IMHO. Remember, the functionality mandated here will apply to all future applications of the protocol (non-IP, non-network-layer, etc.) for which our IP-centric view of addressing may not apply. The 1hop spec is pretty clear on addressing; if the link is numbered, the addresses must be stable. In the unnumbered case, it allows address flexibility. Adding note in section 6 of that document specifying that the dest address must be set to the source address of the received packet in that case is probably a good idea. (Note that if the system persists in using the old address, either it will work because the address is valid, or the session will fail, and in either case should probably converge on the right thing.) I don't want to get into attempting to specify operations based on a nebulous characteristic of one or more of the clients using the session; rather, what I think I will do is to note that an implementation MAY signal the fact that the address changed to the clients, and let them deal with the fallout as they see fit. If an application decides it is fatal, it can always tear down the session. --Dave On Mar 10, 2005, at 2:24 PM, Chris Nogradi wrote: > Dave, > > the base BFD draft in section 6.3 paragraph 3 suggests that a BFD peer > could > decide to change its IP address and that this change would be > transparent to > the running BFD session since it is demultiplexing based on the > discriminator. However, it would seem that the receiving node would > have to > react to this change by sending all BFD packet for this session to the > new > address in order to guarantee that the session does not go down. If > this is > the case, it would seem that it would be beneficial to require nodes > to send > a BFD packet with the new address as soon as it is changed to ensure > that the > peer is quickly made aware of the change. It would also be important > to > document in the packet reception processing the point at which the new > address should start being used (I assume at the same time the peer > discriminator is set). One scenario I would think that would benefit > from > this is for IS-IS neighbors. > > For OSPF and eBGP, the session staying up in the event of an IP address > change, should not matter as the adjacencies will be torn down anyway. > But in > the case of static routes, if the address of the peer changes, the BFD > session should go down. Seeing that this is the case, it would seem > appropriate to only allow the IP address change when ALL routing > protocols > using the BFD session support it or don't care. > > What do you think? > > Thanks, > > Chris > From rtg-bfd-bounces@ietf.org Thu Mar 10 20:18:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28963; Thu, 10 Mar 2005 20:18:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9YqO-0002mE-4w; Thu, 10 Mar 2005 20:21:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Yml-0002We-4d; Thu, 10 Mar 2005 20:17:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Ymi-0002WU-GI for rtg-bfd@megatron.ietf.org; Thu, 10 Mar 2005 20:17:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28827 for ; Thu, 10 Mar 2005 20:17:44 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Ypc-0002f5-OV for rtg-bfd@ietf.org; Thu, 10 Mar 2005 20:20:49 -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 j2B1HcBm079692; Thu, 10 Mar 2005 17:17:38 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2B1Hce99950; Thu, 10 Mar 2005 17:17:38 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: <200503101624.04503.cnogradi@laurelnetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3909cc406c7ac17dc576c7c10432539d@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 10 Mar 2005 18:17:43 -0700 To: Chris Nogradi , "'rtg-bfd@ietf.org'" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Subject: Re: Session IP address changes X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Actually I thought about this a bit more, and came to the conclusion that the spec should say that the BFD implementation must continue to use the configured destination address (given by the client when setting up the session) and that the fact that packets are arriving from a new source address SHOULD be communicated to the client(s) so they can decide what to do. The dest address is a parameter in the API, and BFD should not be changing it of its own accord. --Dave On Mar 10, 2005, at 3:58 PM, Dave Katz wrote: > This scenario was intended to deal with the particular case of running > BFD on an unnumbered IP interface, where the source address of packets > may be unpredictable and may change, but there is nothing amiss with > the BFD session. Since there was this possibility in the particular > case, it became useful to generalize it. > > Note that you're referring to the base spec; it says nothing about IP > or the interactions with particular protocols or the address to which > packets are sent; these are issues for the application specs. All it > says is that received packets must be demuxed solely by the Your Discr > field, which is all that it should say IMHO. Remember, the > functionality mandated here will apply to all future applications of > the protocol (non-IP, non-network-layer, etc.) for which our > IP-centric view of addressing may not apply. > > The 1hop spec is pretty clear on addressing; if the link is numbered, > the addresses must be stable. In the unnumbered case, it allows > address flexibility. Adding note in section 6 of that document > specifying that the dest address must be set to the source address of > the received packet in that case is probably a good idea. (Note that > if the system persists in using the old address, either it will work > because the address is valid, or the session will fail, and in either > case should probably converge on the right thing.) > > I don't want to get into attempting to specify operations based on a > nebulous characteristic of one or more of the clients using the > session; rather, what I think I will do is to note that an > implementation MAY signal the fact that the address changed to the > clients, and let them deal with the fallout as they see fit. If an > application decides it is fatal, it can always tear down the session. > > --Dave > > > > On Mar 10, 2005, at 2:24 PM, Chris Nogradi wrote: > >> Dave, >> >> the base BFD draft in section 6.3 paragraph 3 suggests that a BFD >> peer could >> decide to change its IP address and that this change would be >> transparent to >> the running BFD session since it is demultiplexing based on the >> discriminator. However, it would seem that the receiving node would >> have to >> react to this change by sending all BFD packet for this session to >> the new >> address in order to guarantee that the session does not go down. If >> this is >> the case, it would seem that it would be beneficial to require nodes >> to send >> a BFD packet with the new address as soon as it is changed to ensure >> that the >> peer is quickly made aware of the change. It would also be important >> to >> document in the packet reception processing the point at which the new >> address should start being used (I assume at the same time the peer >> discriminator is set). One scenario I would think that would benefit >> from >> this is for IS-IS neighbors. >> >> For OSPF and eBGP, the session staying up in the event of an IP >> address >> change, should not matter as the adjacencies will be torn down >> anyway. But in >> the case of static routes, if the address of the peer changes, the BFD >> session should go down. Seeing that this is the case, it would seem >> appropriate to only allow the IP address change when ALL routing >> protocols >> using the BFD session support it or don't care. >> >> What do you think? >> >> Thanks, >> >> Chris >> > > From rtg-bfd-bounces@ietf.org Fri Mar 11 20:56:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01825; Fri, 11 Mar 2005 20:56:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9vuc-00074h-7o; Fri, 11 Mar 2005 20:59:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9vov-00028H-8W; Fri, 11 Mar 2005 20:53:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9vot-000257-SN for rtg-bfd@megatron.ietf.org; Fri, 11 Mar 2005 20:53:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01613 for ; Fri, 11 Mar 2005 20:53:34 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9vs1-0006wT-9Z for rtg-bfd@ietf.org; Fri, 11 Mar 2005 20:56:49 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j2C1rQ990890 for ; Fri, 11 Mar 2005 17:53:26 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2C1rLe15236 for ; Fri, 11 Mar 2005 17:53:21 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <302ea42bfd6ba31bd7af777d8a017d42@juniper.net> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "'rtg-bfd@ietf.org'" From: Dave Katz Date: Fri, 11 Mar 2005 18:53:48 -0700 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Subject: TTL/Auth Redux X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit For those not present in Minneapolis yesterday, there was a discussion about the issue of what to say about the use of the TTL Hack when authentication is in use. There seemed to be a feeling in the room that the use of the TTL Hack in this case was desirable enough so that it should be a SHOULD. I felt (though I was not present, but only participating via audio feed) that this was in part driven by Pekka reiterating his concerns about a system being somehow involuntarily forced to run repeated cryptographic operations, providing a DoS opportunity. There was also some discussion about the order of these two operations. Toward the end of the discussion, it appeared that Pekka's concerns were based on the assumption that a system had to attempt to validate any packet carrying authentication that it saw. I thought it would be worth revisiting the issue one last time, now that I think I understand the concern. In the last rev, I put in the following verbiage: If BFD authentication is in use, any value of TTL/Hop Count MAY be used in transmitted packets, and received packets MUST NOT be discarded based on the received TTL/Hop Count. My intent was twofold. First, the only purpose of the TTL check was as a really lousy form of authentication--if other forms of authentication are in use, the TTL check is unnecessary. Second, I am concerned about the unintended consequences of this check. There is an existence proof (or at least a historical existence proof) of media that appear as a single network layer hop, but decrement TTL in mid-link (tunneling schemes), as well as systems that decrement TTL when they ought not to. By mandating the TTL hack, BFD could not function across such links, but they could be worked around through the use of authentication. This ought not to happen, but it has, and if the TTL hack is unnecessary, it ought not to be there. (Not to mention that it is truly heinous.) At least that's my take on the matter. It's also my contention that if you *are* going to use authentication, you *must* have a generic mechanism for avoiding DoS attacks on the crypto engine, since otherwise you *must* trust all potential sources of packets (in which case the authentication is unnecessary.) Pekka can correct me if I'm wrong, but I believe he was concerned that if a system was running without authentication (and thus making the TTL check) and a bad guy off in the distance lobbed in a packet with authentication, the system would be obligated to do cryptographic processing on the packet. However, this scenario cannot happen due to the way the base spec is written. First of all, the packet is demuxed by Your Descr. If it doesn't select a session, the packet is discarded. Next, if packet demuxes to a session and the session is not using authentication, the packet will be discarded if it has the A bit set. So at this point, in the scenario in question, the packet would have been discarded one way or another without ever touching the authentication data. So the short version is that there is *no* risk of doing *any* cryptographic calculation if authentication is not in use. (One side issue is that "authentication in use" is not a well specified term. I will improve that; what it means is that authenticated packets are being sent and received for a particular session.) The language, as written, bars the use of TTL hack when authentication is in use. The question is, what should the spec say if someone *really* wants to use authentication *and* the TTL hack at the same time? The antiauthoritarian product builder in me notes that any implementation is free to deviate from any specification at any time, so long as the implications on interoperability are known and it is done between consenting adults. This is arguably hard-headed. My druthers would be to leave the wording as-is with the belief that it is unnecessary and ugly to spec, and implementors can play games as they see fit. However, I can see some wiggle room in this that serves everyones' purposes and doesn't introduce any interoperability issues. That would be to say that the sender MUST use TTL 255 (which isn't any burden unless you're trying to do some kind of path length limitation, which would be even weirder), and that the receiver MAY make the TTL check, and have a couple of sentences about the implications of all this. The issue then falls completely on the receiving system, and people can lobby their vendors for a knob, and nobody can be accused of being out of spec. Comments? --Dave From rtg-bfd-bounces@ietf.org Sun Mar 13 14:00:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02282; Sun, 13 Mar 2005 14:00:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAYNu-0003BA-Ld; Sun, 13 Mar 2005 14:04:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAYJz-0000qj-LN; Sun, 13 Mar 2005 14:00:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAYJy-0000qd-9w for rtg-bfd@megatron.ietf.org; Sun, 13 Mar 2005 14:00:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02252 for ; Sun, 13 Mar 2005 14:00:10 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAYNR-0003AG-21 for rtg-bfd@ietf.org; Sun, 13 Mar 2005 14:03:49 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j2DIxub12981; Sun, 13 Mar 2005 20:59:56 +0200 Date: Sun, 13 Mar 2005 20:59:56 +0200 (EET) From: Pekka Savola To: Dave Katz In-Reply-To: <302ea42bfd6ba31bd7af777d8a017d42@juniper.net> Message-ID: References: <302ea42bfd6ba31bd7af777d8a017d42@juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: "'rtg-bfd@ietf.org'" Subject: Re: TTL/Auth Redux X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 On Fri, 11 Mar 2005, Dave Katz wrote: > Toward the end of the discussion, it appeared that Pekka's concerns were > based on the assumption that a system had to attempt to validate any packet > carrying authentication that it saw. I have three main concerns: 1) if the system is not configured to use authentication, but the attacker sends you packets with Auth bit set which would be demultiplexed to an existing or new session -- and you don't discard the packets (because the authentication is disabled) before demultiplexing occurs, you end up having to perform SHA1 operations on the attack packet. This is an easy demultiplexing computation DoS attack. 2) if the system is configured to use authentication, but A bit is not set and would be demuxed to an exising or new session, is the packet discarded before performing SHA1 computation? (It seems so, but I'm not 100% sure). 3) If the system is configured to use authentication, and A bit is set in packets sent from an off-link attacker, the attacker is able to perform a SHA1 authentication attack on any router using BFD authentication can be mitigated to the local link if TTL=255 check is done first. The result could be that the operators would be _afraid_ to turn on authentication because that would open an off-link attack vector. ... For 1) and 2), the spec doesn't appear to be 100% clear what the behaviour is (the last sentences of the first paragraph -- maybe this is due to the auth/no-auth transition without session reset?) and 3) is clearly an issue unless the receivers are mandated to perform TTL=255 check unless otherwise configured. [Section 6.7.6:] If the Your Discriminator field is zero, the session MUST be selected based on some combination of other fields, possibly including source addressing information, the My Discriminator field, and the interface over which the packet was received. The exact method of selection is application-specific and is thus outside the scope of this specification. If a matching session is not found, a new session may be created, or the packet may be discarded. This choice is outside the scope of this specification. If the A bit is set and no authentication is in use (bfd.AuthType is zero), the packet MUST be discarded. If the A bit is clear and authentication is in use (bfd.AuthType is nonzero), the packet MUST be discarded. > My intent was twofold. First, the only purpose of the TTL check was as a > really lousy form of authentication--if other forms of authentication are in > use, the TTL check is unnecessary. Second, I am concerned about the > unintended consequences of this check. There is an existence proof (or at > least a historical existence proof) of media that appear as a single network > layer hop, but decrement TTL in mid-link (tunneling schemes), as well as > systems that decrement TTL when they ought not to. These don't appear to be "single-hop" BFD sessions ? This seems hacking around broken media to be "pseudo single-hop" while they really aren't? While I can see why addressing these may be lucrative from the practical point-of-view, maybe we should be just making sure that multihop BFD works well in these scenarios? > It's also my contention that if you *are* going to use authentication, you > *must* have a generic mechanism for avoiding DoS attacks on the crypto > engine, since otherwise you *must* trust all potential sources of packets (in > which case the authentication is unnecessary.) DoS attacks from the same link vs DoS attacks from anywhere in the Internet have a very different attack vector. The operators may consider the first case to be acceptable (e.g., the customer's link, or semi-trusted IX fabric), but the latter requires another mechanisms for security. Hopefully this clarifies what kind of attacks I'm worried about. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rtg-bfd-bounces@ietf.org Sun Mar 13 15:17:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07745; Sun, 13 Mar 2005 15:17:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAZaI-0005gd-Is; Sun, 13 Mar 2005 15:21:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAZUf-00077N-QJ; Sun, 13 Mar 2005 15:15:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAZUe-00077I-OJ for rtg-bfd@megatron.ietf.org; Sun, 13 Mar 2005 15:15:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07476 for ; Sun, 13 Mar 2005 15:15:19 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAZY6-0005bJ-Ft for rtg-bfd@ietf.org; Sun, 13 Mar 2005 15:18:57 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j2DKEx999540; Sun, 13 Mar 2005 12:15:01 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2DKEre31579; Sun, 13 Mar 2005 12:14:53 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: References: <302ea42bfd6ba31bd7af777d8a017d42@juniper.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0800c8fb4c7cf5af900919aec7dee613@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Sun, 13 Mar 2005 13:15:59 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Cc: "'rtg-bfd@ietf.org'" Subject: Re: TTL/Auth Redux X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit On Mar 13, 2005, at 11:59 AM, Pekka Savola wrote: > On Fri, 11 Mar 2005, Dave Katz wrote: >> Toward the end of the discussion, it appeared that Pekka's concerns >> were based on the assumption that a system had to attempt to validate >> any packet carrying authentication that it saw. > > I have three main concerns: > > 1) if the system is not configured to use authentication, but the > attacker sends you packets with Auth bit set which would be > demultiplexed to an existing or new session -- and you don't discard > the packets (because the authentication is disabled) before > demultiplexing occurs, you end up having to perform SHA1 operations on > the attack packet. This is an easy demultiplexing computation DoS > attack. I don't understand what you're trying to say. If the system is not configured to use authentication, the system will *never* try to authenticate, since it has no means to do so (what would it use for a key?) They will *always* be discarded. The discard is two-way--if authentication is disabled on a session, all authenticated packets will be discarded (as well as the opposite.) So there is no attack possible. > > 2) if the system is configured to use authentication, but A bit is not > set and would be demuxed to an exising or new session, is the packet > discarded before performing SHA1 computation? (It seems so, but I'm > not 100% sure). How could you perform the SHA1 computation on an unauthenticated packet? There's no authentication section, key ID, or hash to verify. There is no authentication calculation on unauthenticated packets, period, there can't be. Any implementor who runs a SHA1 checksum over the packet before checking whether it's necessary deserves to fail. > > 3) If the system is configured to use authentication, and A bit is set > in packets sent from an off-link attacker, the attacker is able to > perform a SHA1 authentication attack on any router using BFD > authentication can be mitigated to the local link if TTL=255 check is > done first. The result could be that the operators would be _afraid_ > to turn on authentication because that would open an off-link attack > vector. I'll throw out my argument about the futility of cryptographic authentication in an environment that is easily DoS'ed. But in any case, the language I suggested allows the TTL check for people who want to do that, it just doesn't mandate it (or bar it.) The order of the checks is outside the scope, as the intent of the protocol spec is not to protect half-baked implementations. Those folks who have DoS-able crypto engines are hopefully smart enough to use the tools the right way. The spec is *not* an implementation guide. > > ... > > For 1) and 2), the spec doesn't appear to be 100% clear what the > behaviour is (the last sentences of the first paragraph -- maybe this > is due to the auth/no-auth transition without session reset?) and 3) > is clearly an issue unless the receivers are mandated to perform > TTL=255 check unless otherwise configured. > > [Section 6.7.6:] > If the Your Discriminator field is zero, the session MUST be > selected based on some combination of other fields, possibly > including source addressing information, the My Discriminator > field, and the interface over which the packet was received. The > exact method of selection is application-specific and is thus > outside the scope of this specification. If a matching session > is > not found, a new session may be created, or the packet may be > discarded. This choice is outside the scope of this > specification. > > If the A bit is set and no authentication is in use (bfd.AuthType > is zero), the packet MUST be discarded. > > If the A bit is clear and authentication is in use (bfd.AuthType > is nonzero), the packet MUST be discarded. I don't get what you're trying to say here. The first paragraph deals with the case when you receive the first packet for a session (no Your Discr.) Whether or not you create a session or discard it depends on how BFD is being used, and is outside the scope of the base spec. Generally you would discard such packets (for example, in the OSPF case, both sides know there's going to be a BFD session by virtue of the OSPF neighbor relationship) but there are certainly cases where you might want to bootstrap a session based purely on BFD. But this is entirely orthogonal to the authentication question. As I said before, if a system is capable of being swamped by authentication, then it is free to turn on the TTL check as the verbiage at the end of my last missive suggested. > >> My intent was twofold. First, the only purpose of the TTL check was >> as a really lousy form of authentication--if other forms of >> authentication are in use, the TTL check is unnecessary. Second, I >> am concerned about the unintended consequences of this check. There >> is an existence proof (or at least a historical existence proof) of >> media that appear as a single network layer hop, but decrement TTL in >> mid-link (tunneling schemes), as well as systems that decrement TTL >> when they ought not to. > > These don't appear to be "single-hop" BFD sessions ? This seems > hacking around broken media to be "pseudo single-hop" while they > really aren't? While I can see why addressing these may be lucrative > from the practical point-of-view, maybe we should be just making sure > that multihop BFD works well in these scenarios? The fact is that they have existed, they may exist in the future, and that their presence may not be known unless somebody is watching TTLs carefully. But it doesn't matter, based on my suggested change. > >> It's also my contention that if you *are* going to use >> authentication, you *must* have a generic mechanism for avoiding DoS >> attacks on the crypto engine, since otherwise you *must* trust all >> potential sources of packets (in which case the authentication is >> unnecessary.) > > DoS attacks from the same link vs DoS attacks from anywhere in the > Internet have a very different attack vector. The operators may > consider the first case to be acceptable (e.g., the customer's link, > or semi-trusted IX fabric), but the latter requires another mechanisms > for security. > > Hopefully this clarifies what kind of attacks I'm worried about. > So now I'm completely lost. Is my suggested verbiage acceptable or not? The rest of this becomes purely academic if it is. Frankly, I'm finding this whole exchange rather frustrating. --Dave From rtg-bfd-bounces@ietf.org Mon Mar 14 09:07:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03885; Mon, 14 Mar 2005 09:07:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAqI9-0003Oe-Sq; Mon, 14 Mar 2005 09:11:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAqCG-0003jS-Jv; Mon, 14 Mar 2005 09:05:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAqCF-0003jM-QF for rtg-bfd@megatron.ietf.org; Mon, 14 Mar 2005 09:05:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03548 for ; Mon, 14 Mar 2005 09:05:25 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAqFr-0003Dn-AK for rtg-bfd@ietf.org; Mon, 14 Mar 2005 09:09:13 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j2EE58o04264; Mon, 14 Mar 2005 16:05:08 +0200 Date: Mon, 14 Mar 2005 16:05:08 +0200 (EET) From: Pekka Savola To: Dave Katz In-Reply-To: <0800c8fb4c7cf5af900919aec7dee613@juniper.net> Message-ID: References: <302ea42bfd6ba31bd7af777d8a017d42@juniper.net> <0800c8fb4c7cf5af900919aec7dee613@juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: "'rtg-bfd@ietf.org'" Subject: Re: TTL/Auth Redux X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Hi, (I agree that 1) and 2) don't seem to be real problems except with really, really broken implementations, so let's not focus on them. Sorry about confusion.) More inline.. On Sun, 13 Mar 2005, Dave Katz wrote: >> 3) If the system is configured to use authentication, and A bit is set in >> packets sent from an off-link attacker, the attacker is able to perform a >> SHA1 authentication attack on any router using BFD authentication can be >> mitigated to the local link if TTL=255 check is done first. The result >> could be that the operators would be _afraid_ to turn on authentication >> because that would open an off-link attack vector. > > I'll throw out my argument about the futility of cryptographic authentication > in an environment that is easily DoS'ed. But in any case, the language I > suggested allows the TTL check for people who want to do that, it just > doesn't mandate it (or bar it.) The order of the checks is outside the > scope, as the intent of the protocol spec is not to protect half-baked > implementations. Those folks who have DoS-able crypto engines are hopefully > smart enough to use the tools the right way. The spec is *not* an > implementation guide. I don't disagree from what's the bare minimum for the protocol spec, but nowadays the specs also must have a security considerations section ;-). The security behaviour in the protocol is very unpredictable unless there is also specification about the security properties of the system. And that's exactly what those couple of uppercase statements on TTL checking try to do. >> These don't appear to be "single-hop" BFD sessions ? This seems hacking >> around broken media to be "pseudo single-hop" while they really aren't? >> While I can see why addressing these may be lucrative from the practical >> point-of-view, maybe we should be just making sure that multihop BFD works >> well in these scenarios? > > The fact is that they have existed, they may exist in the future, and that > their presence may not be known unless somebody is watching TTLs carefully. > But it doesn't matter, based on my suggested change. But do these happen, just out of the blue without the session being reset? If the BFD session does not form when it's initially configured, for the first time, the network admin may suspect that this is the case, and disable TTL checking. > So now I'm completely lost. Is my suggested verbiage acceptable or not? The > rest of this becomes purely academic if it is. Frankly, I'm finding this > whole exchange rather frustrating. I was just trying to get an understanding on the attacks first. You suggested: >However, I can see some wiggle room in this that serves everyones' >purposes and doesn't introduce any interoperability issues. That >would be to say that the sender MUST use TTL 255 (which isn't any >burden unless you're trying to do some kind of path length >limitation, which would be even weirder), and that the receiver MAY >make the TTL check, and have a couple of sentences about the >implications of all this. The issue then falls completely on the >receiving system, and people can lobby their vendors for a knob, and >nobody can be accused of being out of spec. This is a good direction, but I we should have use "SHOULD [...] unless configured otherwise" rather than MAY. (I think this was pretty close to what the WG seemed to feel in MPLS.) In addition, it wouldn't hurt to have some text also recommending to have a configuration knob for this feature, but I'm OK with leaving that out because you'd argue the spec is not an implementation guide ;-). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rtg-bfd-bounces@ietf.org Mon Mar 14 15:30:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18558; Mon, 14 Mar 2005 15:30:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwGs-0003aE-4U; Mon, 14 Mar 2005 15:34:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwCz-00029Z-0S; Mon, 14 Mar 2005 15:30:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwCy-00029H-1q for rtg-bfd@megatron.ietf.org; Mon, 14 Mar 2005 15:30:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18458 for ; Mon, 14 Mar 2005 15:30:34 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwGe-0003Z0-Mt for rtg-bfd@ietf.org; Mon, 14 Mar 2005 15:34:25 -0500 Received: by rproxy.gmail.com with SMTP id j1so2144122rnf for ; Mon, 14 Mar 2005 12:30:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=q+Jq2YSvSOGkDc1F8MDxZNwSI3JcQzyaAQHAOxeWazmtVJ4yGD1FGCeUYzAbV+5h/yUq2Qh6dvPvOSZMmNWmYcNqjHzs2VgltqF5oKK9qMpMSzIK+hhMul3ajJ9ajdrYmepo0C1hFEZHVzyhHZ3mAxorRQNgPpRy96PgegO3EbE= Received: by 10.38.78.51 with SMTP id a51mr3849452rnb; Mon, 14 Mar 2005 12:25:58 -0800 (PST) Received: by 10.38.75.70 with HTTP; Mon, 14 Mar 2005 12:25:58 -0800 (PST) Message-ID: <9e31186f05031412252f866e24@mail.gmail.com> Date: Mon, 14 Mar 2005 21:25:58 +0100 From: Carlos Garcia Braschi To: rtg-bfd@ietf.org In-Reply-To: <4235c365.5a9dd455.1403.ffffa963SMTPIN_ADDED@mx.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4235c365.5a9dd455.1403.ffffa963SMTPIN_ADDED@mx.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Subject: Re: TTL/Auth Redux X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Carlos Garcia Braschi List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit I'm siding with Pekka. I find the "SHOULD unless configured otherwise" wording an interesting option, allowing for strange 1 hop behaviours, and but not encouraging them. I'd rather go with the current MUST but allow it to be configured away, though. I'd like to diminish the possibility that I buy an equipment that is compliant with a "BFD 1hop RFC" specification and implements it in a way that is not trustworthy. Yes, any implementor should be smart enough to make it right, but I don't want to take risks. And I'd like to add the least amount of "desired implementation annotations" to the spec, so that a vendor will implement it right even if it has not heard from us before and did not read this discussion. Carlos. On Mon, 14 Mar 2005 09:01:25 -0800 (PST), rtg-bfd-request@ietf.org wrote: > From: Pekka Savola > Subject: Re: TTL/Auth Redux > To: Dave Katz > Cc: "'rtg-bfd@ietf.org'" > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > Hi, > > (I agree that 1) and 2) don't seem to be real problems except with > really, really broken implementations, so let's not focus on them. > Sorry about confusion.) More inline.. > > On Sun, 13 Mar 2005, Dave Katz wrote: > >> 3) If the system is configured to use authentication, and A bit is set in > >> packets sent from an off-link attacker, the attacker is able to perform a > >> SHA1 authentication attack on any router using BFD authentication can be > >> mitigated to the local link if TTL=255 check is done first. The result > >> could be that the operators would be _afraid_ to turn on authentication > >> because that would open an off-link attack vector. > > > > I'll throw out my argument about the futility of cryptographic authentication > > in an environment that is easily DoS'ed. But in any case, the language I > > suggested allows the TTL check for people who want to do that, it just > > doesn't mandate it (or bar it.) The order of the checks is outside the > > scope, as the intent of the protocol spec is not to protect half-baked > > implementations. Those folks who have DoS-able crypto engines are hopefully > > smart enough to use the tools the right way. The spec is *not* an > > implementation guide. > > I don't disagree from what's the bare minimum for the protocol spec, > but nowadays the specs also must have a security considerations > section ;-). The security behaviour in the protocol is very > unpredictable unless there is also specification about the security > properties of the system. And that's exactly what those couple of > uppercase statements on TTL checking try to do. > > >> These don't appear to be "single-hop" BFD sessions ? This seems hacking > >> around broken media to be "pseudo single-hop" while they really aren't? > >> While I can see why addressing these may be lucrative from the practical > >> point-of-view, maybe we should be just making sure that multihop BFD works > >> well in these scenarios? > > > > The fact is that they have existed, they may exist in the future, and that > > their presence may not be known unless somebody is watching TTLs carefully. > > But it doesn't matter, based on my suggested change. > > But do these happen, just out of the blue without the session being > reset? If the BFD session does not form when it's initially > configured, for the first time, the network admin may suspect that > this is the case, and disable TTL checking. > > > So now I'm completely lost. Is my suggested verbiage acceptable or not? The > > rest of this becomes purely academic if it is. Frankly, I'm finding this > > whole exchange rather frustrating. > > I was just trying to get an understanding on the attacks first. > You suggested: > > >However, I can see some wiggle room in this that serves everyones' > >purposes and doesn't introduce any interoperability issues. That > >would be to say that the sender MUST use TTL 255 (which isn't any > >burden unless you're trying to do some kind of path length > >limitation, which would be even weirder), and that the receiver MAY > >make the TTL check, and have a couple of sentences about the > >implications of all this. The issue then falls completely on the > >receiving system, and people can lobby their vendors for a knob, and > >nobody can be accused of being out of spec. > > This is a good direction, but I we should have use "SHOULD [...] > unless configured otherwise" rather than MAY. (I think this was pretty > close to what the WG seemed to feel in MPLS.) In addition, it > wouldn't hurt to have some text also recommending to have a > configuration knob for this feature, but I'm OK with leaving that out > because you'd argue the spec is not an implementation guide ;-). > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > From rtg-bfd-bounces@ietf.org Mon Mar 14 16:08:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22307; Mon, 14 Mar 2005 16:08:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwrW-0005QA-2S; Mon, 14 Mar 2005 16:12:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwnj-0007b1-24; Mon, 14 Mar 2005 16:08:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwnh-0007aw-9r for rtg-bfd@megatron.ietf.org; Mon, 14 Mar 2005 16:08:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22299 for ; Mon, 14 Mar 2005 16:08:31 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwrO-0005Q0-AC for rtg-bfd@ietf.org; Mon, 14 Mar 2005 16:12:22 -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 j2EL8NBm003418; Mon, 14 Mar 2005 13:08:23 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2EL8Me38362; Mon, 14 Mar 2005 13:08:22 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: References: <302ea42bfd6ba31bd7af777d8a017d42@juniper.net> <0800c8fb4c7cf5af900919aec7dee613@juniper.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Date: Mon, 14 Mar 2005 14:09:51 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit Cc: "'rtg-bfd@ietf.org'" Subject: Re: TTL/Auth Redux X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit On Mar 14, 2005, at 7:05 AM, Pekka Savola wrote: >> I'll throw out my argument about the futility of cryptographic >> authentication in an environment that is easily DoS'ed. But in any >> case, the language I suggested allows the TTL check for people who >> want to do that, it just doesn't mandate it (or bar it.) The order >> of the checks is outside the scope, as the intent of the protocol >> spec is not to protect half-baked implementations. Those folks who >> have DoS-able crypto engines are hopefully smart enough to use the >> tools the right way. The spec is *not* an implementation guide. > > I don't disagree from what's the bare minimum for the protocol spec, > but nowadays the specs also must have a security considerations > section ;-). The security behaviour in the protocol is very > unpredictable unless there is also specification about the security > properties of the system. And that's exactly what those couple of > uppercase statements on TTL checking try to do. There is a Security Considerations section, as you know. Actually, that section in the base spec currently mandates the TTL hack, something that dates to before authentication was added. I'll fix that language (it probably shouldn't be in the base spec, but should reference the 1hop spec instead.) I can add a couple of sentences about the DoS exposure there. The security behavior of the protocol is entirely predictable. It's the security behavior of the *implementation* that is unpredictable, and as such is outside the scope of the protocol spec. It sounds as though someone should write an informational RFC or BCP on this stuff (I have neither the time nor the inclination). > >> However, I can see some wiggle room in this that serves everyones' >> purposes and doesn't introduce any interoperability issues. That >> would be to say that the sender MUST use TTL 255 (which isn't any >> burden unless you're trying to do some kind of path length >> limitation, which would be even weirder), and that the receiver MAY >> make the TTL check, and have a couple of sentences about the >> implications of all this. The issue then falls completely on the >> receiving system, and people can lobby their vendors for a knob, and >> nobody can be accused of being out of spec. > > This is a good direction, but I we should have use "SHOULD [...] > unless configured otherwise" rather than MAY. (I think this was pretty > close to what the WG seemed to feel in MPLS.) In addition, it > wouldn't hurt to have some text also recommending to have a > configuration knob for this feature, but I'm OK with leaving that out > because you'd argue the spec is not an implementation guide ;-). Please go back and read the definition of SHOULD and MAY. SHOULD says, in so many words, that you better have a really good reason, and really know what you're doing, to go against the clause. MAY says that it's fully optional, but you need to be able to interoperate either way. "SHOULD unless configured otherwise" isn't valid specsmanship. As the only reason that one would be forced to do the TTL check is if the crypto engine is substandard, that to me does not fall into the SHOULD category, which ought to apply only to those situations whereby the bulk of implementations are skating on thin ice if they go against it. This check ought to be purely optional, as (a) any useful crypto implementation will not have this issue, and (b) there is no interoperability issue regardless of which way you go (with the revised text), and (c) the TTL check is nothing to be proud of and should be avoided if possible (IMHO.) If you referred to the TTL check as "security" to one of the security guys, I think they might beg to differ. I will happily put in some text to explain the issue, as I said earlier. From a practical standpoint, the outcome is the same--you will ask for the feature from your vendor and they will probably deliver it. My feeling as far as the meeting goes was that there was not sufficient discussion for those in the room to make an informed decision (made worse by my participating through a five second delay), and if I understand the Rules of Engagement correctly, the meetings are advisory and the mailing list is the determining factor. Therefore, in order to try to put this issue to bed, I offer the following text for the indicated two sections in the 1hop draft. Unless there is significant and informed opposition to the text, I will publish it as written and we can move on. --Dave 5. TTL/Hop Count Issues If BFD authentication is not in use on a session, all BFD Control packets for the session MUST be sent with a TTL or Hop Count value of 255. All received BFD Control packets that are demultiplexed to the session MUST be discarded if the received TTL or Hop Count is not equal to 255. A discussion of this mechanism can be found in [GTSM]. If BFD authentication is in use on a session, all BFD Control packets MUST be sent with a TTL or Hop Count value of 255. All received BFD Control packets that are demultiplexed the session MAY be discarded if the received TTL or Hop Count is not equal to 255. In the context of this section, "authentication in use" means that the system is sending BFD control packets with the Authentication bit set and with the Authentication Section included, and that all unauthenticated packets demultiplexed to the session are discarded, per the BFD base specification. Security Considerations In this application, the use of TTL=255 on transmit and receive is viewed as supplying equivalent security characteristics to other protocols used in the infrastructure, as it is not trivially spoofable. The security implications of this mechanism are further discussed in the GTSM specification. The security implications of the use of BFD Authentication are discussed in the base BFD specification. The use of the TTL=255 check simultaneously with BFD Authentication provides a low overhead mechanism for discarding a class of unauthorized packets and may be useful in implementations in which cryptographic checksum use is susceptable to denial of service attacks. The use or non-use of this mechanism does not impact interoperability. From rtg-bfd-bounces@ietf.org Mon Mar 14 16:35:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24667; Mon, 14 Mar 2005 16:35:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAxHr-0006bz-Ft; Mon, 14 Mar 2005 16:39:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAxBG-0002SP-Kf; Mon, 14 Mar 2005 16:32:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAxBF-0002SA-99 for rtg-bfd@megatron.ietf.org; Mon, 14 Mar 2005 16:32:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24351 for ; Mon, 14 Mar 2005 16:32:50 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAxEw-0006TV-Gq for rtg-bfd@ietf.org; Mon, 14 Mar 2005 16:36:42 -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 j2ELWgBm003630; Mon, 14 Mar 2005 13:32:42 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2ELWge42934; Mon, 14 Mar 2005 13:32:42 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <9e31186f05031412252f866e24@mail.gmail.com> References: <4235c365.5a9dd455.1403.ffffa963SMTPIN_ADDED@mx.gmail.com> <9e31186f05031412252f866e24@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <20605b4831756dce34a12f4ec538b484@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Mon, 14 Mar 2005 14:34:11 -0700 To: Carlos Garcia Braschi X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: TTL/Auth Redux X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit On Mar 14, 2005, at 1:25 PM, Carlos Garcia Braschi wrote: > I'm siding with Pekka. I find the "SHOULD unless configured otherwise" > wording an interesting option, allowing for strange 1 hop behaviours, > and but not encouraging them. "SHOULD unless configured otherwise" is not a valid thing to put into a spec, IMHO, as it specifies implementation. > > I'd rather go with the current MUST but allow it to be configured > away, though. > > I'd like to diminish the possibility that I buy an equipment that is > compliant with a "BFD 1hop RFC" specification and implements it in a > way > that is not trustworthy. This is not an issue of being trustworthy; it is an issue of whether the implementation will fall on its face (with complete authentication integrity.) If so, and the vendor does not implement the TTL hack, you should not buy that implementation. This is true of all features of implementation; I can easily make most OSPF implementations collapse with a single misconfiguration, for example, and the OSPF spec is silent on such issues (and should be). There is an informational RFC discussing implementation strategies for OSPF, which is the right place for this kind of thing. > > Yes, any implementor should be smart enough > to make it right, but I don't want to take risks. And I'd like to add > the > least amount of "desired implementation annotations" to the spec, so > that a vendor will implement it right even if it has not heard from us > before and did not read this discussion. Please read the text I just posted and see if that calms your fears. Having a DoS-able crypto implementation is *not* a subtle issue that an implementor might not notice; this is an absolutely fundamental issue with crypto and extends to every protocol that uses it (which is pretty much all of them these days, not just BFD.) As an implementation that falls apart in this way should not be the norm (it is broken) I am loathe to make covering up such inadequacies the preferred behavior--this sends entirely the wrong message. In the text I just posted it is neutral, with an explanation of the issue, which ought to be enough warning for even the stupidest vendors. It allows informed implementation and deployment. I think that's reasonable. --Dave From rtg-bfd-bounces@ietf.org Mon Mar 14 19:02:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09507; Mon, 14 Mar 2005 19:02:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAzZf-0005HB-0G; Mon, 14 Mar 2005 19:06:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAzUy-0002Zw-No; Mon, 14 Mar 2005 19:01:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAzUw-0002Zo-UN for rtg-bfd@megatron.ietf.org; Mon, 14 Mar 2005 19:01:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09342 for ; Mon, 14 Mar 2005 19:01:19 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAzYf-0005Br-6S for rtg-bfd@ietf.org; Mon, 14 Mar 2005 19:05:13 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 14 Mar 2005 17:17:04 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,163,1107734400"; d="scan'208"; a="235115601:sNHT26249348" Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2ENweuC019432; Mon, 14 Mar 2005 15:58:41 -0800 (PST) Received: from [10.83.142.179] (cfcentral.cisco.com [64.101.210.32]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA29396; Mon, 14 Mar 2005 17:58:41 -0600 (CST) Mime-Version: 1.0 X-Sender: wardd@127.0.0.1 Message-Id: In-Reply-To: References: <302ea42bfd6ba31bd7af777d8a017d42@juniper.net> <0800c8fb4c7cf5af900919aec7dee613@juniper.net> Date: Mon, 14 Mar 2005 17:58:39 -0600 To: Dave Katz From: David Ward Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: "'rtg-bfd@ietf.org'" , Pekka Savola Subject: Re: TTL/Auth Redux X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Dave - Good news and bad news in this email message, read below. At 2:09 PM -0700 3/14/05, Dave Katz wrote: >On Mar 14, 2005, at 7:05 AM, Pekka Savola wrote: > >>>I'll throw out my argument about the futility of cryptographic >>>authentication in an environment that is easily DoS'ed. But in >>>any case, the language I suggested allows the TTL check for people >>>who want to do that, it just doesn't mandate it (or bar it.) The >>>order of the checks is outside the scope, as the intent of the >>>protocol spec is not to protect half-baked implementations. Those >>>folks who have DoS-able crypto engines are hopefully smart enough >>>to use the tools the right way. The spec is *not* an >>>implementation guide. >> >>I don't disagree from what's the bare minimum for the protocol >>spec, but nowadays the specs also must have a security >>considerations section ;-). The security behaviour in the protocol >>is very unpredictable unless there is also specification about the >>security properties of the system. And that's exactly what those >>couple of uppercase statements on TTL checking try to do. > >There is a Security Considerations section, as you know. Actually, >that section in the base spec currently mandates the TTL hack, >something that dates to before authentication was added. I'll fix >that language (it probably shouldn't be in the base spec, but should >reference the 1hop spec instead.) I can add a couple of sentences >about the DoS exposure there. > >The security behavior of the protocol is entirely predictable. It's >the security behavior of the *implementation* that is unpredictable, >and as such is outside the scope of the protocol spec. > >It sounds as though someone should write an informational RFC or BCP >on this stuff (I have neither the time nor the inclination). What you ask for is well documented in RFC 3682. What is being asked of you is to restate/rewrite the GTSH problem/purpose statement here. It isn't necessary thanks to the ability to reference it. >> >>>However, I can see some wiggle room in this that serves everyones' >>>purposes and doesn't introduce any interoperability issues. That >>>would be to say that the sender MUST use TTL 255 (which isn't any >>>burden unless you're trying to do some kind of path length >>>limitation, which would be even weirder), and that the receiver >>>MAY make the TTL check, and have a couple of sentences about the >>>implications of all this. The issue then falls completely on the >>>receiving system, and people can lobby their vendors for a knob, >>>and nobody can be accused of being out of spec. >> >>This is a good direction, but I we should have use "SHOULD [...] >>unless configured otherwise" rather than MAY. (I think this was >>pretty close to what the WG seemed to feel in MPLS.) In addition, >>it wouldn't hurt to have some text also recommending to have a >>configuration knob for this feature, but I'm OK with leaving that >>out because you'd argue the spec is not an implementation guide ;-). > >Please go back and read the definition of SHOULD and MAY. SHOULD >says, in so many words, that you better have a really good reason, >and really know what you're doing, to go against the clause. MAY >says that it's fully optional, but you need to be able to >interoperate either way. > >"SHOULD unless configured otherwise" isn't valid specsmanship. > >As the only reason that one would be forced to do the TTL check is >if the crypto engine is substandard, that to me does not fall into >the SHOULD category, which ought to apply only to those situations >whereby the bulk of implementations are skating on thin ice if they >go against it. > >This check ought to be purely optional, as (a) any useful crypto >implementation will not have this issue, and (b) there is no >interoperability issue regardless of which way you go (with the >revised text), and (c) the TTL check is nothing to be proud of and >should be avoided if possible (IMHO.) If you referred to the TTL >check as "security" to one of the security guys, I think they might >beg to differ. What you have written here Dave is what is stated in RFC 3682 quoting: "3. GTSM Procedure GTSM SHOULD NOT be enabled by default. " So, it seems that the desire to change this RFC is being pushed through the BFD singlehop. >I will happily put in some text to explain the issue, as I said earlier. > >From a practical standpoint, the outcome is the same--you will ask >for the feature from your vendor and they will probably deliver it. > > >My feeling as far as the meeting goes was that there was not >sufficient discussion for those in the room to make an informed >decision (made worse by my participating through a five second >delay), and if I understand the Rules of Engagement correctly, the >meetings are advisory and the mailing list is the determining factor. The mailing list is the determining factor. >Therefore, in order to try to put this issue to bed, I offer the >following text for the indicated two sections in the 1hop draft. >Unless there is significant and informed opposition to the text, I >will publish it as written and we can move on. > >--Dave > > > >5. TTL/Hop Count Issues > > If BFD authentication is not in use on a session, all BFD Control > packets for the session MUST be sent with a TTL or Hop Count value of > 255. All received BFD Control packets that are demultiplexed to the > session MUST be discarded if the received TTL or Hop Count is not > equal to 255. A discussion of this mechanism can be found in [GTSM]. > > If BFD authentication is in use on a session, all BFD Control packets > MUST be sent with a TTL or Hop Count value of 255. All received BFD > Control packets that are demultiplexed the session MAY be discarded > if the received TTL or Hop Count is not equal to 255. > > In the context of this section, "authentication in use" means that > the system is sending BFD control packets with the Authentication bit > set and with the Authentication Section included, and that all > unauthenticated packets demultiplexed to the session are discarded, > per the BFD base specification. > These paragraphs are completely clear, concise and remove any issues. The MUST associated w/ the TTL check is in fact too strong for many smaller devices (the assumption in this conversation seems to be considering only core devices and not other devices) on a global basis. RFC 3682 refers to enabling GTSH on a per peer basis and as OPTIONAL. I cannot understand why we are trying to force BFD to be *specified* differently than other protocols. No other protocols have a MUST. Also, the specific mention of 255 will preclude any two stage forwarding router from decrement TTL on ingress but, BFD TTL check be done on another board. IMHO, we are prescribing implementation in the sentences above, we can't do that. In the end, the paragraphs can put the conversation to bed in a much more strict and restricting yet no more secure definition. > >Security Considerations > > In this application, the use of TTL=255 on transmit and receive is > viewed as supplying equivalent security characteristics to other > protocols used in the infrastructure, as it is not trivially > spoofable. The security implications of this mechanism are further > discussed in the GTSM specification. Use brackets for the normative reference > > The security implications of the use of BFD Authentication are > discussed in the base BFD specification. > > The use of the TTL=255 check simultaneously with BFD Authentication > provides a low overhead mechanism for discarding a class of > unauthorized packets and may be useful in implementations in which > cryptographic checksum use is susceptable to denial of service > attacks. The use or non-use of this mechanism does not impact > interoperability. This is fine and correct. -DWard From rtg-bfd-bounces@ietf.org Mon Mar 14 19:13:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10448; Mon, 14 Mar 2005 19:13:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAzkZ-0005hi-N2; Mon, 14 Mar 2005 19:17:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAzga-0004cV-Dj; Mon, 14 Mar 2005 19:13:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAzgZ-0004cQ-At for rtg-bfd@megatron.ietf.org; Mon, 14 Mar 2005 19:13:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10437 for ; Mon, 14 Mar 2005 19:13:20 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAzkG-0005hL-V6 for rtg-bfd@ietf.org; Mon, 14 Mar 2005 19:17:14 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j2F0DC910608; Mon, 14 Mar 2005 16:13:12 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2F0D6e75167; Mon, 14 Mar 2005 16:13:07 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: References: <302ea42bfd6ba31bd7af777d8a017d42@juniper.net> <0800c8fb4c7cf5af900919aec7dee613@juniper.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <70df817669488eac5fc0b0b8eaffdb25@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Mon, 14 Mar 2005 17:14:39 -0700 To: David Ward X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: "'rtg-bfd@ietf.org'" , Pekka Savola Subject: Re: TTL/Auth Redux X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit >> discussed in the GTSM specification. > > > Use brackets for the normative reference Do these need to be in every reference, or just the first? It is bracketed in section 5. --Dave From rtg-bfd-bounces@ietf.org Tue Mar 15 13:34:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01182; Tue, 15 Mar 2005 13:23:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBGZg-00012Y-Pr; Tue, 15 Mar 2005 13:15:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBGVa-0004u2-TN; Tue, 15 Mar 2005 13:11:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBGS8-0004Gj-Jb for rtg-bfd@megatron.ietf.org; Tue, 15 Mar 2005 13:07:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29609 for ; Tue, 15 Mar 2005 13:07:30 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBGHS-0007m7-4Z for rtg-bfd@ietf.org; Tue, 15 Mar 2005 12:56:35 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j2FHqD704392; Tue, 15 Mar 2005 19:52:13 +0200 Date: Tue, 15 Mar 2005 19:52:13 +0200 (EET) From: Pekka Savola To: David Ward In-Reply-To: Message-ID: References: <302ea42bfd6ba31bd7af777d8a017d42@juniper.net> <0800c8fb4c7cf5af900919aec7dee613@juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: "'rtg-bfd@ietf.org'" , Dave Katz Subject: Re: TTL/Auth Redux X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Responding to both Daves.. On Mon, 14 Mar 2005, David Ward wrote: > What you have written here Dave is what is stated in RFC 3682 > > quoting: > > "3. GTSM Procedure > > GTSM SHOULD NOT be enabled by default. " > > So, it seems that the desire to change this RFC is being pushed through the > BFD singlehop. I think the key thing to remember is why GSTM spec says that. AFAICS, they don't want to break backward compatibility with the existing base of BGP, MSDP, and whatnot protocols which didn't support GTSM from day one. However, BFD did, so this should not be a technical factor. Dave Katz: > "SHOULD unless configured otherwise" isn't valid specsmanship. The text was an oversimplification. It could be said, for example, All received BFD Control packets that are demultiplexed SHOULD be discarded if the received TTL or Hop Count is not equal to 255. If such packets are not discarded by default, the implementation MUST have a configuration toggle to enable the discarding. or: All received BFD Control packets that are demultiplexed SHOULD be discarded if the received TTL or Hop Count is not equal to 255. If the implementation chooses not to do this by default, it MUST have a configuration toggle to enable the discarding. (note, there appeared to be extra "the session" around 'demultiplexed') I could even live with the above wording if the first "SHOULD be discarded" was a MAY, i.e., if the still spec had a MUST for implementing the toggle for implementations which don't do it. Otherwise, the text that dkatz proposed seemed pretty good. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rtg-bfd-bounces@ietf.org Tue Mar 15 15:17:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14160; Tue, 15 Mar 2005 15:17:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBIXc-0004e9-Lx; Tue, 15 Mar 2005 15:21:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBISP-0001GQ-KJ; Tue, 15 Mar 2005 15:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBISN-0001Fv-Of for rtg-bfd@megatron.ietf.org; Tue, 15 Mar 2005 15:15:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13545 for ; Tue, 15 Mar 2005 15:15:57 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBIVY-0004Kg-Ca for rtg-bfd@ietf.org; Tue, 15 Mar 2005 15:19:16 -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 j2FKE0Bm015994; Tue, 15 Mar 2005 12:14:00 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2FKDxe72721; Tue, 15 Mar 2005 12:14:00 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: References: <302ea42bfd6ba31bd7af777d8a017d42@juniper.net> <0800c8fb4c7cf5af900919aec7dee613@juniper.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Date: Tue, 15 Mar 2005 13:15:50 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: "'rtg-bfd@ietf.org'" , David Ward Subject: Re: TTL/Auth Redux X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit On Mar 15, 2005, at 10:52 AM, Pekka Savola wrote: > The text was an oversimplification. It could be said, for example, > > All received BFD > Control packets that are demultiplexed SHOULD be discarded > if the received TTL or Hop Count is not equal to 255. > If such packets are not discarded by default, the implementation > MUST have a configuration toggle to enable the discarding. > > or: > > All received BFD > Control packets that are demultiplexed SHOULD be discarded > if the received TTL or Hop Count is not equal to 255. If the > implementation chooses not to do this by default, it MUST have a > configuration toggle to enable the discarding. > > (note, there appeared to be extra "the session" around 'demultiplexed') > > I could even live with the above wording if the first "SHOULD be > discarded" was a MAY, i.e., if the still spec had a MUST for > implementing the toggle for implementations which don't do it. The spec *cannot* dictate implementation. *Every* protocol has issues where implementors can be stupid (never underestimate the power of cluelessness.) Why should this be any different? Implementors must be free to implement or not implement the TTL discard behavior according to the needs and capabilities of their product. If I have a good crypto engine that does the right thing, why should I have to implement this? Further, as Dave2 points out, it may be entirely impossible to implement depending on the system architecture. I think what you are really trying to have the spec say is, "if your crypto implementation is broken, you MUST do the TTL hack." That doesn't belong in a spec either. The spec calls out the issue, and allows both implementors and customers to make informed decisions. This is more than most protocol specs do. The text I proposed (modulo editorial fixes) lays out the issue very plainly, and I believe strikes the right balance between your concerns and mine. Can we *please* move on? --Dave From rtg-bfd-bounces@ietf.org Thu Mar 17 09:10:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00042; Thu, 17 Mar 2005 09:10:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBvmG-0000tH-DB; Thu, 17 Mar 2005 09:15:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBvh9-0007qn-SN; Thu, 17 Mar 2005 09:09:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBvh9-0007qi-2l for rtg-bfd@megatron.ietf.org; Thu, 17 Mar 2005 09:09:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29947 for ; Thu, 17 Mar 2005 09:09:48 -0500 (EST) Received: from paperclip.laurelnetworks.com ([63.94.127.69] ident=nobody) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBvlN-0000s8-CA for rtg-bfd@ietf.org; Thu, 17 Mar 2005 09:14:14 -0500 Received: from postit.laurelnetworks.com (postit.laurelnetworks.com [63.94.127.21]) by paperclip.laurelnetworks.com (Laurel/Laurel) with ESMTP id j2HE9m3G021299; Thu, 17 Mar 2005 09:09:48 -0500 Received: from cnogradi-linux.dhcp.pit.laurelnetworks.com (cnogradi-linux.dhcp.pit.laurelnetworks.com [10.0.19.158]) by postit.laurelnetworks.com (Laurel/Laurel) with ESMTP id j2HE9led018002; Thu, 17 Mar 2005 09:09:48 -0500 From: Chris Nogradi Organization: Laurel Networks To: Dave Katz Date: Thu, 17 Mar 2005 09:08:53 -0500 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200503170908.53160.cnogradi@laurelnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Authentication X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Dave, I just noticed that you have added the following sentence to the base draft in section 6.6: "Implementations MUST support SHA1 authentication. Other froms of authentication are optional." Since you did not make mention of this in the document changes sections, I assume that this does not mean that all implementations must support at least this form of authentication. Is the purpose of this sentence to say that if an implementation uses authentication, it must support SHA1? BTW, there is a typo in this sentence as it should say "forms" instead of "froms". Thanks, Chris From rtg-bfd-bounces@ietf.org Thu Mar 17 10:48:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14971; Thu, 17 Mar 2005 10:48:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBxJ8-0005MV-8x; Thu, 17 Mar 2005 10:53:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBx9X-0002qo-2U; Thu, 17 Mar 2005 10:43:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBx9V-0002qj-Rk for rtg-bfd@megatron.ietf.org; Thu, 17 Mar 2005 10:43:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14178 for ; Thu, 17 Mar 2005 10:43:11 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBxDj-0005BT-VD for rtg-bfd@ietf.org; Thu, 17 Mar 2005 10:47:38 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j2HFgrG26786; Thu, 17 Mar 2005 17:42:53 +0200 Date: Thu, 17 Mar 2005 17:42:53 +0200 (EET) From: Pekka Savola To: Chris Nogradi In-Reply-To: <200503170908.53160.cnogradi@laurelnetworks.com> Message-ID: References: <200503170908.53160.cnogradi@laurelnetworks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: rtg-bfd@ietf.org, Dave Katz Subject: Re: Authentication X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Thu, 17 Mar 2005, Chris Nogradi wrote: > Since you did not make mention of this in the document changes sections, I > assume that this does not mean that all implementations must support at least > this form of authentication. Is the purpose of this sentence to say that if > an implementation uses authentication, it must support SHA1? I think this makes sense. In any case, security area typically will not accept any new protocols which don't support SHA1 -- and further, there must be at least one mandatory-to-implement security mechanisms so different implementations will be able to interoperate. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rtg-bfd-bounces@ietf.org Thu Mar 17 13:27:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03521; Thu, 17 Mar 2005 13:27:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBzn3-0001xa-Jy; Thu, 17 Mar 2005 13:32:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBzi5-0007ux-Mc; Thu, 17 Mar 2005 13:27:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBzi4-0007up-0r for rtg-bfd@megatron.ietf.org; Thu, 17 Mar 2005 13:27:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03492 for ; Thu, 17 Mar 2005 13:27:00 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBzmL-0001ws-0G for rtg-bfd@ietf.org; Thu, 17 Mar 2005 13:31:30 -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 j2HIQrBm039841; Thu, 17 Mar 2005 10:26:53 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2HIQje48107; Thu, 17 Mar 2005 10:26:45 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <200503170908.53160.cnogradi@laurelnetworks.com> References: <200503170908.53160.cnogradi@laurelnetworks.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <13a4e73cebe5495e4785368aefb0dfb2@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 17 Mar 2005 11:29:17 -0700 To: Chris Nogradi X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: Authentication X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit On Mar 17, 2005, at 7:08 AM, Chris Nogradi wrote: > Dave, > > I just noticed that you have added the following sentence to the base > draft in > section 6.6: > > "Implementations MUST support SHA1 authentication. Other froms of > authentication are optional." > > Since you did not make mention of this in the document changes > sections, I > assume that this does not mean that all implementations must support > at least > this form of authentication. Is the purpose of this sentence to say > that if > an implementation uses authentication, it must support SHA1? Sorry, I forgot to list that in the changes. This is in there because the IESG will not allow the document to advance without it. It's an interesting question as to whether they would allow the spec to say that an implementation could have no authentication at all; my guess is that their stand is that the spec must require that all implementations support SHA1 authentication. I also expect that vendors will make their own choices, as there is no significant difference between an implementation in which nobody turns on authentication and an implementation that does not even include it. But that's the word from on high. > > BTW, there is a typo in this sentence as it should say "forms" instead > of > "froms". Thanks... --Dave From rtg-bfd-bounces@ietf.org Thu Mar 17 13:34:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04391; Thu, 17 Mar 2005 13:34:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBztk-00028q-0U; Thu, 17 Mar 2005 13:39:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBzjp-0008QZ-GZ; Thu, 17 Mar 2005 13:28:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBzjp-0008QU-3N for rtg-bfd@megatron.ietf.org; Thu, 17 Mar 2005 13:28:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03883 for ; Thu, 17 Mar 2005 13:28:49 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBzo6-0001zZ-3v for rtg-bfd@ietf.org; Thu, 17 Mar 2005 13:33:19 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j2HISZ956391; Thu, 17 Mar 2005 10:28:35 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2HISTe48344; Thu, 17 Mar 2005 10:28:29 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: References: <200503170908.53160.cnogradi@laurelnetworks.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 17 Mar 2005 11:31:01 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: Authentication X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit On Mar 17, 2005, at 8:42 AM, Pekka Savola wrote: > On Thu, 17 Mar 2005, Chris Nogradi wrote: >> Since you did not make mention of this in the document changes >> sections, I >> assume that this does not mean that all implementations must support >> at least >> this form of authentication. Is the purpose of this sentence to say >> that if >> an implementation uses authentication, it must support SHA1? > > In any case, security area typically will not accept any new protocols > which don't support SHA1 -- and further, there must be at least one > mandatory-to-implement security mechanisms so different > implementations will be able to interoperate. Yep. Luckily they are protocol police, not implementation police. --Dave From rtg-bfd-bounces@ietf.org Thu Mar 17 13:40:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05334; Thu, 17 Mar 2005 13:40:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBzzZ-0002Md-I4; Thu, 17 Mar 2005 13:45:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBzvC-0002g2-RG; Thu, 17 Mar 2005 13:40:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBzvA-0002ft-LI for rtg-bfd@megatron.ietf.org; Thu, 17 Mar 2005 13:40:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05293 for ; Thu, 17 Mar 2005 13:40:32 -0500 (EST) Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBzzS-0002Lh-BM for rtg-bfd@ietf.org; Thu, 17 Mar 2005 13:45:02 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j2HIeQMe002140; Thu, 17 Mar 2005 13:40:26 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA06400; Thu, 17 Mar 2005 13:40:25 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Thu, 17 Mar 2005 13:40:25 -0500 Message-ID: <313680C9A886D511A06000204840E1CF0B454151@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: "'Dave Katz'" Date: Thu, 17 Mar 2005 13:40:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: rtg-bfd@ietf.org Subject: RE: Authentication X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Dave, Is it actually the case that the IESG will not allow the document to advance without requiring SHA-1, or is it the case that we either mandate it or we define the security and/or trust environment in which it is, or is not, required? One could make the case that authentication is not required for devices that are not directly exposed to the big I. In such devices, it could also be the case that realistic authentication is unlikely to be feasible. In that case, and assuming that making an attempt to provide authentication that is even approximately realistic has a non-zero cost - even if it is never turned on - why would we want to mandate authentication for such devices? -- Eric -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org]On Behalf Of Dave Katz Sent: Thursday, March 17, 2005 1:29 PM To: Chris Nogradi Cc: rtg-bfd@ietf.org Subject: Re: Authentication On Mar 17, 2005, at 7:08 AM, Chris Nogradi wrote: > Dave, > > I just noticed that you have added the following sentence to the base > draft in > section 6.6: > > "Implementations MUST support SHA1 authentication. Other froms of > authentication are optional." > > Since you did not make mention of this in the document changes > sections, I > assume that this does not mean that all implementations must support > at least > this form of authentication. Is the purpose of this sentence to say > that if > an implementation uses authentication, it must support SHA1? Sorry, I forgot to list that in the changes. This is in there because the IESG will not allow the document to advance without it. It's an interesting question as to whether they would allow the spec to say that an implementation could have no authentication at all; my guess is that their stand is that the spec must require that all implementations support SHA1 authentication. I also expect that vendors will make their own choices, as there is no significant difference between an implementation in which nobody turns on authentication and an implementation that does not even include it. But that's the word from on high. > > BTW, there is a typo in this sentence as it should say "forms" instead > of > "froms". Thanks... --Dave From rtg-bfd-bounces@ietf.org Thu Mar 17 13:58:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06760; Thu, 17 Mar 2005 13:58:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC0H8-0002or-EX; Thu, 17 Mar 2005 14:03:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC0CA-0007HS-R7; Thu, 17 Mar 2005 13:58:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC0C9-0007HH-Ga for rtg-bfd@megatron.ietf.org; Thu, 17 Mar 2005 13:58:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06707 for ; Thu, 17 Mar 2005 13:58:05 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC0GQ-0002nC-Oe for rtg-bfd@ietf.org; Thu, 17 Mar 2005 14:02:36 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j2HIvt956728; Thu, 17 Mar 2005 10:57:55 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2HIvne53733; Thu, 17 Mar 2005 10:57:49 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <313680C9A886D511A06000204840E1CF0B454151@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF0B454151@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 17 Mar 2005 12:00:21 -0700 To: "Gray, Eric" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: Authentication X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit On Mar 17, 2005, at 11:40 AM, Gray, Eric wrote: > Dave, > > Is it actually the case that the IESG will not allow > the document to advance without requiring SHA-1, or is it > the case that we either mandate it or we define the security > and/or trust environment in which it is, or is not, required? I'm not sure, Dave2 or Jeff could comment. My impression was that they would not let the document advance without it being fully mandatory. > > One could make the case that authentication is not > required for devices that are not directly exposed to the > big I. In such devices, it could also be the case that > realistic authentication is unlikely to be feasible. In > that case, and assuming that making an attempt to provide > authentication that is even approximately realistic has a > non-zero cost - even if it is never turned on - why would > we want to mandate authentication for such devices?\ I fully agree. I suspect that the reality is that most vendors who are only interested in single hop BFD will throw a CPU-based authentication implementation in and continue to use the TTL hack and nobody will use it. Or else they will just leave it out (but then some customer will demand it because the spec says it has to be there, and they'll be forced to do the above.) --Dave From rtg-bfd-bounces@ietf.org Sun Mar 20 07:13:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10625; Sun, 20 Mar 2005 07:13:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCzNh-0002mT-0b; Sun, 20 Mar 2005 07:18:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCzII-0007ny-5B; Sun, 20 Mar 2005 07:12:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCzIH-0007nt-DU for rtg-bfd@megatron.ietf.org; Sun, 20 Mar 2005 07:12:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10587 for ; Sun, 20 Mar 2005 07:12:29 -0500 (EST) From: roggie-bfd@sohu.com Received: from [61.135.132.204] (helo=websmtp1.mail.sohu.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCzN5-0002lz-PZ for rtg-bfd@ietf.org; Sun, 20 Mar 2005 07:17:33 -0500 Received: from mx66.mail.sohu.com (unknown [192.168.95.81]) by websmtp1.mail.sohu.com (Postfix) with ESMTP id 73D491B342608; Sun, 20 Mar 2005 20:12:22 +0800 (CST) Message-ID: <13616729.1111320742672.JavaMail.postfix@mx66.mail.sohu.com> Date: Sun, 20 Mar 2005 20:12:22 +0800 (CST) To: Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-Mailer: Sohu Web Mail 2.0.13 X-SHIP: 219.239.105.83 X-Priority: 3 X-SHMOBILE: 0 X-Sohu-Antivirus: 0 X-Spam-Score: 1.7 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 8bit Cc: rtg-bfd@ietf.org Subject: Detection time in demand mode X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 1.7 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 8bit Dave, In section 6.7.4 , it said : In Demand mode, the Detection Time calculated in the local system is equal to bfd.DetectMult, multiplied by the agreed transmit interval (the greater of bfd.RequiredMinRxInterval and the last received Desired Min TX Interval.) bfd.DetectMult is (roughly speaking, due to jitter) the number of packets that have to be missed in a row to declare the session to be down. From the above sentence , i get the flowing conclosion , for example : A------------------B DM=3 DM=1 MTI=100ms MTI=10ms MRI=20ms MRI=200ms if A sends a poll sequence , the transmit interval is 200ms[max(100ms,200ms)] , the detection time is 60ms[3*max(20ms,10ms)] , is it correct?? another question : in the spec , it always said "If Demand mode is not active" , i wants to ask is it the flowing meaning if one side set to demand mode and the other side dose not set , the side setted to demand mode also MUST send period control packet ? i am not sure ! Thanks Roggie From rtg-bfd-bounces@ietf.org Sun Mar 20 12:54:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05188; Sun, 20 Mar 2005 12:54:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD4iZ-00046f-BP; Sun, 20 Mar 2005 13:00:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD4cE-00089l-1F; Sun, 20 Mar 2005 12:53:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD4cC-00089f-4M for rtg-bfd@megatron.ietf.org; Sun, 20 Mar 2005 12:53:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05106 for ; Sun, 20 Mar 2005 12:53:25 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD4h5-00044p-Vu for rtg-bfd@ietf.org; Sun, 20 Mar 2005 12:58:32 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 20 Mar 2005 09:53:19 -0800 Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2KHrFDr011152; Sun, 20 Mar 2005 09:53:16 -0800 (PST) Received: (from wardd@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA21851; Sun, 20 Mar 2005 11:53:10 -0600 (CST) Date: Sun, 20 Mar 2005 11:53:10 -0600 From: David Ward To: Dave Katz Message-ID: <20050320115310.R16669@cfcentral.cisco.com> References: <313680C9A886D511A06000204840E1CF0B454151@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dkatz@juniper.net on Thu, Mar 17, 2005 at 12:00:21PM -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: rtg-bfd@ietf.org Subject: Re: Authentication X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 We have been told that the document will not proceed w/o SHA-1 being mandatory. MD5 is also strongly suggested. An implementation can choose to also offer no authentication. The protocol can easily support all three options for deployment. -DWard On Thu, Mar 17, 2005 at 12:00:21PM -0700, Dave Katz wrote: > > On Mar 17, 2005, at 11:40 AM, Gray, Eric wrote: > > > Dave, > > > > Is it actually the case that the IESG will not allow > > the document to advance without requiring SHA-1, or is it > > the case that we either mandate it or we define the security > > and/or trust environment in which it is, or is not, required? > > I'm not sure, Dave2 or Jeff could comment. My impression was that they > would not let the document advance without it being fully mandatory. > > > > > One could make the case that authentication is not > > required for devices that are not directly exposed to the > > big I. In such devices, it could also be the case that > > realistic authentication is unlikely to be feasible. In > > that case, and assuming that making an attempt to provide > > authentication that is even approximately realistic has a > > non-zero cost - even if it is never turned on - why would > > we want to mandate authentication for such devices?\ > > I fully agree. > > I suspect that the reality is that most vendors who are only interested > in single hop BFD will throw a CPU-based authentication implementation > in and continue to use the TTL hack and nobody will use it. Or else > they will just leave it out (but then some customer will demand it > because the spec says it has to be there, and they'll be forced to do > the above.) > > --Dave From rtg-bfd-bounces@ietf.org Sun Mar 20 14:12:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10523; Sun, 20 Mar 2005 14:12:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD5v9-0006O8-FP; Sun, 20 Mar 2005 14:17:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD5op-0000Ea-LL; Sun, 20 Mar 2005 14:10:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DD5on-0000ES-2L for rtg-bfd@megatron.ietf.org; Sun, 20 Mar 2005 14:10:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10412 for ; Sun, 20 Mar 2005 14:10:31 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DD5th-0006MX-Hh for rtg-bfd@ietf.org; Sun, 20 Mar 2005 14:15:37 -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 j2KJAHBm060009; Sun, 20 Mar 2005 11:10:18 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2KJACe75431; Sun, 20 Mar 2005 11:10:12 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <13616729.1111320742672.JavaMail.postfix@mx66.mail.sohu.com> References: <13616729.1111320742672.JavaMail.postfix@mx66.mail.sohu.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Date: Sun, 20 Mar 2005 12:13:50 -0700 To: roggie-bfd@sohu.com X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: Detection time in demand mode X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit On Mar 20, 2005, at 5:12 AM, roggie-bfd@sohu.com wrote: > > Dave, > In section 6.7.4 , it said : > In Demand mode, the Detection Time calculated in the local system is > equal to bfd.DetectMult, multiplied by the agreed transmit interval > (the greater of bfd.RequiredMinRxInterval and the last received > Desired Min TX Interval.) bfd.DetectMult is (roughly speaking, due > to jitter) the number of packets that have to be missed in a row to > declare the session to be down. > From the above sentence , i get the flowing conclosion , for example > : > A------------------B > DM=3 DM=1 > MTI=100ms MTI=10ms > MRI=20ms MRI=200ms > if A sends a poll sequence , the transmit interval is > 200ms[max(100ms,200ms)] , > the detection time is 60ms[3*max(20ms,10ms)] , is it correct?? No, and thank you for catching this, I somehow managed to goof the language completely. The casual text is right--the agreed transmit interval is 200 ms, so the detection time would be 600 ms. I'll fix this ASAP; I can't believe that none of us noticed this in two years as it's pretty fundamental! Here's the proper language: In Demand mode, the Detection Time calculated in the local system is equal to bfd.DetectMult, multiplied by the agreed transmit interval of the local system (the greater of bfd.DesiredMinTxInterval and the last received Required Min RX Interval.) bfd.DetectMult is (roughly speaking, due to jitter) the number of packets that have to be missed in a row to declare the session to be down. > > another question : in the spec , it always said "If Demand mode is > not active" , > i wants to ask is it the flowing meaning if one side set to demand > mode and > the other side dose not set , the side setted to demand mode also > MUST send > period control packet ? i am not sure ! From the spec: 6.5. Demand Mode Demand mode is negotiated by virtue of both systems setting the Demand (D) bit in its BFD Control packets. Both systems must request Demand mode for it to become active. If this is not clear, please let me know. --Dave From rtg-bfd-bounces@ietf.org Tue Mar 22 15:57:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02708; Tue, 22 Mar 2005 15:57:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDqX5-0004Uo-KU; Tue, 22 Mar 2005 16:03:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDqKe-0006cx-P1; Tue, 22 Mar 2005 15:50:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDqKb-0006cR-I8; Tue, 22 Mar 2005 15:50:29 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01483; Tue, 22 Mar 2005 15:50:27 -0500 (EST) Message-Id: <200503222050.PAA01483@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Mar 2005 15:50:27 -0500 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-multihop-02.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD for Multihop Paths Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-multihop-02.txt Pages : 6 Date : 2005-3-22 This document describes the use of the Bidirectional Forwarding Detection protocol (BFD) over multihop paths, including unidirectional links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-multihop-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-multihop-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-multihop-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-22162456.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-multihop-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-multihop-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-22162456.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Tue Mar 22 16:05:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04618; Tue, 22 Mar 2005 16:05:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDqeU-00057I-Ek; Tue, 22 Mar 2005 16:11:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDqKW-0006cM-Iv; Tue, 22 Mar 2005 15:50:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDqKS-0006XP-B2; Tue, 22 Mar 2005 15:50:20 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01476; Tue, 22 Mar 2005 15:50:18 -0500 (EST) Message-Id: <200503222050.PAA01476@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Mar 2005 15:50:18 -0500 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-v4v6-1hop-02.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : BFD for IPv4 and IPv6 (Single Hop) Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-v4v6-1hop-02.txt Pages : 11 Date : 2005-3-22 This document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. It further describes the use of BFD with OSPFv2, OSPFv3, and IS-IS. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-v4v6-1hop-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-v4v6-1hop-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-v4v6-1hop-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-22162443.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-v4v6-1hop-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-v4v6-1hop-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-22162443.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Tue Mar 22 16:14:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07465; Tue, 22 Mar 2005 16:14:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDqnN-00069c-6C; Tue, 22 Mar 2005 16:20:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDqKp-0006fc-5t; Tue, 22 Mar 2005 15:50:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDqKl-0006f9-Lt; Tue, 22 Mar 2005 15:50:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01499; Tue, 22 Mar 2005 15:50:38 -0500 (EST) Message-Id: <200503222050.PAA01499@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Mar 2005 15:50:37 -0500 Cc: rtg-bfd@ietf.org Subject: I-D ACTION:draft-ietf-bfd-base-02.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Bidirectional Forwarding Detection Author(s) : D. Katz, D. Ward Filename : draft-ietf-bfd-base-02.txt Pages : 43 Date : 2005-3-22 This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. Comments on this draft should be directed to rtg-bfd@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bfd-base-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bfd-base-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-22162509.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bfd-base-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bfd-base-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-22162509.I-D@ietf.org> --OtherAccess-- --NextPart-- From rtg-bfd-bounces@ietf.org Tue Mar 22 16:17:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08476; Tue, 22 Mar 2005 16:17:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDqqK-0006YU-PK; Tue, 22 Mar 2005 16:23:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDqaC-0002UZ-7L; Tue, 22 Mar 2005 16:06:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDqaA-0002UP-R8 for rtg-bfd@megatron.ietf.org; Tue, 22 Mar 2005 16:06:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05037 for ; Tue, 22 Mar 2005 16:06:33 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDqfU-0005F8-Tj for rtg-bfd@ietf.org; Tue, 22 Mar 2005 16:12:06 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j2ML6O918049 for ; Tue, 22 Mar 2005 13:06:24 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2ML6Je66349 for ; Tue, 22 Mar 2005 13:06:19 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <1ead1ea748a77c95d853a08475d8622b@juniper.net> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "'rtg-bfd@ietf.org'" From: Dave Katz Date: Tue, 22 Mar 2005 14:07:01 -0700 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: New Drafts X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit The new drafts seem to be hitting the archives today. I'm still working on the generic spec, hopefully in a few days. Looks like the secretariat has moved into the 20th century; a few months back I had a submission rejected because it was sent as a *text* attachment in a MIME message. The irony of that was precious. This time I sent them three documents as attachments to one message; we'll see if that turns out to be too complicated. Only one has been announced so far, hmm... --Dave1 (for Dave2) From rtg-bfd-bounces@ietf.org Wed Mar 23 09:50:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21225; Wed, 23 Mar 2005 09:50:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE7Hh-0008E0-EL; Wed, 23 Mar 2005 09:56:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE78I-0008TD-Kv; Wed, 23 Mar 2005 09:46:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE78H-0008R0-6j; Wed, 23 Mar 2005 09:46:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20589; Wed, 23 Mar 2005 09:46:49 -0500 (EST) Received: from adsl-66-120-207-101.dsl.sntc01.pacbell.net ([66.120.207.101] helo=coffee.rawdofmt.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE7Dj-00085x-9U; Wed, 23 Mar 2005 09:52:31 -0500 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 8A7213DCCAD; Wed, 23 Mar 2005 06:46:40 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5d0e7e1010295221c425a17b7d2d6a22@rawdofmt.org> Content-Transfer-Encoding: 7bit From: Christian Hopps Date: Wed, 23 Mar 2005 06:46:39 -0800 To: ISIS WG X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Fwd: I-D ACTION:draft-chopps-isis-bfd-tlv-00.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit For some reason the announcement didn't make it to the isis-wg list. After some time for initial review I would like to propose this become a working group document. Chris. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: March 21, 2005 12:31:51 PM PST > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-chopps-isis-bfd-tlv-00.txt > Reply-To: internet-drafts@ietf.org > X-Spam-Level: > X-Spam-Status: No, score=-2.6 required=2.0 tests=AWL,BAYES_00, > MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.0.2 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : IS-IS BFD Enabled TLV > Author(s) : C. Hopps > Filename : draft-chopps-isis-bfd-tlv-00.txt > Pages : 6 > Date : 2005-3-21 > > This document describes a TLV for use in the IS-IS routing protocol > that allows for the proper functioning of the Bidirectional > Forwarding Detection protocol (BFD). There exists certain scenarios > in which BFD will fail to detect a forwarding plane failure without > use of either this TLV or some other method. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chopps-isis-bfd-tlv-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-chopps-isis-bfd-tlv-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-chopps-isis-bfd-tlv-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2005-3-21154226.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce From rtg-bfd-bounces@ietf.org Thu Mar 24 11:24:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29449; Thu, 24 Mar 2005 11:24:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEVEB-0000Yj-Nx; Thu, 24 Mar 2005 11:30:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEV7H-000615-43; Thu, 24 Mar 2005 11:23:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEV7F-00060x-Vn for rtg-bfd@megatron.ietf.org; Thu, 24 Mar 2005 11:23:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29301 for ; Thu, 24 Mar 2005 11:23:23 -0500 (EST) Received: from paperclip.laurelnetworks.com ([63.94.127.69] ident=nobody) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEVCw-0000V5-AG for rtg-bfd@ietf.org; Thu, 24 Mar 2005 11:29:19 -0500 Received: from postit.laurelnetworks.com (postit.laurelnetworks.com [63.94.127.21]) by paperclip.laurelnetworks.com (Laurel/Laurel) with ESMTP id j2OGNMLp026501; Thu, 24 Mar 2005 11:23:22 -0500 Received: from sherlock.pit.laurelnetworks.com (washer.pit.laurelnetworks.com [10.0.0.46]) by postit.laurelnetworks.com (Laurel/Laurel) with ESMTP id j2OGNMtI000403; Thu, 24 Mar 2005 11:23:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Mar 2005 11:23:05 -0500 Message-ID: <44467058B41F7E4CB6305769819D5E631DF274@SHERLOCK.pit.laurelnetworks.com> Thread-Topic: Reflections on new state machine Thread-Index: AcUwjcIld3EUNo8LSEOjFtYUxCz1yA== From: "Chris Nogradi" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org Subject: Reflections on new state machine X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Dave, =20 section 6.7.6 of the new base document (v2) reads: =20 If received state is AdminDown If bfd.SessionState is not Down Set bfd.LocalDiag to 3 (Neighbor signaled session down) Set bfd.SessionState to Down Else If bfd.SessionState is AdminDown Discard the packet =20 shouldn't the local state remain AdminDown even if the received state is = AdminDown? =20 Two other observations: 1. we remain indefinitely in the init state if peer keeps sending down = state since packet is not discarded and timer is reset 2. we remain in the up state if the peer keeps sending init state since = packet is not discarded and timer is reset The first seems to be ok but the second does not seem right? =20 Thanks, =20 Chris =20 From rtg-bfd-bounces@ietf.org Thu Mar 24 12:19:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05394; Thu, 24 Mar 2005 12:19:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEW5T-0002V4-QQ; Thu, 24 Mar 2005 12:25:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEVxo-0006rD-23; Thu, 24 Mar 2005 12:17:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEVxm-0006r8-F6 for rtg-bfd@megatron.ietf.org; Thu, 24 Mar 2005 12:17:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05218 for ; Thu, 24 Mar 2005 12:17:40 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEW3T-0002RZ-Ve for rtg-bfd@ietf.org; Thu, 24 Mar 2005 12:23:37 -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 j2OHHVBm008549; Thu, 24 Mar 2005 09:17:31 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2OHHUe37832; Thu, 24 Mar 2005 09:17:31 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <44467058B41F7E4CB6305769819D5E631DF274@SHERLOCK.pit.laurelnetworks.com> References: <44467058B41F7E4CB6305769819D5E631DF274@SHERLOCK.pit.laurelnetworks.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5551a80ad8a4ea77c78036eebf03830a@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 24 Mar 2005 10:17:30 -0700 To: "Chris Nogradi" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: Reflections on new state machine X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit On Mar 24, 2005, at 9:23 AM, Chris Nogradi wrote: > Dave, > > section 6.7.6 of the new base document (v2) reads: > > If received state is AdminDown > If bfd.SessionState is not Down > Set bfd.LocalDiag to 3 (Neighbor signaled session down) > Set bfd.SessionState to Down > > Else > If bfd.SessionState is AdminDown > Discard the packet > > shouldn't the local state remain AdminDown even if the received state > is AdminDown? Yep, good point. If both sides are AdminDown they should stay there. The intent is that AdminDown is an administrative state and is "clamped" there until administrative action is taken to exit it. I'll make this more explicit. > > Two other observations: > 1. we remain indefinitely in the init state if peer keeps sending down > state since packet is not discarded and timer is reset This is true; this should only happen if there is one-way communication. The net result is that the session doesn't come up, which is the intent. There's no magic about the difference between Down and Init operationally. > 2. we remain in the up state if the peer keeps sending init state > since packet is not discarded and timer is reset This can only happen if the peer is broken, since the peer cannot stay in init state indefinitely if properly implemented. If the peer hears you sending Up, he must go Up. If he's not hearing you, he times out and goes Down. So this scenario can only happen for a Detection Time, and only if communications goes one-way during session establishment, which is what you'd expect. --Dave From rtg-bfd-bounces@ietf.org Thu Mar 24 12:38:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07763; Thu, 24 Mar 2005 12:38:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEWO0-00039l-EZ; Thu, 24 Mar 2005 12:44:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEWHc-00014a-Tv; Thu, 24 Mar 2005 12:38:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEWHb-00014Q-FP for rtg-bfd@megatron.ietf.org; Thu, 24 Mar 2005 12:38:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07727 for ; Thu, 24 Mar 2005 12:38:09 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEWNJ-000393-6M for rtg-bfd@ietf.org; Thu, 24 Mar 2005 12:44:06 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j2OHbx944472; Thu, 24 Mar 2005 09:38:00 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2OHbse45086; Thu, 24 Mar 2005 09:37:54 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <44467058B41F7E4CB6305769819D5E631DF274@SHERLOCK.pit.laurelnetworks.com> References: <44467058B41F7E4CB6305769819D5E631DF274@SHERLOCK.pit.laurelnetworks.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <973a61750f9f4883d5801b722a8d5958@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Thu, 24 Mar 2005 10:37:53 -0700 To: "Chris Nogradi" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: Reflections on new state machine X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Here's what the text in that neighborhood should look like. Note that the transmit interval update is moved before the state machine mechanics; this ensures that a system in AdminDown state still pays attention to the receive interval wishes of the remote system. ... Update the Detection Time as described in section 6.7.4. Update the transmit interval as described in section 6.7.2. If bfd.SessionState is AdminDown Discard the packet If received state is AdminDown If bfd.SessionState is not Down Set bfd.LocalDiag to 3 (Neighbor signaled session down) Set bfd.SessionState to Down Else If bfd.SessionState is Down If received State is Down Set bfd.SessionState to Init Else if received State is Init Set bfd.SessionState to Up Else if bfd.SessionState is Init If received State is Init or Up Set bfd.SessionState to Up Else (bfd.SessionState is Up) If received State is Down Set bfd.LocalDiag to 3 (Neighbor signaled session down) Set bfd.SessionState to Down If the Demand (D) bit is set and bfd.DemandModeDesired is 1, and bfd.SessionState is Up, Demand mode is active. ... --Dave From rtg-bfd-bounces@ietf.org Fri Mar 25 22:40:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21769; Fri, 25 Mar 2005 22:40:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DF2GH-0003AI-Pw; Fri, 25 Mar 2005 22:46:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DF29C-0006UR-KB; Fri, 25 Mar 2005 22:39:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DF29B-0006To-6n; Fri, 25 Mar 2005 22:39:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21613; Fri, 25 Mar 2005 22:39:31 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DF2F3-00038a-Vk; Fri, 25 Mar 2005 22:45:46 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IDX00HYBWWO27@szxga01-in.huawei.com>; Sat, 26 Mar 2005 11:41:12 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IDX00B8FWWOW6@szxga01-in.huawei.com>; Sat, 26 Mar 2005 11:41:12 +0800 (CST) Received: from z11024 ([10.110.100.73]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IDX00G7GX2LQZ@szxml01-in.huawei.com>; Sat, 26 Mar 2005 11:44:45 +0800 (CST) Date: Sat, 26 Mar 2005 11:41:24 +0800 From: zhaisuping To: "dkatz@juniper.net" , "dward@cisco.com" Message-id: <0IDX00G7IX2LQZ@szxml01-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: quoted-printable X-Spam-Score: 4.3 (++++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd-bounces@ietf.org" , "rtg-bfd@ietf.org" Subject: some comment to draft-ietf-bfd-base-02.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhaisuping@huawei.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 4.3 (++++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Dave2, In the draft-ietf-bfd-base-02.txt, 6.3. (Demultiplexing and the= Discriminator Fields), it reads as following,=A1=A1=A1=A1 The method of demultiplexing the initial packets (in which= Your Discriminator is zero) is application-dependent, and is thus= outside the scope of this specification.=A1=A1=A1=A1 One problem is that when the two nodes running BFD session are= belong to different providers, So there should be some= specification on the interworking problem. I propose to add some= general description about this some like the following, When use OSPF as the BFD bootstrap mechanism, the method fo= demutipexing the initail packets is...... When use IS-IS as the BFD bootstrap mechanism, the method fo= demutipexing the initail packets is...... When use MPLS-Ping as the BFD bootstrap mechanism, the method= fo demutipexing the initail packets is...... Or the common TLV can be defined to these mechanism to= bootstrap BFD session. So I don't know if this is appropriate to the BFD base draft? Best Regards, zhaisuping@huawei.com Huawei Technologies Co., Ltd. Tel: +86-10-82882867 Fax: +86-10-82882537 2005-03-26 From rtg-bfd-bounces@ietf.org Sat Mar 26 01:56:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05702; Sat, 26 Mar 2005 01:56:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DF5JI-00014t-06; Sat, 26 Mar 2005 02:02:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DF5By-0007UB-LR; Sat, 26 Mar 2005 01:54:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DF5Bv-0007Tz-9V for rtg-bfd@megatron.ietf.org; Sat, 26 Mar 2005 01:54:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05634 for ; Sat, 26 Mar 2005 01:54:38 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DF5Hw-00012Y-Qo for rtg-bfd@ietf.org; Sat, 26 Mar 2005 02:00:54 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j2Q6s9959354; Fri, 25 Mar 2005 22:54:15 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2Q6s3e09619; Fri, 25 Mar 2005 22:54:03 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <0IDX00G7IX2LQZ@szxml01-in.huawei.com> References: <0IDX00G7IX2LQZ@szxml01-in.huawei.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <7a4b43d33a21cd43a3f80cbba38fef94@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Fri, 25 Mar 2005 23:54:01 -0700 To: zhaisuping@huawei.com X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: "'rtg-bfd@ietf.org'" , David Ward Subject: Re: some comment to draft-ietf-bfd-base-02.txt X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit On Mar 25, 2005, at 8:41 PM, zhaisuping wrote: > Dave2, > In the draft-ietf-bfd-base-02.txt, 6.3. (Demultiplexing and the > Discriminator Fields), it reads as following,　　 > > The method of demultiplexing the initial packets (in which Your > Discriminator is zero) is application-dependent, and is thus outside > the scope of this specification.　　 > > One problem is that when the two nodes running BFD session are belong > to different providers, So there should be some specification on the > interworking problem. I propose to add some general description about > this some like the following, > > When use OSPF as the BFD bootstrap mechanism, the method fo > demutipexing the initail packets is...... > When use IS-IS as the BFD bootstrap mechanism, the method fo > demutipexing the initail packets is...... > When use MPLS-Ping as the BFD bootstrap mechanism, the method fo > demutipexing the initail packets is...... > > Or the common TLV can be defined to these mechanism to bootstrap > BFD session. > > So I don't know if this is appropriate to the BFD base draft? This is all specified in the application drafts. --Dave From rtg-bfd-bounces@ietf.org Mon Mar 28 10:53:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29843; Mon, 28 Mar 2005 10:53:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFwfD-0000Qr-Gj; Mon, 28 Mar 2005 11:00:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFwXD-00064s-31; Mon, 28 Mar 2005 10:52:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFwXC-00064g-Ca for rtg-bfd@megatron.ietf.org; Mon, 28 Mar 2005 10:52:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29660 for ; Mon, 28 Mar 2005 10:52:07 -0500 (EST) Received: from paperclip.laurelnetworks.com ([63.94.127.69] ident=nobody) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFwdi-0000P2-Oc for rtg-bfd@ietf.org; Mon, 28 Mar 2005 10:58:55 -0500 Received: from notepad.laurelnetworks.com (notepad.laurelnetworks.com [63.94.127.20]) by paperclip.laurelnetworks.com (Laurel/Laurel) with ESMTP id j2SFq6MC005908; Mon, 28 Mar 2005 10:52:06 -0500 Received: from cnogradi-linux.dhcp.pit.laurelnetworks.com (cnogradi-linux.dhcp.pit.laurelnetworks.com [10.0.19.158]) by notepad.laurelnetworks.com (Laurel/Laurel) with ESMTP id j2SFq5Ae010044; Mon, 28 Mar 2005 10:52:06 -0500 From: Chris Nogradi Organization: Laurel Networks To: Dave Katz Date: Mon, 28 Mar 2005 10:50:52 -0500 User-Agent: KMail/1.6.2 References: <44467058B41F7E4CB6305769819D5E631DF274@SHERLOCK.pit.laurelnetworks.com> <973a61750f9f4883d5801b722a8d5958@juniper.net> In-Reply-To: <973a61750f9f4883d5801b722a8d5958@juniper.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503281050.53387.cnogradi@laurelnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: Reflections on new state machine X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Dave, Section 6.7.3 of the base draft requires a BFD implementation to send a poll flag when the required receive interval changes and it is in the up state. I would therefore suppose that in order to enforce that a peer is behaving properly, the local BFD session should ensure that it only allows interval changes to occur in the up state when the peer is sending a poll flag. If this is a valid assumption, I don't think I am comfortable with the relocation of the transmit interval update since it requires updating the transmit interval (which should be gated on the existence of the poll bit when the session is in the up state) before the current session state is evaluated. In addition to this, I am not sure a session that has been administratively disabled should continue to react to received packets. Thanks, Chris On Thursday 24 March 2005 12:37, Dave Katz wrote: > Here's what the text in that neighborhood should look like. Note that > the transmit interval update is moved before the state machine > mechanics; this ensures that a system in AdminDown state still pays > attention to the receive interval wishes of the remote system. > > ... > > Update the Detection Time as described in section 6.7.4. > > Update the transmit interval as described in section 6.7.2. > > If bfd.SessionState is AdminDown > Discard the packet > > If received state is AdminDown > If bfd.SessionState is not Down > Set bfd.LocalDiag to 3 (Neighbor signaled session down) > Set bfd.SessionState to Down > > Else > > If bfd.SessionState is Down > If received State is Down > Set bfd.SessionState to Init > Else if received State is Init > Set bfd.SessionState to Up > > Else if bfd.SessionState is Init > If received State is Init or Up > Set bfd.SessionState to Up > > Else (bfd.SessionState is Up) > If received State is Down > Set bfd.LocalDiag to 3 (Neighbor signaled session > down) > Set bfd.SessionState to Down > > If the Demand (D) bit is set and bfd.DemandModeDesired is 1, > and bfd.SessionState is Up, Demand mode is active. > > ... > > --Dave From rtg-bfd-bounces@ietf.org Mon Mar 28 12:40:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20736; Mon, 28 Mar 2005 12:40:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFyKw-0007ia-AC; Mon, 28 Mar 2005 12:47:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFyDp-0001RJ-9k; Mon, 28 Mar 2005 12:40:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFyDn-0001R8-LD for rtg-bfd@megatron.ietf.org; Mon, 28 Mar 2005 12:40:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20672 for ; Mon, 28 Mar 2005 12:40:12 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFyKI-0007hU-EN for rtg-bfd@ietf.org; Mon, 28 Mar 2005 12:47:01 -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 j2SHe3Bm032430; Mon, 28 Mar 2005 09:40:03 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j2SHe2e64194; Mon, 28 Mar 2005 09:40:03 -0800 (PST) (envelope-from dkatz@juniper.net) In-Reply-To: <200503281050.53387.cnogradi@laurelnetworks.com> References: <44467058B41F7E4CB6305769819D5E631DF274@SHERLOCK.pit.laurelnetworks.com> <973a61750f9f4883d5801b722a8d5958@juniper.net> <200503281050.53387.cnogradi@laurelnetworks.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <482eb70ff086324a34eb0502c089b66b@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Mon, 28 Mar 2005 10:40:01 -0700 To: Chris Nogradi X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: Reflections on new state machine X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit On Mar 28, 2005, at 8:50 AM, Chris Nogradi wrote: > Dave, > > Section 6.7.3 of the base draft requires a BFD implementation to send > a poll > flag when the required receive interval changes and it is in the up > state. I > would therefore suppose that in order to enforce that a peer is > behaving > properly, the local BFD session should ensure that it only allows > interval > changes to occur in the up state when the peer is sending a poll flag. See section 6: This section discusses the normative requirements of the protocol in order to achieve interoperability. It is important for implementors to enforce only the requirements specified in this section, as misguided pedantry has been proven by experience to adversely affect interoperability. In general tests like this are a bad idea. It is not the job of the local peer to enforce sanity in the remote peer; that's the job of the remote peer's software engineer. Further, the protocol has no mechanism for "ensuring" anything; notably there is no mechanism for tearing down a session when something "improper" happens, and this is purposeful, as it makes the protocol more robust. If an implementation doesn't do a Poll when changing the timing parameters, the worst that will happen is that the session will drop anyhow. It doesn't make the protocol go insane or become inconsistent or anything. The point of the poll/final sequence is to gain confidence that the remote system has heard the parameter change before actually changing the timing so that the session doesn't drop. In the case of the session not being Up, it makes no difference whether the sender uses Poll or not (and the receiver is always required to respond with Final, regardless of state.) An implementation could in fact send packets with Poll outside of Up state and nothing bad will happen (in fact, this is implicitly allowed by the spec.) > If > this is a valid assumption, I don't think I am comfortable with the > relocation of the transmit interval update since it requires updating > the > transmit interval (which should be gated on the existence of the poll > bit > when the session is in the up state) before the current session state > is > evaluated. Moving that line has no effect on the protocol other than to have the timing management apply when in AdminDown. > In addition to this, I am not sure a session that has been > administratively disabled should continue to react to received packets. This was exactly the point of the change. If I'm telling you I only want packets every 10 seconds, you should listen to me even in AdminDown. The two systems are still exchanging packets; it just means that the BFD session is not allowed to come up. --Dave