From lucillehillman@aol.com Fri Jul 2 00:19:58 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B9BF3A683E for ; Fri, 2 Jul 2010 00:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtwN1kZwROpY for ; Fri, 2 Jul 2010 00:19:57 -0700 (PDT) Received: from imr-da04.mx.aol.com (imr-da04.mx.aol.com [205.188.105.146]) by core3.amsl.com (Postfix) with ESMTP id 17AD33A6812 for ; Fri, 2 Jul 2010 00:19:57 -0700 (PDT) Received: from imo-ma03.mx.aol.com (imo-ma03.mx.aol.com [64.12.78.138]) by imr-da04.mx.aol.com (8.14.1/8.14.1) with ESMTP id o627Jt0Y032648 for ; Fri, 2 Jul 2010 03:19:55 -0400 Received: from lucillehillman@aol.com by imo-ma03.mx.aol.com (mail_out_v42.9.) id l.dac.eea4368 (43999) for ; Fri, 2 Jul 2010 03:19:51 -0400 (EDT) Received: from smtprly-dc02.mx.aol.com (smtprly-dc02.mx.aol.com [205.188.170.2]) by cia-dd06.mx.aol.com (v129.4) with ESMTP id MAILCIADD068-d2f34c2d9311136; Fri, 02 Jul 2010 03:19:50 -0400 Received: from webmail-d093 (webmail-d093.sim.aol.com [205.188.255.4]) by smtprly-dc02.mx.aol.com (v129.4) with ESMTP id MAILSMTPRLYDC022-d2f34c2d9311136; Fri, 02 Jul 2010 03:19:46 -0400 To: rtg-bfd@ietf.org Subject: Basic clarification on BFD session setup Date: Fri, 02 Jul 2010 03:19:45 -0400 X-MB-Message-Source: WebUI X-AOL-IP: 115.113.232.135 X-MB-Message-Type: User MIME-Version: 1.0 From: lucillehillman@aol.com Content-Type: multipart/alternative; boundary="--------MB_8CCE7CE151C1F53_7B0_27A29_webmail-d093.sysops.aol.com" X-Mailer: AOL Webmail 32213-STANDARD Received: from 115.113.232.135 by webmail-d093.sysops.aol.com (205.188.255.4) with HTTP (WebMailUI); Fri, 02 Jul 2010 03:19:45 -0400 Message-Id: <8CCE7CE15175C95-7B0-15468@webmail-d093.sysops.aol.com> X-AOL-SENDER: lucillehillman@aol.com X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 08:58:14 -0000 ----------MB_8CCE7CE151C1F53_7B0_27A29_webmail-d093.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" All, I have been looking into BFD drafts recently and have the following basic= queries. Would appreciate if someone could clarify. Firstly, the base draft states - "A session begins with the periodic, slow= transmission of BFD Control packets". My interpretation of this is that during session establishment,= the configured DesiredMinTxInterval and the transmit interval (max of Des= iredMinTx and RemoteMinRx) determined thereof will not be used. Instead so= me fixed default value that would result in a slow rate so as not to hog= the bandwidth, should be used. That is the actual negotiated transmit int= erval is actually used only after session establishment (UP state) for the= periodic transmission of BFD control packets. Is this right? Further from the bfd for mpls draft, it looks like the LSP ping echo reque= st is to be immediately replied by a BFD control packet without necessaril= y being sent on the next periodic transmission. This seems unlike the base= draft (as quoted above - slow "periodic" transmission). Or have I got thi= s wrong? Cheers Lucy ----------MB_8CCE7CE151C1F53_7B0_27A29_webmail-d093.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
All,
 
I have been looking into BFD drafts recently and have the following= basic queries. Would appreciate if someone could clarify.
 
Firstly, the base draft states - "A session begins with the periodic,= slow transmission of BFD Control
packets". My interpretation of this is that during session establishment,= the configured DesiredMinTxInterval and the transmit interval (max of Des= iredMinTx and RemoteMinRx) determined thereof will not be used. Instead so= me fixed default value that would result in a slow rate so as not to hog= the bandwidth, should be used. That is the actual negotiated transmit int= erval is actually used only after session establishment (UP state) for the= periodic transmission of BFD control packets. Is this right?
 
Further from the bfd for mpls draft, it looks like the LSP = ping echo request is to be immediately replied by a BFD control packe= t without necessarily being sent on the next periodic transmission. This= seems unlike the base draft (as quoted above - slow "periodic" transmissi= on). Or have I got this wrong?
 
Cheers
Lucy

 ----------MB_8CCE7CE151C1F53_7B0_27A29_webmail-d093.sysops.aol.com-- From lucillehillman@aol.com Fri Jul 2 02:20:42 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A314F3A685B for ; Fri, 2 Jul 2010 02:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.731 X-Spam-Level: X-Spam-Status: No, score=-1.731 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8X4shB4-yJdn for ; Fri, 2 Jul 2010 02:20:41 -0700 (PDT) Received: from imr-ma04.mx.aol.com (imr-ma04.mx.aol.com [64.12.206.42]) by core3.amsl.com (Postfix) with ESMTP id 16D193A689C for ; Fri, 2 Jul 2010 02:20:40 -0700 (PDT) Received: from imo-ma01.mx.aol.com (imo-ma01.mx.aol.com [64.12.78.136]) by imr-ma04.mx.aol.com (8.14.1/8.14.1) with ESMTP id o629KeCD017526 for ; Fri, 2 Jul 2010 05:20:40 -0400 Received: from lucillehillman@aol.com by imo-ma01.mx.aol.com (mail_out_v42.9.) id l.e8f.2c365e3 (37060) for ; Fri, 2 Jul 2010 05:20:35 -0400 (EDT) Received: from smtprly-da03.mx.aol.com (smtprly-da03.mx.aol.com [205.188.249.146]) by cia-db04.mx.aol.com (v129.4) with ESMTP id MAILCIADB046-5bbe4c2daf5f2d; Fri, 02 Jul 2010 05:20:35 -0400 Received: from webmail-d018 (webmail-d018.sim.aol.com [205.188.181.29]) by smtprly-da03.mx.aol.com (v129.4) with ESMTP id MAILSMTPRLYDA035-5bbe4c2daf5f2d; Fri, 02 Jul 2010 05:20:31 -0400 References: <8CCE7CE2F5E3F4B-7B0-15484@webmail-d093.sysops.aol.com> To: rtg-bfd@ietf.org Subject: Basic clarification on BFD session setup Date: Fri, 02 Jul 2010 05:20:31 -0400 X-AOL-IP: 115.113.232.135 In-Reply-To: <8CCE7CE2F5E3F4B-7B0-15484@webmail-d093.sysops.aol.com> X-MB-Message-Source: WebUI MIME-Version: 1.0 From: lucillehillman@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CCE7DEF4339B85_F90_173E7_webmail-d018.sysops.aol.com" X-Mailer: AOL Webmail 32213-STANDARD Received: from 115.113.232.135 by webmail-d018.sysops.aol.com (205.188.181.29) with HTTP (WebMailUI); Fri, 02 Jul 2010 05:20:31 -0400 Message-Id: <8CCE7DEF42ED8C1-F90-C387@webmail-d018.sysops.aol.com> X-AOL-SENDER: lucillehillman@aol.com X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 09:20:42 -0000 ----------MB_8CCE7DEF4339B85_F90_173E7_webmail-d018.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" All, =20 I have been looking into BFD drafts recently and have the following basic= queries. Would appreciate clarification. =20 Firstly, the base draft states - "A session begins with the periodic, slow= transmission of BFD Control packets". My interpretation of this is that during session establishment,= the configured DesiredMinTxInterval and the transmit interval (max of Des= iredMinTx and RemoteMinRx) determined thereof will not be used. Instead so= me fixed default value that would result in a slow rate so as not to hog= the bandwidth, should be used. That is the actual negotiated transmit int= erval is actually used only after session establishment (UP state) for the= periodic transmission of BFD control packets. Is this right? =20 Further from the bfd for mpls draft, it looks like the LSP ping echo reque= st is to be immediately replied by a BFD control packet without necessaril= y being sent on the next periodic transmission. This seems unlike the base= draft (as quoted above - slow "periodic" transmission). Or have I got thi= s wrong? =20 Cheers Lucy ----------MB_8CCE7DEF4339B85_F90_173E7_webmail-d018.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
All,
 
I have been looking into BFD drafts recently and have the following= basic queries. Would appreciate clarification.
 
Firstly, the base draft states - "A session begins with the periodic,= slow transmission of BFD Control
packets". My interpretation of this is that during session establishment,= the configured DesiredMinTxInterval and the transmit interval (max of Des= iredMinTx and RemoteMinRx) determined thereof will not be used. Instead so= me fixed default value that would result in a slow rate so as not to hog= the bandwidth, should be used. That is the actual negotiated transmit int= erval is actually used only after session establishment (UP state) for the= periodic transmission of BFD control packets. Is this right?
 
Further from the bfd for mpls draft, it looks like the LSP = ping echo request is to be immediately replied by a BFD control packe= t without necessarily being sent on the next periodic transmission. This= seems unlike the base draft (as quoted above - slow "periodic" transmissi= on). Or have I got this wrong?
 
Cheers
Lucy

 ----------MB_8CCE7DEF4339B85_F90_173E7_webmail-d018.sysops.aol.com-- From dkatz@juniper.net Fri Jul 2 10:26:41 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 577F728C140 for ; Fri, 2 Jul 2010 10:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.431 X-Spam-Level: X-Spam-Status: No, score=-4.431 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07NbP0+jNoVu for ; Fri, 2 Jul 2010 10:26:40 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 1D40828C11D for ; Fri, 2 Jul 2010 10:26:40 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTC4hW6dXCZFRUuRxepTO5kCHMDsTB5qX@postini.com; Fri, 02 Jul 2010 10:26:52 PDT Received: from p-emfe03-sac.jnpr.net (66.129.254.75) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server id 8.2.254.0; Fri, 2 Jul 2010 10:25:30 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe03-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Jul 2010 10:25:29 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Jul 2010 10:25:29 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Jul 2010 10:25:28 -0700 Received: from nimbus-bsr.juniper.net (nimbus-bsr.juniper.net [172.16.12.201]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o62HPSb53243; Fri, 2 Jul 2010 10:25:28 -0700 (PDT) (envelope-from dkatz@juniper.net) Subject: Re: Basic clarification on BFD session setup MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary="Apple-Mail-71--863382630" From: Dave Katz In-Reply-To: <8CCE7CE15175C95-7B0-15468@webmail-d093.sysops.aol.com> Date: Fri, 2 Jul 2010 10:25:27 -0700 Message-ID: <8FD10B9C-1392-445E-9587-5A6457317C5E@juniper.net> References: <8CCE7CE15175C95-7B0-15468@webmail-d093.sysops.aol.com> To: X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 02 Jul 2010 17:25:28.0677 (UTC) FILETIME=[90D10150:01CB1A0B] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 17:26:41 -0000 --Apple-Mail-71--863382630 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Jul 2, 2010, at 12:19 AM, lucillehillman@aol.com wrote: > All, > =20 > I have been looking into BFD drafts recently and have the following = basic queries. Would appreciate if someone could clarify. > =20 > Firstly, the base draft states - "A session begins with the periodic, = slow transmission of BFD Control > packets". My interpretation of this is that during session = establishment, the configured DesiredMinTxInterval and the transmit = interval (max of DesiredMinTx and RemoteMinRx) determined thereof will = not be used. Instead some fixed default value that would result in a = slow rate so as not to hog the bandwidth, should be used. That is the = actual negotiated transmit interval is actually used only after session = establishment (UP state) for the periodic transmission of BFD control = packets. Is this right? Yes. There is more formal language in the normative part of the spec = that defines this process more precisely. > =20 > Further from the bfd for mpls draft, it looks like the LSP ping echo = request is to be immediately replied by a BFD control packet without = necessarily being sent on the next periodic transmission. This seems = unlike the base draft (as quoted above - slow "periodic" transmission). = Or have I got this wrong? The point of the bootstrapping process is that there is no way to send = BFD packets before the LSP Ping arrives, so there isn't any periodic = transmission happening. The arrival of the Ping triggers the creation = of the session, and the periodicity starts at that point. Having said that, this is an implementation decision. The fact is that = there will always be latency between the time a system sends a Ping and = the time it eventually sees a BFD packet from the other end. Whether = that latency is due to an implementation taking its time sending the = first packet or because of interplanetary packet delays cannot be = determined. "Immediately" is a rather nebulous concept in networking. = In the cases in the BFD base spec where an "extra" packet is to be = returned (ignoring the negotiated interval), the point is to speed the = BFD state machine along. For that matter, the "extra" packet could be = lost in flight, so the correctness of the protocol can never rely on = anything happening "immediately" or "as soon as practicable" or "post = haste"--it's an optimization. --Dave --Apple-Mail-71--863382630 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" lucillehillman@aol.com = wrote:
All,
 
I have been looking into BFD drafts recently and have the following = basic queries. Would appreciate if someone could clarify.
 
Firstly, the base draft states - "A session begins with the = periodic, slow transmission of BFD Control
packets". My interpretation of this is that during session = establishment, the configured DesiredMinTxInterval and the transmit = interval (max of DesiredMinTx and RemoteMinRx) determined thereof will = not be used. Instead some fixed default value that would result in a = slow rate so as not to hog the bandwidth, should be used. That is the = actual negotiated transmit interval is actually used only after session = establishment (UP state) for the periodic transmission of BFD control = packets. Is this right?

Yes. =  There is more formal language in the normative part of the spec = that defines this process more precisely.

 
Further from the bfd for mpls draft, it looks like the = LSP ping echo request is to be immediately replied by a BFD = control packet without necessarily being sent on the next periodic = transmission. This seems unlike the base draft (as quoted above - slow = "periodic" transmission). Or have I got this = wrong?

The point of the = bootstrapping process is that there is no way to send BFD packets before = the LSP Ping arrives, so there isn't any periodic transmission = happening.  The arrival of the Ping triggers the creation of the = session, and the periodicity starts at that = point.

Having said that, this is an = implementation decision.  The fact is that there will always be = latency between the time a system sends a Ping and the time it = eventually sees a BFD packet from the other end.  Whether that = latency is due to an implementation taking its time sending the first = packet or because of interplanetary packet delays cannot be determined. =  "Immediately" is a rather nebulous concept in networking.  In = the cases in the BFD base spec where an "extra" packet is to be returned = (ignoring the negotiated interval), the point is to speed the BFD state = machine along.  For that matter, the "extra" packet could be lost = in flight, so the correctness of the protocol can never rely on anything = happening "immediately" or "as soon as practicable" or "post = haste"--it's an = optimization.

--Dave

<= /html>= --Apple-Mail-71--863382630-- From glen.kent@gmail.com Fri Jul 2 17:44:07 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163853A68C7 for ; Fri, 2 Jul 2010 17:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=1.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZjZRWMMT8YJ for ; Fri, 2 Jul 2010 17:44:06 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 27B2C3A68BD for ; Fri, 2 Jul 2010 17:44:06 -0700 (PDT) Received: by gxk3 with SMTP id 3so103238gxk.31 for ; Fri, 02 Jul 2010 17:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=jT2V/Juc0kLwlRD7LjR4wvmrmHygxc8G4rvpta12Rrw=; b=C10wafjix2tinVTPHFnzGxeSmRWnezZaPtswW74uMKWVquvVKQBKUQ3g7YIYsny//8 Q2YwDzdWnLljIiTC43ZqiOTx3E7jdhmNN08bc0dqL9gxZBXtDAm6IInTyhMCb8nc2R78 P0a0TysIxxEsDzZeXHeFZ4ksrOFsN+OkHz7Ao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=BbfW9cwkQqcMaPz+8pX9RUXrzPCFGOwcO8u+dPmegjhjgHL7iqubZuxcTEBePoqhqD pDa0/nK6f5q3fVl+FJuFx+gbyhL6//I8rx5wFHq6vsxcE7ncYxaKVxCvR54mgA9IB2Gi yP8ypKAtwzP8Er74ehGbZs5u7SLkbf4Xrt+eE= MIME-Version: 1.0 Received: by 10.100.32.19 with SMTP id f19mr1433147anf.87.1278117854667; Fri, 02 Jul 2010 17:44:14 -0700 (PDT) Received: by 10.100.11.12 with HTTP; Fri, 2 Jul 2010 17:44:14 -0700 (PDT) Date: Sat, 3 Jul 2010 06:14:14 +0530 Message-ID: Subject: Min TX Interval From: Glen Kent To: rtg-bfd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 00:44:07 -0000 Hi, What is the standard default Tx interval for BFD packets? 50ms? Are there implementations that are going lower than this? Given that the usual desired value for MPLS FRR should be sub 50ms, BFD timeouts should be less than that, which would mean that BFD timeouts should be in O(10)ms. Are there any implementations that give TX rates in microseconds? Thanks, Glen From dkatz@juniper.net Fri Jul 2 18:26:40 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6696F3A67CC for ; Fri, 2 Jul 2010 18:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.438 X-Spam-Level: X-Spam-Status: No, score=-5.438 tagged_above=-999 required=5 tests=[AWL=1.161, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+Cx77Vx0TSX for ; Fri, 2 Jul 2010 18:26:39 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 34C333A659B for ; Fri, 2 Jul 2010 18:26:39 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTC6R2ugid2UZLzeAn+Q4jBEWZcc/59ll@postini.com; Fri, 02 Jul 2010 18:26:51 PDT Received: from p-emfe02-sac.jnpr.net (66.129.254.73) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server id 8.2.254.0; Fri, 2 Jul 2010 18:24:30 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Jul 2010 18:24:30 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Jul 2010 18:24:29 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Jul 2010 18:24:29 -0700 Received: from nimbus-bsr.juniper.net (nimbus-bsr.juniper.net [172.16.12.201]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o631OQb64242; Fri, 2 Jul 2010 18:24:27 -0700 (PDT) (envelope-from dkatz@juniper.net) Subject: Re: Min TX Interval MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Dave Katz In-Reply-To: Date: Fri, 2 Jul 2010 18:24:24 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <31D36D2F-EC3D-4A0D-8B9C-9FDAE4E35789@juniper.net> References: To: Glen Kent X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 03 Jul 2010 01:24:29.0270 (UTC) FILETIME=[7B8B7760:01CB1A4E] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 01:26:40 -0000 There is no "standard default" since appropriate values are highly = dependent on the application and the context. There are implementations that operate in the O(10) msec range. There are implementations for which the configurations are in = microseconds, but this has no bearing on how fast they can actually run. --Dave On Jul 2, 2010, at 5:44 PM, Glen Kent wrote: > Hi, >=20 > What is the standard default Tx interval for BFD packets? 50ms? >=20 > Are there implementations that are going lower than this? Given that > the usual desired value for MPLS FRR should be sub 50ms, BFD timeouts > should be less than that, which would mean that BFD timeouts should be > in O(10)ms. Are there any implementations that give TX rates in > microseconds? >=20 > Thanks, > Glen >=20 From jhaas@slice.pfrc.org Wed Jul 7 09:32:57 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C6D53A686A for ; Wed, 7 Jul 2010 09:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EtjmHomp8P5 for ; Wed, 7 Jul 2010 09:32:56 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 5FE6E3A6859 for ; Wed, 7 Jul 2010 09:32:56 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C086722415A; Wed, 7 Jul 2010 16:32:59 +0000 (UTC) Date: Wed, 7 Jul 2010 16:32:59 +0000 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Call for agenda items for IETF 78 Message-ID: <20100707163259.GB31766@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 16:32:57 -0000 We will be meeting at IETF 78 in Maastricht. We have a short session planned, 1 hour. If you'd like an timeslot for the session, please mail Dave and I. -- Jeff and Dave From root@core3.amsl.com Thu Jul 8 18:00:01 2010 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7890B3A699C; Thu, 8 Jul 2010 18:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-bfd-mib-10.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100709010001.7890B3A699C@core3.amsl.com> Date: Thu, 8 Jul 2010 18:00:01 -0700 (PDT) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 01:00:01 -0000 --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 Management Information Base Author(s) : T. Nadeau, et al. Filename : draft-ietf-bfd-mib-10.txt Pages : 35 Date : 2010-07-08 This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-mib-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-bfd-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-08175803.I-D@ietf.org> --NextPart-- From nobo@cisco.com Thu Jul 8 18:04:25 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0BD03A69A3 for ; Thu, 8 Jul 2010 18:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHlbZx8pyo6G for ; Thu, 8 Jul 2010 18:04:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 83D003A698C for ; Thu, 8 Jul 2010 18:04:24 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4GANYSNkyrR7Hu/2dsb2JhbACTdYw/caV8mlKFJQSDeYZ2 X-IronPort-AV: E=Sophos;i="4.53,561,1272844800"; d="scan'208";a="556346551" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 09 Jul 2010 01:04:29 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6914Tga013100 for ; Fri, 9 Jul 2010 01:04:29 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Jul 2010 18:04:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D Action:draft-ietf-bfd-mib-10.txt Date: Thu, 8 Jul 2010 18:04:27 -0700 Message-ID: In-Reply-To: <20100709010001.7890B3A699C@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-bfd-mib-10.txt Thread-Index: AcsfAi/urXqgZbbkTMiQCSKPeRpEagAAGJKA References: <20100709010001.7890B3A699C@core3.amsl.com> From: "Nobo Akiya (nobo)" To: X-OriginalArrivalTime: 09 Jul 2010 01:04:29.0008 (UTC) FILETIME=[AE9C8500:01CB1F02] X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 01:04:25 -0000 Folks, draft-ietf-bfd-mib-10 has been submitted. This revision references draft-ietf-bfd-tc-mib. Unfortunately TC MIB cannot be submitted until the gate opens up for -00 draft submissions. For the time being, please find draft-ietf-bfd-tc-mib-00 at this location. http://dl.dropbox.com/u/8862348/draft-ietf-bfd-tc-mib-00.txt Regards, Nobo P.S. Manav, Vishwas, multi-keyed authentication is not included in this revision, but it has not been forgotten =3D) > -----Original Message----- > From: rtg-bfd-bounces@ietf.org=20 > [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: Friday, July 09, 2010 10:00 AM > To: i-d-announce@ietf.org > Cc: rtg-bfd@ietf.org > Subject: I-D Action:draft-ietf-bfd-mib-10.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Bidirectional Forwarding=20 > Detection Working Group of the IETF. >=20 >=20 > Title : BFD Management Information Base > Author(s) : T. Nadeau, et al. > Filename : draft-ietf-bfd-mib-10.txt > Pages : 35 > Date : 2010-07-08 >=20 > This draft defines a portion of the Management Information=20 > Base (MIB) for use with network management protocols in the=20 > Internet community. > In particular, it describes managed objects for modeling=20 > Bidirectional Forwarding Detection (BFD) protocol. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-bfd-mib-10.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 From Adrian.Farrel@huawei.com Tue Jul 13 08:55:33 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D9C3A697D for ; Tue, 13 Jul 2010 08:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xgH2PXepWfB for ; Tue, 13 Jul 2010 08:55:33 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id E83253A68DE for ; Tue, 13 Jul 2010 08:55:32 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5I000MP6WTAT@usaga01-in.huawei.com> for rtg-bfd@ietf.org; Tue, 13 Jul 2010 08:55:41 -0700 (PDT) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5I00DMN6WRCI@usaga01-in.huawei.com> for rtg-bfd@ietf.org; Tue, 13 Jul 2010 08:55:41 -0700 (PDT) Date: Tue, 13 Jul 2010 16:55:34 +0100 From: Adrian Farrel Subject: IETF Last Cal on draft-ietf-isis-bfd-tlv To: rtg-bfd@ietf.org Message-id: <84D91C68AF664CF781388934F79EC5C6@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 15:55:33 -0000 Hi BFD WG, Please be aware of this IETF last call that relates to BFD and please make any comments you have as part of the last call process. Thanks, Adrian ----- Original Message ----- From: "The IESG" To: "IETF-Announce" Cc: Sent: Monday, July 12, 2010 7:40 PM Subject: Last Call: draft-ietf-isis-bfd-tlv (IS-IS BFD Enabled TLV) toProposed Standard > The IESG has received a request from the IS-IS for IP Internets WG (isis) > to consider the following document: > > - 'IS-IS BFD Enabled TLV ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2010-07-26. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-isis-bfd-tlv-02.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17118&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From jhaas@slice.pfrc.org Mon Jul 19 06:55:41 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E467F3A6B12 for ; Mon, 19 Jul 2010 06:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+0f6RyNdhtV for ; Mon, 19 Jul 2010 06:55:41 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 34AD03A6AF2 for ; Mon, 19 Jul 2010 06:55:41 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8F49B22414B; Mon, 19 Jul 2010 13:55:55 +0000 (UTC) Date: Mon, 19 Jul 2010 13:55:55 +0000 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Final call for agenda items for IETF 78 Message-ID: <20100719135555.GE14488@slice> References: <20100707163259.GB31766@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100707163259.GB31766@slice> User-Agent: Mutt/1.5.18 (2008-05-17) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 13:55:42 -0000 We will be meeting at IETF 78 in Maastricht. We have a short session planned, 1 hour. If you'd like an timeslot for the session, please mail Dave and I. -- Jeff and Dave From jhaas@slice.pfrc.org Fri Jul 23 08:25:09 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83FF63A67E6 for ; Fri, 23 Jul 2010 08:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVUjP60zX6a1 for ; Fri, 23 Jul 2010 08:25:08 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id ABE663A68CF for ; Fri, 23 Jul 2010 08:25:08 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 18A5C224168; Fri, 23 Jul 2010 15:25:27 +0000 (UTC) Date: Fri, 23 Jul 2010 15:25:27 +0000 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Looking for scribes for the upcoming IETF session Message-ID: <20100723152526.GL14488@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 15:25:09 -0000 In the interest of keeping our session moving along smoothly, it would be very helpful to have a scribe for the WG session prior to the session actually starting. This would let us focus on meeting content rather than WG session overhead. Please let Dave or I know if you're willing to volunteer. -- Jeff From jhaas@slice.pfrc.org Wed Jul 28 02:26:25 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03B9528C138 for ; Wed, 28 Jul 2010 02:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBsRfdsRqSnU for ; Wed, 28 Jul 2010 02:26:23 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id AF8E43A6A2A for ; Wed, 28 Jul 2010 02:26:23 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A2C0C22437B; Wed, 28 Jul 2010 09:26:46 +0000 (UTC) Date: Wed, 28 Jul 2010 09:26:46 +0000 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Draft Minutes from IETF 78, Maastricht Message-ID: <20100728092646.GA9998@slice> References: <5E893DB832F57341992548CDBB33316398450B3F0F@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E893DB832F57341992548CDBB33316398450B3F0F@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 09:26:25 -0000 Thanks to Dave Ward for capturing minutes. Please submit additions or corrections before Wednesday, September 1. --- Draft minutes for BFD working group session, IETF 78, July 2010, Maastrict: Co-Chairs: David Ward Jeffrey Haas Agenda: Document status Charter Discussion BFD for Multipoint Networks draft-katz-ward-bfd-multipoint-02.txt (expired) BFD Generic Cryptographic Authentication draft-bhatia-bfd-crypto-auth-02 BFD for MPLS-TP (one-way bfd) George Swallow Presentations are posted on the IETF 78 meeting materials site: https://datatracker.ietf.org/meeting/78/materials.html --- Document Status (Chairs): Original working group charter largely accomplished with the exception of the MIB. The MIB is mostly done but may receive updates based on possible new WG charter items. We would like input from people interested in a BFD-MPLS MIB to please contact the mailing list. The goal is to not re-write the BFD MIB once published to update for MPLS if necessary. --- Charter Discussion (Chairs): WG should take on a stewardship role on the BFD protocol and not shutdown. This includes reserving changes to the core BFD protocol to the working group. Stewardship would involve providing guidance and review of BFD application documents in other group. This is similar to role that IDR has for BGP protocol. Possible new WG tasks: Point to Multi-Point BFD Generic Cryptographic Authentication DHCP extensions to configure BFD (not presented) [Addendum after last presentation, BFD for MPLS-TP. Need to decide if this a profile of existing BFD or a new version.] ---------- BFD for Multipoint Networks (Dave Ward) Dave covered p2mp draft no questions. See presentation. ---------- BFD Generic Cryptographic Authentication (Jeff Haas for Manav and Vishwas) Jeff presented auth draft for Manav and Vishwas. See presentation. Discussion: Gregory: Anyone implemented authentication in BFD? No Anyone ever heard of anyone ever ask for stronger authentication? Lou Berger: We want all of our control protocols to have security features. Ruediger Volk (DT): Priorities have not caused an analysis for a need for auth/crypto on BFD. Nabil Bitar: Always have had requirement for authentication in BFD. Doesn't appear to be interoperable Kireeti Kompella: "To operators ... do the IGPs run with auto?" Yes! "Now given BFD can take down IGP ... do you trust your BFD implementation?" RV: Priorities and timing and availability of product across product lines JH: The primary point of the doc is key roll over. Concern with requiring the MUST for SHA-2 in the draft is that it will make people wanting to implement rollover but not SHA-2 non-compliant. Causes problems with Requests for Proposals (RFPs). Shane Amante: The "good enough" to get things going. There is low order security techniques, ACLs, TTL check, etc.. These are good enough that it can be deployed in the network. SHA-2 is overkill for what is largely needed. Key roll over is not strictly a requirement but, a Nice To Have. Nabil: This is also a Chicken and egg problem ... BFD solves lack of failure notification at lower layer so BFD is only mechanism. Therefore use what you have. From a security point of view, people want him to run everything over IPsec. P2P or P2MP isn't the issue. It is Multi-hop BFD that probably needs crypto first. Room poll to adopt this draft as a WG item: Adopt? 6 Any objections? 1 Question to the room from Jeff: Current draft has SHA-2 as a MUST, change to SHOULD? 3 Leave as MUST? 1 Final comment from Gregory: Security ADs probably won't approve the draft without a MUST. ---------- BFD for MPLS-TP (George Swallow): Presented Simplified BFD procedures for bi-dir LSPs for MPLS OAM. See presentation. Early question: In BFD WG or MPLS? Dave Ward: TP OAM requirements state auth must be possible. Rob Reneson: Why change the slow start refresh mechanism from what it is in the draft? Why not leave it? George Swallow: So, base spec is changing even if minor Jeff Haas: If a profile requires changes to the state machine and other behaviors with BFD v1, will you address how to make it interoperable? Dave Ward: Adrian, has this gone through the MPLS change process? Adrian: We've lost track if one of those requirements has actually followed the MPLS change process. Push for technical change. Dave Ward/Jeff Haas: Can we make this backward compatible? Jeff Haas: To solve Poll/Final (P/F) issue send diag if see P/F George Swallow: P/F has issues of not timing out during init state, which is a change from BFD v1. Dave Allan: In current version, we had means of identifying independent mode (via tx rate of 0) DW: See P2MP for overloading semantics of certain values Adrian: How about adding source? Room poll to adopt work on BFD for MPLS-TP as a WG item: Adopt? 8 Objections? 2